C++ is a modern disaster.
Poor noobs can't understand memory management. "It's too hard."
Nearly 70% of Chrome bugs are memory related (according to this).
Apparently experienced programmers don't understand it either.
Why is this?
Why is C++ off transmorgifying C++ into Lisp (wait until you see the REPL)?
Watching videos on various C++ conferences is horrifying.
"Igor, let's graft ranges onto for loops!"
Reminds me of the movie "Time Bandits" where Evil says "You are a very troublesome little fellow [ C++ ]. I think I should teach you one of my special lessons? What do you think, Robert? Benson? What would look nice? Half-warthog? Half-donkey? Half-oyster? Half-carrot?"
What would look nice?
Half python, half lisp?
Half PL/I, half Haskell?
Half templates-as-turing-equivalent, half Fortran?
Forty years ago I worked for a company called Unilogic, Ltd. that sold a document system called Scribe (I think the bibliographic reference format - see this - can still be found today).
Scribe was written in Bliss (see https://www2.cs.arizona.edu/classes/cs520/spring06/bliss.pdf), "Bill's Language for Implementing Spiffy Systems" according to some. It was used internally by Digital Equipment Corporation (Dec) to write things like VMS, etc. (see this paper on the history of Bliss).
When I arrived at Unilogic in 1981 James Gosling (of Java fame) had been working part time (while earning his PhD from Carnegie Mellon University) on technology to convert Bliss to C so Scribe could run on non-DEC platforms. He also created his own version of emacs (we called it gosmacs). As he moved on from CMU I inherited the problem of converting Scribe to C so that the Scribe market could be increased from only DEC VAX/VMS (which wasn't popular at universities).
At the time BSD unix on VAX was a hot area but, unfortunately, it only supported C and not Bliss as it wasn't a DEC product.
Eventually the Gosling translation process was replaced by technology I created and we were able to convert Scribes Bliss source code into Ada, C, and other languages.
To accomplish this we initially (a team of myself and perhaps six other people) created a Lisp-based translator process that consumed entire programs, processed them into an intermediate semantic tree containing not only the operators but also the comments and source sourced stored in an object oriented database form, and a "dumper" that wrote out the intermediate form as in some different language.
(I am glossing over many, many details here - after all it was forty years ago - but for now this is good enough.)
Our customers, among others, were Bell Labs (Fortran to C CAD system), Honeywell (PL/M for AN/UGC-144), of course Scribe Systems (what Unilogic had become), NASA (Fortran) and Boeing.
One customer, Rational Systems I believe they were called, was building an Ada machine - a physical piece of hardware that executed some kind of compiled Ada. They wanted Scribe to run there.
By this time the translation technology we had worked for Scribe fairly well, so well, in fact, that it was easy to "lift up" the semantic translation and implement a "virtual byte address machine" in the output of the translation. The effect of this was to implement byte addressable memory as a giant Ada array and to translate operations on memory in the source language into array operations in Ada. Surprisingly it worked well, the Ada version of Scribe passed all its acceptance tests and was shipped to the customer.
We scooped WASM by thirty five years.
There were all the same problems as you see with WASM - for example: what to do about runtime. In those days C was not the language of choice - but the prevalence of it at universities caused new hires to want to go in the Unix/C direction away from old standards like Fortran.
I remember attending a Unix conference in Toronto the 1970's and joking with the guy selling Gosling's emacs that one day IBM would use Unix. Little did we know...
So what's the point of this rambling? How does it relate to the disaster of C++?
I learned a lot in this process about the structure and nature of programming. I saw how compiler writers thought and I saw how users of those compilers thought.
The "semantic model" we had for universally representing programming languages became the way I thought. I don't think in C++ or Lisp or Python. I think in an abstract semantic model format and translate what I am thinking into the appropriate output language, just like the translator used to do.
What I see today with C++ is wrong.
Wrong because the more features, bells and whistles that get added take the language further and further away from someone's intent and understanding.
For example, take a C++ lambda. A context and a function pointer. Before there was C++ that's how you would implement the conceptual lambda - a struct for a context with a corresponding pointer to a function that used the struct for the bindings.
This is a hard thing for noobs to understand. Lambdas are scary and mysterious because they don't follow the traditional sequential flow of other programming models.
Adding layers and layers of silly semantics (like '&' and '=') just make understanding and debugging harder. They don't make the ideas behind it simpler or easier to understand. They obscure what's happening. The compiler works harder, the output of the compiler is less efficient.
(C++ today relies on the 1ns cycle times available in today's processors. Had processors not gained such efficiencies (a DEC PDP/11 cycle time was around 800ns for 16 bits) C++ would be a failure.
C++ is living on borrowed time.
I have worked on software products that spanned decades. The most important things you can do is A) to write code so the dumbest person you can think of can understand it and B) make the tools like the debugger work as well as possible with the code so the dumb person can quickly and easily understand the codes operation.
Why?
Because that dumb person is going to be you...
No comments:
Post a Comment