more intuitive visual interface

[John Gluck]

Hi All

There are obviously several ways of looking at things and I don't think that there's a one size fits all
answer to this discussion. It is important to to look at specific needs and environments befroe choosing
a particular set of tools. Once the tools are chosen, it is usually because it's a best fit and not a
perfect fit.

The real point I was trying to make is that there is a danger in too much abstraction. In cases like
Visual Basic where you use drag and plop, IMHO, your not really doing programming. You're essentially
just stacking up lego blocks. When someone who has only learned this type of "programming" is faced with
a real programming task, he falls flat or has quite a learning curve ahead of him.

I use existing libraries when they make sense. But I can easily write my own code in C, C++ and
assembler  as well as other languages when the need arises.

Some of the points made by Juergen are quite true. They also point out that there are different needs
requiring different tools and different skills. I don't think the need for very skilled programmers will
go away. On the other hand there is also a use for people who can skillfully pile up lego blocks
although I wouldn't call then programmers.

The difference between embedded systems and workstations is remarkable. In  embedded systems, code is
staticly linked and shared libraries are not used. In small embedded systems, there is no device from
which to load code. In large embedded systems, there may be a disk drive or a flash disk from which to
load but code is usually not loaded dynamically. In either case, system resources are much more limited
than on a workstation. There is a marked difference in programming techniques for embedded systems
compared to workstations. This is especially true when you are trying to make high availablility
embedded systems for process control and communications.

This debate doesn't have one correct answer. It has many answers that are defined by the problem space
being addressed.

John

Juergen Suessmaier wrote:

> > > If you wrote a MyListBox that only had functionality that you need,
> > > it would likely be smaller.
> >
> > I see, yes, I did misunderstand that.
> Ok, that's correct from a single program's point of view and only if
> code size is really an issue. It _is_ an issue for example on small
> embedded systems where you've got a certain amount of EPROM space
> into which you have to fit your program. If your code is larger then
> you've got a real problem.
>
> On the other hand when writing software for "regular" workstation
> users, the philosophy of highly optimized code won't work that well
> in practice. If you've got some real powerful libraries like Qt, which
> in addition is used as a shared lib by a lot of programs, then you'll
> get (and in fact your do get) double benefit. First you speed up development
> drastically by using common well tested shared libraries -even if they
> provide a lot more code than your specific application will use, and
> second you'll preserve a reasonable amount of memory as these shared
> libs are loaded only once. Just assume each KDE tool and KDE itself
> used it's own optimized container or widget classes, then you'd have
> dozens of implementations basically doing the same job. I think it is
> somewhat guaranteed that dozens of those classes take much more memory
> and disk space than one single general purpose "bloated" one does. So
> in fact you do preserve memory resources plus you'll save hours and days
> of implementation, debugging and testing time in this case.
>
> > > Especially if it were based upon your own generic classes. I'm not
> > > saying Qt is bad I'm just saying that
> > > it will tend to produce larger binaries than stuff that's home grown
> > > lean and mean.
> >
> > Like  Gtk+? Hey, just kidding... :-)
> Well, it always depends on the environment - see above. The multithreaded
> lib of Qt 2.3 needs about 5 Meg of memory. If you are running a single
> application under a non-KDE window manager, the statement is true without
> any doubt. Even a "do nothing" Qt application will load this shared lib
> into memory - very expensive for this case. But if your application runs
> within a "normal" KDE environment, each other KDE app will just use this
> once loaded lib - as well as KDE itself...
>
> > > I think he was trying to say the empolyee was incompetent. Your
> > > second sentence above insinuates that
> > > the writer of the post is also incompetent. My impression is that he
> > > is at least fairly competent.
> >
> > No no, I apologize sincerely if that is the way my statement was
> > understood. I am in no way to make any judgements about the original
> > posters competence whatsoever. What I was meaning to say was, that the
> > *employer* seems to be fairly unreliable, firing people for something
> > that is so simple to fix. The person in question had already shown the
> > ability to learn something, so why not retrain him to teach him what
> > pointers to functions are, that concept is really not difficult to
> > understand, no reason to fire someone.
> Well, business is sometimes somewhat tough :-( In times where a lot of
> software guys apply for a single job, the "hire and fire" method will
> match the business interests quite well. If you can get an experienced
> developer for the same money as you'd have to pay for a newbie, then
> it would be quite stupid (from the management's point of view) not to
> hire the expert. In times where it is really hard to find experts, it
> would be stupid to fire the newbie - assuming that he is willing to and
> able to learn new things. This is the short-term view of business. Long
> term it could be better to train the newbie until he matches the requirements
> as this also enforces the employee's loyality towards the company.
> Probably a weak assumption but I personally do also count on an employee
> as a human being as I think it makes a big difference between having
> people who feel responsible and are part of the company and those
> people who just sell a fixed amount of time. Of course this all depends
> on how critical your business actually is, but also less experienced
> folks can do great jobs - for example by supporting your gurus in helping
> them do the less interesting but simpler parts of the project(s). This
> could also give advantages as the highly experienced folks can concentrate
> on the "hard" parts while the newbies doing the "boring" stuff (which
> isn't that much boring from their point of view). That way you could
> save expensive expert resources and you'll educate the people who will
> become the experts one year or two later.
>
> Well, again, this is basically a matter of mentality, philosophy and
> of course economic environment.
>
> Best regards,
> Juergen
> --
> -------------------------------------------------------------------------
> J. Süßmaier Systementwicklungen
> Jürgen Süßmaier
> juergen at suessmaier.de                       Realtime Software Development
> Katharina Geisler Str. 14                       Embedded Applications
> D-85356 Freising                                     Automation
> Germany
> -------------------------------------------------------------------------
>                       http://www.suessmaier.de
> -------------------------------------------------------------------------
>       The day Microsoft makes something that doesn't suck is
>         probably the day they start making vacuum cleaners
> -------------------------------------------------------------------------
>
> -
> to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
> unsubscribe »your-email-address«


-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«