“Jets” are the proverbial “Sufficiently Smart Compiler.” The seal between a core of Maxwellian purity and the world of filthy expedient compromises which lies outside must be absolutely perfect – like the seal on the airlock of a multi-generational starship. In fact, building the airlock at all is a terrible idea. Anyone who whines about being welded into the hull doesn’t belong on the journey.
Think of every high level language with a C FFI you’ve used. Having the FFI is not harmless. It colors the programmer’s thoughts. It destroys the Master-Of-All-I-Survey majesty of the entire system. Another way must be found.
Month: January 2014 Page 1 of 2
In fact, if I had to write “hello, world” in Haskell to avert the death penalty, it would take at least a look at the tutorial. If Haskell supporters admit that Haskell has failed, apologize for inflicting on the world, and agree to at least consider defecting to Urbit, I will apologize for this ignorant attitude. Obviously, a lot of fine work has gone into Haskell. A lot of fine work has gone into a lot of things. It has not necessarily made them fine.
The types of programming language semantics, according to CTM
Neither programmers nor users are able to purchase a modern computer which behaves sanely – at any price. We have allowed what could have once become the most unbridled creative endeavor known to man short of pure mathematics to become a largely janitorial trade; what could have been the greatest amplification of human intellect in all of history – comparable only to the advent of written language – is now confined to imitating and trivially improving on the major technological breakthroughs of the 19th century – the telegraph, telephone, phonograph, and typewriter.
… a trivial (in retrospect) method for entirely relieving compilers of the burden of stack discipline: a necessary first step towards relieving programmers of the burden of compilers. A systems programmer or electrical engineer educated in the present Dark Age might ask why we ought to demand relief from CPUs which force machine code to “drive stick” in register allocation and stack discipline. After all, have we not correctly entrusted these tasks to optimizing compilers? Should we not continue even further in this direction?
For concerned locals, the shuttles symbolize their collective fears about the rise of the tech sector…
That proverbial horse left the barn a loooong time ago. San Franciscans against the Google buses seem not to realize that without the tech economy, the Bay Area would have become the Rust Belt with nicer weather.
I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult.
The “debate” had an interlude, in which Costanza asked Sussman why MIT had switched away from Scheme for their introductory programming course, 6.001. This was a gem. He said that the reason that happened was because engineering in 1980 was not what it was in the mid-90s or in 2000. In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme – it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that’s all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.
But programming now isn’t so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.
So the good thing about the new 6.001 was that it was robot-centered – you had to program a little robot to move around. And robots are not like resistors, behaving according to ideal functions. Wheels slip, the environment changes, etc – you have to build in robustness to the system, in a different way than the one SICP discusses.
And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all.