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

Why Lisp?

nyxt.atlas.engineer

Post reply on HN
Print view View original

181–190 of 339 posts

Re: Why Lisp?

#181

Post by garbagecoder »

Paul-Craft wrote: post #154

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good i…

They don’t mention Clojure at all either. Since it runs on the JVM, if the JVM can do it, so can Clojure, even if inelegantly.

I used it on one project where there was a wage involved, just one, but I do love it.

Re: Why Lisp?

#182

Post by ibiza »

eterevsky wrote: post #111
lisper wrote: post #104

Earlier quoted context omitted.

It depends on how you write the code and the compiler you use, but Lisp can be as fast as if not faster than C. But the main thing is that in Lisp it's easy to turn the dial between speed and other things you might want to optimize for like safety and debugability. Making C code memory safe is a lot of work at best, and actually impossible at worst.

You could write safe-ish C++ and Rust that is both readable and fast. Could you point me to some benchmarks of Lisp being comparable to C? Also, unless I am mistaken, Common Lisp doesn't have strong types. How can you make either fast or safe language without compiler knowing the types?

Your point stands, but I think you're arguing about static vs dynamic typing, rather than strong vs weak typing.

CL is dynamically typed (values have types, not variables), w/ strong types (automatic type coercions are rare).

Re: Why Lisp?

#183

Post by sulam »

jcranmer wrote: post #151
lisper wrote: post #144

Earlier quoted context omitted.

> I am not sure how "native threads" == "green threads" You are still confused. Green threads and native threads are mutually exclusive implementation strategies for threads. Native threads are provided by the O/S. Green threads are implemented at the user level without relying on any O/S capabilities. Green threads, by definition, run in a single O/S process and can therefore only use one core. > look up Erlang/Elix…

FWIW, you are literally the first person I've seen who has insisted that green threads are incompatible with an M:N threading model. Every other definition I've seen for green threads is that they involve userspace scheduling, and there's no requirement that there must be but one thing that something can be scheduled onto.

There’s history here. Green threads are as opposed to native, you both agree on that. The original green threads were pretty weak and behaved as described above. People use the green threads term today to mean a much more featured version that is as you describe it. Lisp also has it. So really everyone is right, except for your statement that Lisp does not have green threads. It has native, old style green and new style green threads.

Re: Why Lisp?

#184

Post by skissane »

lisper wrote: post #152
jcranmer wrote: post #151

Earlier quoted context omitted.

FWIW, you are literally the first person I've seen who has insisted that green threads are incompatible with an M:N threading model. Every other definition I've seen for green threads is that they involve userspace scheduling, and there's no requirement that there must be but one thing that something can be scheduled onto.

It's possible that the definition has changed; (human) language is malleable. But the original definition of "green thread", which goes back at least to the 1990s, was in contrast to "native thread" where the latter was implemented by the operating system and the former by the language implementation. The whole point of "green threads" was that they let you do something that looked like parallel processing (but was r…

Traditional, purist definitions: 1:1 threading = native threads, N:1 threading = green threads, M:N threading = hybrid threads (since it is a hybrid of the native and green approaches)

However, a lot of people nowadays call M:N threading "green" instead of "hybrid". Just Google it you will find lots of people using the term in this way. From a traditional purist viewpoint it is an incorrect usage, but it is also now very common. I guess part of the reason is that green threads in the original sense is less useful today – one of the major historical motivators was it could run on OS platforms which lacked native threads, which was a common problem in the mid-1990s and earlier but nowadays almost never is – so it is unsurprising the term gets stolen for a closely related yet distinct technology with far greater contemporary usefulness.

Wikipedia's article – https://en.wikipedia.org/wiki/Green_thread – essentially contradicts itself. The start of the article gives the traditional definition of "green threads". But then the "Green threads in other languages" section ends up describing lots of things which are much closer to being "hybrid threads" than "green threads". This is the problem with an "encyclopaedia which anyone can edit", it is easy to unintentionally edit an article into contradicting itself, and on highly technical topics it is easy for the contradiction to go unnoticed. I myself am not sure I can fix it, because although I know the true story about the definitions (or at least I think I do), I don't know any reliable source to cite for it.

