Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Lisp? (2015)

blog.rongarret.info

Post reply on HN
Print view View original

71–80 of 174 posts

Re: Why Lisp? (2015)

#71

Post by hajile »

codr7 wrote: post #11
firebaze wrote: post #3

Better question: why not Lisp?

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…

SBCL is already about as fast as Java and can get most of that speed without very much time optimizing everything.

Java has hundreds (thousands?) of developers working on it.

SBCL has a handful of part-time devs.

What could SBCL become with all those man-years behind it?

Custom syntax is hardly the big issue when using Common Lisp. I'll take that any day over the dozens of layers of useless abstraction in Java projects. I'll take it over the C code golf or "what does this undefined behavior do?". I'd even take it over the piles of garbage JavaScript I've waded through over the years.

Re: Why Lisp? (2015)

#72

Post by hajile »

gaze wrote: post #69

Why does it feel like there’s more prose about lisp being written than lisp code? I swear there’s like 15 people writing Common Lisp — Nikodemus, Shirakumo, Stylewarning, Christian Schafmeister, Borodust, the ITA folks, and maybe 2 startups.

There are three commercial lisp companies that continue to exist selling CL platforms. They exist despite SBCL being faster. They even make stuff like tools to build iOS and Android apps in CL. They didn't invest the money building that that out for no reason.

The companies that use lisp don't tend to talk about it. For example, a company I worked for only talked about their Ruby/rails and javascript stuff publicly. It was only after I hired that I found out that the mission-critical core software was written in Common Lisp.

Re: Why Lisp? (2015)

#73

Post by hajile »

Jtsummers wrote: post #50
spicybright wrote: post #40

Earlier quoted context omitted.

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…

Shen is an example of that. In its original form, Qi, it was written for Common Lisp and later written for other languages. http://shenlanguage.org/

Wow, I'm glad that they opened up the documentation. I liked what I saw a few years ago, but I'm not getting behind a language where all the usable docs are proprietary.

Re: Why Lisp? (2015)

#74

Post by hajile »

hesk wrote: 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.

Chicken Scheme is probably a nice middle-of-the-road scheme to try. It's "eggs" offer a lot of the functionality you'd want, the FFI for calling C is decent, and the documentation isn't bad.

Re: Why Lisp? (2015)

#75

Post by masak »

hesk wrote: 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.

If I may be so bold as to recommend my in-progress Bel implementation: https://github.com/masak/bel

Caveat: I'm still working towards being able to recommend Bel _unconditionally_, not just for small programs. Right now you'll experience unreasonable slowness, terse/uninformative error messages, and missing documentation -- probably in that order. All of those are being addressed. But already today, it's fun to play with.

Re: Why Lisp? (2015)

#76

Post by lanstin »

kevin_thibedeau wrote: post #47
lanstin wrote: post #43

Earlier quoted context omitted.

Lisp compiles to native code, TCL is forever parsing the strings it passes around.

> TCL is forever parsing the strings it passes around. No it isn't. Tcl has had dual-ported objects and a bytecode interpreter for over 20 years.

Well I learned something. But if you represent a list as a lift of strings wouldn’t it have to parse them as Argv in the c implementation? It has been a while but only 17 years since I wrote TCL commands but each one started with a list of strings. Maybe the byte code interpreter doesn’t work with older C extensions? But the main selling point of TCL was easy extension.

Re: Why Lisp? (2015)

#77

Post by [deleted] »

kaeland wrote: post #67
jim-jim-jim wrote: post #34

Earlier quoted context omitted.

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'm fairly new to lisp programming, but there's a language called Coalton that provides static type checking to Common Lisp. I believe both languages are one and the same, but Coalton provides some type guarantees while still being able to have all of the interactiveness CL devs are used to. https://github.com/coalton-lang/coalton

[deleted]

Re: Why Lisp? (2015)

#78

Post by reikonomusha »

Zababa wrote: post #52
spicybright wrote: post #40

Earlier quoted context omitted.

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…

> 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. There's at least typed racket. > I have 0 experience here but that's really surprising to me. > I'd think out of any language lisp would shine here. I don't think you should be surprised that people don't want to write their typechecker…

It’s a lot more practical than you think if you’re willing to roll up your sleeve and do the work.

Fortunately, people have already done the work for you. [1]

[1] https://github.com/coalton-lang/coalton

Re: Why Lisp? (2015)

#79

Post by adgjlsfhk1 »

spicybright wrote: post #48
throw10920 wrote: post #20

Earlier quoted context omitted.

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

> ... AAA video games? Yes. One of my favorite stories of the ideas of lisp commercially is a dialect that Naughty Dog developed for their game development. It started as being developed for Crash Banicoot on the PS1. Which is really interesting given how limited the system was (1mb to 2mb of ram depending on what you were doing with the system!) They later iterated on it for Jak and Daxter on the PS2. To quote the w…

that's basically Julia. take lisp, remove the s expressions and add a bunch of really good math libraries and you've just reinvented Julia.

Re: Why Lisp? (2015)

#80

Post by bmitc »

I love Lisp and Scheme and all their relatives (Clojure, Logo, Racket, etc.). However, the fact of the matter is, Common Lisp has not kept up with modern developments in terms of presenting a cohesive ecosystem with forward momentum. Everybody is off on their own doing their own thing with no shared goals or cohesion.

Clojure seems to have this (I have not used Clojure much, so I don't really know). Elixir definitely has this. I think Elixir is the language ecosystem to look at in terms of having a solidified core language that is essentially done, and now the goal is to continue to flesh out the ecosystem with things like Nx, Axon, Livebook, Liveview, Mix improvements, Phoenix, etc. Elixir is pretty similar to Lisp/Scheme anyway given its macros, ability to live update, dynamically typed programming, but it goes well beyond any Lisp/Scheme (and many modern languages) in terms of having a practical but expansive ecosystem with a strong set of idiomatic conventions.

Post reply on HN