Live data from Hacker News

A road to Lisp: Why Lisp

scotto.me

241–250 of 322 posts

Re: A road to Lisp: Why Lisp

#241
post #148

Earlier quoted context omitted.

This is the "fallacy by Turing completeness". Sure, and you may as well write full systems in Minecraft and create your own type system inside and whatnot. Macros can make some small specific uses safe, indeed. But they are not comparable to languages with type systems where everything is type safe, unless you literally have written a new type system and compiler to begin with. Which is trivially true in every other…

> unless you literally have written a new type system and compiler This is entirely possible with plain lisp macros. See https://coalton-lang.github.io Having that natively available as plain Common Lisp code is a very different thing from your "just read a text block and compile it as rust code!" concept. Or at least, the tool chain gymnastics required to make a C program emit its own source in another language... W…

Well, I was talking about the fundamental part. Of course you can have more practical implementations, like Scala or rust's macro system, that gives you a proper typed AST.

Re: A road to Lisp: Why Lisp

#242
post #193

Earlier quoted context omitted.

Language design has almost nothing to do with language popularity. People learn JavaScript or TypeScript because they want to write web apps. Swift or Objective C to write iOS or Mac apps. SQL because there’s a database they need to get data out of. Python because there’s a machine learning library they need to use. Etc etc. Language design is far down the list of priorities.

I would refine that: Language design has only indirect relevance to language popularity. People go where the money is, hence python. But python is widespread because there is employment in it. That adoption by employers follows a network effect, but it originally came about through the language design. Early-adopter => mainstream => long tail Adoption hinges on that jump from evangelists to the mass market, and that…

When Python got its popularity, programming was an in-demand skill, so the thing that determined adoption was being easy for beginners to learn. Python was extremely beginner-friendly, so it became popular.

Now, the thing that determines popularity is popularity. So Python still wins, even though its beginner friendliness isn't so important anymore.

Re: A road to Lisp: Why Lisp

#243

Don't miss out, we had new excellent editors and tools being released in the last months: Mine: a complete, single-download application that comes with everything needed to experience the interactive and incremental development programming workflow, including hot-reloading and on-the-fly debugging. For CL and Coalton. https://coalton-lang.github.io/20260424-mine/ OLIVE: a new hand-made plugin for VSCode. ICL: a new R…

I can't find the source for `mine`. Do you have a link?

Re: A road to Lisp: Why Lisp

#244