Their thread article – https://en.wikipedia.org/wiki/Thread_(computing)#Threading_m... – does define M:N as "hybrid threading", whereas it calls N:1 "user-level threading". It also notes "green threads" as a synonym for "user threads"–but "user threads" aka "green threads" exist in both the M:N and N:1 models. It never defines "green threads" as a model as opposed to as a type of thread which exists in two out of the three models.

Re: Why Lisp?

#185

Post by sulam »

pdimitar wrote: post #160
lisper wrote: post #157

Earlier quoted context omitted.

> why hasn't anyone done it yet and made it easy to consume for everyone else? Dunno. No demand? No standard? I recently wrote a library like this for my job. It took me about a day. I haven't published it because it was a work for hire and so it's not mine to publish. But it's the basis for my confidence that it's not hard to do. If you want to write up a spec, I'm available for contract work (and I'm sure you would…

I mean, high-quality work should be paid. Obviously. But now we're making a full U-turn to my initial argument: LISP doesn't have features that I find are (or should be) basic building blocks so I am just taking my business elsewhere.

I think you are being willfully disagreeable here. There is a Lisp with the style of threads you claimed doesn’t exist. So you’re simply wrong with your claim. Also even if that didn’t exist, no one can say that a day’s worth of work is a prohibitive barrier to getting things done.

Re: Why Lisp?

#186

Post by whartung »

varjag wrote: post #136
dehrmann wrote: post #61

> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 2…

> You could say the same about Java and 20 years. Really doubt you'll get your EJB project from the day going now without major rework.

Not necessarily.

The biggest rock in the pond recently is the Great Renaming to Jakarta, but many containers still support the older package names.

The only real legacy stuff from 20 years ago that has truly died on the vine is Entity Beans. But even then, Entity Beans we’re mostly horrible, and not many folks used them.

But they may well still be supported in some modern containers.

That said the old style way of using XML for everything (notably declarations of Session Beans and such) still exists today. Annotations rule the day today, but the old XML style still exists, and has not been deprecated, or if it has, it’s quite recently.

There is in fact a lot of backward compatibility stuff still there in the modern containers because fundamentally the concepts have not changed, just how they are expressed in modern runtimes.

Re: Why Lisp?

#188

Post by schemescape »

Paul-Craft wrote: post #154

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good i…

I'm not qualified to respond, but I switched from Scheme to Common Lisp for CL's condition system and REPL.

Other than Smalltalk and some very niche languages, I couldn't find any languages that, after hitting an error, let me reliably interactively inject new/replacement code from my code editor and then re-run the function (obviously assuming it is reasonable to do so).

Re: Why Lisp?

#189

Post by schemescape »

vindarel wrote: post #76
eimrine wrote: post #21

The article seems like mostly about Common Lisp, but how many of the points are applicable to rest of Lisps? (Scheme, Emacs Lisp, Janet, etc)

Racket has mediocre interactive features or so I hear: https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1... > no condition/restart but just print you a trace, and little runtime inspector/debugger support CL really was built with interactive support from the ground up. I don't think Janet has many?

I'm curiuos about the interactivity of Janet as well. I saw that someone added support for opting into a level of indirection for resolving symbols, which would theoretically support re-defining functions interactively. There also appears to be Conjure support for editor integration.

In my case, I wasn't convinced Janet would support REPL-driven programming like Common Lisp, so I decided to try CL first. I very much like the concept of Janet (a Lua-sized Lisp), but I couldn't identify a compelling reason to choose Janet over CL in my case (just some hobby projects).

Re: Why Lisp?

#190

Post by proamdev123 »

dragonwriter wrote: post #170
kerkeslager wrote: post #169

Earlier quoted context omitted.

You might want to check out Racket. It's not immediately obvious that it's a Scheme, but it has a much more vast ecosystem of libraries than any other Scheme I know of.

Racket is no longer called PLT-Scheme because its not a Scheme, though it includes some and is still closely related.

What about Racket makes it not a Scheme?
Post reply on HN