One of the things I don't like about Common Lisp is the unusual names. Just on the basis of the linked page, CL21 doesn't fix that. Take princ #"Hello, ${name}\n". Why not just use print like the rest of the programming world. Okay, some languages use writeln, etc. But princ? Why not print? A little further down, we see while-let1. Why the number? If you want to call it "Common Lisp in the 21st Century" you need to c…
As odd as it may seem, I ended up prefering car/cdr over anything else (except when access to pattern matching and destructuring). I know first/rest, head/tail or even fst/snd are clearer names, but car/cdr ended up as symbols having precisely this meaning in LISP idioms (recursion over cons-cell based lists). My 1.5cents
CL21: An experimental project redesigning Common Lisp
21–30 of 102 posts
Re: CL21: An experimental project redesigning Common Lisp
#22One of the things I don't like about Common Lisp is the unusual names. Just on the basis of the linked page, CL21 doesn't fix that. Take princ #"Hello, ${name}\n". Why not just use print like the rest of the programming world. Okay, some languages use writeln, etc. But princ? Why not print? A little further down, we see while-let1. Why the number? If you want to call it "Common Lisp in the 21st Century" you need to c…
As odd as it may seem, I ended up prefering car/cdr over anything else (except when access to pattern matching and destructuring). I know first/rest, head/tail or even fst/snd are clearer names, but car/cdr ended up as symbols having precisely this meaning in LISP idioms (recursion over cons-cell based lists). My 1.5cents
I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times.
You'd be far better off shipping "first" & "rest" and whispering to the old hands that you're sure they know how to "fix" the problem in their code, than presenting new people with car & cdr and then try to wedge an explanation into a brain that just threw an exception and went "Wait, what?"
Re: CL21: An experimental project redesigning Common Lisp
#23This looks cool enough but it would need a big community to really change the common lisp landscape (in my opinion). I wonder how the lazy sequence support stacks up to Clojure, Haskell, etc. support. One difficulty with promoting a more modern layer to common lisp is that Clojure is already such a productive and practical language. I have written a few common lisp books, and remain a fan of the language, and an upgr…
A bit of a tangent, but I've been looking at the series library[0] recently. It makes it possible to write functional style code which is compiled into a loop for efficiency. For example:
(defun integers ()
"Returns a series of all of the integers."
(declare (optimizable-series-function))
(scan-range :from 1))
(defun squares ()
"Returns a series of all of the square numbers."
(declare (optimizable-series-function))
(map-fn t
(lambda (x) (* x x))
(integers)))
(defun sum-squares (n)
"Returns the sum of the first N square numbers."
(collect-sum (subseries (squares) 0 k)))
Although the above definition of sum-squares seems like it would be inefficient, it is roughly the same as the following: (defun sum-squares (n)
"Returns the sum of the first N square numbers."
(loop for i from 1 to n
for square = (* i i)
sum square))
I find it pretty awesome that it is possible to write code that is efficient and functional like that, but I guess series is a bit too magical to be put to actual use.Re: CL21: An experimental project redesigning Common Lisp
#24Earlier quoted context omitted.
Honestly? Mostly because Lisp conventions predate "the rest of the programming world". As for while-let1, it's a while-let with just one variable binding (I guess I'd prefer them to stick with just while-let). There's usually a very good reason behind all those "unusual names" of Common Lisp. I don't think that dumbing things up so that they look more similar to everything else in a language that is already different…
Things that made perfect sense in the 1970s, are not set in stone for all time.
Re: CL21: An experimental project redesigning Common Lisp
#25I think this is an okay idea, but the comparison to Clojure is really lacking. Why build on CL when you can build on Clojure? I get the inter-operability, but when Multi-Threading and Multi-Processing is listed under Deferred , Clojure could provide so much of that for free. On Clojure, etc.
Re: CL21: An experimental project redesigning Common Lisp
#26Earlier quoted context omitted.
As odd as it may seem, I ended up prefering car/cdr over anything else (except when access to pattern matching and destructuring). I know first/rest, head/tail or even fst/snd are clearer names, but car/cdr ended up as symbols having precisely this meaning in LISP idioms (recursion over cons-cell based lists). My 1.5cents
As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be…
Re: CL21: An experimental project redesigning Common Lisp
#27Earlier quoted context omitted.
As odd as it may seem, I ended up prefering car/cdr over anything else (except when access to pattern matching and destructuring). I know first/rest, head/tail or even fst/snd are clearer names, but car/cdr ended up as symbols having precisely this meaning in LISP idioms (recursion over cons-cell based lists). My 1.5cents
As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be…
I like the distinction of car/cdr meaning pointers vs first/rest meaning "start of list/rest of list".
It weirded me out at first, but I came to really appreciate it.
Re: CL21: An experimental project redesigning Common Lisp
#28I think this is an okay idea, but the comparison to Clojure is really lacking. Why build on CL when you can build on Clojure? I get the inter-operability, but when Multi-Threading and Multi-Processing is listed under Deferred , Clojure could provide so much of that for free. On Clojure, etc.
What if you aren't interested in targeting the JVM?
Re: CL21: An experimental project redesigning Common Lisp
#29Earlier quoted context omitted.
As odd as it may seem, I ended up prefering car/cdr over anything else (except when access to pattern matching and destructuring). I know first/rest, head/tail or even fst/snd are clearer names, but car/cdr ended up as symbols having precisely this meaning in LISP idioms (recursion over cons-cell based lists). My 1.5cents
As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be…
Re: CL21: An experimental project redesigning Common Lisp
#30Earlier quoted context omitted.
As odd as it may seem, I ended up prefering car/cdr over anything else (except when access to pattern matching and destructuring). I know first/rest, head/tail or even fst/snd are clearer names, but car/cdr ended up as symbols having precisely this meaning in LISP idioms (recursion over cons-cell based lists). My 1.5cents
@desdiv: If you happen to read this, you appear to have been hellbanned. Not sure why. Just a friendly heads-up.