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

Interactive Common Lisp Development

n16f.net

Post reply on HN
Print view View original

11–20 of 48 posts

Re: Interactive Common Lisp Development

#11

Post by vindarel »

ngcc_hk wrote: post #2

Not sure what this for and what is it to do with interactive part of development. If you are vim people try search for vim and lisp and got there. emacs people obviously no need.

It is about the little things that might bite you during a long development session, like deleting a generic function in source but still having the function in the image, or the strategy to update existing object instances when a class definition is updated (and slots are modified, added or removed).

---

btw, regarding packages and removing a symbol: uiop:define-package fixes the annoyance.

Re: Interactive Common Lisp Development

#12

Post by throwaway123422 »

kragen wrote: post #9
borissk wrote: post #8

Lisp is amazing. Interesting why Python won the race to become the language of choice for the neural networks wave of AI.

well, if we categorize python and js as non-lisp languages, i'd say it's mostly because python has been the language of choice at google since last millennium, at least for situations where flexibility outweighs performance last millennium when google started up, no lisp was a good option. clojure didn't exist, schemes were mostly for teaching, cmucl was in disrepair, and though there were proprietary common lisps, t…

[flagged]

Re: Interactive Common Lisp Development

#13

Post by FullGarden_S »

borissk wrote: post #8

Lisp is amazing. Interesting why Python won the race to become the language of choice for the neural networks wave of AI.

Simple. Python had more hype than Lisp did when it mattered (partly because it was modern). So everyone boarded the hype train and here we are.

Re: Interactive Common Lisp Development

#14

Post by IKantRead »

borissk wrote: post #8

Lisp is amazing. Interesting why Python won the race to become the language of choice for the neural networks wave of AI.

As a huge Lisp/Scheme fan, I don't find it surprising that Python became the language of choice for neural networks over Lisp.

NN in general just boil down to doing lots of linear algebra, which is a lot about mutating very large matrices. For this you really just want a wrapper around BLAS/LAPACK, so you can leverage existing optimized libraries.

Working with matrices in Lisp always feels a bit clunky, and doubly so when you want to do a lot of stateful operations on them. The real compitetor in this space to Python is something like Matlab, which has probably the best interface for doing linear algebra (but is worse at everything else).

The one area where Lisp and Python both shine is the ability to perform automatic differentiation. Lisps are great for this task since it's all symbolic manipulation. However, this is only important once you have a solid interface for working with matrices.

If you want to get a feel for the difference I would suggest reading through the surprisingly excellent The Little Learner. I think you'll find that while it really demonstrates the power of Scheme (Racket in this case) in areas where it excels, you wouldn't want to use the framework in that book for anything other than toy examples.

Re: Interactive Common Lisp Development

#15

Post by pjmlp »

borissk wrote: post #8

Lisp is amazing. Interesting why Python won the race to become the language of choice for the neural networks wave of AI.

Not really, Python is where many Lisp folks went when it started to win attention around 20 years ago in research.

CERN and Fermilab were adopting Python for Grid Computing (aka Cloud nowadays), already in 2003.

MIT changed SICP from Scheme to Python back in 2006, thus news generations started playing with Python.

Peter Norvig called Python an acceptable Lisp around 2010, in HN. Having written Python for Lisp programmers in 2000.

https://news.ycombinator.com/item?id=1803351

https://norvig.com/python-lisp.html

What bums me out, is the lack of JIT in the box (yes I know there are some alternatives).

Re: Interactive Common Lisp Development

#16

Post by jimbokun »

IKantRead wrote: post #14
borissk wrote: post #8

Lisp is amazing. Interesting why Python won the race to become the language of choice for the neural networks wave of AI.

As a huge Lisp/Scheme fan, I don't find it surprising that Python became the language of choice for neural networks over Lisp. NN in general just boil down to doing lots of linear algebra, which is a lot about mutating very large matrices. For this you really just want a wrapper around BLAS/LAPACK, so you can leverage existing optimized libraries. Working with matrices in Lisp always feels a bit clunky, and doubly so…

But is there is something inherent to Lisp that makes it "clunky" to work with matrices?

Lisp can be at least as high level and expressive as any other language.

Re: Interactive Common Lisp Development

#17

Post by whartung »

pjmlp wrote: post #5
vindarel wrote: post #4

To really discover what interactive, image-based CL development is about, my pointers: - https://www.youtube.com/watch?v=jBBS4FeY7XM (5min) my demo to show how to resume execution of a long running program, from the stack frame right before the bug, after having fixed and recompiled the function, without quitting the debugger hence without stopping the program, thus without restarting everything from zero. - https://…

The critic of shipping images in Common Lisp and Smalltalk is kind of ironic in the days of Docker and Kubernetes all over the place. Thanks for the links.

