[Qt-interest] Are there any disadvantages with OT

[Jeffrey Brendecke]

> There's a difference between having the skills to find out and needing
> prerequisite knowledge of internals before using them.  We'd all be in lost
> if we needed to know how an engine converted fuel into power before driving
> a car.  [ . . . ]
I have heard this comparison from the commercial software industry many times 
before. It is one of those things that superficially sound self-evident but 
in reality it is a completely invalid comparison.

What the statement here is really comparing is learning how to refine copper 
and silicon before learning how to use (not design) a program. You are not 
talking about driving a car but rather designing one. But a car is much less 
complex than a general-purpose computer and operating system in that it is 
designed for a very specific purpose along with all of its components.

The laws of nature dictate much of what you can and can't do when designing a 
car, but with software, this is not the case: The rest is the accumulated, 
not terribly well coordinated, very arbitrary, and eternally changing 
agglomeration of what computer scientists, engineers, and corporations with 
vested interests have created over the last decades. The only thing that 
really acts like laws of nature in the software world are such concepts of 
how information is processed in memory, maybe boolean logic, the mathematical 
foundations for algorithm design, or maybe good design principles, though the 
last point is not universally agreed upon.

> It simply doesn't matter.  [ . . . ]
No, you don't know need to know how to refine copper and silicon before you 
use a computer, but you do need to know about and understand what you are 
working with before you write a program. Better put, the program you write is 
much more likely to be good.

Here's a thought: What if the person designing the software for the automatic 
braking system thought or was told that it was more important to create a 
multicolored light show on your dashboard in a braking emergency than in 
saftely braking the car under conditions of uneven traction on a slippery 
curve?

> Likewise, I shouldn't have to know how  
> to deal with QStyle and stylesheets before using QWidget!  But I am more
> valuable as a programmer if I can find out when needed.
Learning QStyle and stylesheets before learning QWidget is in my opinion the 
reverse order of how to approach the problem. Presentation is arbitrary and 
funtionality much, much less so. Qt is great in that you can put together a 
functional application and then make it pretty later without changing much. 
In my opinion, one of the major faults of the visual tools is that they force 
users to approach the visual appearance of their applications before really 
making them give much thought to the real work that needs to be done and the 
best way to implement it. That is very backwards and a good foundation for 
bad software.

> In fact I said I needed to learn Qt internals in order to create derived
> classes that worked around Qt bugs.  
Maybe you might be doing something wrong or trying to make it program based on 
your understanding of another framework, which is only natural. Changing 
frameworks often means approaching problems differently. I have never had to 
change the Qt internals to get a job done.

And if Qt doesn't do quite what I need I can use STL or the boost libraries or 
even native APIs. Qt stays, as it should, pretty neutral. I have read it even 
lets me use the boost signal-slot mechanism instead of its own if desired. 
Now, that's awesome!

> This is necessary in Qt more than 
> other frameworks, so I do know how to dive into framework internals. 
With the propietary black box components you mention, you can't see or change 
the internals, and if they don't do what you want, as you want, and you have 
committed to using them, then you at the mercy of the company selling the 
components as to whether anything gets fixed (or even unfixed) or really 
needed features are implemented.

Sincerely,

Jeffrey Brendecke

Managing Director
icanetix Software Systems and Consulting GmbH
Untere Hagenstrasse 26
91217 Hersbruck
Germany

Commercial Registry B 25317 Nuremberg, Germany
VAT-ID: DE250213502

[ I am not going to put one of those silly statements here that tell you to 
forget everything you had to read before you got to this point. ]

--------------------
Date: Friday 05 March 2010 23:25
From: "David Ching" <dc at remove-this.dcsoft.com>
To: qt-interest at trolltech.com
Cc: 
Subject: Re: [Qt-interest] Are there any disadvantages with OT
--------------------

> "Jeffrey Brendecke" <jwbrendecke at icanetix.com> wrote in message
> news:201003052109.07195.jwbrendecke at icanetix.com...
>
> >> I suppose I was ranting about the NEED to learn it.
> >
> > Developers programming using a technology they don't understand is not a
> > good
> > idea for any business. Yes, those flashy integrated development
> > environments
> > make it look easy to create programs, but a program tends to spend more
> > time
> > in maintenance and extension than in initial design and deployment.
> >
> > * All the lovely numbered-name identifiers IDEs throw into the code and
> > the
> > concomitant spaghetti-style lack of design make understanding the code by
> > a
> > new person, who assumes responsibility later on, very difficult. Making
> > changes causes bugs and fixing bugs causes bugs. Extension becomes
> > problematic and leads to bugs.
> >
> > * Easy-to-dive-into IDEs used by people who do not understand what they
> > are
> > doing promotes developers programming beyond their ability, especially
> > given
> > the ability to change code while running a debugger. Too little time gets
> > spent actually thinking about what needs to be done and what the best way
> > to
> > do it is. Good code often results from the 2nd or 3rd draft.
> > IDE-developed code all too easily turns into a taped and glued mess with
> > areas labeled "Don't touch this section! It seems to work, but I don't
> > know why!".
> >
> > I think the issue here is the need for education of the business world on
> > what
> > is good and useful and in their own interests as opposed to the common
> > practice of thinking that all we need to do is throw some IDE-equipped
> > amature developers, who actually have other duties at the company, at
> > software development problems. Is that really a sound business practice?
> >
> > I only mention amateur developers and IDEs because the issue at hand
> > seems to
> > be whether someone should need to learn the technology.
>
> There's a difference between having the skills to find out and needing
> prerequisite knowledge of internals before using them.  We'd all be in lost
> if we needed to know how an engine converted fuel into power before driving
> a car.  It simply doesn't matter.  Likewise, I shouldn't have to know how
> to deal with QStyle and stylesheets before using QWidget!  But I am more
> valuable as a programmer if I can find out when needed.
>
> In fact I said I needed to learn Qt internals in order to create derived
> classes that worked around Qt bugs.  This is necessary in Qt more than
> other frameworks, so I do know how to dive into framework internals. 
> Still, I prefer to buy pre-made components that I can treat as a black box
> to save some time, relying on my debugging ability to make them work for
> me.
>
> -- David
>
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest