Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Idea of Lisp

dev.to

Post reply on HN
Print view View original

321–330 of 348 posts

Re: The Idea of Lisp

#321

Post by grzm »

dTal wrote: post #319
qwertyuiop924 wrote: post #259

Earlier quoted context omitted.

Racket isn't Scheme. It is its own dialect. That's why it's no longer called Scheme. At present, there are only a few Schemes that are practical: Chicken, Guile, Chez, and Gambit seem to be the big players, with Cyclone, Chibi, and Bigloo bringing up the rear.

Wow, pedantic much? It started out as a pure Scheme, then "took a practical turn" as the parent said. You can still make it act like a pure Scheme with a #lang directive. It's also kind of funny that a handful of major, practical implementations is considered a low amount. Number of Python implementations? Between one and three, depending on definition. Number of Javas? 2 or 3 again. Number of Clojure implementations…

Number of Clojure implementations? One.

At least three:

- Clojure on the JVM: https://github.com/clojure/clojure

- ClojureScript (JavaScript): https://github.com/clojure/clojurescript

- Clojure on the CLR: https://github.com/clojure/clojure-clr

Re: The Idea of Lisp

#322

Post by qwertyuiop924 »

dTal wrote: post #319
qwertyuiop924 wrote: post #259

Earlier quoted context omitted.

Racket isn't Scheme. It is its own dialect. That's why it's no longer called Scheme. At present, there are only a few Schemes that are practical: Chicken, Guile, Chez, and Gambit seem to be the big players, with Cyclone, Chibi, and Bigloo bringing up the rear.

Wow, pedantic much? It started out as a pure Scheme, then "took a practical turn" as the parent said. You can still make it act like a pure Scheme with a #lang directive. It's also kind of funny that a handful of major, practical implementations is considered a low amount. Number of Python implementations? Between one and three, depending on definition. Number of Javas? 2 or 3 again. Number of Clojure implementations…

>pedantic much?

Not at all.

>It started out as a pure Scheme, then "took a practical turn" as the parent said.

False.

PLT Scheme, like all serious schemes, started out as Scheme extended for practical use.

Racket, what PLT Scheme became, isn't an extended Scheme: it is a different language with its own semantics. That's not good, bad, or pedantic, but it is true.

>You can still make it act like a pure Scheme with a #lang directive.

No, you can make it use RnRS. The difference is that in actual Schemes, the language you write in is extended RnRS, not an entirely different language.

At the end of the day, calling Racket a Scheme is like calling Java a C: they look similar, but they are radically different under the surface.

Re: The Idea of Lisp

#323

Post by anoctopus »

kazinator wrote: post #317
anoctopus wrote: post #294

Earlier quoted context omitted.

Could you explain what you think is wrong with Clojure? Maybe it's because I've spent far more time using it than CL, but I see Clojure as having a very consistent, well designed core. It's very opinionated in it's design, but it's a practical and pragmatic one. I don't see what's unlispish about it.

All that immutability humbug, for starters. Traditional Lisps are "everything you can access is mutable". Lisp trusts the programmer to be responsible with mutability and not to abuse it. The trust is not misplaced; the sky doesn't fall.

Immutability was what I had in mind calling it opinionated, and it's an opinion I agree with. After learning Clojure, I now hate working in languages with mutability. It obviously isn't necessary to make working applications, but I like not having to think about where else I'm passing this particular data structure, and the language has enough escape hatches for places when it really would get in the way.

Re: The Idea of Lisp

#324

Post by dTal »

grzm wrote: post #321
dTal wrote: post #319

Earlier quoted context omitted.

Wow, pedantic much? It started out as a pure Scheme, then "took a practical turn" as the parent said. You can still make it act like a pure Scheme with a #lang directive. It's also kind of funny that a handful of major, practical implementations is considered a low amount. Number of Python implementations? Between one and three, depending on definition. Number of Javas? 2 or 3 again. Number of Clojure implementations…

Number of Clojure implementations? One. At least three: - Clojure on the JVM: https://github.com/clojure/clojure - ClojureScript (JavaScript): https://github.com/clojure/clojurescript - Clojure on the CLR: https://github.com/clojure/clojure-clr

I stand corrected. That was the only one I didn't check out. I didn't know about Clojure on the CLR but in fairness I should have remembered Clojurescript.

Re: The Idea of Lisp

#325

Post by anoctopus »

qwertyuiop924 wrote: post #307
anoctopus wrote: post #294

Earlier quoted context omitted.

Could you explain what you think is wrong with Clojure? Maybe it's because I've spent far more time using it than CL, but I see Clojure as having a very consistent, well designed core. It's very opinionated in it's design, but it's a practical and pragmatic one. I don't see what's unlispish about it.

