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

Creating a Non-Trivial Lisp Game in 2018

defungames.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Creating a Non-Trivial Lisp Game in 2018

#21

Post by lispm »

dustingetz wrote: post #20
armitron wrote: post #16

Earlier quoted context omitted.

Clojure is practically tied to the JVM and the Java ecosystem (ClojureScript is different enough to count as a different language so I'll focus on Clojure). To me that's not fun. It's also limited by design to fit the development model Rich Hickey wanted for his consultancy. It is nowhere near as encompassing or paradigm agnostic as Common Lisp. Moreover, you can take old Lisp code that's 40+ years old and run it tod…

if by limited we mean full ecosystem compatibility with jvm and javascript, then yes, Clojure is limited. Which 40 year old CL codebase is it that i am trying to run?

> if by limited we mean full ecosystem compatibility with jvm and javascript, then yes, Clojure is limited.

I don't think that was he meant. Probably he meant that Clojure took a bunch of things from Lisp, but there is a lot in Lisp, which is not in Clojure - for example because of the limitations of the JVM eco-system (for example creating an executable image in SBCL of a running Lisp is an easy task, whereas in Clojure it involves a complex & slow machinery like GraalVM) or design limitations imposed by its developers (like a compiler written in Java and no interpreter) - plus it seems not to be an open language design - more or less the language is driven by a single company listening to its community and sometimes not.

Re: Creating a Non-Trivial Lisp Game in 2018

#22

Post by armitron »

_emacsomancer_ wrote: post #19
armitron wrote: post #16

Earlier quoted context omitted.

Clojure is practically tied to the JVM and the Java ecosystem (ClojureScript is different enough to count as a different language so I'll focus on Clojure). To me that's not fun. It's also limited by design to fit the development model Rich Hickey wanted for his consultancy. It is nowhere near as encompassing or paradigm agnostic as Common Lisp. Moreover, you can take old Lisp code that's 40+ years old and run it tod…

Still, in cases where one is tied to the Java ecosystem for whatever reason, surely Clojure is better than no-clojure?

I'd still pick something else in that case too since I don't really like the decisions behind Clojure. But hey go for it if it fits the problems that you find yourself solving.

Re: Creating a Non-Trivial Lisp Game in 2018

#23

Post by armitron »

dustingetz wrote: post #20
armitron wrote: post #16

Earlier quoted context omitted.

Clojure is practically tied to the JVM and the Java ecosystem (ClojureScript is different enough to count as a different language so I'll focus on Clojure). To me that's not fun. It's also limited by design to fit the development model Rich Hickey wanted for his consultancy. It is nowhere near as encompassing or paradigm agnostic as Common Lisp. Moreover, you can take old Lisp code that's 40+ years old and run it tod…

if by limited we mean full ecosystem compatibility with jvm and javascript, then yes, Clojure is limited. Which 40 year old CL codebase is it that i am trying to run?

The decisions behind Clojure worked out well for Rich Hickey and his consultancy but they don't fit the programs that I find myself writing all the time (compilers, assemblers, virtual machines, tight control of code generation and memory operations and so on). I can do all of that - and more - in SBCL and it's a pleasure to use as the I don't have to bend myself to work around language shortcomings. Common Lisp gives me a multitude of programming paradigms and an enormous arsenal of approaches to use. When working in exploratory domains, that I do all the time, nothing else comes close. Here is an example of using SBCL for exploratory lowlevel programming by Paul Khuong [1].

I've written performant and lightweight TCP/IP network stacks in Common Lisp. Clojure is just too constrained.

As far as old Lisp code goes, it's everywhere - if you care to look -. The lambda papers, McCarthy's original papers, the CMU CL repository (still of practical use today), vast archives of Lisp code from MIT and so on and so forth. Not to mention useful frameworks like Screamer [2] which is close to 30 years old and Maxima [3] which is even older.

[1] https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembl...

[2] http://nikodemus.github.io/screamer/

[3] http://maxima.sourceforge.net

Re: Creating a Non-Trivial Lisp Game in 2018

#24

Post by drmeister »

agumonkey wrote: post #9
drmeister wrote: post #6

My group is developing Clasp (github.com/clasp-developers/clasp.git). It's a Common Lisp implementation that interoperates with C++ and uses llvm as the backend. It's something you might want to look at because it could change your options in the following ways: (1) Clasp interoperates with C++ - C++ libraries like graphics and physics engines can be easily exposed within Clasp Common Lisp. (See https://github.com/cl…

Hi, I watch your llvm talk but, correct me if I'm wrong, it seems you didn't really have enough time to cover all you wanted. Do you think you'll have another conf to do it fully ? or maybe find time to do it on another video platform ? oh also, someone on your talk main thread suggested to use more GPU ( https://news.ycombinator.com/item?id=18707771 <= get ready for some harsh adjectives). I wonder if you're already…

Yes, there is never enough time to cover all that I want. There will be more talks in the future and more as Clasp gets more exposure.

Re: Creating a Non-Trivial Lisp Game in 2018

#25

Post by cracauer »

gameswithgo wrote: post #12
drmeister wrote: post #6

My group is developing Clasp (github.com/clasp-developers/clasp.git). It's a Common Lisp implementation that interoperates with C++ and uses llvm as the backend. It's something you might want to look at because it could change your options in the following ways: (1) Clasp interoperates with C++ - C++ libraries like graphics and physics engines can be easily exposed within Clasp Common Lisp. (See https://github.com/cl…

Does clasp still support all the metaprogramming features of lisp while using llvm, and how does it do it?

Well, there are a lot of those, they need to be looked at separately.

What I (and the QPX school if I might use the term) use is compile-time computing, aka a programmable programming language. LLVM never gets to see this, by the time you pass it to the compiler it is dumb code. QPX after macroexpansion looked like C.

When it comes to executing code that only becomes available at run time (repl, eval, from a string, from a file etc) you generally just kick off the compiler, which is that Clasp and LLVM do right now. You can also use the interpreter which again both Clasp and SBCL have.

When it comes to the dynamic nature of CLOS method invocation, that is generally accelerated with special dispatch mechanism that live in the compilers. You can implement CLOS without any compiler support, but teaching the compiler about method dispatch makes it faster. The Lisp compilers emit abstract assembly code for LLVM or the last stage of SBCL.

When talking about dynamic typing the same applies. The compilers that do Lisp emit abstract machine language, pretty much the same way for Clasp and SBCL.

To Clarify, Clasp uses various LLVM compilation targets including LLVM's "JIT" for runtime known code. I am not sure I'd call it a JIT because it doesn't compile functions when they are used, but they are compiled into memory (as opposed to into object files).

Hope this helps.

Re: Creating a Non-Trivial Lisp Game in 2018

#26

Post by agumonkey »

drmeister wrote: post #24
agumonkey wrote: post #9

Earlier quoted context omitted.

Hi, I watch your llvm talk but, correct me if I'm wrong, it seems you didn't really have enough time to cover all you wanted. Do you think you'll have another conf to do it fully ? or maybe find time to do it on another video platform ? oh also, someone on your talk main thread suggested to use more GPU ( https://news.ycombinator.com/item?id=18707771 <= get ready for some harsh adjectives). I wonder if you're already…

Yes, there is never enough time to cover all that I want. There will be more talks in the future and more as Clasp gets more exposure.

Well, I'm super eager to see more clasp/cando videos on frontpages.

Re: Creating a Non-Trivial Lisp Game in 2018

#27

Post by maufdez »

armitron wrote: post #22
_emacsomancer_ wrote: post #19

Earlier quoted context omitted.

Still, in cases where one is tied to the Java ecosystem for whatever reason, surely Clojure is better than no-clojure?

I'd still pick something else in that case too since I don't really like the decisions behind Clojure. But hey go for it if it fits the problems that you find yourself solving.

There's always Armed Bear Common Lisp. which runs on the JVM, if you want to stay in it. And you can also try [Linj](https://github.com/xach/linj) which is similar to Common Lisp an transpiles to Java.

Re: Creating a Non-Trivial Lisp Game in 2018

#28

Post by _emacsomancer_ »

maufdez wrote: post #27
armitron wrote: post #22

Earlier quoted context omitted.

I'd still pick something else in that case too since I don't really like the decisions behind Clojure. But hey go for it if it fits the problems that you find yourself solving.

There's always Armed Bear Common Lisp. which runs on the JVM, if you want to stay in it. And you can also try [Linj]( https://github.com/xach/linj ) which is similar to Common Lisp an transpiles to Java.

Interesting. Can ABCL be used for the same sorts of use cases as Clojure?
Post reply on HN