09:20 am, 26 Nov 03
[x] is better
"Objective study" on why all should be using lisp. They do mention what seems to me to be the flaw, though: people who know lisp tend to be better programmers.
I mostly mention that because we keep making jokes about how our PL class is mostly about why we should use ML. Whenever we see a question on an assignment like "Can you do [x] in another language [safely, efficiently, etc.]?" we know the answer is already "no".
Jokes aside, it's only because the class focuses on the advantages of more advanced type systems (existential types, polymorphism) and why stuff like immutability is useful, and ML is just a good example of such a system.
I mostly mention that because we keep making jokes about how our PL class is mostly about why we should use ML. Whenever we see a question on an assignment like "Can you do [x] in another language [safely, efficiently, etc.]?" we know the answer is already "no".
Jokes aside, it's only because the class focuses on the advantages of more advanced type systems (existential types, polymorphism) and why stuff like immutability is useful, and ML is just a good example of such a system.
Adrian
But considering languages themselves, I guess what I like is what the Ruby community calls the "principle of least surprise" — that the language doesn't have lots of sharp corners and exceptions to rules that will cause situations where what the code does isn't what you expected it to do, or where you made a trivial hard-to-see mistake that made the sense of the code change entirely (like the infamous "if( x = 1 )" bug in C.)
I also like a language that will keep me from doing things that are wrong, that will make some type of mistake either impossible (e.g. bad pointer refs in a garbage-collected system) or flagged at compile time (e.g. type mismatches in any statically-typed language.) I often make sweeping changes, like altering the return type of a common method, and rely on the compiler to catch all the side effects that I then need to fix up in turn. A compiler that will let nearly anything by on the assumption that it can figure out what it thinks I meant, is my enemy.
From that you can see a couple of the many reasons I hate Perl. =)
A couple other bits:
* Simple things should be simple. It annoys me that Objective-C is still a superset of C and so C arrays are still present even though you almost never use them, while the omnipresent dynamic arrays use clunky syntax like "[anArray objectAtIndex: 0]".
* Being able to change the structure of the language around to suit your tastes is, I think, just too dangerous. It leads to code that does things other than what it claims to do, where you have to know the behavior of too many other parts of the program to understand what any other part is doing. Operator overloading is the most common example of this.
Not quite sure how you are relating Lisp and ML in this though. Where's the connection between the first paragraph and the rest of the article?
I really need to learn Haskell. I keep seeing papers that use it.
And what do you mean by "those safety and efficiency concerns"? To be honest, I only know a little scheme, but as far as I know they're all dynamic. (I know people have tried to add static typing to lisp, but as far as I can tell none of them are really part of the language, right?) That doesn't mean that safety/efficiency aren't a concern but it does mean that the solutions will need to be significantly different.
Oh, and if you want to attach an identity to your comment, you can email me for an LJ invite code, or wait until Jesse finishes the Blogger/MT-style "enter your name" form additions for anon users. (I think the latter is taking a while because they want to include validation.)