it sounds like the PIC compilers you are speaking of don't even do dead code
removal. Take a look at JAL it has limitations sure but in general even
simple programs include hundreds of lines of files (I think my "flash an
led" program included something like 1500 lines from various libaries) the
end product is something on the order of 130 bytes, and you want to know the
best thing? I dont even really know how it works ;->. I could find out by
reading the lib's etc but I don't have to if I don't want to.
As for knocking VB, I have used it to make a program that interfaced with a
mysql database to run almost all aspects of a telecomunications company in
around a day. From tracking faults through to resolution, "Instant
Messaging" between staff, Billing customers, checking wholesale rates, stock
managment, sales person "managment" and a whole heap of other stuff. Point
is unless you were some godlike C coder there is no way you could have done
that in a day and make it look nice to the users. VB has its place C has its
place. Get over it.
----- Original Message -----
From: "Herbert Graf"
To:
Sent: Saturday, June 21, 2003 11:12 AM
Subject: Re: [PIC] My version of visual programming
> > Sorry but I cannot agree.Your assertion that visual design leads
> > to bloat is
> > only true because the tools or the users of the tools are crap.
> >
> > Some of the tools available require that users build everything from the
> > most primitive component right up to what they really wanted in the
first
> > place.
> >
> > It's like a user trying to build a circuit with a solderless breadboard
> > being told that each of the chip he wants to use must in turn be built
on
> > their own boards with other chips, and doing this recursively until he
> > finally reaches discreet transistors.
> >
> > The visual design concept is not the issue.
>
> OK, concede the point that the visual design concept is not the
only issue,
> however EVERY example of visual design I've seen has been fraught with the
> bloat problem, so it seems that no one has figured out (or simply hasn't
> bothered trying) how NOT to get bloat.
>
> > >
> > > Personally even going to C might create more bloat than it's worth.
> >
> > But again this depends on the quality of the tool (the C compiler and
> > linker) and the user of the tools. Typically these days a good C
> > programmer
> > can get to within 90% of the code produced by a good assembler
programmer.
> > When I think of bloat I normally think of a generated app that is
hundreds
> > of times bigger than it needs to be not 10%
>
> Not really. With C there is automatic "close to assembly" in the
design of
> the language (which isn't a coincidence, that's what C was originally
> created to be), that is why some find it so hard to understand, you have
to
> think more like an assembly language programmer then with other HLL tools
> (i.e. VB, which should be stricken from the planet, but I digress...)
>
> > > By decreasing the complexity of development you are most
> > > definitely giving something up. And in many cases one of the
> > things you are
> > > giving up is efficiency. TTYL
> >
> > Again I disagree. Let's say you hired a consultant to build you several
> > systems that could be configured, possibly even used together. Let's
also
> > say that this consultant is a genius, that he spends a great deal of
time
> > building many versions of each function (together with
> > conditional assembly
> > where appropriate) so that they are optimised for use in different
> > combinations. Now you would expect a really cool bloat free result.
>
> I agree that sort of system is possible, where I disagree is the
existence
> of this sort of product, the amount of work needed to do this far
outweighs
> the gains, which is why this sort of extreme optimization is rarely seen.
>
> > Now imagine that the consultant also builds you a sophisticated
> > menu driven
> > configuration system so that it automatically configures the
> > systems for you
> > and builds the executable code. This way it is not possible for you to
> > configure the system incorrectly and obtain bloated code. Also
development
> > complexity for the user of this tool has been greatly reduced.
> > Now instead of a
> > menu configuration system imagine that you are allowed to
> > configure the system
> > by dragging and dropping components onto a diagram and connect them with
> > graphical lines between specialised points on each component (kind of
like
> > wiring the pins of ICs together). This is what visual programming
> > should be
> > like. You should be able to pick up a printout and instantly see
> > how the system
> > is configured.
>
> Interesting example, but I think you've limited things to much.
Consider
> this: what happens if I want a system with a subset of the features the
> person created? That's the issue with many visual programming
environments.
> As an very simple crude quickie example, consider printf. Printf is a very
> complicated routine. When I use it in a typical compiler what happens? THE
> WHOLE routine is brought in. Even if I only use it once, to print a single
> number, the whole routine, with all it's vast features, that I don't need,
> are brought it. Now I know that this is exactly what you are taking about:
> optimizing things so that only the needed parts of printf are introduced,
> but I have yet to see one compiler that does this.
>
> All in all you make many interesting points, but from the real
world view I
> have never seen a visual tool that didn't heavily add bloat. Heck, just a
> "hello world" type program on windows using a visual tool results in a
100k
> executable and several required DLL, total size over 2MB. A visual tool
CAN
> be made as bloat free as possible, but I've never seen one. TTYL
>
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu
--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu