6 ms·

Common Lisp in the 21st Century

90 points by johnwalker 13y ago

emiljbs 13y ago
And this is what /r/lisp thought about it: http://www.reddit.com/r/lisp/comments/1vtueu/cl21_common_lisp_in_the_21st_century/ http://www.reddit.com/r/lisp/comments/1vtueu/cl21_common_lis...
adwf 13y ago
I've always thought that CL needed a set of common libraries to be strongly recommended. The problem is that it has been tried before, but never really taken off. However, given the recent rise of quicklisp for managing libraries, it's entirely possible that a project of this type will be much more successful. I hope so! I still remember the first time I looked at the Alexandria library and realised I'd already implemented a good 1/4 of the functionality myself, just because it was glaringly missing from the CL core spec.
- orthecreedence 13y ago
  > I still remember the first time I looked at the Alexandria library and realised I'd already implemented a good 1/4 of the functionality myself Yeah, same here. I have a bunch of utilities lying around from when I started that Alexandria would have completely obliterated. I'm interested in cl21's use of symbol partitioning. I've always thought the `cl:` package was really, really bloated and somewhat confusing to newcomers. Something that divides everything into "this is for math" "this is for primitive data types" etc would make things a bit easier to manage. I know /r/lisp didn't really like it for the most part, but since the spec is frozen it's nice to see people who are involved in lisp actively trying to make it better. The world is littered with successful projects that started out with people saying "You're wrong, don't bother doing this." I wish Mr. Fukamachi well and look forward to progress.
ryeguy 13y ago
One of the annoyances of CL is the absolutely nonsense function names. Just looking at these examples, I have no idea what princ (something to do with print, i assume), getf, or elt (element?) mean.
- orthecreedence 13y ago
  Yeah, you're right. A lot of people are turned off by it and a lot of the old-guard just say "deal with it!!" After getting used to a lot of the symbols (`car`, `cadr`, etc) you kind of stop being too annoyed and don't even notice them anymore. It's like learning another language, there's not always a 1:1 mapping of words. That said, it's much better to recognize a problem and try to fix it that say "It has worked fine for 50 years!! Leave it!" That definitely seems to be one of the goals of this project: to give CL a face that makes a bit more sense.
