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

21–30 of 48 posts

Re: Interactive Common Lisp Development

#21

Post by vindarel »

lenkite wrote: post #19
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.

Implementations evolve and improve. https://lisp-journey.gitlab.io/blog/these-years-in-common-li...

I just learned today that another new GC for SBCL is in the works, with GC pauses under 100 microseconds.

Re: Interactive Common Lisp Development

#22

Post by kagevf »

lenkite wrote: post #19
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.

It's unlikely the ANSI standard will ever get updated - it's a very expensive process.

Python doesn't have a standard, but it has a canonical implementation, so maybe a "defacto standard". Not having an official standard didn't matter, though.

Common Lisp has defacto "standard libraries" for things like threading. Other things, such as async, are less clear (to me), but libraries do exist. Just because something isn't in the standard, though, doesn't mean it can't exist. Also, implementation such as SBCL pick up a lot of the slack, filling in some of the missing gaps.

Re: Interactive Common Lisp Development

#23

Post by lenkite »

kagevf wrote: post #22
lenkite wrote: post #19

Earlier quoted context omitted.

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.

It's unlikely the ANSI standard will ever get updated - it's a very expensive process. Python doesn't have a standard, but it has a canonical implementation, so maybe a "defacto standard". Not having an official standard didn't matter, though. Common Lisp has defacto "standard libraries" for things like threading. Other things, such as async, are less clear (to me), but libraries do exist. Just because something isn'…

Python evolves through PEP's https://peps.python.org. Can you kindly correct my deplorable ignorance and point me to the Common LISP enhancement proposals ? Maybe I am missing something elementary.

Re: Interactive Common Lisp Development

#24

Post by mepian »

lenkite wrote: post #23
kagevf wrote: post #22

Earlier quoted context omitted.

It's unlikely the ANSI standard will ever get updated - it's a very expensive process. Python doesn't have a standard, but it has a canonical implementation, so maybe a "defacto standard". Not having an official standard didn't matter, though. Common Lisp has defacto "standard libraries" for things like threading. Other things, such as async, are less clear (to me), but libraries do exist. Just because something isn'…

Python evolves through PEP's https://peps.python.org . Can you kindly correct my deplorable ignorance and point me to the Common LISP enhancement proposals ? Maybe I am missing something elementary.

They are here: https://cdr.common-lisp.dev/

Re: Interactive Common Lisp Development

#26

Post by brabel »

ngcc_hk wrote: post #10
dmpk2k wrote: post #3

Earlier quoted context omitted.

I find the content of the article far too detailed and interesting to warrant a dismissive comment.

If you look at the top post you can understand the disappointment when I click this link and got that. Yes there are a lot of content. Just the topic is …

For someone who knows Common Lisp but rarely plays with the redefinitions mentioned in the post, it's quite enlightening to learn those things. If you're not into Common Lisp you're definitely not the target audience for a post looking at the weird details of it like this one.

Re: Interactive Common Lisp Development

#27

Post by lispm »

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…

Generally Common Lisp is agnostic to the development style. For production, there are also batch compiler. Image saving/starting is also not supported by all implementations (not supported for example in ECL and ABCL).

In early Lisp I would guess it was more often to save an image. There is one system which works mostly like Smalltalk: Interlisp-D, now called Medley. https://interlisp.org It also manages the code, in some ways similar to Smalltalk. Interlisp was provided by Xerox PARC, like Smalltalk. It originates from BBN Lisp, from the 60s.

Other than that, most Lisp systems store code in the file system.

> its not unreasonable to have someone ship a "ball of mud"

That's also relatively common (!) in Lisp.

In Smalltalk we often see variants which can ship images and run them on different architectures. In Common Lisp images are mostly tied to a certain architecture & OS.

Re: Interactive Common Lisp Development

#28

Post by lispm »

IKantRead wrote: post #18
jimbokun wrote: post #16

Earlier quoted context omitted.

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

Lisps have n-dimensional arrays since decades. Often their implementations are a bit less efficient than the ones found written in C and used by Python.

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

What?

Re: Interactive Common Lisp Development

#29

Post by medo-bear »

IKantRead wrote: post #18
jimbokun wrote: post #16

Earlier quoted context omitted.

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

I think matlab has the most succint language for writing matricies

  [1 2 3; 4 5 6; 7 8 9]
then lisp

   #2A((1 2 3) (3 4 5) (7 8 9))
then python comma freak show

   [[1,2,3],[4,5,6],[7,8,9]]
python's greatest achievement was bringing open source to matrix calculations and dethroning matlab. python is what it is today because it offered 99% of what matlab offered in open source and for $0 to uni students

Re: Interactive Common Lisp Development

#30

Post by reikonomusha »

dusted wrote: post #6

After getting sbcl up with visual studio code and the alive extension, my mind was totally blown, I'm certain that emacs/slime is the true pure way, but for someone who's not wanting to learn emacs, alive is just pretty amazing and magic, and it fits well with what is described in the article. I wish I could do stuff like recompile functions in-place and just retry the call without exiting the process in every langua…

The IDE situation remains the #1 issue in adoption. Emacs+SLIME+Paredit (or variants) really are the best way to write Common Lisp, but it's also extremely unpalatable to someone who isn't willing to invest in not just a new language, but also an entirely new and extremely intricate editor stack.

It's been my hope for well over a decade that the situation would change. Alive is decent, but has a long way to go before being a tool a professional could reasonably use.

Post reply on HN