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

161–170 of 174 posts

Re: Why Lisp? (2015)

#161

Post by eigenspace »

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

Earlier quoted context omitted.

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/

> in this sense hosted languages are always a front-end. common lisp is not this

Even self-hosted languages are front-ends for assemblers and microcode. What actually matters is being able to have arbitrary control over how code is executed. Julia has this in spades.

Julia has it's own intermediate representations where you can write custom compiler passes and intercept and modify whatever you like (in pure julia). You can think of these tools as being like macros, except instead of lexical extent they have a completely dynamic extent.

With these passes, you can arbitrarily change the meaning of any code recursively. E.g. You could define an execution context where multiplication and addition have swapped meanings, or you could locate every if-else statement in the entire callstack of a program and switch the if clause with the else clause. And again, this is not limited to the lexical extent of a macro, and it does not disable compilation. It is instead a programmable step in compilation.

A classic example of this would be Zygote.jl [1] which takes a program and recursively generates code to that would give the derivative of that program. Doing this requires you to modify literally every function call in the callstack, and you can do this all in pure julia without ever knowing a lick of LLVM.

Granted, there is something ideologically appealing about the idea of a self-hosted langauge. I'm just arguing that on a practical level, the compiler tools allow total control over code execution without changing languages, just as you'd get in a self-hosted language.

[1] https://github.com/FluxML/Zygote.jl

Re: Why Lisp? (2015)

#162

Post by daniel-cussen »

bmitc wrote: post #80

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…

