It's pretty rare that I don't have syntax highlighting. Another thing about the parens that is annoying is that there doesn't seem to be a single, canonical way for them to interact with indentation, like K&R style for C.
I haven't used ruby, but I think terseness and readability tend to go hand in hand, and ruby looks terse.
Having a sugar -> S-expressions transform is great. It's the best of both worlds.
From what I understand, the "canonical way" is basically "whatever Emacs does", but I don't use Emacs. How I indent code (and how I have seen most other people indent code) is as follows:
2 spaces for indentation. Use indentation after any "block" expression:
(def foo (x)
(bar x))
(let foo 5
(bar foo))
Non-block expressions should be like so:
(foo 1 2 3 4)
(foo 1
2
3
4)
(foo 1
2
3
4)
That last one is generally rare and considered somewhat bad form, from what I understand.
Aside from "if", the Lisp code I've seen is generally very uniform, much more so than the JavaScript code I've seen, which can vary substantially from one person to another. For instance, when reading Racket code, it is usually very readable, and the only difference I've noticed is that in some situations they use 1 space rather than 2.
I think the reason Lisp doesn't have a "standard indentation style" is because it doesn't need one. There's no curly braces or distinction between statements and expressions, so people naturally tend to converge on a single style.
And even in the case of the different styles for "if", I at least choose whichever style works the best for me on a case-by-case basis, so that it looks the best. My general heuristic is as follows:
Use this style when there's only 3 arguments:
(if 1
2
3)
Use this style when there's more than 3 arguments:
(if 1
2
3
4)
Rarely use this style, only when all the arguments are short:
(if 1 2
3 4)
For Nulan, I haven't yet worked out the "if" idioms, but thus far I've used this form exclusively:
"The nice thing about indenting in C is simply that it falls out naturally, so you don't have to think about it."
In my experience with Java, Groovy, and JavaScript, the indentation gets just as idiosyncratic when it comes to nested function call expressions, long infix expressions, and method chaining.
I've rarely used C, but does its error code idiom obscure this drawback? I imagine error codes force programmers to put many intermediate results into separate variables, whether they like it that way or not.
In other words, you usually won't see this in C, right?
foo(bar(qux(1, 2, 3)))
Instead, you'd write it more like this:
x = qux(1, 2, 3)
if (x == ERR) {
...
}
x = bar(x)
if (x == ERR) {
...
}
x = foo(x)
if (x == ERR) {
...
}
Because you don't have nested expressions, there's only a single way to indent the code. But in languages like JavaScript, method chaining and nested function calls mean that there's now multiple ways to indent the same code.
Thus, C's syntax isn't actually more uniform than Lisp, it only seems that way because of C's way of handling errors.
Hmm, I'm losing track of my point. I prefer writing code so it models all errors explicitly, so I end up with that kind of verbosity in JavaScript too. I only get code like foo(bar(qux(x))) when I'm using lots of function calls that have no errors (or whose arguments can be errors).
>> C's syntax isn't actually more uniform than Lisp
C's syntax is actually less uniform, isn't it?
C isn't a very sophisticated language, but it tends to be readable. At least in the sense of following the flow of control; perhaps things like error handling make it hard to see the forest for the trees.
There may be a fundamental law that the more underpowered the language, the easier it is to read. Sort of like how Dr. Seuss books are more readable than research papers on programming languages theory, right?
I don't think Pauan was referring to C syntax as a whole. In this subthread, I think we've been specifically talking about whether certain languages have a "single, canonical" indentation style that "falls out naturally."
---
"There may be a fundamental law that the more underpowered the language, the easier it is to read. Sort of like how Dr. Seuss books are more readable than research papers on programming languages theory, right?"
In one sense that's true, since it's easy to make naive improvements to one feature while neglecting another. In another sense, a less readable language is always relatively "underpowered" due to its greater difficulty to use (assuming it's a language we use by reading :-p ).
I think C is a great language. It maps straightforwardly onto to the capabilities of the hardware. What I meant by calling it underpowered is that it doesn't do much to increase your power beyond freeing you from having to write assembly language.
Higher order functions and metaprogramming are the sort of things I associate with a powerful language, like Lisp. But sometimes things get so abstract you can't tell what you're looking at.
As you point out, it's easy to ruin something like a programming language while trying to improve it. (I haven't created a programming language, but I've used bad ones.)
> "There may be a fundamental law that the more underpowered the language, the easier it is to read."
That's a lot stronger claim than your original :) Aren't python, ruby, and haskell all high-power but easy to read?
There's the confounding effect of learnability; lisp gets more readable over time. There's also the confounding effect of density or difficulty. This quote captures both:
"If you're used to reading novels and newspaper articles, your first experience of reading a math paper can be dismaying. It could take half an hour to read a single page. And yet, I am pretty sure that the notation is not the problem, even though it may feel like it is. The math paper is hard to read because the ideas are hard. If you expressed the same ideas in prose (as mathematicians had to do before they evolved succinct notations), they wouldn't be any easier to read, because the paper would grow to the size of a book." (http://www.paulgraham.com/power.html)
I seem to have overlooked this post until just now...
Incidentally, I've never written python, ruby, or haskell, except for a tiny amount of python.
Good quote. I've been reading a lot of computer science papers lately, and I tend to skip over the math formulas and focus on the text. This could be because I'm reading them for "fun" and not because I have to for a class, or something. But I have always found it hard to take in dense notation, and preferred a conceptual argument. Maybe it's just that I have a deficiency in that area. But I think prose has the potential to carry powerful insights that are out of the reach of formulas; I suspect the problem is that succinct, brilliant prose is just incredibly hard to write. It's probably easier to just list formulas than to get deep ideas into prose. The reverse is also true, of course. Some ideas can only be expressed properly with notation.
But that probably has nothing to do with programming language syntax per se.
"I've been reading a lot of computer science papers lately, and I tend to skip over the math formulas and focus on the text."
I do that too. :) Unfortunately, at some point it gets hard to understand the prose without going back to read some of the fine details of the system they're talking about. XD
I tend to jump around. The introduction is usually boilerplate for the particular area of research, so it can be skipped. (I wonder how many different papers have told the story of the memory hierarchy and how it's getting more and more important as data gets bigger.) Then I try to figure out if the paper has anything important to say, before working on the math. I figure that sometimes the big idea of the paper is in the math, and other times, the big idea is in the text, and the math is just obligatory. (You can't publish a paper on an algorithm without spelling out the precise bounds on time and space, even if the formula contains 15 terms. Not all 15 terms can be important to the performance, but it certainly is important to put them in the paper.) I guess it depends on the field, but in the data structures papers I like to look at, it usually doesn't take a lot of math notation to express the key innovation.
