Live data from Hacker News

A Lisp adventure on the calm waters of the dead C (2021)

mihaiolteanu.me

31–33 of 33 posts

Re: A Lisp adventure on the calm waters of the dead C (2021)

#31
post #10

Earlier quoted context omitted.

I don't think you're missing much. Yeah, the main point seems to be that if your language has closures, you suddenly can express a lot of things that were out of reach before. Not a new insight. But there's another point I think that is hinted at on the topic of control abstractions. Or at least I'm reminded of the topic. It's better and more succinctly and explicitly talked about in an early chapter of the free book…

There's an upside to C's limitations. Several times I've seen expressed the notion that "every big Lisp project uses its own dialect of Lisp". This is less true in C, I think, because it doesn't have the power (ignoring preprocessor abuse, which does happen, see Bourne shell source[1]). C++ has a bit more power, and there we see projects tend to use their own subset of C++. In both Lisp, and C++, taking some isolated…

> This is less true in C, I think, because it doesn't have the power

It may be, but even so, C is famously unreadable to the extent that it's a common observation that people can't read their own code from a few months earlier.

I think there is an argument -- one that would be very unpopular among Lisp folks, I suspect -- that says that for languages to enforce some forms of simplicity would help their uptake and use.

Most language advocacy revolves around poorly-defined notions of "power" where more power is seen as desirable.

I think Niklaus Wirth was on to something when he took the ideas of Pascal and kept simplifying as well as improving: Modula, Modula-2, Oberon, Oberon 2, and finally Oberon-07. (There are more -- Active Oberon, Zonnon -- but Wirth had retired by then.)

Re: A Lisp adventure on the calm waters of the dead C (2021)

#32
post #27

Earlier quoted context omitted.

The author may be eloquent, but unfortunately calls imperative operators, like while, "functions".

Imperative code is a function from one program state to another.

That concept is not reified in the imperative language in any meaningful way. There is no actual function from the program state, to the next state as a language construct. Even if there were, it would be in a different category from the while loop and its ilk.

Re: A Lisp adventure on the calm waters of the dead C (2021)

#33
There seems to be a lot of "Lisp is better than C/C++/..." articles around. I wonder why?

If the purpose is to try and convince non-Lispers to use Lisp, a more convincing argument (for me at least) would be to demonstrate modern commercial software written faster and more bug free in Lisp.

For example: "Here is a modern biz web application written in Lisp" showing step by step how Lisp makes the development process faster and less buggy than implementing the same application using (say) Typescript/C++.

Notes: I use custom code generators to generate more than 90% of the Typescript/C++ code needed to implement biz applications. Leaving only the core biz logic. So macros for code generation doesn't really give me anything I don't have already. And using macros for defining my own DSL's within the language would just makes the code unreadable for other developers. So it is not a feature I actually want.

Post reply on HN