Live data from Hacker News

A road to Lisp: Why Lisp

scotto.me

201–210 of 322 posts

Re: A road to Lisp: Why Lisp

#201

Programming is in tension between the Light Side and the Dark Side. The Light Side is about preventing the programmer from making mistakes: Get rid of go-tos! Add static types! Do not allow a bug to be expressible. The Dark Side is about giving power to the programmer: Macros? Obviously. Operator overloading? Self-modifying code? Multi-line reg-exps? Go to town! The Light Side knows programmers are flawed and imposes…

it's dark side-ish at the ast level mostly, which is not the same as the dark side of mutable state over byte arrays

Re: A road to Lisp: Why Lisp

#202

Earlier quoted context omitted.

I'll paraphrase someone who commented on HN once (about dynamic vs static typing, IIRC): permissive languages are enablers for solo programmers, but you need more restrictive languages for team programming. This matches my experience because you don't chose who you work with. Skill level is uneven among the team. Less skilled co-workers will make mistakes that will have more consequences when the language is more per…

>This matches my experience because you don't chose who you work with. That's what job interviews are supposed to be for. It should be easy to hire only the most skilled programmers, especially with the massive number of unemployed programmers out there right now.

Maybe it's trivial what I'm saying, but hiring the most skilled available person does not solve the skill disparity.

Re: A road to Lisp: Why Lisp

#203
post #153

Earlier quoted context omitted.

Lisp generally has precise GC, which I'd say makes it light side. It's even relatively type-safe if you count runtime type-checking. Highly reliable systems are written in Erlang, which if you squint is another Lisp dialect. There's even a sexp-based version called LFE, for Lisp-flavored Erlang. Erlang's key to reliability is error recovery, rather than exceptional levels of error prevention. I do like your light sid…

> Erlang, which if you squint is another Lisp dialect Prolog disagrees. IIRC the first versions of Erlang were written in Prolog, and you can still see its influence in the syntax.

Correct, although I would assert Prolog shares many concepts with Lisp.

Re: A road to Lisp: Why Lisp

#204
post #152

Earlier quoted context omitted.

If you squint enough, JS is a lisp.. Define a goddamn language, syntax is not enough to define one! What are the semantics? Without that you are just talking about syntax trees like they would mean anything

> If you squint enough, JS is a lisp.. Yes, that is true. I'm not big on the idea that Lisp is defined by parentheses. The implementation strategies are another way to look at it. That doesn't capture it either, but it's an angle to try.

It isn't, Dylan and Julia are two Lisps with Algol like syntax.

Indeed there was a proposal to add Algol like syntax to Lisp,

https://en.wikipedia.org/wiki/LISP_2

Re: A road to Lisp: Why Lisp

#205
post #158

Earlier quoted context omitted.

No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holist…

Why do you think other people who have fallen in love with, say, Ruby, are less experienced in other languages? They just have less of a cult.

You sweet, summer child, just so you know, I have existed for nearly half a century in this world where the larger part of it I have spent dealing in computing. I have seen and dealt with more programming languages (including Ruby) than you can count with your fingers and toes and that number keeps growing still. I'm not advocating for any particular language, runtime, framework or paradigm - do use whatever your heart desires.

I'm simply pointing out that there is a meaningful difference in REPLs in homoiconic and non-homoiconic PLs. You don't have to listen to me, this is easily verifiable information. Google it, ask LLMs, try it yourself, or ignore the notion entirely - it's completely up to you. But let's not get too intimate and slide into insulting one another - you have no idea who I am and what cults I'm specifically fond of.

Re: A road to Lisp: Why Lisp

#206
post #195

Earlier quoted context omitted.

> Do not allow a bug to be expressible That is a very powerful idea, but unfortunately it cannot be realized with a fixed set of language rules. Some invariants are universal, but some are bound to the domain. Some projects require, say, an int (EvenInt) to take on only even numbers and others odds (OddInt). You can imagine the possibilities here are unbounded ("the numbers should be prefixed by numbers that are divi…

Well put. Minor quibble: I see what you're driving at with "inexpressibility" but i think i could write EvenInt and OddInt in F#. I don't know Haskell, but i believe you would have to work hard to find a domain constraint that you can't declare in the Haskell type system.

You are, of course, right about EvenInt being easy to express in a type system. In fact, I believe type systems are generally so expressive as to allow just about any constraint to be expressed (eventually..).

I notice a lot of arguments on this topic resolve to "but Turing", which is not completely uncalled for but I think misses the point a bit. Not because it is wrong, but because it highlights the wrong property.

I don't doubt, say, Brainfucks ability to express any arbitrary computation, but I do doubt its ability to do so sanely. Now you may say Haskell's type system is very clean, but some constraints will definitely push it out of its comfort zone. I'm not saying it won't be able to express them, but I am claiming there will be dragons. One example of a constraint that's at least awkward is when the absence of a fixed type is part of the design. There are of course myriad solutions to this problem but they generally all require not quite so straightforward constructions that eventually might make sense with enough exposure, but whose complexity can actually be disproportionate to the value of the guarantee.

It's very much a testament to the genius of languages like F# and Haskell that you have to think hard of practical counter-examples.

That said, I actually think the Dark/Light polarity rears its head again even deep inside Haskell as any sufficiently complicated software system encounters barriers it needs to overcome and those require carefully constructed escape hatches: unsafePerformIO, metaprogramming, that is to say, the (relative) Dark Side.

In that metaphor undisciplined use of Lisp is like a vast, dark gravitational field of possibility and Haskell is like a sea of light with some carefully marked dark patches.

Re: A road to Lisp: Why Lisp

#207

[dead]

I would be very interest in seeing how "getting lisp" enables you to write software that is more successful than the C and C++ software that runs the world. Perhaps you have written software in Lisp demonstrating this? Something you can show us?

Go ate a big lunch from Java, C and a bit of C++ as a systems' language, which Go was designed as "C sucessor without the C++ bullshit". Even the most modern C (Plan9/9front, not what the ANSI C comitee vomits in every iteration) it's a very different beast.

Still, Common Lisp it's in places where trying to build such kind of software in C/C++ would be a reciper for disasters.

https://www.lispworks.com/success-stories/index.html

Re: A road to Lisp: Why Lisp

#208
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…

I've never much luck selling a language on cleat benefits alone, but I guess there's not many climbers in my department.

Re: A road to Lisp: Why Lisp

#209
post #14

All roads lead to Lisp

What has Lisp ever done for us?

"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

- Guy Steele, Java spec co-author

"35 years of Lisping at SISCOG"

https://www.siscog.pt/en-us/blog/35-years-of-lisping-at-sisc...

https://en.wikipedia.org/wiki/Emacs

https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-A0E9...

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Re: A road to Lisp: Why Lisp

#210

I’m guessing there’s some way for a Lisp program to load a DLL and call a function in it so writing a Windows application using the Windows App SDK is likely possible. The one part I can’t imagine is how do you pass a Lisp function as a callback?

Yes, Allegro Common Lisp, and Lisp Works support this just fine.
Post reply on HN