Yep, incredibly smart. I’ve seen a few talks by him (he lives half the year in Austin, Texas and half the year in Edinburgh). In fact, I think the best talk I’ve ever sat in was him describing some work one of his PhD students did verifying the correctness of ACL2 inside ACL2.
Did he mention how the AMD engineers refused to accept that there could possibly be any bug in their design and that he could not possibly produce a functioning model of the FPU, along with proof of correctness, in a matter of weeks? Only to do both of those things, and find numerous bugs that they couldn’t have found with testing alone!
ITA Software uses Common Lisp for their core flight planning software.
Maybe. Other languages are definitely catching up with a lot of what used to be special to Lisp. On the other hands, the above mentioned clojure has some really interesting characteristics.
The weird part is that this was a course I took at a a “legitimate” university (that I refer to as “Good ole FU”) and all the code I saw there was like that. Honestly, the code in the book and the stuff the professor gave us was all like that. (Just a mess.)
I don’t know, I mean I was mostly comparing it to coding in C at the time on the university’s computers. It definitely was no where near as bad as coding in lisp. (Especially for someone like me that likes to explicitly break down arithmetic statements with parens.) You try that in LISP and man you’re in for a world of hurt.
I suspect what was throwing notsoheavyd3 was that “(x)” is not equivalent to “x” in Lisp. If you’re used to introducing parentheses willy-nilly about expressions for precedence disambiguation purposes, “just to be sure”, then you will find yourself in trouble when you try to do the same in Lisp.
Of course, the only reason precedence disambiguation is ever needed is the mixing of prefix, postfix, and/or infix operators; in a language like Lisp, this isn’t a problem. But one can imagine this being unclear at first to those accustomed to other languages’ syntax.
To clarify what I was saying in preemptive defense against pedantic nitpicks, operator precedence disambiguation is generally only needed if either A) there are infix operators (written purely between their arguments, with no explicit bracketing) or B) there are both prefix and postfix operators. Anyway, none of this applies to Lisp, whose syntax (quite sensibly, some would say) sticks to the regular, ambiguity-less format “(function arguments…)”.
I learned LISP at MIT in the early '70s, and used assembler extensively right after that in almost the environment you give. Except I didn’t have to enter things on the front panel. Usually. Assembler was far easier.
But that was me. Seeing this debate for a long time convinces me that there is a subset of programmers for whom LISP and functional languages are natural, and another subset for whom they are not. Market results seem to indicate that the second group is bigger than the first.
You got it exactly. I mean I’m comparing this mostly to C (and later C++) where you can add extra parens to be very explicit how you want things grouped.(It all still works) You do that in LISP and bad things start happening. (It’s as though they explicitly developed the language to annoy people like me.)
In Lisp you’re already adding parentheses to be explicit about how you want things grouped. There’s no other way to do it (by default). The problem seems to be that you want to… add useless parentheses? Add parentheses that, by definition, do not need to exist?
I understand all of your words, but you might as well be complaining about how the sky is a particularly ugly shade of magenta every time the Roman Catholic Church solemnizes marriages between a unicorns and Honda motorcycles.
It’s worse than that: the only possible way you can even add useless parentheses in expressions (like C et al allow), is to wrap stuff in parentheses that already are explicitly parenthesized.
c-style, fully parenthesized:
foo (a, b) {
((a + b) + (a * b))
}
lisp style:
(defn foo [a b]
(+ a b (* a b))) ;; or (+ (+ a b) (* a b))) if you prefer 2-arg +
there is just no way to add parentheses that aren’t already there in the lisp code.
I’m willing to accept that this is a notation that some people will just never accept, and I actually do think that for mathematical notation it’s not ideal. For function call notation, the difference with C is completely trivial (just move the left parentheses one place to the left, ignore commas and you’re done). Apparently, that’s still too weird for people. I don’t really care.
I think it makes sense. Addition is just a function like any other; the fact that many other languages don’t recognise this, and treat is as a special “operator” muddles things, to be sure. But, if you commit to treating functions as first class values, and add Haksell-style partial application to the language, then it makes sense. There’s a reason why sections are written in a Lispy manner in Haskell; (+ 1) is just the successor function, for instance.
Nitpick: That’s almost, but not quite, right: a user might add (in their mind, wanted; in reality, unwanted) parentheses around an atom. E.g., turning “4” into “(4)” or “myvariable” into “(myvariable)”.
I’m not sure what the relevance of partial application and Haskell sections is; the other, non-flipped section of addition would be (1 +), which is not in Lisp-style syntax.
I think the strongest argument for Lisp syntax making sense is just the one you make originally: all the “operators” are just functions like any other. Why treat them specially? Why muddle the language with all that irregularity?
No, the strongest argument is that if Lisp had a different syntax, it would be more difficult than necessary to make macros work, and macros are central to the Lisp universe. Macros really make Lisp as powerful as it is.
Brainfuck is Turing complete. Turing completeness isn’t power. ‘Power’ means ‘reducing boilerplate’, and nothing reduces boilerplate like being able to generate code in a high-level language using that same high-level language in all its glory.
OK, I can get behind this to a point, but ‘power’ also means ‘being able to think of doing things you wouldn’t be able to conceive of in another language’, where ‘another language’ has gone from being C++ to Java in the last 15 or so years. Macros provide that: You need to be the kind of person who lives and breathes compilers to create AspectJ, but you only need to be moderately wizardly to do the same thing for Common Lisp. Adding your own Smalltalk-like object system to any reasonable Lisp is at heart a weekend hack. All of that is due to macros. That is power.
(In short: A weak form of Sapir-Whorf applies to programming languages and programmers. ‘Power’ consists of breaking that down a little bit.)
I know. I just really wonder about the mindset of people who do that (in C-style languages). Are they afraid their variables will explode if they don’t surround them with parentheses?
(4) is a bit eccentric, but there was a time when not every C++ compiler implemented operator precedence correctly, so it did pay to be explicit about how expressions should be evaluated.