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

191–200 of 339 posts

Re: Why Lisp?

#191

Post by LispSporks22 »

pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

All that stuff you're worried about is just implemented in libraries. Lisp lets you do that. You don't have to wait around years for a ECMA committee or whatnot to provide you a "async" keyword, or any other keyword. The language is flexible enough to let you add it yourself. It's a whole change of mindset.

In practice however, several people probably implemented "async" independently and the community as a whole just settles around a favorite.

Re: Why Lisp?

#192

Post by erichocean »

pmarreck wrote: post #167

Elixir is like a LISP with pure functions, only immutable values all the way down (which gets you a guarantee you wouldn't have otherwise in languages where this is optional), actor concurrency, pattern-matching, actual readable syntax, and of course macros (which do the same thing LISP macros do- Accept and output an AST value that happens at the compilation step- the only difference being LISP homoiconicity). It si…

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 Clojure from an arbitrary Python interpreter).

Plus a few other things you didn't mention:

4) ClojErl is Clojure on BEAM. You have full access to Erlang libraries (e.g OTP) and 98% of Clojure, missing only things that don't make sense on BEAM.

5) Write native iOS/Android apps with either React Native or Flutter (via ClojureDart). Develop them interactively just like you do browser stuff with ClojureScript.

6) Clojure now makes a great scripting platform with Babushka, which has completed replaced Node.js/Python/Bash for that use case for me.

6) Datomic/Datalog, there's still nothing like it after 10 years and in the last two weeks, it's Apache 2-licensed free to use and deploy.

Elixir/Erlang are really impressive, but being BEAM-only is a serious limitation. Clojure is a bit more practical (and I still get to run Clojure-on-BEAM when that makes sense).

Re: Why Lisp?

#193

Post by [deleted] »

Paul-Craft wrote: post #148
lispm wrote: post #132

Earlier quoted context omitted.

Many Lisps (and Common Lisp) had 'green threads' decades ago. Green threads are not preemptively scheduled by the OS/hardware. Multi-Processor Lisps were new and very rare (like the Lisp&Scheme for BBN Butterfly https://en.wikipedia.org/wiki/BBN_Butterfly or the Lisp for massive parallel Connection Machine). So the green threads then were mostly on a single core. Many Common Lisps moved to native threads in the last…

It's funny, even Emacs lisp has threads now: https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...

[deleted]

Re: Why Lisp?

#194

Post by dataangel »

vindarel wrote: post #130
pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

> 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

Re: Why Lisp?

#195

Post by dataangel »

jabradoodle wrote: post #102
pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

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?

Re: Why Lisp?

#196

Post by 1ark »

Hammershaft wrote: post #83
submeta wrote: post #51

Appreciating what Lisp is capable of doing (think macros), and having worked through SICP some twenty years ago, and after having tried to make a deep dive in CL and Emacs Lisp two years ago, I come to the conclusion that there is no silver bullet in Lisp-land. Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. Building websites, doing maths, a…

Python compares woefully for metaprogramming & creating domain specific languages, a field that Lisp is far & away best in class in.

Nim can do metaprogramming and DSL beautifully. Python-like syntax, compiled, fast, small.

Re: Why Lisp?

#197

Post by jgoodhcg »

ravi-delia wrote: post #31
jgoodhcg wrote: post #15

Earlier quoted context omitted.

I work with clojure and test driven development is not nearly as productive as repl driven development imo.

There's a place for both even with a REPL I think. Sometimes when I'm tracking a bug down or writing a new function against an old one, I find that I'm writing little one-off functions or worse, replicating a function body line by line in a let block to simulate arguments. Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed. I literally got as far as opening another file…

I almost always do my repl work in a source code file. That way I never lose it when the repl closes and I can copy it into a test when I know what’s going on.

Re: Why Lisp?

#198

Post by jgoodhcg »

marcosdumay wrote: post #17
jgoodhcg wrote: post #15

Earlier quoted context omitted.

I work with clojure and test driven development is not nearly as productive as repl driven development imo.

I'll have to agree here, with the caveat that this applies to functional code. For side-effect heavy code, a repl is not nearly as productive as good tests and a debugger. (What is interesting is that people tend not to test or check manually their code's side effects, so a repl is the best option for almost all the debugging that people actually do.)

I worked in Kotlin and Java for awhile and the closest thing I had to a repl was stopping the debugger and running arbitrary single lines of code in the context I paused. It was awful compared to the clojure repl.

Re: Why Lisp?

#199

Post by jgoodhcg »

geophile wrote: post #45
jgoodhcg wrote: post #15

Earlier quoted context omitted.

I work with clojure and test driven development is not nearly as productive as repl driven development imo.

Depends on what you mean be effective. TDD is great if you want to be sure you don’t break things in the future. Repl seems better for getting the next thing working right now.

The repl is great for understanding something quickly and easily. It works for big new parts of the code base and small things that you just need to be reminded about. The nice thing is, if you save your repl output, you can really easily create tests from it.

Re: Why Lisp?

#200

Post by jgoodhcg »

agumonkey wrote: post #35
jgoodhcg wrote: post #15

Earlier quoted context omitted.

I work with clojure and test driven development is not nearly as productive as repl driven development imo.

I'm often wondering how to couple both. Explore freely, extract more invariants and constraints as types/tests. Iterate.

Saving repl output is a great way to make tests. It’s often the stuff that is confusing and likely to change that you exercise in that space so if you take what you find from there and make a test out of it someone will likely benefit later.
Post reply on HN