Well, there's the fact that lists aren't conses, and conses as Lispers would expect them to exist don't. I think conses are pretty useful. But Clojure has the cons operator anyways. This also means that clojure's `read` violates one of read's important guarantees: the structure you read in will be identical to the structure you wrote out. Then there's the macro system. Given, it's better than CL's in some respects (i…

I agree that it isn't the One True Lisp, because there will never be one. Clojure is just a nice, modern lisp with some ideas I really like at the core of it's design.

I don't really care about having conses the way CL has them, and seqs feel like a very nice abstraction over the concept, though I also tend to use the idiomatic map-heavy style anyway.

Clojurescript has the staged macro issue, but JVM Clojure doesn't.

I wouldn't even say that Clojure has an object system, and wouldn't want one. Lacking TCO is a shame.

Re: The Idea of Lisp

#326

Post by ilurkedhere »

anoctopus wrote: post #294
qwertyuiop924 wrote: post #258

Earlier quoted context omitted.

Clojure's an odd, unlispish language, at least for us Lispers and Schemers. CL is still very good at what it does: all current implementations have solved many of the problems you mentioned, and there are a lot of libraries that will run across implementations. CL is a beast, but clojure is a mess. Scheme is elegant, but has a radically different, more ALGOL mentality than CL, at least in some respects. Some of it is…

Could you explain what you think is wrong with Clojure? Maybe it's because I've spent far more time using it than CL, but I see Clojure as having a very consistent, well designed core. It's very opinionated in it's design, but it's a practical and pragmatic one. I don't see what's unlispish about it.

I use Common Lisp, and now sometimes Clojure. I don't get why folks call Clojure a modern-Lisp. I miss the cons cell abstraction, the multiple values support, condition system, the fast start-up times, the native compilation, and executables.

Stacktrace in Clojure with no possibility to restart also make me sad.

Re: The Idea of Lisp

#327

Post by rntz »

bogomipz wrote: post #289
btilly wrote: post #277

Earlier quoted context omitted.

My understanding is that the first version of Lisp with true GC was Scheme. Which was, not coincidentally, the first version of Lisp with lexical scope and closures. The first implementation of Lisp used reference counting.

I am confused by your comment, reference counting is a form of GC. Could you elaborate?

Often reference counting is considered distinct from GC; sometimes the term "tracing GC" is used to disambiguate. Refcounting & tracing GC have the same purpose, but different implementation techniques and performance implications; and perhaps more importantly, reference counting can't collect objects which cyclically reference one another.

Re: The Idea of Lisp

#328

Post by rntz »

Ericson2314 wrote: post #313
stcredzero wrote: post #156

Earlier quoted context omitted.

Challenge: Write a Turing complete machine using a finite number of registers and a state machine. One or all of the registers can contain a rational number of unlimited precision. (This has already been done, so if you are aware of the existing machines, you have to create a new one.)

This...is not possible?

No, it's possible. The key insight is that a "rational number of unlimited precision" can be used to store an arbitrarily large amount of data; it can emulate a Turing machine's unlimited working tape.

Re: The Idea of Lisp

#329

Post by qwertyuiop924 »

ilurkedhere wrote: post #326
anoctopus wrote: post #294

Earlier quoted context omitted.

Could you explain what you think is wrong with Clojure? Maybe it's because I've spent far more time using it than CL, but I see Clojure as having a very consistent, well designed core. It's very opinionated in it's design, but it's a practical and pragmatic one. I don't see what's unlispish about it.

I use Common Lisp, and now sometimes Clojure. I don't get why folks call Clojure a modern-Lisp. I miss the cons cell abstraction, the multiple values support, condition system, the fast start-up times, the native compilation, and executables. Stacktrace in Clojure with no possibility to restart also make me sad.

Conditions are something I miss in Scheme. They sort-of-not-really exist in my Scheme of choice, and it makes me sad.

Re: The Idea of Lisp

#330

Post by bpicolo »

yogthos wrote: post #287
bpicolo wrote: post #6

Does anybody have a few examples of DSLs people make in a lisp (ideally clojure because I have worked with it a tad)? I've seen plenty of cases where people make a pseudo-dsl via optional arguments, but not seen this so-oft mentioned "yeah we just wrote a dsl for it because lisp" sort of deal.

A few good examples in Clojure would be: core.async https://github.com/clojure/core.async core.match https://github.com/clojure/core.match Compojure https://github.com/weavejester/compojure Midje https://github.com/marick/Midje Korma http://sqlkorma.com/

Serious question: Why are these considered "DSLs"? To me, these are just libraries with functions. Are they considered DSLs just because Lisps are basically an AST to begin with? Because when I think of a DSL, I think of something like SQL, or HTML, that is definitively different syntax, with it's own interpreter, for a specific purpose.

Function calls in Clojure doesn't match with the definition of what's in my head here. This is sort of what I was getting at in my original comment.

Post reply on HN