To a point. There's an entire culture of software and processes around building up container images from scratch for deployment. There's a term of art that I forget, "Pets vs XXX", with XXX being disposable VMs, in contrast to a Pet computer lovingly cared for over time.

For many Common Lisp scenarios, it's actually similar -- start with the raw based image, load in your code and data, snapshot it, and ship the resulting artifact. At least for me, interactive development aside, it's not untoward to restart a CL system from scratch as a routine part of development. We're not running on Lisp Machines anymore where restarting was actually quite expensive (though there were anecdotes about how at some point it was faster to restart a LispM than let it grind through its GC process, I don't know about that).

However, I don't know how common that is with Smalltalk. How often they restart from scratch. Saving the image is routine in Smalltalk. Where in Lisp you CAN save the image, it's not necessarily part and parcel operationally, historically, or culturally to constantly save the image, especially post LispM. In Smalltalk it is.

I think with CL folk moreso build a new base image, load in some routine utilities, etc. to form a baseline. But application code and image are separate.

Smalltalk, they're not. Code is part of the image (it's stored separately, but it's presented as if they're one and the same). So the image is a much more first class citizen in the Smalltalk world, rather than, perhaps, an artifact.

Especially today, I imagine they have build processes that build up the entire thing again from scratch, but it would not surprise me if they bumped into problems where the image and the source code "don't quite match" that they have to suss out in testing before deployment, because something slipped through and tweaked the long saved image that wasn't properly captured.

In any case, while I'm sure it doesn't quite happen like that today, its not unreasonable to have someone ship a "ball of mud" Smalltalk image in contrast to one in CL.

Re: Interactive Common Lisp Development

#18

Post by IKantRead »

jimbokun wrote: post #16
IKantRead wrote: post #14

Earlier quoted context omitted.

As a huge Lisp/Scheme fan, I don't find it surprising that Python became the language of choice for neural networks over Lisp. NN in general just boil down to doing lots of linear algebra, which is a lot about mutating very large matrices. For this you really just want a wrapper around BLAS/LAPACK, so you can leverage existing optimized libraries. Working with matrices in Lisp always feels a bit clunky, and doubly so…

But is there is something inherent to Lisp that makes it "clunky" to work with matrices? Lisp can be at least as high level and expressive as any other language.

> But is there is something inherent to Lisp that makes it "clunky" to work with matrices?

s-exps are basically coding at the level of the AST, which for many programming tasks is a powerful level of both abstraction and control.

But this interface tends to work much better on tree-like structures (the most simple of which is the list, which in it's simplest case is a cons cell, Lisp's most fundamental particle).

Most programming tasks can boil down to tree manipulation, but large matrices feel a bit out of place with this interface because you are basically to working with arrays (which in it's simplest cases is a pointer to a memory address, which is C's fundamental particle). C like languages (I know, technical ALGO-like), tend to feel more natural for these tasks.

But of course if you can manipulate trees easily, you can manipulate code easily which gives you...

> Lisp can be at least as high level and expressive as any other language.

In practice, for Lisp this is also a weakness. Again, I love Lisps in general, and of course any Lisp and especially Common Lisp (with it's exceptionally excellent macro system) can do anything you want.

However, my (and many others) experience has been that this leads to is it becomes very easy to create code that is amazing for the original developer, but very difficult for new developers to get their head around. Hence the adage "Lisp is optimal for team sizes of one."

You could undoubtable build the worlds most elegant interface to working with matrices in Lisp, but now you essentially have a new language.

Re: Interactive Common Lisp Development

#19

Post by lenkite »

borissk wrote: post #8

Lisp is amazing. Interesting why Python won the race to become the language of choice for the neural networks wave of AI.

Maybe when Common LISP gets its next standard and stops being a geezer on the deathbed ? The world has changed since 1994. So has the computing landscape. If a programming language is static for more than a human generation, then it cannot expect any sort of adoption.

Re: Interactive Common Lisp Development

#20

Post by everforward »

whartung wrote: post #17
pjmlp wrote: post #5

Earlier quoted context omitted.

The critic of shipping images in Common Lisp and Smalltalk is kind of ironic in the days of Docker and Kubernetes all over the place. Thanks for the links.

To a point. There's an entire culture of software and processes around building up container images from scratch for deployment. There's a term of art that I forget, "Pets vs XXX", with XXX being disposable VMs, in contrast to a Pet computer lovingly cared for over time. For many Common Lisp scenarios, it's actually similar -- start with the raw based image, load in your code and data, snapshot it, and ship the resul…

> There's a term of art that I forget, "Pets vs XXX", with XXX being disposable VMs, in contrast to a Pet computer lovingly cared for over time.

"Cattle" is what I usually hear. Pets are unique and cannot be interchanged. Cattle are fungible and expendable.

Post reply on HN