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

271–280 of 339 posts

Re: Why Lisp?

#271

Post by pmarreck »

stefcoetzee wrote: post #260
pmarreck wrote: post #254

Earlier quoted context omitted.

How did they make Babashka (it’s apparently spelled that way) instantly start? Do they pre-warm a Java thread in the background? Do math errors still dump Java stack traces in Clojure? That and the lack of syntax once ruled it out for me.

Babashka runs on GraalVM, as opposed to the usual JVM. I understand the frustration with Clojure errors, but am surprised that a lack of syntax would rule a programming language out.

I don't know of a rational basis for this other than simply being more comfortable with more syntax and fewer parentheses to trace visually. I did take a class in Scheme once so I'm not completely unfamiliar with coding in a Lisplike.

Re: Why Lisp?

#272

Post by reikonomusha »

dataangel wrote: post #195
jabradoodle wrote: post #102

Earlier quoted context omitted.

There are staticly typed and gradually typed lisps. Clojure also has a similar concurrency to go with channels.

Coalton doesn't really work ( https://github.com/coalton-lang/coalton/issues/84?s=09 ) and Typed Racket is only typed outside macros (and I don't just mean that macros are hard to type, I mean the imperative code you write to generate code is not type checked). Any others?

I can't speak for dataangel's requirements but Coalton does work, as I discussed here [1].

[1] https://news.ycombinator.com/item?id=35863429

Re: Why Lisp?

#273

Post by lispm »

actuallyalys wrote: post #248
lispm wrote: post #208

Earlier quoted context omitted.

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

what is this fairly close resemblance? Parentheses?

There are a bunch of Lisp like languages without s-expression syntax: Lisp 2, Logo, MDL, RLISP, CLISP (not the CL implementation), Dylan, Racket with its new syntax (Racket2, Rhombus), Skill, ...

For example Dylan is based on Scheme & CLOS + a different syntax + some other influences. https://opendylan.org

https://github.com/dylan-lang/opendylan/blob/master/sources/...

Re: Why Lisp?

#274

Post by reikonomusha »

foldr wrote: post #263
medo-bear wrote: post #238

Earlier quoted context omitted.

sure taken separately that looks more elegant. but, provided your whole program is complex enough, i think if you take a step back your language of choice is gonna look like a pigs sty compared to the same thing written in common lisp. i think the amazing thing about common lisp as a high level language is that it can be a low language also. imo it is an unmatched balance of a high/low level language

Are there any examples of elegant CL code that performs lots of vector geometry calculations? I'm skeptical that this sort of code would come out elegantly in CL (at least if it had to perform reasonably well).

This isn't a direct answer to your question (it's not a computational geometry codebase), but one option for implementing geometry might be to use MAGICL. [1] It is optionally and transparently accelerated by BLAS/LAPACK.

[1] https://github.com/quil-lang/magicl/blob/master/doc/high-lev...

Re: Why Lisp?

#275

Post by lispm »

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 like Scheme, but prefer Common Lisp for its environments and the old-school feel of the language.

> And there are some solid standards

Good things don't come alone: R5RS, R6RS, R7RS, RNRS + SRFI X..Y, IEEE Scheme, Racket, ...

> entry for 'kludges'

That's a form of self-deprecating humor, if you missed it. There are many more funny index entries in CLtL. The core designers did not take themselves too serious. Especially Guy L Steele.

For example Dave Moon said about the search for a name for the language:

"...whatever we call this common Lisp" and this time, among great sadness and consternation that a better name could not be had, it was selected."

Re: Why Lisp?

#276

Post by lispm »

kerkeslager wrote: post #168
xmcqdpt2 wrote: post #158

Earlier quoted context omitted.

I recently decided to try a scheme and did not find any that had supported Windows as a first class platform, so that's one limitation. By comparison SBCL just runs on Windows without any difficulties.

Racket has supported Windows since I tried it out in high school, which was a long, long time ago. The thing with Schemes is that you can implement one in an afternoon, and you can probably add some neato feature in the same afternoon, so there are a ton of Schemes out there. But you can't build community, ecosystem of libraries, platform support, etc. that you would want for a language you're going to use in product…

