Lisp for the Web (2008)
adamtornhill.com
adamtornhill.com
https://github.com/rongarret/BWFP
If there's enough interest I'll pick it back up again.
I will try to find some time to write more. Anything in particular you'd like to see in the next chapter?
McCarthy was deep in the Amazon when suddenly out of nowhere...
https://english.stackexchange.com/questions/16768/discover-o...
It turns out that for many, this idea is far from the truth. The similarities are superficial. The notation is abstract artifice. Math is not programming. Programming is not math.
If you try to take what you know, and instictively use in one context, and try to walk it over to the other, and directly reapply it, you'll surprise yourself at the amount of disappointment experienced.
I first heard it explained by Philip Wadler, and upon reflection it was one of those "enlightenment" moments that Lispers always go on about: Lambda calculus is a discovery, and should we ever encounter an alien space-faring species, we could read their programs in spite of their alien processing architectures (given that they use a functional language, but let's face it, they have the tech to cross space, they know what they are doing, i.e. they're in the functional camp)
"Propositions as Types" by Philip Wadler, Strange Loop. (https://youtu.be/IOiZatlZtGU?t=1678)
I do agree that lisp being super tiny and quite mathematical at heart is probably less a social invention than the rest.
Lambda calculus. Enlightenment. Discovered, not invented. If it already exists somewhere... Everything coming together in the same patterns. Influence.
Attitudes may change, of course; had Nathan Myhrvold discovered Lisp, he'd have it locked up in patents till well after 32-bit time_t's overflow.
Saying that lisp is all about writing (function arguments...) misses the point. One can write function application in ML in this way too. The key things are approximately that all syntax could be written as sexps, including things like let and lambda which in other languages require special syntax; and that the semantics (somewhat) corresponds to the lambda-calculus and so includes lambdas.
I would not say that Lisp is fantastically succinct. There are many ways to express things and the main advantage of lisp is that you can choose how to do this, so long as you express things in sexps.
Yes the (very) ancient Egyptians sort-of knew about Pythagoras’ theorem, although I would perhaps say that the babylonians knew it better. I don’t know whether it is known if they knew that it held for right triangles both ways or just that one could make a right triangle from a^2+b^2=c^2. However I wouldn’t say that Pythagoras made it succinct. For one thing he likely didn’t exist. Also the main contribution of the Greeks to this would be the notion and formalisation of proof (which evolved over time in Greece), rather than the theorem itself. Indeed I would say that the modern expression of the theorem is more succinct than the one one will find in eg Elements
McCarthy thunk up a beautiful self-evaluating eval function for lambda calculus and wrote it down. (The page-long "Maxwell's equations".) Then he showed it to someone (I forget who) who said, "I can implement that." and did. Suddenly: LISP.
Same pattern with Smalltalk: Alan Kay thought it up and someone wrote a little VM in C and suddenly Smalltalk was a thing in the world.
I came up with the Smalltalk half-pager because John McCarthy had shown how to do it -- and because message-passing OOP can be a not too crazy perspective on Lisp (especially a variant of "apply", and especially if you use the FEXPR and closure ideas).
Apologies for my glibness, I meant no disrespect. I knew it was someone I should remember. (He of BitBlt fame, damn I'm getting old and forgetful!)
- - - -
So... "discovered" or "invented"?
FWIW, I think the point turns on one's metaphysics. Is there some Platonic realm where e.g. each of the "Turing Drawings" ( https://maximecb.github.io/Turing-Drawings/ ) has always existed, just waiting to be discovered? Or did Maxime Chevalier-Boisvert invent them? All of them? What is the ontological status of the vast set of TDs that have never (yet) been seen by any eye, or that have never been run on any real machine?
- - - -
Er, on a tangent, may I make bold to ask you, did you know that Prolog Discrete Clause Grammar rules are very similar to the OMeta parser generators? https://en.wikipedia.org/wiki/Definite_clause_grammar
The Peano axioms describe constraints for instances within a set. Is something already "there" just because we can test the constraints after it appears, or use them to make it?
The foundations of OMeta go way way back (starting with Meta II by Val Schorre ca 1964 -- and in the context of the many different approaches to parsing in the 60s). The modern addition to help make OMeta was the packrat parsing idea. It wouldn't be surprising if some Prolog lore wafted its way in, but I don't recall that any of the many parsing schemes that Prolog has been used for were in the conversations. One of the Ur-centers that most parsing theory has to contend with is "Earley Parsing". However, the idea that a dynamic proof can be used to parse goes very far back.
I've been an avid reader of VPRI's papers and reports. Incredible work. It deserves to be more widely known.
Someone on a forum somewhere pointed out the similarity between DCGs and OMeta, I didn't notice it myself.
I'm working to complete a project directly inspired by your work (and Ted Nelson's "Dream Machines" book) that should culminate in a system that approaches the "20,000 lines of code" ... "from the end‐user down to the metal" limit. I'm using Prolog and Joy programming languages and targeting the RISC that Prof. Wirth developed for Project Oberon. I have a simple modeless UI modeled on Oberon OS and Jef Raskin's "Humane Interface". If anything comes of it I'll probably try to show it to you someday.
Pro: rapid prototyping and development, excellent debugging capabilities (both for your web app and network requests... can be extended to browser-side with effort), your app can have capabilities that are difficult to implement with static languages/frameworks
Con: small user community which results in limited selection of frameworks all having their own quirks/limitations, when things break you're often on your own, in dynamic languages performance often won't scale as easily or as far vertically (the recommended approach is often to be sure your design can scale horizontally)
Though the 45-page book was finished in 2015, according to https://leanpub.com/lispweb.