Live data from Hacker News

These years in Common Lisp: 2023-2024 in review

lisp-journey.gitlab.io

31–40 of 54 posts

Re: These years in Common Lisp: 2023-2024 in review

#31
post #19

A few cool thing happened! I might give the CLOS course a try! I’m a functional guy but I feel CLOS isn’t your typical object system.

CLOS is great, but CL also supports pure typed FP with https://coalton-lang.github.io Coalton progress is discussed briefly in the OP: https://lisp-journey.gitlab.io/blog/these-years-in-common-li...

Coalton is its own language, just implemented and embedded in CL.

Re: These years in Common Lisp: 2023-2024 in review

#32
post #28
post #11

Earlier quoted context omitted.

Indeed, most successful FP languages have their OOP like approaches. Another thing all modern Lisps have since the 1980's, is all major data structures, not only lists as many think when discussing Lisp.

Having the data structures is nice and all, but using them is kind of painful. They are certainly second class. Having to use accessor functions or destructuring macros instead of just a period or -> is often annoying too. The lack of syntax has cons as well as pros.

I mean you can write a macro that let's you write

(object -> slot)

and transforms it to (slot object)

"->" should be unused

Re: These years in Common Lisp: 2023-2024 in review

#33
post #29
post #11

Earlier quoted context omitted.

Indeed, most successful FP languages have their OOP like approaches. Another thing all modern Lisps have since the 1980's, is all major data structures, not only lists as many think when discussing Lisp.

Common Lisp isn't a functional programming language to be clear.

It definitely isn't one, when instead of looking at it with the eyes of CS knowledge, people take the mindset whatever Haskell does.

FP predates Haskell by decades.

Re: These years in Common Lisp: 2023-2024 in review

#34
post #28
post #11

Earlier quoted context omitted.

Indeed, most successful FP languages have their OOP like approaches. Another thing all modern Lisps have since the 1980's, is all major data structures, not only lists as many think when discussing Lisp.

Having the data structures is nice and all, but using them is kind of painful. They are certainly second class. Having to use accessor functions or destructuring macros instead of just a period or -> is often annoying too. The lack of syntax has cons as well as pros.

Everything needed is place, there is no second class about using arrays instead of lists.

Re: These years in Common Lisp: 2023-2024 in review

#35
post #33
post #29

Earlier quoted context omitted.

Common Lisp isn't a functional programming language to be clear.

It definitely isn't one, when instead of looking at it with the eyes of CS knowledge, people take the mindset whatever Haskell does. FP predates Haskell by decades.

It also isn't one when "looking at it with the eyes of CS knowledge", given that Common Lisp has very powerful support for OO and procedural programming out of the box, and in order to most effectively use an FP style it's necessary to rely on community developed libraries...

Re: These years in Common Lisp: 2023-2024 in review

#36
post #35
post #33

Earlier quoted context omitted.

It definitely isn't one, when instead of looking at it with the eyes of CS knowledge, people take the mindset whatever Haskell does. FP predates Haskell by decades.

It also isn't one when "looking at it with the eyes of CS knowledge", given that Common Lisp has very powerful support for OO and procedural programming out of the box, and in order to most effectively use an FP style it's necessary to rely on community developed libraries...

What FP style? Haskell style, I guess.

When I learnt Lisp, Lisp and Scheme were FP, Miranda was still around, and Caml Light had just started being known outside INRIA.

I really dislike revisionism regarding what it means to be FP.

Re: These years in Common Lisp: 2023-2024 in review

#37
post #36
post #35

Earlier quoted context omitted.

It also isn't one when "looking at it with the eyes of CS knowledge", given that Common Lisp has very powerful support for OO and procedural programming out of the box, and in order to most effectively use an FP style it's necessary to rely on community developed libraries...

What FP style? Haskell style, I guess. When I learnt Lisp, Lisp and Scheme were FP, Miranda was still around, and Caml Light had just started being known outside INRIA. I really dislike revisionism regarding what it means to be FP.

The issue's that Schemes (and Clojure) are way more functional than Common Lisp and e.g. `funcall` feels like a kludge compared to lisp-1. If you read the old CL codebases or modern code, destructive and imperative use are common, so it doesn't feel terribly revisionist (just compared to pascal, c, bliss etc.).

Re: These years in Common Lisp: 2023-2024 in review

#39
post #37
post #36

Earlier quoted context omitted.

What FP style? Haskell style, I guess. When I learnt Lisp, Lisp and Scheme were FP, Miranda was still around, and Caml Light had just started being known outside INRIA. I really dislike revisionism regarding what it means to be FP.

The issue's that Schemes (and Clojure) are way more functional than Common Lisp and e.g. `funcall` feels like a kludge compared to lisp-1. If you read the old CL codebases or modern code, destructive and imperative use are common, so it doesn't feel terribly revisionist (just compared to pascal, c, bliss etc.).

Wikipedia page for “functional programming”:

”The first high-level functional programming language, Lisp, was developed in the late 1950s…”

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

Re: These years in Common Lisp: 2023-2024 in review

#40
post #18
post #14

The most unexpected news to me was that Hacker News, apparently, runs on top of SBCL now, via a secret implementation of Arc in Common Lisp!

Ya, when are we going to hear about "Clarc"? Where's the source?

I read that the source won't be made available because it contains some anti-spam (anti-abuse?) measures that would be easily circumvented if the source were open. Security through obscurity is famously no security at all, but I can see how it can reduce the noise that dang has to deal with a bit.
Post reply on HN