Jonathan Blow showed up in the comments on the HN Bel post with some excellent thought-clarifying questions: https://news.ycombinator.com/item?id=21237636

Seems like a classic case of software conservative meeting a software liberal (https://gist.github.com/cornchz/3313150). Or a big-team programmer meeting a small-team programmer. Or a shipping-software programmer meeting a sketching-prototypes programmer.

I threw my 2 cents in. Anyone pursuing Lisp in this day and age is frankly mad. Its insidious parenthetical notation, and archaic nature make it an eternally fascinating, but ultimately useless exercise.

"I don't even see the parenthesis." 🤭 Seriously though one of my basic macros is to have

(with x = 5 x2 = (* x x) (+ x2 x 1))

map to

(let* ((x 5) (x2 (* x x)) (+ x2 x 1))

.

@Kartik Agaram wait.. who's who in those analogies? I feel like they're both conservative, small-team.

Bel seems liberal. Mostly extrapolating from past history. You're right that it's not obvious just from this prose. But I'm curious why it seems conservative.

The question any new high level language needs to answer today is “How are you going to compete with JavaScript?”

You mean any new high level language that cares about adoption. But not everyone cares about adoption. Bel seems like a https://en.wikipedia.org/wiki/Gedankenexperiment

Ha, I've seen a number of "Rust is the new Javascript" blog posts. Here's one: https://blog.usejournal.com/moving-from-nodejs-to-rust-in-2019-62c0b85d2fa7

Clojure seems to be a counter-example earlier on in this thread, showing that parens are not a big deal.

As for Bel, it doesn't even have support for numbers, so why are we comparing it to production ready programming languages? I interpret it as an exercise in programming language design, and I believe that useful insights can come out of such an exercise. Programming language design is an important field of study.

But, but apples to oranges comparisons are the best comparisons!

I’ve never heard of Rust referred to as a high level language. I thought it was more like C++ than Smalltalk.

I think C++ is high level 😄 Rust is higher.

Part of what makes Clojure parens "not a big deal" is that Clojure (somehow) fosters projects like Parinfer (https://shaunlebron.github.io/parinfer/), which makes writing lisp feel like writing a whitespace language. When I write clojure, I set my parens to a very faint color. It's nice!... and totally not as karmically risky as standing on a mountaintop in the rain wearing copper armour shouting "all gods are bastards".

Notice that Parinfer supports non-Clojure Lisps. It's not the only such tool. Lisp programmers often use tooling to deal with parens.

I'm totally reading this in his voice

I couldn't write any Lisp code (mostly Scheme and Emacs Lisp these days) without paredit in Emacs, And like @Ivan Reese, I set parens to a faint color so they don't dominate visually. I am much more efficient writing this than e.g. Python, although I have probably written 10x more Python code than all Lisps taken together. (Achievement unlocked: I used "10x" to describe myself.)

@Konrad Hinsen Why are you much more efficient writing Lisp than Python? Inquiring language designers need to know!

@Doug Moen I'd say really getting a concrete syntax down cold takes a while.

@Doug Moen Uniformity of syntax is one aspect. In Python you have parentheses, indentation, and square brackets being used in different concepts for the same purpose: establishing a tree structure. The other aspect is tool support. WIth paredit in Emacs, I almost think in terms of paredit operations rather than in terms of characters. It goes a long way towards structural editing from my point of view.

Without adding anything new, I’d like to add myself as someone with long Lisp exposure (about 8 years of Clojure) who also feels much more efficient/at ease with the uniformity of Lisp syntax + paredit’s structural editing

@Kartik Agaram “You mean any new high level language that cares about adoption. But not everyone cares about adoption.” I don’t just mean compete for user adaption. I also mean compete for usefulness in achieving your goal. For example, let’s say your end goal isn’t primarily testing an experimental language design, but rather to build a FoC development environment. Then you have to ask if your custom language is really the best base to build it on. If JS supports enough of the high level features you feel you need to build your development environment in, then you have to ask how your own language would compete for accomplishing the goal of building your development environment (regardless of whether or not you care about your development environment’s adoption).

I think it goes without saying, that all of the FoC projects have as their overt or secret agenda the dethroning of JS. JS was developed in haste, and the HTML/CSS/JS/framework stack is arguably one of the most complex and messy toolchains ever used by programmers. Just from an economic point of view it cannot continue this way, because the costs of code that balloons exponentially in terms of dependencies is non-linear. When people were rushing to get something out quickly to "get there first", the poor quality of the toolchain was an acceptable tradeoff, but for companies and products that are now going to be around for decades, it is time to adopt some sensible programming methodologies and tools. We have learned a lot about what kind of errors are common, and how to make it harder for human error to occur, and although inertia is the most powerful force in the universe and the change will take some time, there is hope and opportunity here.

@Edward de Jong / Beads Project It seems to me that good abstractions can allow one to leverage powerful (albeit less than ideal systems) such as JS & DOM in a way that allows them to be easily replaced once better options are available. Just as modern OSes may not be ideal, but we can build languages and tools on top of them without exposing the higher level to the details of the lower. To attempt to replace the entire stack seems like it would ensure you’ll be working for decades on the lower parts before you can make any progress on the higher parts.

Just like TypeScript, CoffeeScript, etc., In my Beads language i emit JS and AS3 so as to leverage the fully debugged lower part of the stack. I present a graph database, a nice fluid 2D layout and drawing model, and an event model that is miles away from CSS/HTML/JS, so that one doesn't have to think in that JS/OOP way. It would add man years to the project to go one layer deeper and go directly to the OS. Eventually though one usually does go the extra mile, because it removes a dependency from the chain.