> After getting comfortable reading code with so many parentheses I never managed to get over the (). Ruby has a very flexible syntax, compared to many other languages, in that you can omit syntax in many cases. For instance, using () for method calls is largely, for the most part, optional. So when I have the python code: cat = Cat() cat.meow() I find it worse than the ruby code: cat = Cat.new cat.meow (Though you c…

> the ruby code: ``` cat = Cat.new cat.meow ```

As a non-Ruby user, this confuses me. Why can't `Cat.new` be a function reference? Does Ruby explicitly disallow this (i.e. passing around a function)?

Re: A road to Lisp: Why Lisp

#245

In commercial practice DSLs are an anti-pattern. Someone will create an under-documented DSL that only they understand and move on. The following programmers have to try to decipher this strange language. It is almost always a better idea to use standard language structures and features. Code is read more than it is written.

Hate to break it to you, but every time you create a function, you're creating your own language, specific to the domain.

I suspect what you're actually objecting to is a lack of referential transparency, which is a problem in many languages (including Lisp, to be fair).

Re: A road to Lisp: Why Lisp

#246

In commercial practice DSLs are an anti-pattern. Someone will create an under-documented DSL that only they understand and move on. The following programmers have to try to decipher this strange language. It is almost always a better idea to use standard language structures and features. Code is read more than it is written.

In Lisp, those following programmers can simply macroexpand. With modern tools they can even do it inside their editor, co-located as replacement text in the same source file, connected to a live Lisp environment, if they wish.

A great example is Common Lisp's own LOOP macro - if someone's usage is difficult to understand, you simply ask Lisp to expand it into the more verbose non-LOOP fundamental calls, and you don't need to understand anything about LOOP. In fact you can replace the LOOP form with the expanded code.

That's a key difference from DSL's in most other languages where the DSL code is really data structures that are interpreted.

Re: A road to Lisp: Why Lisp

#247
post #227

Earlier quoted context omitted.

iLemming: creating a new user just to say that seems a bit over the top.

I don't know who that is. I don't play stupid social games to win stupid social prizes. Why would I create a new account and yet keep replying with another one? I have single accounts pretty much everywhere, except Reddit - they shadowbanned my first one when I posted while connected to a VPN (apparently that's not allowed). You can easily use some OSINT tools to confirm that.

Again though: please don't be an asshole. You're doing a disservice to Lisp.

Re: A road to Lisp: Why Lisp

#248

Earlier quoted context omitted.

I've found LLMs to be bad at balancing parenthesis. I've also found them to be less likely to hallucinate library types in dynamic languages, they tend to hallucinate arguments to library functions/methods instead.

> LLMs to be bad at balancing parenthesis Because you treating Lisp just like any other (non-homoiconic) PL. Give an agent a true Lisp REPL to mess around, and you'd be surprised. Things get very interesting. I still don't understand why more people don't do that - isn't that obvious first thing anyone should figure out? Like I can't even imagine working with Lisp without a REPL and structural editing - I'd immediate…

Yeah. In my GToolkit setup, I started with giving it eval. At first, it tried to "rebuild the world" for each task, but we gradually settled on a set of images for specific tasks that can be rebuilt as a separate step and are otherwise cached. That gave us fast eval, and it kinda snowballed from there. I thought I would need to implement some IPC into a live image, but the startup is fast enough that it doesn't matter too much. The agent now has both the textual source (in Tonel) on disk and can easily query a live image via CLI.

What do you think about making the agent write type annotations? There are built-in forms in CL, and in Smalltalk, I settled for pragmas for now. They are not checked, but since I started using them, I think the rate of one- or two-shotting solutions has gone up.

Re: A road to Lisp: Why Lisp

#249
post #75

Earlier quoted context omitted.

> I would like to see some articles that have a level-headed criticisms or critique of Lisp, it's ideas and it's place in the ecosystem of languages. Standardized Concurrency is basic table-stakes for a language today. CL does not have a standardized async/await or concurrency model. The standard hasn't been updated since 1995 so it will never happen.

And it remains in a state of almost getting to the point of generic collections (like C++, Clojure, many others) using the standard functions, but not quite getting there. There are functions (not generic functions) which operate on sequences, but no standard way to extend what types are considered sequences (as one example). It makes sense that the 1995 version of the spec would be incremental, but without a further…

I don't quite understand what you mean by generic collections in this case. Do you want to restrict a list to only contain one specific type?

Re: A road to Lisp: Why Lisp

#250
post #247

Earlier quoted context omitted.

I don't know who that is. I don't play stupid social games to win stupid social prizes. Why would I create a new account and yet keep replying with another one? I have single accounts pretty much everywhere, except Reddit - they shadowbanned my first one when I posted while connected to a VPN (apparently that's not allowed). You can easily use some OSINT tools to confirm that.

Again though: please don't be an asshole. You're doing a disservice to Lisp.

Da fuk you're talking about? Where the heck am I being an asshole? I have not used a foul language or insult in this thread once, even when someone accused me of being in a cult. Don't patronize me, even if you bought a moral authority on a discount - I'm not your fucking child. No matter how many times you say "please" and call me "asshole" I won't correct anything in my behavior because there's nothing to correct to begin with. What "disservice"? a) I could't care less about Lisp's popularity b) You seriously think someone, anyone would be like "don't look at Lisp... because there's one jerk in this specific HN thread. He said something in 2026. Eight levels nested down..."
Post reply on HN