[Interest] Qt API annoyances: where to log/discuss?

Roland Hughes roland at logikalsolutions.com
Sun Nov 4 00:07:09 CET 2018


Giuseppe,

I missed the beginning of this thread and don't have enough time for one 
of my usual missives. I did want to take issue with the comment about 
using C++ latest.

It's _never_ a good idea to chase a standard.

Please allow a few words of caution from a grizzled old code warrior.

I started programming before we had PCs or a C compiler for them. If you 
want a loose interpretation of the time which shortly followed rent 
"Halt and Catch Fire" https://www.imdb.com/title/tt2543312/ and follow 
it up with "Pirates of Silicon Valley" https://www.imdb.com/title/tt0168122/

Back there and back then we had to chase the standard. The C language 
itself didn't provide enough functionality to develop the applications 
users wanted and we were mixing memory models trying to make them fit 
under the infamous 640K barrier. By the time C++ compilers were 
commercially available most compilers were so far afield from any 
"standard" that you couldn't write something in Borland C++ with any 
hope of it compiling under Microsoft or Watcom and yes, you could switch 
the order with the statement still being true.

I used to skim the edge, but I had to because we were writing programs 
for IBM "compatible as long as you didn't try to run Flight Simulator" 
machines. I even subscribed to Rex Jaeschke's standards tracking blue 
magazine back in the day. While I wouldn't say we were friends, we did 
exchange emails before we had an Internet and email standard. We did 
also exchange emails earlier this year. You can look him up here  
http://rexjaeschke.com/  but might be best to dig through old Dr. Dobbs 
issues. The dude really worked hard and wrote well. We all worked hard 
back then.

Standards bodies have a tendency to jump the shark a bit too often for 
my comfort. I came to this realization with the introduction of trigraphs.

https://en.wikipedia.org/wiki/Digraphs_and_trigraphs

P.J. Pluager (we DON'T exchange emails) was hailing their salvation of 
mankind in "The C/C++ Users Journal" while many of us grunt coders in 
the field were decrying them even being thought about. This was the 
result of a select few individuals trying to solve a language problem 
with an addition to a programming language. They wanted to make the C 
language family "the one" to replace all others. It was the wrong 
solution before the idea was even hatched. IBM and a select few others 
could not wait for the correct solution, so they slammed through an 
ill-formed solution and went merrily on making money. (To this day I 
don't know of a single widely available programming editor which will 
show you the translation of a trigraph or digraph on your screen. 
Somewhere one or two might exist, but they certainly didn't exist when 
this egg was laid.)

What was the correct solution you ask? UTF

There were other attempts to be sure. Various language sets which could 
be loaded on demand, but, the programmers who coded close to the metal 
needed to step back. We were well past the days of being able to rely on 
the characters contained in either a BIOS/firmware code page or the one 
loaded by DOS. (Windows was nothing but DOS all the way until NT.)

Being long in the tooth and somewhat greying of hair and having spent 
roughly 3 decades as a hired gun in the software programming world, I 
will share with you a bit of advice which will find deaf ears which will 
fall on the deaf ears of the young guns who stay up nights reading 
communications of the standards body.

The person hired to maintain your code will have one overriding 
qualification. They will be "priced right." As a software mercenary, if 
you write code which skims the edge of the current standard, word will 
get around and you will find yourself stocking shelves at Walmart.

I've known quite a few consultants over the years who tried to make 
themselves indispensable by writing code nobody else could maintain. One 
used to write "hand tuned assembler" for portions of every system he 
wrote and we are talking less than a decade ago. He wasn't writing PC 
software, but working on a big midrange system and pretty much 
everything he did in assembler could have been done in BASIC or COBOL on 
the same platform. In fact that company has someone rewriting it all in 
a high level language now. Yeah, he's not there anymore.

During my 3 decade career I've only encountered one client site which 
did not prefer a full page of easy to read code to that one incredibly 
ingenious line which could replace it all. That one place has a teem of 
young guns who basically sleep with the standards documents who like to 
write incredibly complex and impossible to debug templates for various 
things. As of last year their product was still in trouble. It wasn't 
even that complex of a product conceptually. There was certainly no 
reason for the code to get that way. Oh yeah, I forgot about the macros 
which use other macros that use other macros. When you compile a listing 
the macro set on one line expands to, in some cases, an entire page or 
more of code.

Long life Qt shops. Those building products which must be field 
maintained for a decade or more like medical devices, cargo x-ray, etc. 
Need a code base which can be maintained by their most junior developer. 
They need a college intern to become functional within 2 days and able 
to maintain the system within a month.

Young guns like skimming the edge of a standard to prove their chops. 
They, however, create systems which either never see the light of day or 
only survive for a couple of years in the field.

On 11/1/18 5:33 PM, Giuseppe D'Angelo wrote:
> As I said in the other thread, not using C++-latest costs
> _you_  more. It shouldn't cost anything for Qt.

-- 
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us




More information about the Interest mailing list