One idea that I think gives the best of both worlds is to use lisp to generate your C++ (or whatever) boilerplate instead of dealing with the maddening vaugeries of template metaprogramming, boost, STL, etc to achieve genericity.
I don't think it's as easy as that. In fact there's probably no single reason accountable for Lisp's lack of popularity. Here's my own personal pet peeve: Declaring local variables creates a level of nesting. Local variables are a great tool for improving code clarity. Having to wrap your logic with `(let [value (...)] ...)` in order make a new local variable is unnecessarily painful.
The deal breaker for me is the unwillingness to rename outdated identifiers: `car` instead of `first` or `head` and `cdr` instead of `rest` or `tail`; the use of asterisks to show that a function differs in semantics (`let` versus `let*`); and the verbosity of using anything other than a pure list.
If I had to use a Lisp-like language, I'd choose Clojure so I can interoperate with the JVM. (I use Scala already, so I could interoperate with that, too.)
I designed my own Lisp dialect that is very influenced by Common Lisp. It has the cadar functions down to five levels deep. They are awesome. I have about 17 years of Lisp coding experience. Only in the last few years, I have come around to using those cddrcadr and so on. They express the right thing when the subject is tree structure, rather than a flat list which contains items.
Suppose that we have used (cddr x) to test whether the list
x continues after the second item. It is then unnatural to have (third x) to retrieve the third item! It is like "faulty parallelism" in your English essay. :)
If the condition (and (cdr x) (consp (cddr x))) holds, then the proper way to get that item is (caddr x). This is easy to verify: If cddr is a cons, then its car is given by tacking on an "a": caddr.
In any case, car, cdr and the rest are an absolute must in a Lisp dialect. They are instantly understandable; there is no good reason to break with this important convention. A Lisp dialect will not achieve anything by breaking cultural compatibility with other dialects in this regard; it will just be shunned by Lisp people yet still disused by everyone else. Although CAR and CDR come from IBM 704 machine language, which means nothing to pretty much anyone over fifty years later, the people who allowed these names to infect the higher level language weren't idiots. They discovered that the names just work and so used them. Borrowing some mnemonic that works from the IBM 704 is no worse than borrowing some equally arbitrary greek letter like lambda from a branch of mathematics. If the mathematics of anonymous functions had been called "Tau Calculus" we would be writing (tau (x y) + x y) instead of lambda; it's just a historic accident. All names are historic accidents: one person calls it water, another one aqua, a third one mizu.
I also love the star convention and have used it in many places. for instance mapcar* is a lazy mapcar: it can take infinite lists as its arguments and returns the resulting lazy list immediately. Leslie Lamport picked up on this star notation in LaTeX; that's where I first encountered it. When I got into Lisp years later it was like, hello, is that where Lamport got it from?
I don't like verbosity, so I made my dialect slick and ergonomic. It can "code-golf" side by side with the so-called "modern" scripting languages, while remaining clear.
Having to wrap your logic with `(let [value (...)] ...)` in order make a new local variable is unnecessarily painful.
You can have more than one value in a let and it typically does not cause problems. If you do find it causes problems, it is trivial to change the language and invent your own, expression for defining local variables.
Its fine to have your reasons for hating lisp, but if this is the only thing that puts you off, I recommend giving it another try.
I program in Clojure more than in any other language. That doesn't change the fact that I feel a stronger incentive to avoid local variables than in any other language I've used so far. Also if I wanted to tackle this issue with a macro I'd probably have to make an alternative to `defn`. That's a great way to invent a dialect of Clojure nobody else will be familiar with.
C only introduced the ability to mix declarations and statements in 1999, and not all compilers caught up with C99 right away.
By that time, C had long been a popular language, in spite of demanding that, just like in Pascal, local variables have to be defined at the opening of a new block scope, after which only statements follow.
This is actually a good idea; I avoid mixed declarations and statements in C programming.
Also, mixed declarations and statements are against the Linux kernel coding guidelines and are diagnosed. Yet countless people hack on the Linux kernel for fun and profit.
When I really need some tightly scoped local variable in C, I introduce a little scope with a new braced compound statement, just like `(let` in Lisp. This has the advantage that you determine where the scope ends, not only where it begins. You know: from line 27 this 75 line function, down to line 53, and that's it, not all the way down to line 75.
The mainstream dialect of lisp known as Scheme has a define construct which lets you create new scopes with local variables at the same level of nesting. (Scheme compilers transliterate these defines-s to nested let for you). Yet Scheme is not taking over the world. This aspect rarely even comes up as a topic.
In fact there's probably no single reason accountable for Lisp's lack of popularity.
There is this one: simple statistics. People have created an astonishing number of programming languages, of which only a vanishing minority are popular. If you pick a language randomly out of all of the ones that have been ever created, you will with a very high probability close to 1 land on something that is not used at all.
Given the age of the first versions of Lisp, it is astonishing that the descendants are still here and that there is a lot of resemblance.
Tuples are also used in Python to express an immutable list (sorry for imprecise wording there) of values.
I haven't worked enough in a Lisp to encounter this problem. Rather, my issue is just that I really dislike the syntax and find Lisp code difficult to read.
Hmm, not sure I agree with "[W]hile Clojure does have some nice syntax for handling maps, which can be used to represent records, it's unfortunately still pretty idiomatic to store tuples in lists in Clojure code."
It's way more common to use key/value maps, precisely because Clojure has a simple, universal reader macro for representing it. Likewise, his Clojure example at the end:
(def point ['vec3d 3 4 -3])
(match [point] ['vec3d x y z] (printf "(%s,%s,%s)" x y z))
is absurd. I can't imagine anyone familiar with Clojure choosing that over a simple map or record. E.g.:
Lisp's problem is rather that so many people play around with it, but not long enough to develop /good taste/ in it, and finally loudly complain about the language when their real problem is their lack of imagination.
You discovered structs, but you should not have stopped there. Structs can be configured. You can declare boa constructors (yes, really, By Order of Arguments). You can configure the names of the accessors. You might even create a little reader macro for creating them. You might want to write a little with-3dvecs macro for quick destructuring. When structs do not have everything you need, maybe go to CLOS classes.
In Python, “there is only one way to do it”. In Perl, “there is more than one way to do it”. In Lisp, there are thousands of ways to do it. If you haven't found a good one for your problem yet, keep looking. I promise, there is at least one.
By the way, you also have no idea of Clojure, but I have only been using it for a few years, so I feel not confident to give meaningful hints.
Lisp's problem is that almost nobody plays with it, but they know that it's that language that relies a lot on parentheses. When they do rarely come across the odd example it is full of unfamiliar symbols: car, labels, mapcan, assoc, setf and so on. Depending on the code, it's possible that not a single thing means anything to even be able to guess.
Oh, wow, a random state is not a list, but a structure object.
CL-USER 205 > (pathname "/foo/bar/baz.lisp")
#P"/foo/bar/baz.lisp"
CL-USER 206 > (describe *)
#P"/foo/bar/baz.lisp" is a PATHNAME
HOST NIL
DEVICE NIL
DIRECTORY (:ABSOLUTE "foo" "bar")
NAME "baz"
TYPE "lisp"
VERSION NIL
Oh, wow, a pathname is not a list or string, but a pathname object.
The Lisp I'm using has literally thousands of structure classes and CLOS classes defined. A Lisp Machine of the mid 80s had around 6000 classes defined.
CL-USER 158 > (defclass vec3d ()
((x :initarg :x) (y :initarg :y) (z :initarg :z)))
#<STANDARD-CLASS VEC3D 40201F4F8B>
CL-USER 159 > (with-slots (x y z) (make-instance 'vec3d :x 3 :y 4 :z -3)
(format t "(~S,~S,~S)" x y z))
(3,4,-3)
The only thing to understand is that Lisp code is usually not optimized for shortest code on the token level.
Though more compact versions of the DEFCLASS macro are being used sometimes. If an application needs a shorter notation, the programmer can always use macros and read-macros to introduce that.
The advantage of CLOS instances and structures over hashtables/vectors/lists is that they carry their class and that they use features like inheritance and method dispatch. The usual OO stuff.
Structures can have by-order-arguments and already print themselves readable:
CL-USER 162 > (defstruct (svec3d (:constructor svec3d (x y z))) x y z)
SVEC3D
CL-USER 163 > (svec3d 1 2 3)
#S(SVEC3D :X 1 :Y 2 :Z 3)
A structure can also have accessor functions without the structure name prefix:
CL-USER 168 > (defstruct (svec3d
(:constructor svec3d (x y z))
(:conc-name))
x y z)
SVEC3D
CL-USER 169 > (let ((p (svec3d 1 2 3)))
(format t "(~S,~S,~S)" (x p) (y p) (z p)))
(1,2,3)
NIL
One can also provide multiple constructors and embed literal objects in code:
Some implemetations also support the use of WITH-SLOTS with structures:
CL-USER 190 > (with-slots (x y z) #S(SVEC3D :X 1 :Y 2 :Z 3)
(format t "(~S,~S,~S)" x y z))
(1,2,3)
NIL
The tradition of Lisp usually is to give the programmer the choice of representation: adhoc lists/vectors/multiple values or structures (efficient records) or CLOS classes (flexible objects) or any kind of user defined stuff...
For any larger code and CLOS classes are usually the default choice for tuple data structures which don't need the last bit of efficiency.
I think that the author needs to learn about association lists. The constructor (define point '((x 1) (y 2) (z 3))) is as clear as any other language. Granted, (assoc 'x point) is a bit more verbose than point.x, but you could extend Lisp with the syntax ('x point) if it matters. Does Arc do that?
> I think that the author needs to learn about association lists. The constructor (define point '((x 1) (y 2) (z 3))) is as clear as any other language. Granted, (assoc 'x point) is a bit more verbose than point.x, but you could extend Lisp with the syntax ('x point) if it matters. Does Arc do that?
As a minor point, the values in an alist are just the cdrs of each pair, so your point alist would be written '((x . 1) (y . 2) (z . 3)); yours has each value being a one-element list. But anyway, if that level of verbosity doesn't bother you, you could just use a struct like the article mentions and write:
(defstruct point x y z)
(defvar *point* (make-point :x 1 :y 2 :z 3))
(format t "~&x is ~a" (point-x *point*))
The author claims that this is too verbose and therefore no one uses structs or classes, which is not at all true in my experience, and it doesn't look that verbose to me either. If the point- prefix really bothers you, you can say (defstruct (point (:conc-name)) x y z) and then the accessors will be defined without it.
This article is shit, and it amazes me that a website called "the code project" could greenlight it.
There is so much wrong with the article, but it can be summarized on: People who don't know lisp shouldn't attempt to criticize it.
Exhibit A of ignorance:
"Of course Lisp has alternative ways to store tuples. It has structs; it has objects; it has multiple types of structs and objects. However, most Lisp programmers and programs don't use them very much, and later we'll talk about why."
Which is patently untrue; in fact there is a legion of lispers that were attracted to it due to its object system.
Exhibit B:
Author makes a really poor attempt to work with vectors, by just defining a simple struct, and then complains about the verbose syntax.
If he was a person who really used lisp for writing an actual working, useful program, he would already know that if he needs brief syntax for his own custom vector, has many options:
1. use array notation: #(1 2 3)
2. write a macro
3. write a macro to define his own custom vector delimiters.
4. create an object, add necesary methods.
5. a combination of anything above.
There is so much wrong with the article, the author seems to even doesn't know about association lists and plists; etc.
28 comments
[ 3.1 ms ] story [ 71.6 ms ] threadIf I had to use a Lisp-like language, I'd choose Clojure so I can interoperate with the JVM. (I use Scala already, so I could interoperate with that, too.)
Suppose that we have used (cddr x) to test whether the list x continues after the second item. It is then unnatural to have (third x) to retrieve the third item! It is like "faulty parallelism" in your English essay. :)
If the condition (and (cdr x) (consp (cddr x))) holds, then the proper way to get that item is (caddr x). This is easy to verify: If cddr is a cons, then its car is given by tacking on an "a": caddr.
In any case, car, cdr and the rest are an absolute must in a Lisp dialect. They are instantly understandable; there is no good reason to break with this important convention. A Lisp dialect will not achieve anything by breaking cultural compatibility with other dialects in this regard; it will just be shunned by Lisp people yet still disused by everyone else. Although CAR and CDR come from IBM 704 machine language, which means nothing to pretty much anyone over fifty years later, the people who allowed these names to infect the higher level language weren't idiots. They discovered that the names just work and so used them. Borrowing some mnemonic that works from the IBM 704 is no worse than borrowing some equally arbitrary greek letter like lambda from a branch of mathematics. If the mathematics of anonymous functions had been called "Tau Calculus" we would be writing (tau (x y) + x y) instead of lambda; it's just a historic accident. All names are historic accidents: one person calls it water, another one aqua, a third one mizu.
I also love the star convention and have used it in many places. for instance mapcar* is a lazy mapcar: it can take infinite lists as its arguments and returns the resulting lazy list immediately. Leslie Lamport picked up on this star notation in LaTeX; that's where I first encountered it. When I got into Lisp years later it was like, hello, is that where Lamport got it from?
I don't like verbosity, so I made my dialect slick and ergonomic. It can "code-golf" side by side with the so-called "modern" scripting languages, while remaining clear.
You can have more than one value in a let and it typically does not cause problems. If you do find it causes problems, it is trivial to change the language and invent your own, expression for defining local variables.
Its fine to have your reasons for hating lisp, but if this is the only thing that puts you off, I recommend giving it another try.
By that time, C had long been a popular language, in spite of demanding that, just like in Pascal, local variables have to be defined at the opening of a new block scope, after which only statements follow.
This is actually a good idea; I avoid mixed declarations and statements in C programming.
Also, mixed declarations and statements are against the Linux kernel coding guidelines and are diagnosed. Yet countless people hack on the Linux kernel for fun and profit.
When I really need some tightly scoped local variable in C, I introduce a little scope with a new braced compound statement, just like `(let` in Lisp. This has the advantage that you determine where the scope ends, not only where it begins. You know: from line 27 this 75 line function, down to line 53, and that's it, not all the way down to line 75.
The mainstream dialect of lisp known as Scheme has a define construct which lets you create new scopes with local variables at the same level of nesting. (Scheme compilers transliterate these defines-s to nested let for you). Yet Scheme is not taking over the world. This aspect rarely even comes up as a topic.
There is this one: simple statistics. People have created an astonishing number of programming languages, of which only a vanishing minority are popular. If you pick a language randomly out of all of the ones that have been ever created, you will with a very high probability close to 1 land on something that is not used at all.
Given the age of the first versions of Lisp, it is astonishing that the descendants are still here and that there is a lot of resemblance.
I haven't worked enough in a Lisp to encounter this problem. Rather, my issue is just that I really dislike the syntax and find Lisp code difficult to read.
It's way more common to use key/value maps, precisely because Clojure has a simple, universal reader macro for representing it. Likewise, his Clojure example at the end:
(def point ['vec3d 3 4 -3])
(match [point] ['vec3d x y z] (printf "(%s,%s,%s)" x y z))
is absurd. I can't imagine anyone familiar with Clojure choosing that over a simple map or record. E.g.:
{:x 3 :y 4 :z -3}
You discovered structs, but you should not have stopped there. Structs can be configured. You can declare boa constructors (yes, really, By Order of Arguments). You can configure the names of the accessors. You might even create a little reader macro for creating them. You might want to write a little with-3dvecs macro for quick destructuring. When structs do not have everything you need, maybe go to CLOS classes.
In Python, “there is only one way to do it”. In Perl, “there is more than one way to do it”. In Lisp, there are thousands of ways to do it. If you haven't found a good one for your problem yet, keep looking. I promise, there is at least one.
By the way, you also have no idea of Clojure, but I have only been using it for a few years, so I feel not confident to give meaningful hints.
Oh, wow, a graphics state for drawing is not a list, but a structure object.
Oh, wow, a random state is not a list, but a structure object. Oh, wow, a pathname is not a list or string, but a pathname object.The Lisp I'm using has literally thousands of structure classes and CLOS classes defined. A Lisp Machine of the mid 80s had around 6000 classes defined.
The only thing to understand is that Lisp code is usually not optimized for shortest code on the token level.Though more compact versions of the DEFCLASS macro are being used sometimes. If an application needs a shorter notation, the programmer can always use macros and read-macros to introduce that.
The advantage of CLOS instances and structures over hashtables/vectors/lists is that they carry their class and that they use features like inheritance and method dispatch. The usual OO stuff.
Structures can have by-order-arguments and already print themselves readable:
A structure can also have accessor functions without the structure name prefix: One can also provide multiple constructors and embed literal objects in code: Some implemetations also support the use of WITH-SLOTS with structures: The tradition of Lisp usually is to give the programmer the choice of representation: adhoc lists/vectors/multiple values or structures (efficient records) or CLOS classes (flexible objects) or any kind of user defined stuff...For any larger code and CLOS classes are usually the default choice for tuple data structures which don't need the last bit of efficiency.
As a minor point, the values in an alist are just the cdrs of each pair, so your point alist would be written '((x . 1) (y . 2) (z . 3)); yours has each value being a one-element list. But anyway, if that level of verbosity doesn't bother you, you could just use a struct like the article mentions and write:
The author claims that this is too verbose and therefore no one uses structs or classes, which is not at all true in my experience, and it doesn't look that verbose to me either. If the point- prefix really bothers you, you can say (defstruct (point (:conc-name)) x y z) and then the accessors will be defined without it.This is an almost line for line translation of the MSDN "Your First Windows Program" C demo:
Sad but true.
This article is shit, and it amazes me that a website called "the code project" could greenlight it.
There is so much wrong with the article, but it can be summarized on: People who don't know lisp shouldn't attempt to criticize it.
Exhibit A of ignorance:
"Of course Lisp has alternative ways to store tuples. It has structs; it has objects; it has multiple types of structs and objects. However, most Lisp programmers and programs don't use them very much, and later we'll talk about why."
Which is patently untrue; in fact there is a legion of lispers that were attracted to it due to its object system.
Exhibit B:
Author makes a really poor attempt to work with vectors, by just defining a simple struct, and then complains about the verbose syntax.
If he was a person who really used lisp for writing an actual working, useful program, he would already know that if he needs brief syntax for his own custom vector, has many options:
1. use array notation: #(1 2 3) 2. write a macro 3. write a macro to define his own custom vector delimiters. 4. create an object, add necesary methods. 5. a combination of anything above.
There is so much wrong with the article, the author seems to even doesn't know about association lists and plists; etc.