How you got that from the essay, I don't know, if you see that quote in context he is not saying that at all, he is saying that the low level stuff is neccessary to allow the high level stuff to get built:
You might ask, “Why would someone write code in a grotesque language that exposes raw memory addresses? Why not use a modern language with garbage collection and functional programming and free massages after lunch?” Here’s the answer: Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis.
Denying the existence of pointers is like living in ancient Greece and denying the existence of Krackens and then being confused about why none of your ships ever make it to Morocco, or Ur-Morocco, or whatever Morocco was called back then. Pointers are like Krackens—real, living things that must be dealt with so that polite society can exist.
Make no mistake, I don’t want to write systems software in a language like C++. Similar to the Necronomicon, a C++ source code file is a wicked, obscure document that’s filled with cryptic incantations and forbidden knowledge. When it’s 3 A.M., and you’ve been debugging for 12 hours, and you encounter a virtual static friend protected volatile templated function pointer, you want to go into hibernation and awake as a werewolf and then find the people who wrote the C++ standard and bring ruin to the things that they love.
The C++ STL, with its dyslexia-inducing syntax blizzard of colons and angle brackets, guarantees that if you try to declare any reasonable data structure, your first seven attempts will result in compiler errors of Wagnerian fierceness:
Syntax error: unmatched thing in thing from std::nonstd::__ map<_Cyrillic, _$$$dollars>const basic_string< epic_ mystery,mongoose_traits < char>, __default_alloc_<casual_ Fridays = maybe>>
One time I tried to create a list<map<int>>, and my syntax errors caused the dead to walk among the living. Such things are clearly unfortunate. Thus, I fully support high-level languages in which pointers are hidden and types are strong and the declaration of data structures does not require you to solve a syntactical puzzle generated by a malevolent extraterrestrial species.
That being said, if you find yourself drinking a martini and writing programs in garbage-collected, object-oriented Esperanto, be aware that the only reason that the Esperanto runtime works is because there are systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge.
Of course, you could also try writing system software in a language like Oberon, where two guys could create a language, a compiler, a GUI, an OS, and the hardware to run it on, in a couple of years, while teaching.
Note that Wirth is currently writing a new edition of Project Oberon, with a new FPGA-based computer.
Comments
How you got that from the essay, I don't know, if you see that quote in context he is not saying that at all, he is saying that the low level stuff is neccessary to allow the high level stuff to get built:
You might ask, “Why would someone write code in a grotesque language that exposes raw memory addresses? Why not use a modern language with garbage collection and functional programming and free massages after lunch?” Here’s the answer: Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis.
Denying the existence of pointers is like living in ancient Greece and denying the existence of Krackens and then being confused about why none of your ships ever make it to Morocco, or Ur-Morocco, or whatever Morocco was called back then. Pointers are like Krackens—real, living things that must be dealt with so that polite society can exist.
Make no mistake, I don’t want to write systems software in a language like C++. Similar to the Necronomicon, a C++ source code file is a wicked, obscure document that’s filled with cryptic incantations and forbidden knowledge. When it’s 3 A.M., and you’ve been debugging for 12 hours, and you encounter a virtual static friend protected volatile templated function pointer, you want to go into hibernation and awake as a werewolf and then find the people who wrote the C++ standard and bring ruin to the things that they love.
The C++ STL, with its dyslexia-inducing syntax blizzard of colons and angle brackets, guarantees that if you try to declare any reasonable data structure, your first seven attempts will result in compiler errors of Wagnerian fierceness:
One time I tried to create a list<map<int>>, and my syntax errors caused the dead to walk among the living. Such things are clearly unfortunate. Thus, I fully support high-level languages in which pointers are hidden and types are strong and the declaration of data structures does not require you to solve a syntactical puzzle generated by a malevolent extraterrestrial species.That being said, if you find yourself drinking a martini and writing programs in garbage-collected, object-oriented Esperanto, be aware that the only reason that the Esperanto runtime works is because there are systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge.
http://research.microsoft.com/en-us/people/mickens/thenightw...
Of course, you could also try writing system software in a language like Oberon, where two guys could create a language, a compiler, a GUI, an OS, and the hardware to run it on, in a couple of years, while teaching.
Note that Wirth is currently writing a new edition of Project Oberon, with a new FPGA-based computer.
Based on the last Wirth-related thread, I'm pretty sure it's done and it is just a matter of the documentation getting out there (or not).
Start here: http://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.ht...
But I'm pretty sure the specifics of the FPGA he's running on are not well documented yet. I would be happy to be corrected on that point.
In any case, it's a super cool project.
Ooo, I may just have a use for that.
Third page, first column. Goodness, others here quoted bits of it and now you show us that it's all one passage!