Common Lisp has Allegro CL and LispWorks, both with GUI libs, interface builder and extensive support for Windows.

Re: Why Lisp?

#277

Post by bjoli »

hajile wrote: post #253
bjoli wrote: post #218

Earlier quoted context omitted.

Is it? HN is mostly static content. Ten years ago I wrote a simple web application using twister (python) that did well over a thousand requests per second. If we count just handling requests (and not churning out much data or doing anything fun processing) japronto for python claims to handle something like 1.2 million req/s on a single thread.

The most frequently access parts of the site are always in flux with users constantly adding, removing, and editing content. I don’t know how you could statically generate that. At most, you could memoize the parts of the page that haven’t changed yet and return them without a complete lookup, but keeping that in synch with a database is not an easy problem.

You could regenerate the start page every 5s and comment pages whenever you need (new, edited or deleted comments) or every request if there has been more than 30s since it was last updated.

That would leave the serving to some of the applications being good at that (varnish?).

Finding the right heuristic regarding page regeneration might take some tweaking, but the amount of generating you have to do is small enough not to bother any single threaded program.

Re: Why Lisp?

#278

Post by [deleted] »

Capricorn2481 wrote: post #267
erichocean wrote: post #192

Earlier quoted context omitted.

Clojure does all three: 1) Native, compiled binaries with GraalVM. 2) ClojureScript (already mentioned) for the browser. 3) For ML, Clojure in the last 2-3 years has built a really great internal ecosystem but it hardly matters because libpython-clj exists so you can run NumPy, PyTorth, etc. from Clojure. Getting data in and out of Python land is just as easy as Java-interop. The reverse also works (calling out to Cl…

ClojureDart is not ready. I would be surprised of ClojErl was. And GraalVM is not some drop-in native compiler. You might have to radically change your code to work with GraalVm. Proposing these things as "ready for the average Clojure noob" is exactly the snake-oil nonsense that turns people off to Clojure

[deleted]

Re: Why Lisp?

#279

Post by bjoli »

funcDropShadow wrote: post #214
bjoli wrote: post #206

Earlier quoted context omitted.

What about it is head and shoulders above other lisps? The ecosystem? The lack of first class continuations? All the things that can be portably implemented in any language?

Clojure makes simple code easy to write and maintain. It is more practical than most other Lisps by wisely choosing on which giants should to stand. E.g. - make immutability the normal case, yet it is sufficiently performing that one rarely has to go back to mutability - minimal syntax, uniformity, dynamic typing, macro-system, symbols from Lisp - it extends Lisp with namespaces, even symbols get namespace - access t…

I would probably say that It is opinionated in a way that makes it good to write services in and it integrates well with the JVM.

CL has packages and most implementations have PLN so you get most (all?) of what the clojure namespaces offer.

I think that if anyone was rethinking scheme the would steal the immutability things from clojure (something like HAMTs and RRB trees or the scala finger tree vectors are more exciting I would say).

I don't think clojure brought anything new, per se. It took some nice parts from common lisp and scheme and added an immutability first paradigm. Nothing new, but getting people to understand how nice immutability is probably involves making the happy path immutable from day 1.

Re: Why Lisp?

#280

Post by lisper »

pdimitar wrote: post #243
lisper wrote: post #178

Earlier quoted context omitted.

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

> I want Erlang-style concurrency

OK, but you must want something besides that because...

> an ideal model (Erlang) but if that's not available

It is available. In Erlang. So if that's what you want, why are you not just using Erlang? Why even bother with the contingency of "if that's available"? Why are we having this discussion at all?

This is the reason that Erlang-style concurrency is not available off-the-shelf in Lisp. There's no market for it. The people who really want Erlang-style concurrency just use Erlang. No language will ever do Erlang-style concurrency better than Erlang. Erlang-style concurrency is Erlang's defining feature. The whole point of Erlang is to do Erlang-style concurrency. You can't do better than Erlang at "Erlang-style concurrency" by definition.

The point of Lisp is not do X-style-anything better than X. The main benefit of Lisp is that it allows you to explore a much larger space of possible solutions in a much shorter time, which is a big win when you don't know what you want, which, I submit, is most of the time.

Post reply on HN