The thing about Common Lisp is, code doesn't rot. It doesn't matter if CL code is 5 years old or 30, it runs. I have yet to see even one ounce of bit rot. CL code is as eternal as solid gold, honestly. And sometimes, yes, there's a few ways your code will fail to run, mostly because you're shooting yourself in the foot (eg starting slime in a different directory than what you're meant to).

Versus Python, I didn't even get to use Python 2 before I started getting nagged and harangued by various exceptions in the terminal about how I had to migrate to Python 3.

And it depends what you're doing with CL, how well it works for you. As an algorithm designer, I use literally no libraries. I don't glue anything to anything. I just use the batteries that come included with Common Lisp (SBCL is great), forget about connecting to the internet, forget I/O, forget graphics and GUIs and OOP, and just focus on coming up with as many ideas as I can per minute, until I crack the algorithmic problem. Just with the austere tools that come included in SBCL: xor (#'logxor), popcount (#'logcount), #'sort, #'svref, #'pop, #'push, #'make-array, #'dotimes, 'lambda, 'labels, 'let, 'do, the basics.

Re: Why Lisp? (2015)

#163

Post by codr7 »

throw10920 wrote: post #133
codr7 wrote: post #29

Earlier quoted context omitted.

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.

This is a variant of the "Turing tarpit" fallacy - that is, saying that all things that are technically possible are equivalent. Calling Java code in Clojure is completely seamless[1] - there's a world of difference from the CL FFI (which isn't that bad to use), which is turn easier to use than the CPython FFI. You might as well say that C is just as powerful as Common Lisp, because you can implement Common Lisp in i…

I certainly don't recall it as being seamless; Clojure is a very different language from Java, and the interop code I've seen doesn't look like the kind of Clojure anyone would write otherwise, hence the comparison to CFFI which has the same impedance issues.

But it's all JVM bytecode, so ofcourse it's going to be somewhat smoother.

Re: Why Lisp? (2015)

#165

Post by lispm »

eigenspace wrote: post #161
medo-bear wrote: post #158

Earlier quoted context omitted.

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/

> in this sense hosted languages are always a front-end. common lisp is not this Even self-hosted languages are front-ends for assemblers and microcode. What actually matters is being able to have arbitrary control over how code is executed. Julia has this in spades. Julia has it's own intermediate representations where you can write custom compiler passes and intercept and modify whatever you like (in pure julia). Y…

Julia is a language and its implementation.

Common Lisp is a language with multiple very different implementations.

Common Lisp is not 'self hosted' - many implementations are. Many are not.

Re: Why Lisp? (2015)

#166

Post by medo-bear »

eigenspace wrote: post #161
medo-bear wrote: post #158

Earlier quoted context omitted.

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/

> in this sense hosted languages are always a front-end. common lisp is not this Even self-hosted languages are front-ends for assemblers and microcode. What actually matters is being able to have arbitrary control over how code is executed. Julia has this in spades. Julia has it's own intermediate representations where you can write custom compiler passes and intercept and modify whatever you like (in pure julia). Y…

as i said i think that Julia is an exciting project in the scientific computing space. my statements were not directed against julia or any other language. i just happen to think that common lisp also has great potential for scientific computing, one that can appeal to scientists who want to be software engineers also. for those that just want to crunch numbers right now python is a first reference then julia, imho. however, i sincerely hope that julia overtakes python

having the ability to be self hosted is definitely not ideological. [* here is a hypothetical question that can be asked: would a julia programmer be more powerful if llvm was written in julia? i think the answer is clear that they would be *]

common lisp is a language specification. it does not have an official implementation, although by far the most popular one is sbcl. in fact there is an implementation CLASP[0] that is hosted on llvm

[0] https://github.com/clasp-developers/clasp

[*...*] enclosed part added to the response subsequently to initial posting

Re: Why Lisp? (2015)

#167

Post by eigenspace »

medo-bear wrote: post #166
eigenspace wrote: post #161

Earlier quoted context omitted.

> in this sense hosted languages are always a front-end. common lisp is not this Even self-hosted languages are front-ends for assemblers and microcode. What actually matters is being able to have arbitrary control over how code is executed. Julia has this in spades. Julia has it's own intermediate representations where you can write custom compiler passes and intercept and modify whatever you like (in pure julia). Y…

as i said i think that Julia is an exciting project in the scientific computing space. my statements were not directed against julia or any other language. i just happen to think that common lisp also has great potential for scientific computing, one that can appeal to scientists who want to be software engineers also. for those that just want to crunch numbers right now python is a first reference then julia, imho.…

Yes, and sorry if I also came off as combative here, it was not my intention either. I've used some Common Lisp before I got into Julia (though I never got super proficient with it) and I think it's an excellent language and it's too bad it doesn't get more attention.

I just wanted to share what I think is cool about julia from a metaprogramming point of view, which I think is actually its greatest strength.

> here is a hypothetical question that can be asked: would a julia programmer be more powerful if llvm was written in julia? i think the answer is clear that they would be

Sure, I'd agree it'd be great if LLVM was written in julia. However, I also don't think it's a very high priority because there are all sorts of ways to basically slap LLVM's hands out of the way and say "no, I'll just do this part myself."

E.g. consider LoopVectorization.jl [1] which is doing some very advanced program transformations that would normally be done at the LLVM (or lower) level. This package is written in pure Julia and is all about bypassing LLVM's pipelines and creating hyper efficient microkernels that are competitive with the handwritten assembly in BLAS systems.

To your point, yes Chris' life likely would have been easier here if LLVM was written in julia, but also he managed to create this with a lot less man-power in a lot less time than anything like it that I know of, and it's screaming fast so I don't think it was such a huge impediment for him that LLVM wasn't implemented in julia.

[1] https://github.com/JuliaSIMD/LoopVectorization.jl

Re: Why Lisp? (2015)

#168

Post by medo-bear »

eigenspace wrote: post #167
medo-bear wrote: post #166

Earlier quoted context omitted.

as i said i think that Julia is an exciting project in the scientific computing space. my statements were not directed against julia or any other language. i just happen to think that common lisp also has great potential for scientific computing, one that can appeal to scientists who want to be software engineers also. for those that just want to crunch numbers right now python is a first reference then julia, imho.…

Yes, and sorry if I also came off as combative here, it was not my intention either. I've used some Common Lisp before I got into Julia (though I never got super proficient with it) and I think it's an excellent language and it's too bad it doesn't get more attention. I just wanted to share what I think is cool about julia from a metaprogramming point of view, which I think is actually its greatest strength. > here i…

great! i think that as far as scientific computing is concerned one has every right to be excited about julia. it is impressive how much work is being done in such a short time. i first came across it in 2015/6 and i am very happy about how its ecosystem evolved. i use julia and will continue to use it

this is what i would advise given the current state of affairs in machine learning

* use tensorflow / pytorch / pyro for industrial purposes. otherwise know what you are doing !

* use julia and its ecosystem for academic/research purposes. universities should be at the cutting edge of research

* use anything else if you want to experiment deeply. here is where i see the value of common lisp

Re: Why Lisp? (2015)

#169

Post by igouy »

hajile wrote: post #71
codr7 wrote: 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…

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

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

Whatever stopped that happening in the past, still stops that happening, and will continue to stop that happening in the future.

Re: Why Lisp? (2015)

#170

Post by tmm84 »

daniel-cussen wrote: post #162
bmitc wrote: post #80

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…

The thing about Common Lisp is, code doesn't rot. It doesn't matter if CL code is 5 years old or 30, it runs. I have yet to see even one ounce of bit rot. CL code is as eternal as solid gold, honestly. And sometimes, yes, there's a few ways your code will fail to run, mostly because you're shooting yourself in the foot (eg starting slime in a different directory than what you're meant to). Versus Python, I didn't eve…

I can't think of any code rot either. As long as it is built against the standard it tends to just work.

I also find the idea of using no libraries a big thing in more advanced users of CL. The more advanced of a user the more it makes sense that you can just implement it yourself (with only the functionality required) and know it works without having to leverage a library. Then again, the idea of CL is that things that tend to be bigger/harder to solve problems in other languages can be done simpler in CL because you can break the problem up different and have an easier to understand or implement solution.

Post reply on HN