- johnwalker 13y ago
  The functions are basically inconsistent in both name and argument order. I think that's one of the problems they're working on correcting (a generic elt/getf), and more obvious ways of creating and using non-list data structures.
  - orthecreedence 13y ago
    I think the hash table syntax is a huge step in the right direction. Almost every modernly-used language ever has hash table syntax. In lisp, I have to do (let ((myhash (make-hash-table :test 'equal))) (setf (gethash "name" myhash) "andrew" (gethash "location" myhash) "sf")) Instead of `#{"name" "andrew" "location" "sf"}`.
    - johnwalker 13y ago
      Yep! It's necessary to modify slime (or light table? I've been interested in making a CL plugin for it) to take advantage of this syntax, but the absense of sane reader macros in the spec has always driven me nuts.
      - emiljbs 13y ago
        Huh? No you don't... Maybe I don't get what you mean. Here's the code for basic hashtable syntax: https://gist.github.com/ejbs/8924773 https://gist.github.com/ejbs/8924773
deleted 13y ago
[deleted]
- orthecreedence 13y ago
  It's general purpose. It's a high-level language that has OS-level threading, can be functional/imperative, compiles to machine code, has powerful macros which completely cut down code repetition and allow syntax expansion, can call out to C without compiling wrappers. About the only thing it's missing are coroutines, and even those can be mimicked by macros to some extent. Really, a better question is what can't lisp do. It's probably not the best choice for an embedded device or something like that, or anywhere you need tight control over memory/resources. I'd say it's an extremely decent complement to C in a lot of respects. If you can get passed some of the oddly-named symbols, it's a great language that has made leaps and bounds in the past 10 years as far as third-party libraries and implementation features.
- martinflack 13y ago
  Well, it's amazing for rapid prototyping. The same could be said for Ruby/Perl etc but the addition of the REPL, CLOS, Macros, etc make it slightly better. As long as the libraries exist for CL upon which to build, which can be a sticking point. To give the more canonical answer, though... CL is the programmable programming language, so it's not suited for a task per se; rather you lay down a base that's suited to your problem domain, and then you solve your problem in your newly-created "language". It's hard to explain but true if you get it right.
deleted 13y ago
[deleted]
kenbot 13y ago
Lisp for the 21st century and it's.... _more_ object oriented?
- vseloved 13y ago
  cause, in Lisp OO is done right ;)
melipone 13y ago
CL in the 21st Century is Clojure.
- PuercoPop 13y ago
  Damn right, I love how clojure hosted semantics import all the great features of their host. Like how clojurescript has only floating point numbers and coerces string to numbers when using the + operator. In all seriousness, I mad love to Clojure, but is a different language with different sensibilities/tradeoff. Not a 'better' CL. For example, I imagine that interfacing with c code using cffi should be way easier and simpler than using JNI and then exposing that to clojure. Or having defined semantics for numerical computations.
- stewbrew 13y ago
  Inexplicable stack traces caused by mediocre tools?
  - deleted 13y ago
    [deleted]
- vseloved 13y ago
  You've probably never seriously programmed in CL. I'd say, the opposite, i.e. Clojure is in many ways backward compared to CL.
ScottBurson 13y ago
Huh. These all seem like minor details. I think (shameless plug) that my FSet functional collections library helps modernize CL quite a bit more than this does. I've had a couple of people tell me that FSet has changed the way they program. That's a high compliment. I'd be the first to admit that FSet takes some getting used to, but if you're willing to put in the work to learn to think this way, there are substantial benefits. It greatly expands one's opportunities to write CL code in a functional style. (Those already familiar with the functional style will find it fairly natural.)
- johnwalker 13y ago
  That's really cool. I've wanted your library for a long time!
- e12e 13y ago
  I assume that's: http://common-lisp.net/project/fset/ http://common-lisp.net/project/fset/
  - ScottBurson 13y ago
    Yep!

90 points by johnwalker 13y ago

And this is what /r/lisp thought about it: http://www.reddit.com/r/lisp/comments/1vtueu/cl21_common_lisp_in_the_21st_century/ http://www.reddit.com/r/lisp/comments/1vtueu/cl21_common_lis...

adwf 13y ago

I've always thought that CL needed a set of common libraries to be strongly recommended. The problem is that it has been tried before, but never really taken off. However, given the recent rise of quicklisp for managing libraries, it's entirely possible that a project of this type will be much more successful. I hope so! I still remember the first time I looked at the Alexandria library and realised I'd already implemented a good 1/4 of the functionality myself, just because it was glaringly missing from the CL core spec.

orthecreedence 13y ago
> I still remember the first time I looked at the Alexandria library and realised I'd already implemented a good 1/4 of the functionality myself Yeah, same here. I have a bunch of utilities lying around from when I started that Alexandria would have completely obliterated. I'm interested in cl21's use of symbol partitioning. I've always thought the `cl:` package was really, really bloated and somewhat confusing to newcomers. Something that divides everything into "this is for math" "this is for primitive data types" etc would make things a bit easier to manage. I know /r/lisp didn't really like it for the most part, but since the spec is frozen it's nice to see people who are involved in lisp actively trying to make it better. The world is littered with successful projects that started out with people saying "You're wrong, don't bother doing this." I wish Mr. Fukamachi well and look forward to progress.

ryeguy 13y ago

One of the annoyances of CL is the absolutely nonsense function names. Just looking at these examples, I have no idea what princ (something to do with print, i assume), getf, or elt (element?) mean.

orthecreedence 13y ago
Yeah, you're right. A lot of people are turned off by it and a lot of the old-guard just say "deal with it!!" After getting used to a lot of the symbols (`car`, `cadr`, etc) you kind of stop being too annoyed and don't even notice them anymore. It's like learning another language, there's not always a 1:1 mapping of words. That said, it's much better to recognize a problem and try to fix it that say "It has worked fine for 50 years!! Leave it!" That definitely seems to be one of the goals of this project: to give CL a face that makes a bit more sense.
johnwalker 13y ago
The functions are basically inconsistent in both name and argument order. I think that's one of the problems they're working on correcting (a generic elt/getf), and more obvious ways of creating and using non-list data structures.
- orthecreedence 13y ago
  I think the hash table syntax is a huge step in the right direction. Almost every modernly-used language ever has hash table syntax. In lisp, I have to do (let ((myhash (make-hash-table :test 'equal))) (setf (gethash "name" myhash) "andrew" (gethash "location" myhash) "sf")) Instead of `#{"name" "andrew" "location" "sf"}`.
  - johnwalker 13y ago
    Yep! It's necessary to modify slime (or light table? I've been interested in making a CL plugin for it) to take advantage of this syntax, but the absense of sane reader macros in the spec has always driven me nuts.
    - emiljbs 13y ago
      Huh? No you don't... Maybe I don't get what you mean. Here's the code for basic hashtable syntax: https://gist.github.com/ejbs/8924773 https://gist.github.com/ejbs/8924773

deleted 13y ago

[deleted]

orthecreedence 13y ago
It's general purpose. It's a high-level language that has OS-level threading, can be functional/imperative, compiles to machine code, has powerful macros which completely cut down code repetition and allow syntax expansion, can call out to C without compiling wrappers. About the only thing it's missing are coroutines, and even those can be mimicked by macros to some extent. Really, a better question is what can't lisp do. It's probably not the best choice for an embedded device or something like that, or anywhere you need tight control over memory/resources. I'd say it's an extremely decent complement to C in a lot of respects. If you can get passed some of the oddly-named symbols, it's a great language that has made leaps and bounds in the past 10 years as far as third-party libraries and implementation features.
martinflack 13y ago
Well, it's amazing for rapid prototyping. The same could be said for Ruby/Perl etc but the addition of the REPL, CLOS, Macros, etc make it slightly better. As long as the libraries exist for CL upon which to build, which can be a sticking point. To give the more canonical answer, though... CL is the programmable programming language, so it's not suited for a task per se; rather you lay down a base that's suited to your problem domain, and then you solve your problem in your newly-created "language". It's hard to explain but true if you get it right.

deleted 13y ago

[deleted]

kenbot 13y ago

Lisp for the 21st century and it's.... _more_ object oriented?

vseloved 13y ago
cause, in Lisp OO is done right ;)

melipone 13y ago

CL in the 21st Century is Clojure.

PuercoPop 13y ago
Damn right, I love how clojure hosted semantics import all the great features of their host. Like how clojurescript has only floating point numbers and coerces string to numbers when using the + operator. In all seriousness, I mad love to Clojure, but is a different language with different sensibilities/tradeoff. Not a 'better' CL. For example, I imagine that interfacing with c code using cffi should be way easier and simpler than using JNI and then exposing that to clojure. Or having defined semantics for numerical computations.
stewbrew 13y ago
Inexplicable stack traces caused by mediocre tools?
- deleted 13y ago
  [deleted]
vseloved 13y ago
You've probably never seriously programmed in CL. I'd say, the opposite, i.e. Clojure is in many ways backward compared to CL.

ScottBurson 13y ago

Huh. These all seem like minor details. I think (shameless plug) that my FSet functional collections library helps modernize CL quite a bit more than this does. I've had a couple of people tell me that FSet has changed the way they program. That's a high compliment. I'd be the first to admit that FSet takes some getting used to, but if you're willing to put in the work to learn to think this way, there are substantial benefits. It greatly expands one's opportunities to write CL code in a functional style. (Those already familiar with the functional style will find it fairly natural.)

johnwalker 13y ago
That's really cool. I've wanted your library for a long time!
e12e 13y ago
I assume that's: http://common-lisp.net/project/fset/ http://common-lisp.net/project/fset/
- ScottBurson 13y ago
  Yep!