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

241–250 of 339 posts

Re: Why Lisp?

#241

Post by pdimitar »

skissane wrote: post #184
lisper wrote: post #152

Earlier quoted context omitted.

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…

Thanks a lot for the context. I wasn't aware of the distinction between green vs. hybrid threads and was only using "green threads" I suppose as "suspendable coroutines" or "fibers"? Not sure about that either, gotta admit.

Re: Why Lisp?

#242

Post by pdimitar »

sulam wrote: post #185
pdimitar wrote: post #160

Earlier quoted context omitted.

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.

I suppose part of the context got lost here but no, I haven't gotten out of my way to disagree specifically; more like I got frustrated because the other guy seemed to purposefully miss the point from where I was standing.

I don't want just a best-effort-with-what-we-have-in-our-runtime-that-was-not-ever-designed-for-it implementation however, I want proper preemptive scheduling and a transparent M:N threading model, very akin to what Erlang/Elixir have.

I was made aware of Clojure's core.async but after reviewing it, it's IMO not good enough. Though as others have said it can be used as a building block for something better. That seems to be true as well.

Re: Why Lisp?

#243

Post by pdimitar »

lisper wrote: post #178
pdimitar wrote: post #165

Earlier quoted context omitted.

Was I vague? Or were you being overly pedant about Wikipedia-sourced definitions that, as another commenter pointed out, are kind of outdated? And now trying to frame me as not knowing what I want? And pretending that the examples I gave about three other languages don't paint the picture well enough? You seem to be arguing in bad faith from where I am standing. ...And okay -- I'd like a M:N green threads runtime (or…

> Was I vague? Well, here's what you originally wrote: > Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, and OCaml 5.0's recent multicore runtime (and the emerging libraries around it)? > I want the higher-level stuff. I want to solve problems and not invent a new async orchestration runtime for every project I work on. That seems prett…

Well it is an argument insofar as you keep insisting that the LISP ecosystem has what I want, and I keep disagreeing with that claim.

But yep, I want Erlang-style concurrency / parallelism and, failing that, something like Golang builtins or Rust's libraries.

So not a subset or intersection, more like a priority-ordered wish-list: I want what I perceive as an ideal model (Erlang) but if that's not available, there is stuff 1-2 floors below that are good enough (Golang, Rust).

But native threads or fully cooperative opt-in parallelism are practically a drag (or were in the projects I used them) and aren't cutting it for the work I do.

I'll grant you that the building blocks for something like what I need are there but I am not willing to put the work to create the runtime / the library, nor pay anyone to do it for me. Hence my original post: I am commenting on the status quo, not on how it could theoretically change at any time. I find the latter of no consequence.

Re: Why Lisp?

#244

Post by pdimitar »

kraf wrote: post #202
pdimitar wrote: post #173

Earlier quoted context omitted.

Other commenters say it's nowhere close to what I'm looking for, btw. And let me repeat that I am not looking for the old-school OS threads support. Almost all programming languages have that. It's nowhere nearly good enough.

It has Go style concurrency, look for `core.async`. Maybe it could have been said that it wasn't lightweight enough and that would have been due to the JVM not providing the primitives but they're here now under the name "Virtual threads".

IIRC somebody in this thread said it's not preemptive and doesn't have enough functionality. Quickly looking at it, it seems to be fully opt-in / cooperative parallelism solution which is IMO not good enough.

Re: Why Lisp?

#245

Post by medo-bear »

dataangel wrote: post #194
vindarel wrote: post #130

Earlier quoted context omitted.

> static strong typing Alright, here is it: https://github.com/coalton-lang/coalton/ > small efficient native binaries The numbers are: with SBCL's core-compression, a web app with dozens on dependencies will weight ±30 to 40MB. This includes the compiler, the debugger, etc. Without core compression, we reach ±150MB. > The actor runtime? the actor library : https://github.com/mdbergmann/cl-gserver > couldn't find a w…

Coalton doesn't actually work: https://github.com/coalton-lang/coalton/issues/84?s=09 This is why it's important to always look at the issues on a repo instead of just believing what's in the README. It fails to detect type errors in some of the most basic situations

> This is why it's important to always look at the issues on a repo instead of just believing what's in the README

this makes it sound like the developers are lying whereas the issue was raised by one of the core developers

> fails to detect type errors in some of the most basic situations

i dont think this is a basic situation. i wouldnt do mutation at coalton level, instead at lisp level

Re: Why Lisp?

#246

Post by koningrobot »

7thaccount wrote: post #40

After learning Python, I wanted to take the next step and find what was better. I looked into a lot of languages reading books on Haskell and Lisp and many others. At least for my use cases (desktop scripting, numerical work... etc) I didn't find Lisp to be superior. Most of what I actually needed to do could be done simpler in Python. Python's REPL isn't near as good as CL, but it's good enough. Then the batteries i…

The one thing that I most wish Python had is Common Lisp's restartable conditions. They're like exceptions but they don't break your whole process if you don't handle them in the code. If you forgot to define a variable, you'll have the option to define it and resume computation. If you forgot to provide a value, you'll be able to provide one now and resume computation. As it is, Python just dies if something unforeseen happens, which feels like a missed opportunity given that Python is a dynamic language (for which it pays a price).

I work in ML, and launching a job on a cluster just to have it fail an hour later on a typo got old ten years ago. Being able to resume after silly mistakes would easily reduce debugging time by an order of magnitude, just because I need to run the job only once and not ten times.

Re: Why Lisp?

#247

Post by hajile »

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 have some reasons.

* Even the fastest of the schemes is slower than SBCL.

* The interactive development features in Common Lisp are there because they got baked into the spec. They aren’t really a thing with scheme.

* Common Lisp has a specification everyone follows. Scheme has THREE completely different specs everyone fights over. Version 6 is the LEAST common (though probably the best for real work), but it’s also the choice of Chez scheme which is the fastest implementation (last I checked).

* Related are the SRFIs. There’s over 200 of them. The language isn’t useful unless a bunch of these have been baked into the compiler. This is HORRIBLE for users. If you want to do something, you must search the SRFIs, find the correct one, look up if it’s actually supported, then read the spec because implementations don’t actually documents this stuff in their own docs. https://srfi.schemers.org/

This all makes portability a disaster. Imagine trying to make a library that works across three versions of the language (all with different features and ways of doing basic things like importing code). Next, you have to work around which implementations support which basic SRFI (eg, Can I use list operators beyond car/cdr? Can I use basic string operators? Mutable arrays? Hash Tables? Records? Threads? Integer bitwise operators? Streams? The other 200+ SRFIs that cover basic stuff that should have been in the language itself?

The result is everyone constantly recreating the wheel in slightly different ways. R7RS-large was supposed to fix some of the worst of these issues, but we’re 10 years out now and still waiting.

Re: Why Lisp?

#248

Post by actuallyalys »

lispm wrote: post #208
latenightcoding wrote: post #205

Earlier quoted context omitted.

>> it does not use linked lists at its core does Clojure? I can implement a Scheme interpreter that passes most test suites using vectors instead of linked lists, would you not consider it a lisp?

> I can implement a scheme that passes most test suites using vectors instead of linked lists, would you not consider it a lisp? My Symbolics Lisp Machine has a Lisp implementation where some form of vectors are an optimization of lists (-> CDR coding). But that's an implementation detail. For most purposes the thing behaves as it uses linked lists - and even has primitive operators for linked lists as CPU instructio…

JavaScript and R are more Lisp-inspired to me. I tend to think of the Lisp family as containing Scheme, Clojure, and other languages with a fairly close resemblance. Common Lisp, its predecessors, and a few other languages like uLisp are more closely related still and are practically, if not strictly, the same language.

I’m not sure this informal taxonomy is “right,” but it seems to be useful and in line with common usage.

Re: Why Lisp?

#249

Post by giraffe_lady »

schemescape wrote: post #189
vindarel wrote: post #76

Earlier quoted context omitted.

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…

Janet has the pieces for this in the spork stdlib with netrepl combined with fibers, but there's no standard or pre-configured way to set it up. Its current approach to namespaces doesn't particularly allow for it either, so you have to choose one of a few various hacks for redefining things as you noticed.

People have been asking for it and demonstrating proofs of concepts for the last year or so so it wouldn't surprise me to see it formally addressed soon. But I don't know, I don't have any particularly insight I just like that language and keep half an eye on it.

Re: Why Lisp?

#250

Post by User23 »

ravi-delia wrote: post #38
User23 wrote: post #27

Earlier quoted context omitted.

One never notices the inconvenience of not having something one is unaware of. This is the biggest challenge for answering “why Lisp?” It’s different enough from the programming that most people are used to that it rises to the level of a radical novelty, with all the explanatory difficulties that entails. In fact, it’s a defining characteristic of the radical novelty that it can only be understood experientially. An…

It's possible that you have experienced an enlightenment that I have yet to, but ultimately I like lisp because parenthesis are pretty, I hate remembering syntax, keywords/symbols are nicer than immutable strings, and typing out commas makes me sad (not that you'd know it from the way I abuse them in this comment). I mean, lots of languages have REPLs now- people get that they're really useful! This isn't secret know…

Nothing you say is in any way incorrect and I agree with it. However, for me, the experience of writing Lisp is very different from that of writing Ruby, or Perl, despite the latter languages having a great many Lispy features. In fact I jokingly call Perl a Lisp-6ish, because of how typeglobs let you mess with the symbol table directly and it has separate namespaces for SCALAR, ARRAY, HASH, CODE (I think that's the subroutine namespace), and a few others if I recall correctly. It's been a bit since I wrote any XS which is pretty much the best way to grok Perl internals. And that difference comes down to interactivity. I totally agree that REPLs are great and can bring a measure of interactivity to other languages. Except I barely ever use the REPL when I'm writing Lisp. I just evaluate the current form directly. Haven't you ever wondered why DEFPARAMETER and DEFVAR both exist? Having both makes no sense in a world where the Common Lisp REPL as equivalent to, say, irb. I'd say that notebooks are where non Lisp languages are coming closest to a kind of Lispy/Smalltalky interactive programming environment. And yes you can do some very very clever things with the JS console in a browser that are in tune with the Lisp way. And that's no surprise since JavaScript was originally a Lisp DSL and that very much shaped its philosophy.

Interestingly enough the Lispiest non Lisp dev experience I've professionally had is writing java 8 using Eclipse on the JVM treating the unit test runner as a kind of C-x C-e. It's no wonder Clojure was such a good fit for the JVM.

Post reply on HN