OpenDylan sheds some parentheses in 2025.1 update OpenDylan is a Lisp without all the parentheses – just as John McCarthy originally intended for LISP-2. OpenDylan 2025.1 is the latest release from the OpenDylan project and contains several handy enhancements. There is a new LSP plug-in, lsp-dylan, so you get syntax highlighting and code-completion in compatible editors. The …
> You mean it wasn't named after the hippy rabbit in The Magic Roundabout?
I am sure that the rabbits in _Hey Duggie_ are a tribute to the one true original Dylan.
Just checking... is it generally known that Eric Thompson largely improvised the dialogue to _the Magic Roundabout_ from watching the video of Serge Danot's originals, without even trying to translate the French?
https://www.independent.co.uk/arts-entertainment/films/features/the-magic-roundabout-from-a-to-zebedee-488744.html
And that Eric was the father of both the wonderful Emma Thompson and her little sister Sophie?
https://www.telegraph.co.uk/women/womens-life/11310359/Sophie-Thompson-remembers-her-father-Eric-and-his-Magic-Roundabout.html
They should've changed the name to Zimmerman.1
Amusing that a guy who borrowed his stage name from an actual poet, one Dylan Thomas, would have the bloated ego temerity to object.
Figures.
_______________
Running out of memory was also a problem even on the C++-based NewtonScript Newton; a Dylan-based one would presumably have had it even worse. (OTOH, Apple could have shipped more RAM at the same price if it had merely stopped including floppies as well as a CD in the Newton box…)
> So am I reading the PDF right, that LISP-2 stalled when they ran out of memory on their development machine?
>
> Shame, that.
Leaving aside the situation at SDS, according to Waychoff John McCarthy was seriously pissed by the fact that Burroughs wouldn't tell him how to circumvent their mainframe memory protection, and as a result replaced Stanford's B5500 with an IBM S/360. And it was years before IBM had working virtual memory, hence the old joke about the letters standing for "I'd Buy Memory"...
" Who knows, maybe if Dylan had used {curly braces} it would have been a big hit?"
I've heard sillier ideas.
You have to remember that when C was young it was competing against languages that used actual words for scoping, like BEGIN / END or IF / ENDIF or (boggle) case / esac. The choice of { } resulted in an immediate and obvious improvement in readability in most people's opinion. (This was even true compared to languages that already used brackets, but insisted on using round brackets for /everything/.)
So yeah, a lot of people are now just comfortable with languages that use bracketty things for containment and which use a variety of kinds of bracket to improve clarity still further. Any language that doesn't is just starting 10 metres behind the rest of the field waiting for the starter's pistol.
My favorite approach is Python's: it's all done with indentation. Very clean to read and straightforward to write.
I've had to read thousands of undergrad programming assignments in languages where delimiters were essential but indentation was an optional afterthought. If only I could go back and do it over in Python!
Although you and I have argued about this several times, and I've usually pointed out that if a peripheral can't adequately distinguish between parentheses and braces then one should look at its font handling and question whether it really is the best tool for the job.
After all, there's plenty of more serious related issues: 0 vs O, l vs I, l vs 1 and so on: and those comparisons will look different to every one of us depending on browser and OS.
Great article, with many fascinating links ... I needed a nap afterwards to allow the cognitive content to properly anneal itself into synaptic updates! (or maybe it's just a sign of aging?!)
I do feel though that Dylan chose the comforts of the road more traveled with its blocky LEGO structure and 11-line long Hello World's boilerplate requirements of libraries and modules. It seems to increase the distance between appetite and satisfaction, unlike BASIC, LISPs, Julia, the MATLAB/Octave vector language, etc ...
The road less traveled of good crazy could have provided more insights imho (if practicable at all). Homoiconically represented programs (eg. LISP) are trees, with trunks, branches and leaves (directed acyclic graphs). There's no need for a Program Counter (PC) to go through them, one just traverses the tree (data structure), and any part of that code can be moved anywhere without bother, even out of what would be sequential PC order, as long as the tree structure is preserved (this FPGA project may have followed that philosophy).
But of course, loops and recursion produce cyclic graphs instead and so to me, beyond homoiconicity, it is the notion of a graph-homomorphic language that needs further exploration. Anaphoric references in macros and functions help a bit³ but don't turn the code tree magically into a cyclic graph (where warranted).
As Tenstorrent's Jim Keller said in interview "Everybody who describes [a] program, they describe a graph, and the graph needs to be lowered [...] to the hardware". So, the closer the programming language is to being graph-homomorphic, and the closer the hardware is to being a graph processing beast, the better off we might eventually end up, imho! (maybe ...)
³⁻ good for anonymity, say: ((lambda (x) (if (< x 0) #t (begin (write x) (self (- x 1))))) 9) ; -> 9876543210#t
Thank you! Happy to hear that. :-)
> I do feel though that Dylan chose the comforts of the road more traveled with its blocky LEGO structure and 11-line long Hello World's boilerplate requirements of libraries and modules.
That's a fair point.
I think, but am not sure, that there is an assumption here that this will be a graphical app and will display the message in... well, originally, whatever the Newton's equivalent of a message box was...
And secondly, that if Apple had pursued Dylan and the Newton based on it, that some more of the pointy edges would have been eroded away.
I did erroneously say in a previous article that Apple's radicaly SK8 IDE was based on Dylan. That is wrong -- it was more of an offshoot of Hypercard, apparently.
I think as LLM-bot fed bloatware gets ever bigger and worse, someone could do an end-run around the entire industry and do some next-gen language and environment based around Smalltalk, Lisp, Dylan, SK8 and stuff like that, and make some tool that makes it stupidly easy to put together GUI apps.
The rest of your comment will need a lot more digestion to usefully respond to.
Ah yes! If that Dylan Hello World puts up a message box widget then it may be worth the 11 lines it's written in ...
With respect to Keller, he was talking mainly about Tenstorrent's (essentially) "dataflow architecture" where the computational graph is to be mapped over many simple sequential computational units (working in parallel) iiuc, in what reminds me a bit of an array of transputers (eg. also SambaNova's Reconfigurable Dataflow Unit (RDU) chip).
But yeah, I was inspired ... don't feel obligated to swallow everything that's on that plate (eh-eh-eh!)!
> The road less traveled of good crazy could have provided more insights imho (if practicable at all). Homoiconically represented programs (eg. LISP) are trees, with trunks, branches and leaves (directed acyclic graphs). There's no need for a Program Counter (PC) to go through them, one just traverses the tree (data structure), and any part of that code can be moved anywhere without bother, even out of what would be sequential PC order, as long as the tree structure is preserved (this FPGA project may have followed that philosophy).
> [...] As Tenstorrent's Jim Keller said in interview "Everybody who describes [a] program, they describe a graph, and the graph needs to be lowered [...] to the hardware". So, the closer the programming language is to being graph-homomorphic, and the closer the hardware is to being a graph processing beast, the better off we might eventually end up, imho! (maybe ...)
And the nearer you get to the hardware, the more you need an understanding of how the program counter, stackframes and so on hang together. Far too much tosh has been written by people who know how to wave their abstract hands, but have no expertise when it comes to getting them dirty: other than milking investment from the gullible.
> C syntax is magical programmer catnip. You sprinkle it on anything and it suddenly becomes "practical" and "readable".
Looking at this in the context of the ALGOL family, the thing is that there's so many different issues. The first one that people think about is using braces rather than begin/end: but in the overall scheme of things that's trivial (potentially just a macro expansion) and is immediately eclipsed by such things as the dangling-else issue (fixed in some ALGOL-derivatives, hacked around in others, ignored in many including C and Pascal).
Then there's things like declaration order: some languages put a type followed by things to be associated with that type, others do it the other way round.
But the elephant in the room is infix notation: C (and most other ALGOL derivatives) embraced that since it was basically a convention that every schoolboy had been familiar with for centuries, LISP (and APL, Forth and Smalltalk) thought they could do better and- I'm tempted to say- arguably harmed the industry and the underlying technology by fragmenting the notation.
Well, I for one do love prefix (not exclusively of course!), I mean, look at this expression:
(+ 1 2 (* 3 4))
it's its own computational tree:
‧ +
/ | \
1 2 ‧ *
‧ ‧ ‧ / \
‧ ‧ ‧3 ‧ 4
A thing of formidable beauty that concisely transcends even aesthetics itself ... Just plain perfect!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
