Common Lisp • Hacker News Board

Re: Common Lisp

#61

Post by fouric » Sat, Oct 02, 2021, 8:05 PM UTC

zetalyrae wrote: post #47

Kototama wrote: post #44

Earlier quoted context omitted.

The website looks good! Do you still use Common Lisp? If not, what are the reasons?

I like Common Lisp but I no longer use it. I'm pretty much completely burned out on dynamic typing. It feels like building on sand. I want calmer programming, even if it's less powerful. At present I'm building a new language[0] with that goal in mind. [0]: https://github.com/austral/austral

I also want static type-checking in my programs. However, reluctant to give up CL, I've been using type annotations, which SBCL will check at compile-time. Is there a particular reason you're not doing this?

Re: Common Lisp

#62

Post by vindarel » Sat, Oct 02, 2021, 9:05 PM UTC

exdsq wrote: post #46

mark_l_watson wrote: post #6

This looks like a rewrite of this web site? I don’t remember it looking so visually appealing. I would hope that every programmer has a “happy language” that they most enjoy using. CL is my happy language, both for personal projects and also since around 1982 I have probably been paid to use Common Lisp for about five of the last 39 years. This may sound sacrilegious, but in modern times I steer people newly interest…

How do you find Lisp work, out of interest? Especially for an experienced professional without commercial lisp experience?

There are some jobs. We see announces on /r/lisp, Twitter, LinkedIn… sometimes very informal ones. Some companies still pick up CL, for instance: https://github.com/azzamsa/awesome-lisp-companies/ (it's possible that Ravenpack is still hiring?). A good way is of course to learn CL and have something ready to show. Some announces don't require a (commercial) Lisp background though, they seek high-level engineers. Another way is to use CL for yourself, at current job or not. There's plenty of space for that. I use it for new services, instead of extending a Python aging monolith (DB access, FTP connection, XML parsing of a big dataset, a simple web frontend,…). I have even been doing live reloads for a year, installing new libraries while the app is running, and it's been a joy so far. I found one bug (with Sentry alerts of course), because I used = where a number could be nil. So I use `equal`. I am happy, I am productive, deployment is easy and the app is fast.

Re: Common Lisp

#63

Post by trenchgun » Sat, Oct 02, 2021, 9:29 PM UTC

coryrc wrote: post #52

zetalyrae wrote: post #47

Earlier quoted context omitted.

I like Common Lisp but I no longer use it. I'm pretty much completely burned out on dynamic typing. It feels like building on sand. I want calmer programming, even if it's less powerful. At present I'm building a new language[0] with that goal in mind. [0]: https://github.com/austral/austral

Check out https://coalton-lang.github.io/ !

That one is quite interesting indeed.

And they use it for quantum computing research:

"One of the state-of-the-art optimizing quantum compilers is an open-source program called QUILC with a companion quantum computer simulator called the Quantum Virtual Machine. Both of these programs are written in 100% Common Lisp, and contain a total of around 50,000 lines of sophisticated, mathematical, data structure–heavy code. And that excludes the plethora of first-party dependencies.

Common Lisp is a fantastic language for developing these programs; it’s fast, stable, extremely flexible, and the developer experience is unmatched. But, both new and seasoned developers sometimes get tripped up and tangled in the web of complex data structures, and inadvertently introduce type errors that the relatively comprehensive test suite doesn’t catch. In addition, such developers heavily rely on documentation strings (“docstrings”) in order to discover what the probable inputs and outputs of the functions are, and those docstrings sometimes go stale.

Coalton’s aim is to allow us to reap the benefits of Common Lisp, and not have to rewrite 50,000 lines of tricky code in order to realize some of the benefits offered by statically typed functional programming languages." https://coalton-lang.github.io/20211010-introducing-coalton/