Quick background from the newb: Programmer for 22 years with assembly and standard C-like imperatives, just recently became proficient in Python and becoming interested in Common Lisp. Why? I want the functional goodness and the MACROS, that's why. Also, I do computer vision and machine learning research, and my Python code is rather slow. I'd like something that's almost as fast as C but very expressive, and is strict but highly dynamic and dynamically-typed.
Here's what's keeping me with Python: my code reads like pseudocode, and I love that. When I come back to Python code I haven't seen in months, it takes me all of five seconds to grok it again.
Short version: significant whitespace (indentation can replace parens), "func(param1 param2)" calls, infix notation (which is good for math code), and it still parses regular s-expressions correctly. Because it transforms "sweet-expressions" to s-expressions, macros still work. Example:
defun factorial (n) if (n <= 1) 1 n * factorial(n - 1)
(which even I can parse :D) is translated to:
(defun factorial (n) (if (<= n 1) 1 (* n (factorial (- n 1)))))
(which I can still parse, but with more trouble). Or this:
(2 + mystuff(7 + x) * -(henry) - correction(a b c d) + 2 - pi() - x)
which is translated to this:
(- (+ (- (+ 2 (* (mystuff (+ 7 x)) (- henry))) (correction a b c d)) 2) (pi) x)
He's almost got me convinced.
I understand that experienced Lispers use indentation to understand code more than parenthesis anyway. This creates a situation (rather like in C-like languages) where the language syntax *doesn't inherently communicate with the coder very well*, and coder has to add redundant formatting to make it clear. Then, like in IDEs for C-like languages, the editors support this to make programming less painful. So why not take the Python route and make formatting syntactically significant? The only difference is that Python requires it, "sweet-expressions" don't.
My main question is whether there are any downsides at all to this approach.
And as an aside, I'd love to have Python's array (list) and dictionary (hash table) syntax. I'd switch to Lisp and convert my entire codebase TODAY if I had that.
Neil Toronto wrote: > Quick background from the newb: Programmer for 22 years with assembly > and standard C-like imperatives, just recently became proficient in > Python and becoming interested in Common Lisp. Why? I want the > functional goodness and the MACROS, that's why. Also, I do computer > vision and machine learning research, and my Python code is rather > slow. I'd like something that's almost as fast as C but very > expressive, and is strict but highly dynamic and dynamically-typed.
> Here's what's keeping me with Python: my code reads like pseudocode, > and I love that. When I come back to Python code I haven't seen in > months, it takes me all of five seconds to grok it again.
How long have you been learning Common Lisp?
I am asking this because it typically takes a week or two (or sometimes a few more) until you get used to Lisp syntax. Afterwards, with more experience, it's typically not an issue anymore. (Although it could simply be that those for whom this is then still an issue switch to other languages.)
> My main question is whether there are any downsides at all to this > approach.
I don't think so. Adding a surface syntax to Lisp shouldn't be that much of a problem, as long as the internal representation stays the same. It could indeed be interesting if there were several different surface syntaxes, for example including graphical ones, which would move Lisp towards something like intentional programming.
On the other hand, I also think that adding one ore more surface syntaxes doesn't solve a fundamental problem, and I don't expect that a considerably large number of Lispers will take up this idea because of that. After all, it's _just_ syntax. In other words, there aren't any downsides, but there also aren't any essential upsides.
Ken Tilton wrote: > Neil Toronto wrote: > > Quick background from the newb:
> Lousy spelling. Should be "fom the t-r-o-l-l".
> hth, kenny
Ah, I see. So not only is the syntax hostile, but so is the community. Fascinating! I wonder if this is as well-studied as Lisp syntax alternatives.
Pascal Costanza wrote: > Neil Toronto wrote: > > Here's what's keeping me with Python: my code reads like pseudocode, > > and I love that. When I come back to Python code I haven't seen in > > months, it takes me all of five seconds to grok it again.
> How long have you been learning Common Lisp?
> I am asking this because it typically takes a week or two (or sometimes > a few more) until you get used to Lisp syntax. Afterwards, with more > experience, it's typically not an issue anymore. (Although it could > simply be that those for whom this is then still an issue switch to > other languages.)
Not too long - I'm mostly just looking into it as a speedy alternative to other dynamically-typed languages. I did spend a semester working in Scheme, which I found to be a chore, and I never did get used to it. I think your parenthetical remark is pretty much spot-on.
> > My main question is whether there are any downsides at all to this > > approach.
> I don't think so. Adding a surface syntax to Lisp shouldn't be that much > of a problem, as long as the internal representation stays the same. It > could indeed be interesting if there were several different surface > syntaxes, for example including graphical ones, which would move Lisp > towards something like intentional programming.
> On the other hand, I also think that adding one ore more surface > syntaxes doesn't solve a fundamental problem, and I don't expect that a > considerably large number of Lispers will take up this idea because of > that. After all, it's _just_ syntax. In other words, there aren't any > downsides, but there also aren't any essential upsides.
I wasn't thinking about Lispers, I was thinking about *me*. Lispers are, by definition, just fine with the syntax as it is.
I disagree very much with the "just" in front of the "syntax" in your post. Syntax is *extremely* important. We're not writing programs just for the compiler, we're writing them for our future selves and other people. If all programmers thought like compilers, we'd have no problem. But the fact that even hard-core Lispers need to indent the heck out of their code and learn to literally ignore a significant portion of the syntax (the parens) indicates that something may be lacking in the syntax. C programmers indent, sure, but they don't have to learn to ignore.
Not that I intend to start a flame-war or anything. I know, I'm getting close. If that happens, I fully expect the great Paul Graham to jump in and defend me. :D Apparently, Arc's indentation will have syntactic meaning.
By the way, thanks for writing your "Highly Opinionated Guide." It's the only document I've found so far that provides a good summary of Lisp's advantages over other dynamically-typed languages. Your summary of macros was especially helpful.
Neil Toronto wrote: > I wasn't thinking about Lispers, I was thinking about *me*. Lispers > are, by definition, just fine with the syntax as it is.
How to you become a 'Lisper'? Probably by learning and practicing Lisp. That includes to learn the culture, the habits and the tools of Lisp programming. You approach a different culture, but you are not really open minded. Since Lisp requires a different mental model of computation (and that includes not only syntax) you need to be prepared to learn a few new things (for example how to read/write/manipulate Lisp code). If you think that this is too expensive (time, brain cells, ...) for you, I think you should not waste your time with syntax experiments and just skip over Lisp, and look for some other solution to your problem - a solution that is more compatible with your current believes.
> I disagree very much with the "just" in front of the "syntax" in your > post. Syntax is *extremely* important. We're not writing programs just > for the compiler, we're writing them for our future selves and other > people.
I'm not sure what that has to do with Lisp. Lisp's external syntax is not for some compiler. Lisp programmers find it useful because it makes tool building very easy. Macros are just one of these tools.
> If all programmers thought like compilers,
How does a compiler think?
> we'd have no > problem. But the fact that even hard-core Lispers need to indent the > heck out of their code
I almost never indent the code by hand. The editor or the Lisp system (pretty printing) does it for me. I like indented code. Nicely indented, color coded code. Indented by the editor or the Lisp system. Good Lisp code is a real pleasure to read.
> and learn to literally ignore a significant > portion of the syntax (the parens) indicates that something may be > lacking in the syntax.
Why should a Lisp programmer ignore the parentheses? That would be stupid. Actually they are part of what makes Lisp programming fun.
Lisp programming has several different dimensions. One is the manipulation of external (text-based) code and data. Programmers need to write/read/manipulate code. Lisp is optimized to allow tools to support you during working with external text-based code.
Lisp allows the editor to query the Lisp system while you type code. The running Lisp system knows all about your code (where it is defined, the documentation, the arglists, the types, the contents, the callers, ...).
Lisp allows the editor to query the Lisp system while you read code. You can jump to definitions, inspect values, try out examples, ...
Lisp also supports you manipulating your code. Every expression has a very simple to find start and end. You can use simple structure-based editing (see paredit), which has little mental overhead once learned (it is a bit like learning to ride a bicycle). It allows you to manipulate your code based on list structure (select, transpose, group, extract, copy, ...).
So, you have an editor/language combination which supports you manipulating your code and you have a Lisp system which is available during editing for various queries.
Then comes the interactive experience. You are working with an editor, which is connected to a Lisp system (for example via SLIME if your editor is Emacs). Alternatively you will use an editor-based Listener. Then you can start thinking of code as data. You will write some code/data in the editor/listener and the Lisp system reads them and you can apply functions that manipulate that code. A simple example is a macro expansion. Your editor buffer has some code and you want to macro expand it. The editor takes the code, the Lisp system reads it, generates data structures, macro expands them, returns new code and your editor displays it (possibly pretty printed).
You can also write some sketch of some code, read it into the Lisp system and use the Lisp system to manipulate it until it has the form you like. Pretty print the result and place it in your editor buffer.
The whole tool chain is highly optimized around Lisp syntax, Lisp datastructures and the various tools to read/write/manipulate these datastructures.
More advanced systems can also parse Lisp data directly from editor buffers (like you want to display a class graph, the editor prompts you for a class and all class names in your editor buffers are mouse sensitive). Or tools like McCLIM allow you to have mouse sensitive Lisp read-eval-print-loops.
Back to your question. What is the cost of ignoring the Lisp culture around the syntax? You will have difficulty to use the tool chain.
But then, the syntax is just the first hurdle. Be prepared for more hurdles. Probably higher ones.
> C programmers indent, sure, but they don't have > to learn to ignore.
Forget the 'ignore' thing.
> Not that I intend to start a flame-war or anything. I know, I'm getting > close. If that happens, I fully expect the great Paul Graham to jump in > and defend me. :D Apparently, Arc's indentation will have syntactic > meaning.
Maybe you should switch to Arc. As soon as it does what you want. 2010? 2015? 2020? Who knows.
> By the way, thanks for writing your "Highly Opinionated Guide." It's > the only document I've found so far that provides a good summary of > Lisp's advantages over other dynamically-typed languages. Your summary > of macros was especially helpful.
> Also, thanks for answering my question.
My final advice? If you really want to use Lisp (because it may solve your initial problem of finding a dynamic language with useful performance), then you should invest the time to learn the whole culture. Most beginners find that after some time (maybe a month) they can read Lisp code just fine. Some are then very enthusiastic about the excellent readability of their Lisp code, because they suddenly can write very high-level problem-specific code.
> (defun factorial (n) > (if (<= n 1) > 1 > (* n (factorial (- n 1))))) > ... > I understand that experienced Lispers use indentation to understand > code more than parenthesis anyway. This creates a situation (rather > like in C-like languages) where the language syntax *doesn't inherently > communicate with the coder very well*, and coder has to add redundant > formatting to make it clear.
Let's test the implicit hypothesis that s-expression syntax does not inherently communicate with the programmer very well in the absence of redundant (actually, "superfluous" is a more precise term) formatting and that Algol syntax does:
defun factorial (n) if (n <= 1) 1 n * factorial(n - 1)
Not any better than:
(defun factorial (x) (if (<= n 1) 1 (* n (factorial (1- n)))))
The main difference is that it is borderline trivial to auto-indent the second one with your editor.
Let's try another test:
defun factorial (x) if (n <= 1) 1 n * factorial(n - 1)
This is hard to read and also shows another weakness: explicit grouping, and therefore no precedence rules to remember. If you take out the parentheses, you have to memorize precedence rules. Precedence rules are one of the chief things that make it easy to write unreadable C and Perl.
By contrast:
(defun factorial (x) (if (<= n 1) 1 (* n (factorial (1- n)))))
This is more readable and, in the event you have trouble reading it, can still be auto-indented.
> And as an aside, I'd love to have Python's array (list) and dictionary > (hash table) syntax. I'd switch to Lisp and convert my entire codebase > TODAY if I had that.
I don't know Python, but Common Lisp makes it easy to add syntax. Reader macros are normally all it takes to get the kind of syntax you are likely after.
"Neil Toronto" <neil.toro...@gmail.com> writes: > Ken Tilton wrote: >> Neil Toronto wrote: >> > Quick background from the newb:
>> Lousy spelling. Should be "fom the t-r-o-l-l".
>> hth, kenny
> Ah, I see. So not only is the syntax hostile, but so is the community. > Fascinating! I wonder if this is as well-studied as Lisp syntax > alternatives.
Yes, indeed, it's a well studied subject too.
> I disagree very much with the "just" in front of the "syntax" in your > post. Syntax is *extremely* important.
Not in Lisp. Not *that* syntax.
> We're not writing programs just > for the compiler, we're writing them for our future selves and other > people. If all programmers thought like compilers, we'd have no > problem. But the fact that even hard-core Lispers need to indent the > heck out of their code and learn to literally ignore a significant > portion of the syntax (the parens) indicates that something may be > lacking in the syntax. C programmers indent, sure, but they don't have > to learn to ignore.
It's not "ignore" literally either. There are serveral level of reading. For example, at the lexical level, it hurts the eyes when you can't write "newbie" correctly, or whey Kenny can't spell "from". All levels are important, and you can be sure that no parenthesis is overlooked or added gratuituously in Lisp. It's just that at the level that matters for programming sophisticated software, parentheses are not a problem but part of the solution, even if a small part. If S-expressions were a problem, it IS ALREADY solved, as LISP was defined in terms of M-expressions, FIFTY YEARS AGO!
So you'll have to perdon us, if after FIFTY YEARS people keep looking half a hour at lisp and keep suggesting to modify the syntax:
- we've got better things to do,
- we've solved the problem once for all with reader macros and macros that allow you to modify the syntax in your program.
I'd just add that IMO, this question should be solved at the editor level: everytime you load a source file in an editor, the editor should apply any syntax, indenting and colorizing the programmer prefers. (And therefore the source files should keep a consistent form: S-expressions, and the use of reader macros should be avoided).
HEALTH WARNING: Care should be taken when lifting this product, since its mass, and thus its weight, is dependent on its velocity relative to the user.
