Hacker News Reader

Comment by mqus | Hacker News Reader

Having a simple syntax might be fine for computers but syntax is mainly designed to be read and written by humans. Having a simple one like lisp then just makes syntactic discussions a semantic problem, just shifting the layers.

And I think an complex syntax is far easier to read and write than a simple syntax with complex semantics. You also get a faster feedback loop in case the syntax of your code is wrong vs the semantics (which might be undiscovered until runtime).

View on HN

Jury's out re: whether I feel this in my gut. Need more time with the lisps for that. But re: cognitive load maybe it goes like:

1. 1 language to rule them all, fancy syntax

2. Many languages, 1 simple syntax to rule them all

3. Many languages and many fancy syntaxes

Here in the wreckage of the tower of babel, 1. isn't really on the table. But 2. might have benefits because the inhumanity of the syntax need only be confronted once. The cumulative cost of all the competing opinionated fancy syntaxes may be the worst option. Think of all the hours lost to tabs vs spaces or braces vs whitespace.

I think 3 is not only a natural state, but the best state.

I don’t think we can have 1 language that satisfies the needs of all people who write code, and thus, we can’t have 1 syntax that does that either.

3 seems the only sensible solution to me, and we have it.

I dunno, here in 3 the hardest part of learning a language has little to do with the language itself and more to do with the ecosystem of tooling around that language. I think we could more easily get on to the business of using the right language for the job if more of that tooling was shared. If each language, for instance did not have it's own package manager, its own IDE, its own linters and language servers all with their own idiosyncrasies arising not from deep philosophical differences of the associated language but instead from accidental quirks of perspective from whoever decided that their favorite language needed a new widget.

I admire the widget makers, especially those wrangling the gaps between languages. I just wish their work could be made easier.

I really like the Linux package managers. If you're going to write an application that will run on some system, it's better to bake dependencies into it. And with virtualization and containerization, the system is not tied to a physical machine. I've been using containers (incus) more and more for real development purposes as I can use almost the same environment to deploy. I don't care much about the IDE, but I'm glad we have LSP, Tree-sitter, and DAP. The one thing I do not like is the proliferation of tooling version manager (NVM,..) instead of managing the environment itself (tied to the project).

I've always thought these complaints are really just a reflection of how stuck we are in the C paradigm. The idea that you have to edit programs as text is outdated IMO. It should be that your editor operates on the syntax tree of the source code. Once you do that, the code can be displayed in any way.

I also believe this, and we're actually about half way there via MPS <https://github.com/JetBrains/MPS#readme> but I'm pretty sure that dream is dead until this LLM hype blows over, since LLMs are not going to copy-paste syntax trees until the other dream of a universal representation materializes[1]

1: There have been several attempts at Universal ASTs, including (unsurprisingly) a JVM-centric one from JetBrains https://github.com/JetBrains/intellij-community/blob/idea/24...

The problem with this statement is that it assumes parsing-easiness as something universal, and stable. And this is certainly not true. You may believe syntax A is so much easier simply because it's the syntax you have been dealing with most of your career thus your brain is trained for it. On top of it a particular task can make a lot of difference: most people would agree that regex is simplification versus writing the same logic in usual if-then way for pattern matching in strings, but I'm not sure many would like to have their whole programs looking that way (but even that could be subjective, see APL).

This is interesting. My first thought was that a language where more meaning is expressed in syntax could catch more errors at compile time. But there seems to be no reason why meaning encoded in semantics could not also be caught at compile time.

The main benefit of putting things in the syntax seems to be that many errors would become visually obvious.

I don't understand your distinction between syntax and semantics. If the semantics are complex, wouldn't that mean the syntax is thus complex?

lisp's syntax is simple - its just parenthesis to define a list, first element of a list is executed as a function.

but for example a language like C has many different syntaxes for different operations, like function declaration or variable or array syntax, or if/switch-case etc etc.

so to know C syntax you need to learn all these different ways to do different things, but in lisp you just need to know how to match parenthesis.

But of course you still want to declare variables, or have if/else and switch case. So you instead need to learn the builtin macros (what GP means by semantics) and their "syntax" that is technically not part of the language's syntax but actually is since you still need all those operations enough that they are included in the standard library and defining your own is frowned upon.

Lisp has way more syntax, that doesn't cover any of the special forms. Knowing about application syntax doesn't help with understanding `let` syntax. Even worse, with macros, the amount of syntax is open-ended. That they all come in the form of S-expressions doesn't help a lot in learning them.

Most languages' abstract machines expose a very simple API, it's up to the language to add useful constructs to help us write code more efficiently. Languages like Lisp start with a very simple syntax, then add those constructs with the language itself (even though those can be fixed using a standard), others just add it through the syntax. These constructs plus the abstract machine's operations form the semantics, syntax is however the language designer decided to present them.

Reply on news.ycombinator.com