Of Lisp Macros and Washing Machines (2011)
loper-os.org
loper-os.org
"But no thank you Microsoft. No thank you spreadshi^Heets. No thank you
Unix. No thank you C++. No thank you unmodifiable syntax. No thank you
von Neumann architectures. No thank you unrepentant snake oil industry
that has lured us into performing the same old menial tasks by mouse instead
of by lever and duped almost everyone involved into thinking of this as some
kind of progress."
spreadsheets? Unix? C++? Unmodifiable syntax? The theory behind every single one of these concepts was to save time.
Faster calculations, an OS with a simple concept applied everywhere, a language implementing an interesting design pattern, a style designed to reduce bugs.
I don't think I follow this story.
The author's ultimate reference point is the Lisp Machine. Being Lisp "all the way down," the user could modify running code even at the OS level upon encountering an error or other undesirable result.
The LMI Lambda 3x3 was kind of a three user machine.
Be very afraid.
This is because with the advent of these machines also our hygiene habits changed. We wash a lot more than before, and therefore there is no time saving but cleaner clothes.
The same is true for computers. They did not save time, they changed the way we treat information. We have a lot more than before to process.
You have to wait of few hundred years to see all the consequences of technology in retrospect.
That's not true. The ratio is not at all the same. Except if you take something like 17th century hygiene habits (and for the poor classes, at that) and compare it to modern day habits.
But we had the frequent clothes washing far before the advent of the washing machine. Not to mention that what you said could also be solved with bigger washing machines and more clothing (so that you can still wash at longer intervals, but you have stuff to wear in between).
What if you reverse this and apply it to computers? I spend maybe 2-3 hours in Excel every week. If I were born 100 years earlier, would it follow that I'd also spend 2-3 hrs/wk making spreadsheets, albeit at a much slower work pace? It seems doubtful. I've got only a few dozen sheets, tops. Lots of time spent in Excel is tweaking, making things line up / look right, updating kludges, etc. Busywork, basically. Maybe this is my fault; the 'math' tells me I should have lots of sheets, but I get caught up doing busywork on this machine that's supposed to automate the whole ordeal. What a scam!
The answer therefore is yes.
With endemic spreadsheet errors (since the 80s), and far better solutions being ignored (also since the 80s), there's certainly something to rant about! ;-)
Our best hope is a slave to an alien runtime.
You can't really have a totally safe systems programming language (correct me if I'm wrong here).
This is a million times wrong. It's not about humans being smart or stupid, it's about humans being bad at being careful millions and millions of times without error.
The answer isn't to tell them to be more careful. They can be more careful, but they are human, so they will still make mistakes. The answer is for them to use higher level languages that eliminate whole classes of errors.
He doesn't seem to think that others would be better.
Couldn't be more wrong though.
The people that wrote UNIX and its whole C userland were far from idiots -- more like geniuses. People like K&R, Bill Joy, etc (and until the 90s they weren't even that many, mainly people from elite computing schools and research centers).
It's not like some moron high school dropout, "Learn C in 24 hours"-reading people wrote UNIX and the common server stuff we use (Bind, Sendmail, etc).
I disagree about sendmail though - that was a stinking turd and I have been ever grateful since postfix arrived on the scene :)
However, there are pratical considerations (e.g performance impact and stuff like that) which make such approaches unattractive for production use.
Languages like Ada and Modula-2, just to cite two examples from many, allow for safer coding while having similar performance.
The people that cite the performance impact of bound checking and other features, usually tend to ignore that they can be disabled if required for performance reasons, because it suits their arguments that no other language can achieve C like performance.
Or they like to forget that the industry has invested more in optimizing compilers for C than for other languages. So they end up discussing languages without regard for the implementations.
While I believe you could write an operating system in Haskell, for instance, I don't know nothing about it's performance. However, microkernels, even though are safer, have some performance drawbacks.
It depends what you mean by totally safe, but Cyclone (http://cyclone.thelanguage.org/) is a type and memory safe dialect of C. It works by adding additional information to the type of every pointer, e.g. if it can be NULL, if it's NUL terminated, if you know the length, the scope it was allocated in, the location on the stack it's from, etc...
This all happens at compile time, and it runs about the same speed as C, so I think it qualifies.
From what I've read, this has had more of an influence on programming language designers/implementers (rust, possibly c++11, probably more), than on anybody else, though.
edit: NULL -> NUL
* "Mechanical" issues like dangling pointers, buffer overflows, integer overflows, etc.
* Design errors
Unfortunately, C makes the first class exceedingly easy to create, and makes the second class exceedingly hard to prevent.
As for design errors, they are hard to prevent anywhere.
I have two problems with this reasoning. First, C is being used for more than writing device drivers; most programs written in C are not device drivers. Second, and more important, is that low-level memory access and the sort of bit-twiddling you are talking about can be done in Common Lisp, and I doubt that you would be shocked to know that the operating systems written in Lisp for Lisp Machines had device drivers. It is possible for any high-level language to expose a low-level pointer type, and doing so will not force programmers to use such low-level constructs in higher-level code.
"As for design errors, they are hard to prevent anywhere."
While true, they are much harder to prevent in C because of the complicated semantics, the enormous amount of undefined behavior, and the plethora of edge cases one must account for. When something as simple as incrementing a counter forces you to deal with edge cases and potentially undefined behavior, it is pretty hard to verify that a C program actually implements a design, even when that design was formally specified and checked. The lack of high-level features and constructs worsens this situation by inflating the number of lines of code in an implementation.
Like any systems programming language, nothing special about C.
There are good arguments for macros, but this is not one of them. Macros are certainly not essential for this purpose.