Live data from Hacker News

Why Lisp? (2015)

blog.rongarret.info

31–40 of 174 posts

Re: Why Lisp? (2015)

#31
post #11

Earlier quoted context omitted.

Performance: Getting Lisp to run as fast as C takes major effort when at all possible. Resources: Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore. Ecosystem: Finding solid libraries is tricky since it's not very popular professionally. Power: Unleashing the full power of Lisp in a diverse team is a recipe for an ad…

> Getting Lisp to run as fast as C takes major effort when at all possible. The Computer Language Benchmarks Game shows Lisp Code as generally being between 2x and 10x slower than C++[1]. As fast as C? No. Way faster than Python, and more than fast enough to be used in almost every single application, modulo hard-real-time systems and AAA video games? Yes. > Lisp needs a lot of space to do it's thing; and while it's…

I don't think you should use "Lisp" as Common Lisp in one reply, and then "Lisp" as Clojure in the other. They are two very different languages. Though with the Armed Bear Common Lisp backend, you have access to the Java libraries.

Re: Why Lisp? (2015)

#32
post #11

Earlier quoted context omitted.

Performance: Getting Lisp to run as fast as C takes major effort when at all possible. Resources: Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore. Ecosystem: Finding solid libraries is tricky since it's not very popular professionally. Power: Unleashing the full power of Lisp in a diverse team is a recipe for an ad…

> Getting Lisp to run as fast as C takes major effort when at all possible. The Computer Language Benchmarks Game shows Lisp Code as generally being between 2x and 10x slower than C++[1]. As fast as C? No. Way faster than Python, and more than fast enough to be used in almost every single application, modulo hard-real-time systems and AAA video games? Yes. > Lisp needs a lot of space to do it's thing; and while it's…

>> Finding solid libraries is tricky since it's not very popular professionally.

> This one is so true it's not even funny

I'd say that's a bit out of date as Quicklisp has made a huge difference for CL. Obviously it's still not the most library-rich ecosystem but it's come a very long way.

Re: Why Lisp? (2015)

#33
post #19
post #11

Earlier quoted context omitted.

Performance: Getting Lisp to run as fast as C takes major effort when at all possible. Resources: Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore. Ecosystem: Finding solid libraries is tricky since it's not very popular professionally. Power: Unleashing the full power of Lisp in a diverse team is a recipe for an ad…

> Getting Lisp to run as fast as C takes major effort when at all possible. But Lisp is faster than almost every widely used language that's not C/C++/Rust, around Java speed. > Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore Dunno, by modern standards it seems pretty small. > Finding solid libraries is tricky sinc…

> There's code out there for most use cases, at least for back-end-y things.

I'm not sure about that. These days in the backend you need a lot of libraries for cloud providers and new databases/services. For example, is there a Common Lisp library for AWS/Azure/Google cloud? Is there one for Clickhouse?

Re: Why Lisp? (2015)

#34
post #3

Better question: why not Lisp?

I cut my teeth on Lisp, but I've found that happiness comes from compile time guarantees. Maybe those two things aren't mutually exclusive, but a thoroughly robust type system seems like a big ask in such a dynamic language. None of the solutions I've encountered have satisfied me, but in fairness I haven't looked that hard.

Re: Why Lisp? (2015)

#35
post #29
post #28

Earlier quoted context omitted.

> Finding solid libraries is tricky since it's not very popular professionally. If we're considering Clojure, then I would argue this point isn't true. Java interoperability in Clojure is really well supported and easy to accomplish, so leaning on the massive Java library ecosystem is possible. Also, anecdotally, a lot of Clojure libraries appear to be defunct, but just actually haven't been updated in so long becaus…

Well, if we're going to venture that far into excuse land Common Lisp has access to every C library in the world through CFFI. Look, I love Lisp, but reality isn't going anywhere.

I haven't used CL so I can't comment on the differences between CL's C interop and Clojure's Java interop. But when I worked at a Clojure shop, "finding solid libraries" was never an issue, because we used Java libraries directly. And we usually preferred to use a Java library even when third-party Clojure wrapper libraries existed. Using Java from Clojure is natural and idiomatic.

Re: Why Lisp? (2015)

#36
As someone that uses Clojure as a hobbyist

I don't think I've ever used the fact it's a homoiconic language in my programs

But I do suspect it's helping me indirectly it does make it easier to write static analysis tools for Clojure

It does make it easier for IDEs to identify what expressions I'm sending to the repl

And if I ever make a macro it will be helpful there

For me the question of why lisp or why Clojure the answer would be much more broad

A lot of the comments in this thread and the original article don't apply to all lisps

Re: Why Lisp? (2015)

#37
Everyday there's at least a post about Lisp. But I see none about TCL that is as regular in syntax as Lisp. Some call it a Lisp without parenthesis.

TCL is also very stable between releases, it has industrial strength and threading support.

But it lacks advocacy. It could get one tenth of what Lisp gets...

Re: Why Lisp? (2015)

#38

Earlier quoted context omitted.

Now imagine having that as: (documentclass article) (usepackage amsmath) (begin document) ;; [...] read syntax for displayed math [(= M (bmat (1 2 3 4 5) ;; case-sensitive treatment: M (3 4 5 6 7))] (end document)

Shouldn't the structure of the expression tree correspond to the structure of the document macros? i.e. (begin document ...)

Maybe, maybe not. Lisp files can have top-level structure (relationship between top-level forms). Like defining a class here, function there.

This is the topic of a StackOverflow question:

https://stackoverflow.com/questions/25720046/why-is-a-lisp-f...

One advantage would be that the stuff between (begin document) and (end document) consists of multiple forms which are separately read, expanded and processed, which can be quite important in some situations.

Also there is the possibility that some form in the document could load another file.

   (begin document)

   (load "boilerplate")

   ...

Re: Why Lisp? (2015)

#39
post #26

What's a good Lisp dialect to write small programs in? I have some Emacs Lisp experience but I wouldn't use it to automate small tasks. For that, I typically use Python.

I'd say the "python of lisp" is definitely racket.

Beginner friendly, lots of batteries included, large community with lots of libraries.

Here's an example of a simple webserver using the standard library: https://docs.racket-lang.org/web-server/run.html#%28part._se...

I'm also a fan of the first tutorial on the site. Instead of the boring stuff like hello world, 2+2, print your name etc, they use a built in library for drawing shapes to the console, and learn how to build up procedures for drawing more complex objects.

It feels like learning to code with logo (which they also have a clone built in of https://docs.racket-lang.org/logo/index.html)

All the good stuff said, I've never used it for system plumbing scripts like I do with python. I'd imagine it's worse for that due to the sheer popularity python has.

https://racket-lang.org/

Re: Why Lisp? (2015)

#40
post #3

Better question: why not Lisp?

I cut my teeth on Lisp, but I've found that happiness comes from compile time guarantees. Maybe those two things aren't mutually exclusive, but a thoroughly robust type system seems like a big ask in such a dynamic language. None of the solutions I've encountered have satisfied me, but in fairness I haven't looked that hard.

I have 0 experience here but that's really surprising to me.

I'd think out of any language lisp would shine here.

You could write as complex of a type system as you wanted that compile time checks, so it's surprising someone hasn't written one that mimics at least java/c++/whatever style types.

I do think that is one of the down sides to lisp though. When you can do almost anything it's very hard to agree on what to actually do.

Post reply on HN