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

291–300 of 339 posts

Re: Why Lisp?

#291

Post by kaveh808 »

lukego wrote: post #270
foldr wrote: post #265

Earlier quoted context omitted.

Try extending this approach to, say, a Polygon datatype and see how far you get :)

Hard to please some people :)

A design decision which needs to be made is at what level of abstraction should the data be "fixed", i.e. not to be manipulated with the full power of CL. This is often a flexibility vs. efficiency tradeoff.

In my 3D CL system [0], I have so far kept all geometric data as naive CLOS classes as the intent of the system is to provide a sandbox for experimentation. I have thought of, perhaps one day, representing the geometry as a foreign library for efficient passing to the GPU.

[0] https://github.com/kaveh808/kons-9

Re: Why Lisp?

#292

Post by ravi-delia »

pdimitar wrote: post #244
kraf wrote: post #202

Earlier quoted context omitted.

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.

It's...close-ish? It could really use default non-blocking IO, but honestly the reason no one's made one integrated solution yet is that giving a callback that pushes to a channel is mostly fine. I'd like something a little more robust obviously, but it's by no means a toy.

Re: Why Lisp?

#293

Post by erichocean »

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

The people who actually use ClojureDart today disagree:

> ClojureDart is production-ready: you can ship applications right now.

Source: https://github.com/Tensegritics/ClojureDart (i.e. the developers themselves)

See a live coding session/demo given a week ago here and decide for yourself: https://www.youtube.com/watch?v=dqBeGpuedf0

ClojureDart is very similar to ClojureScript (which the GP is already comfortable with). If you can create and deploy an app with ClojureScript, you can 100% deploy something with ClojureDart today.

Re: Clojure-not-for-n00bs, I 100% agree and haven't met anyone in the Clojure ecosystem who would disagree. Clojure developers have consistently the most experience of any language ecosystem I've worked in over the last 25 years.

Re: Why Lisp?

#294

Post by pdimitar »

ravi-delia wrote: post #292
pdimitar wrote: post #244

Earlier quoted context omitted.

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.

It's...close-ish? It could really use default non-blocking IO, but honestly the reason no one's made one integrated solution yet is that giving a callback that pushes to a channel is mostly fine. I'd like something a little more robust obviously, but it's by no means a toy.

Oh definitely. I wouldn't call it a toy either, it's just weird that nobody bothered to make something more ready to consume.

Re: Why Lisp?

#295

Post by ravi-delia »

Blackthorn wrote: post #105
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.

Clojure's core.async channel concurrency is nothing like go's. You need to wrap your concurrent block in a macro so it can code walk to find explicit blocking points. That means these points need to be marked, and can't be in already compiled functions. That's an enormous limitation. Compare to go's which just works, no caveat.

Plus Go is just so nice with the automatic IO handoff. But in a functional language I really don't think it's as big a limitation- still large, but not as bad as it could be. The pattern of writing mostly small, pure functions and then piping them together with channels all at the end is pretty workable.

Re: Why Lisp?

#296

Post by lispm »

hajile wrote: post #255
ravi-delia wrote: post #38

Earlier quoted context omitted.

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…

Those REPLs aren’t even close to Common Lisp. Common Lisp borrowed parts of the smalltalk development strategy. You can start a process and gradually update it in very sophisticated ways as you live code against it. You wouldn’t dream of packaging up your Python REPL and shipping it to users. You certainly wouldn’t open a Python REPL on your production server and start redefining functions and data structures on the…

> Common Lisp borrowed parts of the smalltalk development strategy. You can start a process and gradually update it in very sophisticated ways as you live code against it.

Lisp had interactive programming a decade before Smalltalk. The interactive PDP-1 Lisp is from 1963. BBN Lisp was based on it. Which then was taken over by Xerox PARC as Interlisp.

BBN Lisp / Interlisp already had a very sophisticated programming environment in 1970, including a built-in structure editor for Lisp.

Re: Why Lisp?

#297

Post by ravi-delia »

pmarreck wrote: post #271
stefcoetzee wrote: post #260

Earlier quoted context omitted.

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.

Yeah, taste is taste. I do get it- it's why I like Clojure's syntax more than CLs, but man I don't get commas. Or even Elixir, I love the language but its always painful to come back to the syntax. Pipe operator aside, that is.

Re: Why Lisp?

#298

Post by ravi-delia »

pdimitar wrote: post #294
ravi-delia wrote: post #292

Earlier quoted context omitted.

It's...close-ish? It could really use default non-blocking IO, but honestly the reason no one's made one integrated solution yet is that giving a callback that pushes to a channel is mostly fine. I'd like something a little more robust obviously, but it's by no means a toy.

Oh definitely. I wouldn't call it a toy either, it's just weird that nobody bothered to make something more ready to consume.

I do think about that pretty frequently. It wouldn't even be all that hard! Maybe Loom will push things over.

Re: Why Lisp?

#299

Post by Thiez »

lukego wrote: post #217
linguae wrote: post #50

Earlier quoted context omitted.

As a Lisp fan who sometimes codes in Scheme and Common Lisp whenever I get the chance, I agree with you. The gap has certainly narrowed in the past 20 or so years between Lisp and widely-used programming languages. In addition, the rise of statically-typed functional programming languages like OCaml and Haskell provide another alternative for those who love functional programming but want Hindley-Milner types. I stil…

> if I’m writing a machine learning application or a web application, then I’ll most likely reach for Python or JavaScript, respectively, due to the library ecosystems. This sounds eminently sensible but it never pans out that way in practice for me: How do you understand the ML algorithms if you haven't implemented them yourself? And if you have implemented them for the sake of understanding, in whatever language yo…

Do you drive a car you built from scratch? How can you drive from A to B without first understanding how a car works by building one? And since you already built one, why not just keep using that one?

Or maybe you have built a car. But did you type your message on a computer you built yourself using some silicon and a home-baked x-ray lithography machine?

I definitely think there can be value in reimplementing something for educational purposes, but often knowing how to use something without necessarily being able to build it yourself is just fine. And those things you do build for educational purposes should almost always be abandoned after serving their educational purpose.

Re: Why Lisp?

#300

Post by kazinator »

> Future proof is a term thrown around a lot in the tech industry.

  This is the TXR Lisp interactive listener of TXR 286.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  Truly future-proof systems are rare; future-resistant ones are everywhere.
  1> _
Post reply on HN