I have to think carefully about this every single bloody time. As seen here.
7 thoughts on “C Pointer Operator Precedence”
This is an area where Lisps are superior to Algols: operator precedence isn’t a thing, and order of operations is never ambiguous to human readers. Of course, the same thing that makes this true also confers the superpower of metaprogramming (aka macros).
It seems to me that power and complexity inevitably go together. I struggle to read Lisp just as much as I struggle to read pointer manipulation in C. Both of them force me to slow down and read carefully.
Power and complexity do not go to together: It seems obvious to me that you can have something that is both more complex and less powerful. I would grant that you have to trade something for something else at some point, but you need to be close to optimum before that tradeoff is mandatory.
This is why I always say it’s not “fast, cheap, good: pick two” but “fast, cheap, good, pick AT MOST two”. Because “slow, expensive, and crappy” is always an option.
There are many Lisps. Some of them are harder to read than others. And some programs are harder to read that others. At the company I’m at now, some of the easiest code to read is C#, but it’s one the worst systems in terms of performance and bugginess. The absolute worst-to-read system we had was written in Clojure, until someone re-wrote it.
Of course, “difficulty to read” is subjective. I would never argue that YOU aren’t finding it hard to read. But the syntax of most Lisps is inarguably simpler than a typical Algol – it just has fewer things. Note that “simple/complex” is different from “easy/hard”.
I guess the idea I was trying to get at is that if something is “powerful” then it allows you do much with a minimum of expression. Such expressions when composed are terse and comprise many parts interacting in subtle ways so you need to slow down and think carefully. As with mathematics, say.
While the *syntax* of Lisp programs is simple, the *programs* are (often) complex. But you are right that something could be complex and not powerful. I don’t know if a software tool could be powerful and not complex, especially if you go with my definition above where power is capability per unit expression.
Your point that software can be all of slow, expensive, and crappy is well made. Also, loved the Oxford Comma! :)
So yeah, I think the point here is about “expressive power”. Lisps are, IMO, high in experssive power. So expressing a particular problem can in general be more elegantly/powerfully/whateverly done in a Lisp than an in Algol. The key qualifier there is “in general”, and the key idea is “a particular problem”. I don’t think it’s especially interesting to observe that most Lisp I’ve read has been more complicated than most C#, for instance. That’s like saying “Most rocket ships I’ve examined are more complex than most bicycles”.
Obviously you can write great software using many different languages/tools – existence proof for this abounds. But my point is, if I want to express the types of problems I typically express, they are often more easily expressed using a Lisp – and really, Clojure in particular – because of the expressive power of the language. Being functional, immutable, with a strong library for sequences, and having rich data types are all key ingredients for that. Arguably more so than the language syntax, actually, but that, too.
I would really love to see some of these Clojure programs you wrote and refer to. Are any of them open source?
There are, of course, a ton of open-source Clojure programs. My work is no open-source, and I haven’t done any open source work in a long time, but my github has some: https://github.com/candera.
You will, of course, have to spend some amount of time learning the syntax. This will be much smaller than most languages, because there is much less syntax. What will take longer is learning how to think functionally, since that’s a bigger shift than just the Lisp syntax. If you already know a functional language, then it will be relatively familiar.
Without spending that time, then yeah, it’s not going to be easy to read.
This is an area where Lisps are superior to Algols: operator precedence isn’t a thing, and order of operations is never ambiguous to human readers. Of course, the same thing that makes this true also confers the superpower of metaprogramming (aka macros).
It seems to me that power and complexity inevitably go together. I struggle to read Lisp just as much as I struggle to read pointer manipulation in C. Both of them force me to slow down and read carefully.
Power and complexity do not go to together: It seems obvious to me that you can have something that is both more complex and less powerful. I would grant that you have to trade something for something else at some point, but you need to be close to optimum before that tradeoff is mandatory.
This is why I always say it’s not “fast, cheap, good: pick two” but “fast, cheap, good, pick AT MOST two”. Because “slow, expensive, and crappy” is always an option.
There are many Lisps. Some of them are harder to read than others. And some programs are harder to read that others. At the company I’m at now, some of the easiest code to read is C#, but it’s one the worst systems in terms of performance and bugginess. The absolute worst-to-read system we had was written in Clojure, until someone re-wrote it.
Of course, “difficulty to read” is subjective. I would never argue that YOU aren’t finding it hard to read. But the syntax of most Lisps is inarguably simpler than a typical Algol – it just has fewer things. Note that “simple/complex” is different from “easy/hard”.
I guess the idea I was trying to get at is that if something is “powerful” then it allows you do much with a minimum of expression. Such expressions when composed are terse and comprise many parts interacting in subtle ways so you need to slow down and think carefully. As with mathematics, say.
While the *syntax* of Lisp programs is simple, the *programs* are (often) complex. But you are right that something could be complex and not powerful. I don’t know if a software tool could be powerful and not complex, especially if you go with my definition above where power is capability per unit expression.
Your point that software can be all of slow, expensive, and crappy is well made. Also, loved the Oxford Comma! :)
So yeah, I think the point here is about “expressive power”. Lisps are, IMO, high in experssive power. So expressing a particular problem can in general be more elegantly/powerfully/whateverly done in a Lisp than an in Algol. The key qualifier there is “in general”, and the key idea is “a particular problem”. I don’t think it’s especially interesting to observe that most Lisp I’ve read has been more complicated than most C#, for instance. That’s like saying “Most rocket ships I’ve examined are more complex than most bicycles”.
Obviously you can write great software using many different languages/tools – existence proof for this abounds. But my point is, if I want to express the types of problems I typically express, they are often more easily expressed using a Lisp – and really, Clojure in particular – because of the expressive power of the language. Being functional, immutable, with a strong library for sequences, and having rich data types are all key ingredients for that. Arguably more so than the language syntax, actually, but that, too.
I would really love to see some of these Clojure programs you wrote and refer to. Are any of them open source?
There are, of course, a ton of open-source Clojure programs. My work is no open-source, and I haven’t done any open source work in a long time, but my github has some: https://github.com/candera.
You will, of course, have to spend some amount of time learning the syntax. This will be much smaller than most languages, because there is much less syntax. What will take longer is learning how to think functionally, since that’s a bigger shift than just the Lisp syntax. If you already know a functional language, then it will be relatively familiar.
Without spending that time, then yeah, it’s not going to be easy to read.