Comment by musicale | Hacker News Reader

Comment by musicale | Hacker News Reader

Parent Full thread

> I have never really understood people‘s aversion to parentheses

A common refrain from Lisp family language enthusiasts. (Personally I prefer Smalltalk-style "conversational" syntax to Lisp-style or C-style syntax, yet it's similarly unpopular.)

For better or for worse, the vast majority of programmers seem to have voted with their feet for C-style syntax (C/C++/Java/JavaScript/etc.) and its variants (Python). In a C/C++/Java/JavaScript world, C syntax has a fair amount of leverage.

It's a shame that Dylan didn't continue, as it seems to have taken a decent crack at adding algebraic syntax to Common Lisp - arguably realizing McCarthy's original vision of infix M-expressions as a more programmer-friendly syntax. I wonder how hard it would be to add a Dylan-style syntax layer to modern CL?

Be that as it may, one can readily write Lisp/Scheme-style programs in JavaScript. See Crockford's "The Little JavaScripter."[1] The major omission/deficiency being macros for JavaScript syntax.

[1] https://www.crockford.com/little.html

My favorite languages are MLs, particularly F#, which usually have some of the cleanest syntaxes available. It’s not just Lisp-family enthusiasts. I think it’s more for anyone that thinks rather that follows or assumes or whatever.

I actually learned about Lisp/Scheme after I had learned about several other languages.

What do people not like about parentheses? It’s normally along the lines of “well, I just don’t like them”, which can be read as “it’s not what I’m used to”. Yet, these same programmers will freely throw parentheses around expressions in an ad-how manner to communicate with the compiler in their given language. In some ways, one can back Lisp/Scheme out of popular languages by stating that instead of letting parentheses be used to frequently but not always clarify precedence and grouping and function application, they are going to be required to enforce these. Such a thing is not such a radical or unreasonable stance.

McCarthy’s original M-expressions are somewhat irrelevant. He wasn’t trying to make a programming language for software development. He was investigating it as a tool for his research.

My primary complaint about popular languages like Python, C++, C#, etc. are their irregularities. There a lot of syntax, semantics, and little quirks in the languages that make it very hard to just know the language and move on solving problems. My favorite thing about Schemes are their regularity. The social popularity of languages can’t be explained by their technical merits. It’s more due to social and historical phenomena than a technical reason.

For what it’s worth, I also like Smalltalks.

The problem is precisely that too much regularity makes the code harder to scan visually. The irregularity of various delimiters and separators helps to distinguish certain language elements from others.

There is power and elegance in syntactic uniformity, but Lisp in particular is hard to read until you train your eye to see through the nest of parentheses, and it's hard to write without something like Paredit assisting you.

Meanwhile I don't think anyone finds Haskell/ML syntax hard to read. The problem is more that, with idiomatic Haskell in particular, too much abstraction, currying, and un-descriptive variable names can obfuscate what a piece of code actually does.

> more programmer-friendly syntax

Lisp doesn't have programmer-unfriendly syntax. It's just tailored to a different use case: built-in ever-present meta-programming. The language was designed to compute with symbolic expressions as data and it was early discovered that Lisp programs itself could be treated as symbolic expressions. Code as Lisp data. People found it easier to do it all in s-expressions, compared to the mixed syntax of the early design: m-expressions for programs and s-expressions for data. This was shown over and over.

In that space it has some local optimum of programmer friendliness. It's just that most programmers don't have that use case. Some get the ideas of list processing as a practical programming interface.

Alternatives were spawned, though: LOGO as a beginner's Lisp, ML as a functional programming language, Dylan as an Scheme+CLOS targeting the same audience as Swift nowadays, ...

(Open) Dylan is surviving just fine, and we expect to do a new release later this month.

I haven't given a look at this language in a few years; is it still so that there are no enums, and that operators must be surrounded by spaces?

Yes. Making a macro for defining enums isn't that hard (there's one here: https://github.com/cgay/uncommon-dylan/blob/master/enum.dyla...).

I, for one, welcome my whitespace-surrounded operator overlords, but if you really don't want that you're welcome to use function-call syntax for them.

As a Guix developer (there's a lot of Scheme and Common Lisp in Guix :) ), every few years I check on Open Dylan but so far each time there was something missing that made me unable to package it for Guix (building it entirely from source).

I've checked it a few minutes ago and Open Dylan's ./configure says to download a bootstrap compiler from https://opendylan.org/download/index.html first -- but there's no such bootstrap compiler there.

Do you have some hints on how to package it?

The way you actually have to do it is trawling through git repos to find an old version of Gwydion, bashing at it for a while, and maybe getting it to compile on modern platforms. Look for 2.4, then rewind, then pass a config flag, and a few more steps.

I wouldn't call Dylan thriving, unless you're a Windows user that really doesn't care about bootstrapping your language.

It's alive though, in the same sense that Miles, the dog that Segall froze and then brought back to life in 1987, was alive. Brain damaged, but alive.

Gwydion Dylan has been out of the picture for years. Open Dylan is the only maintained implementation. Perhaps you went down a wrong path....

You can't bootstrap OpenDylan from source without a Dylan compiler. You can bootstrap Gwydion without one with substantial elbow work, which you can then pivot into bootstrapping OpenDylan.

I know what I was doing, and if you look elsewhere in the thread, I was right about what the GUIX maintainer wanted. Not to get egg on your face.

There's no special "bootstrap compiler"; you can download a binary release for your platform from the page you linked, and then use that to bootstrap a newer version from a source checkout. If it would help, we could provide a minimalistic build that was only useful for bootstrapping, but at present our builds are "batteries included" (with LLVM/Clang and the BDW garbage collector already provided in the tarball).

Ideally, what Guix would want is similar to what https://github.com/thepowersgang/mrustc/ does for Rust (a compiler, not written in Rust, for Rust).

So for Dylan, we'd like to have a compiler for Open Dylan, not written in Dylan. (it can also require multiple steps to get up to Open Dylan--that would be fine)

It's not in the interest of our users to use binary blob compilers for bootstrapping.

We would also unbundle LLVM, clang and the bdw gc and use the ones from Guix.

I never used Dylan, but isn’t Julia kind of similar, as a Lisp with multiple dispatch and a main-stream syntax?

In high level yes, however Dylan was designed as systems programming language, so it also enjoys AOT compilation and low level stuff that Julia currently isn't able to.

Reply on news.ycombinator.com