Stanislav Datskovskiy writes about computing, simplicity, hardware design, and why modern software and tools fall short.
Commenters link it for its essays on HyperCard, chorded typing, and CPU architecture, describing the author's rants as influential in some circles.
> It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and publishing. [...] He was talking about the lack of protocol-level solutions for resilience of the Web.
That's completely at odds with what Kay actually advocates for. His position is strongly aligned with the "mechanism, not policy" philosophy. That is, what he advocates for is less of what you want, not more. This is apparent from that Dr Dobbs interview, his work with VPRI, back to his OOPSLA speech in 1997. To wit:
> HTML on the Internet has gone back to the dark ages, because it presupposes that there should be a browser that should understand its formats. [...] You don't need a browser if you followed what this staff sergeant in the Air Force knew how to do in 1961. Just read it in, it should travel with all the things that it needs, and you don't need anything more complex than something like X Windows.
Kay has always sat on the diametrically opposite site of the table as those favoring the Principle of Least Power—one of the most underappreciated tenets of computing. Tim Berners-Lee called it out in Axioms of Web Architecture:
> At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. The only way to find out what a Java…
I'll cons this onto my list of reasons why Lisp "failed". Other explanations are:
Worse is Better: https://www.jwz.org/doc/worse-is-better.html
The Bipolar Lisp Programmer: https://groups.google.com/forum/#!topic/comp.lang.lisp/eicqvm3GXiE
The Lisp Curse: http://winestockwebdesign.com/Essays/Lisp_Curse.html
Where Lisp Fails: http://www.loper-os.org/?p=69
Lisp is still my language of choice. I'm more productive in it than other languages (C, Java), not because I know the other languages less well, but because they're less expressive. So, for me, Lisp fixes the world.
Why aren't people using it? There are three things often missed.
(1) People's choice of programming languages perhaps isn't as rational as they might like to believe. There's a large amount of personal taste involved. For a personal project, that's no barrier, you can use your favourite language, but if you're working with a dozen other people, Lisp is unlikely to be adopted because more people on the team will prefer Java, C++, or Python. Multiply over all the commercial projects and you can see why you can't build a career around Lisp programming.
(2) There are accidents of history. When DEC decided to discontinue the PDP-10, the days of the hacker community built around it were numbered. Those involved then went on to build Lisp machines, but they were undercut by cheaper, commodity hardware which ran Unix. Then, the AI winter arrived. It was bad for Lisp, but Prolog fared far…
This whole article is great, but the first 2 paragraphs really resonated with me: http://www.loper-os.org/#selection-29.0-44.0
Here's an excerpt:
Sadly, the above scenario is more truth than fiction – for computer enthusiasts. There is a particularly cruel discrepancy between what a creative child imagines the trade of a programmer to be like and what it actually is. When you are a teenager, alone with a (programmable) computer, the universe is alive with infinite possibilities. You are a god. Master of all you survey. Then you go to school, major in “Computer Science,” graduate – and off to the salt mines with you, where you will stitch silk purses out of sow’s ears in some braindead language, building on the braindead systems created by your predecessors, for the rest of your working life. There will be little room for serious, deep creativity. You will be constrained by the will of your master (whether the proverbial “pointy-haired boss,” or lemming-hordes of fickle startup customers) and by the limitations of the many poorly-designed systems you will use once you no longer have an unconstrained choice of task and medium. To my knowledge, no child grows up “playing doctor” and still believes as a teenager (or even as a college student) that an actual medical practice resembles that activity. Likewise, no one has a fully functional toy legal system to play with as a child, and as a result goes into law. On the other hand, “adult” programming, seen from afar, is…
Lisp had a condition system that was very clever. You still had to write the code, but you were able to separate the problem, the handling, and the restart.
This is the problem that comes up in many languages and which needs to be dealt with:
"Because each function is a black box, function boundaries are an excellent place to deal with errors. Each function--low, for example--has a job to do. Its direct caller--medium in this case--is counting on it to do its job. However, an error that prevents it from doing its job puts all its callers at risk: medium called low because it needs the work done that low does; if that work doesn't get done, medium is in trouble. But this means that medium's caller, high, is also in trouble--and so on up the call stack to the very top of the program. On the other hand, because each function is a black box, if any of the functions in the call stack can somehow do their job despite underlying errors, then none of the functions above it needs to know there was a problem--all those functions care about is that the function they called somehow did the work expected of it.
In most languages, errors are handled by returning from a failing function and giving the caller the choice of either recovering or failing itself. Some languages use the normal function return mechanism, while languages with exceptions return control by throwing or raising an exception. Exceptions are a vast improvement over using normal function returns, but both schemes…
You mean that out of all the things in this combinator [0] flavored abstract rewrite system [1], programmed via a symmetrical [2], forward-inferenced [3] typed language, exposing modula-2 style per-code-block compilation control [4], all designed to support a content centric [5], natively networked [6] global computing environment with sovereignty-hard siloing capabilities [7],
the most difficult part to understand is the naming scheme?
Edit: In the early Urbit docs [8] there was a nigh ad nauseam emphasis on the "stupidity" of the project. What the epiphany of careful inspection revealed was that this stupidity was not that of intellectual deficiency, but rather opposition to "cleverness" of the kind that tends to foster (and infest) Urbit's peer group of deep stack [9] rebuilds. One of the most insightful comments I've heard after springing Urbit on unsuspecting PL professionals was (paraphrased): "It [Urbit] does all the things we've said we wanted, in the worst possible way." All words are equally made up until grounded in referents. The question is, are the Worfian shorthands new words provide worth the cost [10] of expanding the symbol table, as compared to the interpretation overhead of translating new concepts into old? Under the burden of internalizing all the content linked below and more, I judge new vocabulary justified.
[0] http://www.ucombinator.org/
[1] https://en.wikipedia.org/wiki/Abstract_rewriting_system (ARS being the most mechanical of the pure…
> I think this should not be underestimated.
You're right but it's broader than "C folks like terseness."
C is famously hard to read. Before Perl we used to joke that C is a write-only language: you can't understand what your own code means just weeks later.
Combine this with its lack of bounds checking, pointer arithmetic, and other dangerous features, and the result is a language that's macho for geeks: it's hard, it's dangerous, but it's small and it's fast.
It's a motorcycle for nerds. Ada is a tank.
Nerds get to establish dominance over lesser nerds by doing hard stuff in hard languages and making it fast. This bestows nerd street cred: geek cred.
Ada was used by contractors who needed stuff to work and money was no object.
C was used by hackers to do cool hacker stuff that was perceived to be fast and low level.
It's not low level: machine architectures haven't resembled the C abstractions since the 1970s.
https://queue.acm.org/detail.cfm?id=3212479
A modern low-level language would be some brain-bending combination of APL and Lisp with n-dimensional tensor algebra or something.
But C looks cool and hard and you will blow both feet off if you don't hold it just right.
And there are good free versions. So you can be poor and still demonstrate your machismo.
Result, a software industry requiring weekly multi-gigabyte online patches, keeping millions in work.
C makes programmers a cheap fungible commodity.
https://www.loper-os.org/?p=69