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

[Giuseppe D'Angelo]

Hi,

On 04/11/2018 00:07, Roland Hughes wrote:
> 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.

[citation needed], I'm afraid. Every single time I say that "not using 
C++-latest costs more", I do it bringing technical arguments to the 
table, usually quoting which exact new feature or idiom I'm talking 
about (and what would be the advantages in the context of the 
discussion). I don't spread gossip, and I don't embrace the new 
standards blindly.

I'm simply convinced that the adding things to Qt that are also already 
covered in an excellent way by other libraries (_especially_ if it's by 
the Standard Library) simply doesn't justify its work/benefit ratio. And 
this connects to the statement of mine you quoted: if C++2a ships 
ranges, you shouldn't be looking for them into Qt. You should be looking 
for a new compiler. Of course you're free to stick to your current 
compiler, which means not using ranges from the Standard Library, which 
may have a cost for your development.


> 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.

Luckily we're not in 1991 (?) any more, we can use more than 640K of 
memory, C++ is very portable, and all major vendors ship compiler 
updates quickly.

<hearsay> Didn't you hear from Microsoft? They went from being the 
slowest adopter to the fastest -- to this date, MSVC 2017.7 is the 
_only_ C++ compiler that supports the entirety of C++17! That indeed 
shows their commitment! </hearsay>


> 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

Sorry, but this does not make any sense at all. Trigraphs were added to 
C because not all encodings, operating systems, editors, or keyboards 
(notably, yes, IBM's, e.g. the 3270 series) had the full set of symbols 
to properly write C code. How does using a different encoding suddenly 
make such keyboards have new physical keys?

Not to mention that trigraphs were added to C before 1989, and the first 
release of Unicode came in 1991, with UTF-1 and UTF-8 coming then in 
1992. Do you have a time machine?

Yes, people "blame" IBM for that. Yes, trigraphs have finally been 
dropped in C++17, although implementations are free to support them 
(source encoding mapping is still implementation-defined, after all).

And anyhow, are we discussing about _trigraphs_, which are purely a 
_backwards-compatibility feature_, in terms of "chasing the latest 
standard"?


> 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.

Or employed by one of the countless companies who _are_ chasing the 
Standard and making quite some money by building successful products. 
Please stop spreading hearsay!


> 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.

That is, rephrased, "you can write FORTRAN in any language". Using or 
not using the latest standards has nothing to do with this. You can 
write beautiful C++98 code and ugly and complicated C++17. This proves 
or disproves nothing.


> 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.

[citation needed] again. Please, bring facts to the table of using or 
not using some other language feature, not random stories.

Cheers,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181105/1cb31983/attachment.bin>