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

151–160 of 174 posts

Re: Why Lisp? (2015)

#151

Post by hajile »

bmitc wrote: post #140
hajile wrote: post #72

Earlier quoted context omitted.

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

What are the three companies? I know of Allegro CL and LispWorks.

While Clozure CL is free to use, it has a group that offers commercial support.

mocl for android/iOS may still exist.

Last I knew, Scieneer (HPC variant of CMUCL) was also commercial (no idea if they're still around though).

Re: Why Lisp? (2015)

#152

Post by bjoli »

igouy wrote: post #42
agumonkey wrote: post #16

Earlier quoted context omitted.

If performance was such a problem python wouldn't have a subreddit. I think a lot of lispers like handling various paradigms in their head and start with basic lisp, and resort to edsl to reach more appropriate semantics/mechanical sympathy. Just like people call out to C wrappers mostly. The social side of lisp I can't say for sure but I'm sure it's fuzzier than it seems. I've just talked to a dude saying his new gu…

And yet there always seems to be another discussion about how to re-implement CPython so that programs run faster.

hehe. i remember a thing posted about python-on-guile, a rather ambitious project implementing python by compiling it to guile sheme.

The scheme code it produces is pretty awful. Not because it is bad, but because python is extremely unidiomatic scheme, and if you want to keep python semantics thay is where you have to go.

And despite being a one man job, despite being run on a far-from-the-fastest scheme, despite giving the optimizer any chance to do the regular optimizations it was about 1.5x times faster than cpython.

It was in numerical code, so beating cpython is maybe not very hard. I found it funny nontheless.

Re: Why Lisp? (2015)

#153

Post by filoeleven »

gaze wrote: post #148
filoeleven wrote: post #147

Earlier quoted context omitted.

Lisp code is much terser than prose.

It’s not significantly terser than other languages, which don’t feature this enormous asymmetry.

Perhaps I’m wrong, but my understanding is that it has a reputation for being able to build systems with significantly fewer LOC than most languages, without delving into APL-levels of obscurity.

My attempt at deadpan humor doesn’t work if that isn’t true, and I’m not qualified to make the argument since I’ve not used it professionally yet. I can say that picking up Clojure for fun has both reawakened my joy in programming and greatly informed how I write code in other languages. That tends to inspire prose.

Re: Why Lisp? (2015)

#154

Post by Zababa »

IshKebab wrote: post #136
Zababa wrote: post #30

That article partially validates my idea on why some people think that Lisp is such a force multiplier. The idea would be that compilers are one of the most important tool productivity-wise, and that Lisp allows you write your compilers yourself. That would also explain why not Lisp: First, libaries are the new important tool for productivity, and any language can have that. Second, a shared understanding is very imp…

Coffeescript, Babel and Typescript are not macros.

Macros are compilers (well, an AST pass), all of these tools are compilers. A specific transformation of Babel or Typescript or Coffeescript is a macro.

Re: Why Lisp? (2015)

#155

Post by eigenspace »

medo-bear wrote: post #128
tho23u4i23o4 wrote: post #117

Earlier quoted context omitted.

In fairness, the CL spec being quite old, has a fairly dated type system. Obviously, CL is still blazing fast compared to Python, but it can't easily do the kind of things that Julia or even C++ can when it comes to numerical programming. You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this.

> You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the dri…

> this is not the job of compiler writers

Presumably what the GP means is that you can use macros to hack around limitations of CL's type system, such as lack of parametric types, or whatever (very important for good multidimensional generic array code), but they'd rather that the CLOS was just built to be more expressive in the first place, because their local hacks will not be as good as what a language development team can produce while working together.

> in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0].

This is mostly false.

First of all, there's a huge amount of numerical programming infrastructure in Base julia and it's standard library. There is even more outside of the base/stdlib, but the stuff inside is quite diverse and robust.

Second of all, CUDA.jl is a very weird thing to point to for your example. CUDA.jl is essentially a compiler plugin for julia that hijacks it's normal compilation pipeline for specified code and then causes it to emit GPU specialized instructions to LLVM which then compiles a binary.

If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that (but note, this is a rather dumb definition of 'wrapping').

Re: Why Lisp? (2015)

#156

Post by eigenspace »

medo-bear wrote: post #111
adgjlsfhk1 wrote: post #79

Earlier quoted context omitted.

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.

there was dylan before julia, so julia might just be reinventing dylan :) but that's not what's interesting the julia project is in fact very interesting to me and has a great team developing its ecosystem and i work with it alongside python for numerical work. however one key drawback (compared to common lisp) for me is that it is not self-compiled. it is hosted on llvm and over 30% of its repository is in another l…

Can I ask why it matters to you whether or not julia is self hosting?

Re: Why Lisp? (2015)

#157

Post by medo-bear »

eigenspace wrote: post #155
medo-bear wrote: post #128

Earlier quoted context omitted.

> You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the dri…

> this is not the job of compiler writers Presumably what the GP means is that you can use macros to hack around limitations of CL's type system, such as lack of parametric types, or whatever (very important for good multidimensional generic array code), but they'd rather that the CLOS was just built to be more expressive in the first place, because their local hacks will not be as good as what a language development…

why do you presume that's what the GP meant? your post is much more detailed than his

anyway, i know very well that julia has a great standard numerical library. it is a language catered to that community so it better have a rich standard library. my point is that functionality does not need to in the standard library in order to be useful or impactful. i don't think i need to prove my point but take numpy (or any other famous numerical package from the python ecosystem) as an example

>Second of all, CUDA.jl is a very weird thing to point to for your example

i work in machine learning so it is a very important package for me

> If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that

and CL is not. point is that you need to learn LLVM in order to dig deeper, if you so wish

Re: Why Lisp? (2015)

#158

Post by medo-bear »

eigenspace wrote: post #156
medo-bear wrote: post #111

Earlier quoted context omitted.

there was dylan before julia, so julia might just be reinventing dylan :) but that's not what's interesting the julia project is in fact very interesting to me and has a great team developing its ecosystem and i work with it alongside python for numerical work. however one key drawback (compared to common lisp) for me is that it is not self-compiled. it is hosted on llvm and over 30% of its repository is in another l…

Can I ask why it matters to you whether or not julia is self hosting?

because i want to be able to to go turtles all the way down with my code. julia being hosted on llvm does not provide that. if you want to do optimisations in julia you must learn llvm[0]. in this sense hosted languages are always a front-end. common lisp is not this

[0] https://docs.julialang.org/en/v1/devdocs/llvm/

Re: Why Lisp? (2015)

#159

Post by gilch »

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 you're already familiar with Python libraries, check out Hissp (https://github.com/gilch/hissp), which compiles to Python expressions.

Re: Why Lisp? (2015)

#160

Post by gilch »

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…

Hissp is a Lisp clone in Python, with a tiny escape hatch to fully utilize the Python parts. https://github.com/gilch/hissp
Post reply on HN