[HN Gopher] Common Lisp
___________________________________________________________________
Common Lisp
Author : astdb
Score : 155 points
Date : 2021-10-02 04:27 UTC (18 hours ago)
(HTM) web link (lisp-lang.org)
(TXT) w3m dump (lisp-lang.org)
| jolux wrote:
| Compare SxQL to Ecto.Query, the main query DSL for Elixir:
| query = from u in "users", where: u.age > 18,
| select: u.name
| bluefox wrote:
| So what?
|
| You can come up with something like: (from u
| in users where u.age > 18 select u.name)
|
| It's a simple matter of programming.
| jolux wrote:
| I'm illustrating a similarity, not making a judgment on which
| is better.
| fithisux wrote:
| I enjoyed, now it is time to get some books. Wished Scheme did
| the same.
| john2x wrote:
| https://racket-lang.org ;)
| cnbland wrote:
| I feel inspired to start with Lisp after being disappointed with
| the "open" source scene of 2021. I'd rather pay LispWorks a
| yearly fee and be left alone than dealing with unbalanced people
| in the Python space. The free Lisp implementations also look
| somewhat isolated from the ideological wars.
|
| However, a C interface is required. Is this one the recommended
| solution? Is it really portable?
|
| https://common-lisp.net/project/cffi/
|
| What is the speed compared to a Python C extension? Are
| implementation-specific C interfaces faster (I guess they are)?
|
| Sorry for so many questions, but these can usually only be
| answered by people who have actually used the interface.
| Jach wrote:
| If you're interested in FFI, then yeah CFFI is the standard.
| The other comments addressed speed, I also wanted to point out
| https://github.com/rpav/cl-autowrap which is built on top of
| CFFI and can help get a wrapper up and running faster. After
| using autowrap's c-include you can then use CFFI basically like
| normal or some useful autowrap/plus-c's helper functions --
| e.g. in one project, I have an SDL_Event
| (https://wiki.libsdl.org/SDL_Event) and to access
| event.key.keysym.scancode I have a helper function that's just
| (plus-c:c-ref event sdl2-ffi:sdl-event :key :keysym :scancode).
| Last year I wanted to try out using FMOD, and even though it's
| closed source and has a (to me) "interesting" API things worked
| easily:
| https://gist.github.com/Jach/dc2ec7b9402d0ec5836a935384cacdc...
| More work would be needed to make a nice wrapper, type things
| more fully, etc. but depending on the C library you might find
| someone's already done that (or made a start) and made it
| available from quicklisp.
| AtlasBarfed wrote:
| "Unbalanced" python people? Do you have examples? I don't do
| python and have no basis of experience with python, besides the
| fact that I have never installed a python program successfully
| with their package manager.
|
| Is python the language that has spread furthest from
| programming circles? It probably used to be VB mostly due to
| Office, but with Python at #2 in Tiobe ahead of Java and behind
| only C, I'd guess yes.
| na85 wrote:
| Here's a good example of unbalanced people: https://github.co
| m/pypa/pipenv/issues/2228#issuecomment-3926...
| bluefox wrote:
| Yes, CFFI is the defacto standard, and has support for
| practically all implementations in use today. Nobody (but CFFI)
| uses the implementation-specific interfaces.
| Kototama wrote:
| The most friendly and welcoming open source communities in my
| experience are Ruby, Elixir and Clojure. I'm sorry you had bad
| experiences, but don't let that stop your projects.
| codr7 wrote:
| I would give the Emacs/Slime/SBCL combo a try, it's definitely
| an acquired taste but pretty cool and more Lispy than anything
| else you will find.
| aidenn0 wrote:
| Comparing python's C extensions to CFFI is non-trivial because
| they work very differently. With Python, you implement the
| Python API in C, but with CFFI you implement the C API in lisp.
|
| Re: CFFI vs. built-in API
|
| The main difference is what features you have. For example, if
| you need errno, you will need to do something implementation
| specific (I'm currently working on a wrapper for that
| functionality though).
|
| Another example: ECL let's you inline C code in the middle of a
| lisp program. Most other implementations don't.
|
| As far as performance goes, the actual overhead of calling C is
| minimal, but if you need to copy large amounts of data, that
| can kill performance.
|
| There is another library called static-vectors that let's you
| allocate buffers that can be used natively in both lisp and C,
| on the implementations that allow doing so.
| tasubotadas wrote:
| Common lisp is cool but I really wish it wouldn't be an ANSI
| standard so the language development would continue.
|
| The current standard library is a bit limiting and there are a
| bunch of good ideas that it could borrow from Clojure (literals?
| Anyone?)
| Jtsummers wrote:
| I don't think being a standard is the problem. The general loss
| of interest in the language was the problem. If it had
| continued to gain or maintain interest we might've had a later
| revision of the standard. Other standardized languages get
| revised regularly, hell even Ada, Cobol, and Fortran receive
| updates at least once a decade.
| executive wrote:
| Chialisp is interesting.
|
| https://chialisp.com/
| zerr wrote:
| I wish LISP 2 was never abandoned.
| https://en.wikipedia.org/wiki/LISP_2
| derekzhouzhen wrote:
| When reading "Lisp-2", Most lisp programmers will probably
| think of the lisp dialects with 2 namespaces, one for value
| binding, one for function binding. See
| https://andersmurphy.com/2019/03/08/lisp-1-vs-lisp-2.html
|
| Lisp-2 are still alive; emacs lisp is a lisp-2. If you
| extrapolate hard enough, both Erlang and Elixir are lisp-2.
| hollerith wrote:
| Common Lisp is another example of a Lisp with 2 namespaces.
| derekzhouzhen wrote:
| Yeah. Lisp 1s are more common though. Racket, Scheme,
| Clojure, ... Hell, Javascript is also a lisp 1.
| Kototama wrote:
| Not really. See
| http://journal.stuffwithstuff.com/2013/07/18/javascript-
| isnt...
| derekzhouzhen wrote:
| Chill, man. I know I was stretching. It is undeniable
| that javascript took inspiration from lisp/scheme.
| pfdietz wrote:
| Common Lisp has more than two namespaces.
| KineticLensman wrote:
| The point is that it has more than one.
| pfdietz wrote:
| The point is he wrote "two", not "more than one".
| hollerith wrote:
| ". . . with a namespace for functions that is different
| from the one for ordinary values", then!
|
| I got into this trouble by wanting to avoid contributing
| to the perpetuation of the terms "Lisp-1" and "Lisp-2". I
| find those 2 terms regrettable because using a short name
| for a concept implies that the concept is important, but
| whether functions share the same namespace as values do
| is not IMO an important decision in the design of a
| programming language: changing the decision changes the
| character of the language in only a few superficial ways.
| Kototama wrote:
| It exists somehow with Elixir. It's not homoiconic and the
| interactive development experience is far from being as good as
| Common Lisp or even Clojure but it supports metaprogramming at
| an advanced level, is functional and dynamically typed.
| zerr wrote:
| Besides Algol-like syntax, LISP 2 was meant to be compiled,
| fast and statically typed.
| lokedhs wrote:
| Common Lisp is 2 out of those three. Implementations such
| as SBCL give you a lot of static typing too, even though
| it's optional.
| kazinator wrote:
| Arguably, CGOL later did this concept better, using portable
| Lisp code.
| markus_zhang wrote:
| Why do we see programming language webpages and Wikipedia pages
| submission from time to time?
| dathinab wrote:
| Because thats what Hacker News is:
|
| A site which people ping with interesting and noteworthy things
| they stumble about and then other people decide if they think
| it's actually noteworthy until it's either on the front page or
| dropped out.
|
| Wikipedia and other web pages can be quite noteworthy.
|
| Through sure once everyone has seen it it's no longer note
| worthy.
|
| That's why some really noteworthy things pop up on HN again and
| again with gaps of a few month/a year between: People think
| they are noteworthy, push them then "everyone" knows them so
| they are no longer noteworthy but then people forget and wups,
| it's up on the front page again ;=)
| markus_zhang wrote:
| Well if the community is fine with wikipedia pages then so be
| it.
| [deleted]
| Zababa wrote:
| That's my personal opinion, but I think that programming language
| pages should have more information density. I also think that
| using your average "startup template" for Common Lisp is a bit
| weird. A good example of what I like might be the OCaml homepage
| https://lisp-lang.org/, the Go homepage https://golang.org/. The
| Haskell homepage has a REPL with a tutorial, which encourages you
| to play around with the language, I think that's a good idea
| https://www.haskell.org/. TypeScript's page is also nice
| https://www.typescriptlang.org/. For something a little bit
| different, Dhall is also good at quickly demonstrating how it
| works https://dhall-lang.org/.
|
| That might just be a consequence of my time on Hacker News, but I
| think the insistance on Paul Graham is a bit much.
|
| The chart about server performance felt a bit weird to me, as I
| think the difference between Ruby and JS would be bigger at
| least. So I checked on techempower benchmarks
| (https://www.techempower.com/benchmarks/) and sadly there is no
| common lisp. It's also not on the last runs (https://tfb-
| status.techempower.com/). I think putting the origin of the
| results and a way to reproduce them would be a good thing. I
| don't doubt that common lisp is fast, but that diagram looks a
| bit too much like hollow marketing, especially with the image
| behind.
|
| The page about OO (https://lisp-lang.org/learn/clos) has a good
| explanation of multiple dispatch, but I think it should come with
| an example. The first steps pages (https://lisp-
| lang.org/learn/first-steps) also explains atoms well, but it
| doesn't explain lists after mentionning them.
|
| In general this feels a bit unpolished, though some part are
| good. There's no mention of the Common Lisp cookbook
| (https://lispcookbook.github.io/cl-cookbook/), which sadly
| confirms a bit the "Lisp users all have NIH syndrome" meme.
| vindarel wrote:
| They mention the Cookbook on the books page: https://lisp-
| lang.org/books/ (btw Fernando is also the one who did the
| initial effort to port the Cookbook from Sourceforge to Github
| pages. When lisp-lang.org was released the Coobook looked bad
| and didn't have a lot of content).
| p4bl0 wrote:
| > A good example of what I like might be the OCaml homepage
| https://lisp-lang.org/
|
| That should be https://ocaml.org/ of course :).
| Zababa wrote:
| Good catch, thanks!
| Kototama wrote:
| The website seems to be done by one guy only and abandoned
| (look at the "news" section).
| andrewl wrote:
| I agree that a language homepage should be information dense,
| and give the new user a clear overview without having to
| scroll. I think the Common Lisp homepage is an improvement over
| what I remember from years ago, and while it's visually
| _appealing_ it's not as immediately _useful_ as I'd like.
|
| Besides the examples Zababa offered, I'd say the home pages for
| Ruby, Julia, and Python are also good:
|
| https://www.ruby-lang.org/en/
|
| https://julialang.org/
|
| https://www.python.org/
| Zababa wrote:
| They are all good examples too.
| zetalyrae wrote:
| I built this around 2015-2016, the idea was to have a "soft"
| landing page with the headlining features (stability,
| performance etc.) and links to further pages: the success
| stories page[0] (which should have been emphasized more) and
| the wiki[1].
|
| [0]: https://lisp-lang.org/success/
|
| [1]: https://lisp-lang.org/wiki/
| Zababa wrote:
| I thought this was a recent effort, so I'm sorry if I was too
| harsh.
| zetalyrae wrote:
| Hey, I made this! Feel free to ask anything.
|
| I released this in 2016. It was a significant undertaking and I
| burned out pretty hard afterwards. I was operating under a naive
| "if you build it, they will come" model whereby building a
| modern-looking website, the community would coalesce around it
| and contribute to the wiki etc. But my "rallying people behind a
| cause" skills were insufficient.
|
| One nice contribution: at the time Common Lisp didn't really have
| an official logo, which I felt was bad for marketing. So my
| friend made one:
| https://github.com/LispLang/lisplang.github.io/blob/master/a...
|
| This was decidedly a social rather than technical effort, and
| social problems are hard to solve.
| vindarel wrote:
| Hi! When will you come back and write new useful libraries?
| Best,
| lukego wrote:
| It's really neat that you did this :)
|
| Of course you will never please everyone, especially in the
| extremely heterogeneous Common Lisp community, but I think it
| looks sharp.
| zetalyrae wrote:
| Thank you! I built it to try to increase the profile of
| Common Lisp and have a gentle on-ramp to get new users into
| the community.
| Kototama wrote:
| The website looks good! Do you still use Common Lisp? If not,
| what are the reasons?
| zetalyrae wrote:
| 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
| kragen wrote:
| I'm curious how extensively you use automated tests in
| dynamically-typed languages? I find that the types in
| statically-typed languages, especially OCaml, take up a lot
| of the load of tests.
|
| Of course, types can prove things tests can't, and
| especially the linear types you're using in Austral.
|
| I've been wondering what a "tiny Rust" would look like, so
| Austral looks pretty interesting.
| coryrc wrote:
| Check out https://coalton-lang.github.io/ !
| trenchgun wrote:
| 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/
| fouric wrote:
| 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?
| omginternets wrote:
| Can you elaborate on linear types? What do they bring to
| the table and how do they work ?
| mark_l_watson wrote:
| 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 interested in Lisp languages towards Racket. There are also
| many great Scheme implementations.
|
| For my own development I use LispWorks Pro, which is pricey but
| extremely well supported. SBCL is probably the best open source
| CL system, and I often use it side by side with LispWorks.
| exdsq wrote:
| How do you find Lisp work, out of interest? Especially for an
| experienced professional without commercial lisp experience?
| mark_l_watson wrote:
| I enjoy developing in Lisp but the number of jobs are smaller
| than Python/C++/Java/etc.
| vindarel wrote:
| 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.
| default-kramer wrote:
| I've been curious about Common Lisp in the past but never really
| got started because I can't seem to find very good documentation.
| What do veteran CL users use as a reference? This maybe?
| http://www.lispworks.com/documentation/HyperSpec/Front/index...
|
| I suppose I've "become accustomed to a certain lifestyle" coming
| from Racket's excellent documentation. But even if you ignore
| Racket, the R6RS reference (for example) seems way more readable
| than the CL spec: https://docs.racket-lang.org/r6rs/r6rs-
| std/index.html Same goes for Clojure, which I've never used:
| https://clojure.org/reference/documentation
|
| This is not meant to be an attack on Common Lisp; I'm just trying
| to learn.
|
| EDIT: I just saw https://lisp-lang.org/spec/ which says "We're
| currently working on parsing the TeX sources of the specification
| to generate a more modern version of the CLHS. This might take a
| while." I'm looking forward to seeing the result!
| Jach wrote:
| My favorite quick reference I have printed out is
| http://clqr.boundp.org/ It's nice to just quickly explore
| what's available in the base language too.
|
| But when I don't want to flip through it, or find the short
| description for something insufficient, then yeah the HyperSpec
| is usually my first stop for quickly referencing something. I
| use vim, so I just move my cursor over a symbol and type ",h"
| and that opens a browser tab on that thing in the hyperspec --
| e.g. if I want to remind myself what the state parameter of
| make-random-state does, I open
| http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_r...
| Though I often first type ",s" which is just an alias for
| (describe 'symbol) which shows me locally the symbol
| documentation, and for this one I'd learn the same thing
| without having to have my browser open. I think some people
| configure their emacs to do the common IDE thing of showing you
| the doc along with the function signature as you type, I just
| have the latter. I also make use of jump-to-source since
| reading the code is often the quickest way of answering a
| question about it.
|
| PAIP is a great book, but I tend to use PCL as a quick
| reference: https://gigamonkeys.com/book/ Especially until you
| use classes/format/conditions/loop enough to get used to them,
| chapters 17/18/19/22 are helpful. It's still a recommended
| first book for newcomers that's worth going through entirely
| though, not just as a reference.
|
| https://lispcookbook.github.io/cl-cookbook/ is a useful
| community cookbook with info on a lot of topics.
|
| CLTL2 is a reference I haven't used that much, there are a few
| things that are in it that didn't make it to the ANSI spec, but
| what I have read I've found useful and clarifying.
| https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node1.html Guy
| Steele (whose 67th birthday is today) is a great writer.
| lukego wrote:
| Norvig's PAIP is what won me over from Scheme to Common Lisp.
| https://github.com/norvig/paip-lisp
| vindarel wrote:
| This website (and all the author's libraries) was such a
| refresher. It has been important for me to not run away from CL
| (again). At that time, the "official" website, the first Google
| result for CL looked like this:
| https://web.archive.org/web/20160305135106/https://common-li...
| Fortunately, they revamped it circa 2018: https://common-
| lisp.net/ (work mainly due to @mmontone if I'm not mistaken).
| Since then, the Cookbook was expanded with useful content (it was
| kind of hard to find up to date information online, on even
| simple matters like how to build a binary) and we got some useful
| lists too, like https://github.com/CodyReichert/awesome-cl and a
| list of (current, existing) companies:
| https://github.com/azzamsa/awesome-lisp-companies/ Hopefully it's
| easier than ever to have your questions answered and start
| hacking in Lisp!
|
| Another very helpful resource by Fernando was his state of CL
| ecosystem: https://borretti.me/article/common-lisp-sotu-2015 It
| really helped have an overview of the ecosystem, pick libraries
| and work on consolidation. I compiled one for 2020 here:
| https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp...
|
| (ps: yes people, you can avoid Emacs and use VSCode to have a
| good experience! and even Atom, Jupyter notebooks and more. See
| https://lispcookbook.github.io/cl-cookbook/editor-support.ht...)
___________________________________________________________________
(page generated 2021-10-02 23:01 UTC)