In discussions about language features for Java 7, I've seen many suggestions that mythical 'other programmers', presumably ones who don't read/write blogs, will write terrible code that uses the language feature. Programmers will write terrible code, regardless of the restrictions you place on them. If you make it harder for them to write their terrible code, they will learn more slowly. Many even stop learning, but that's a subject for another day. Personally, I've had some ridiculous ideas over the years, and those ideas only lived so long because I couldn't try them out very easily. Some good ideas died for the same reason. In C and Lisp, you are the master over the language. That seems to be true of Python, Ruby and Smalltalk too. Of course, C's #define is so coarse as to make communication between master and servant a bit stilted, but the theory's there. In Java, C#, Pascal and other academic languages, you are the servant. Of course, any servant can learn to express himself, but it takes longer. It's like being forced to speak another language, such as the Welsh were. I expect that the literary production of the Welsh people suffered for a time when they were forced to speak English. If I want a switch statement that works on Strings, I can write it myself, as a developer, not a compiler-writer, in a less restrictive language. Then I can come across problems with it (such as fragility) and find a better solution. If I instead have to boilerplate out a load of if..else statements, I'll take longer to realise that my idea is faulty, rather than the switch statement being inflexible, because I'll be blaming the wrong thing for my boilerplate. If you're worried that operator overloading would let your fellow programmers write awful code, ask them what they would do with it. If you worry about what open classes would result in, write a program in Ruby. If you think that the program was too small to determine it, write a bigger one. If you worry about Lisp macros, write some, or define the following macro: (defmacro defmacro () ()) Now you can't define any more macros. You can remove defun in the same way. I imagine that wouldn't be so good for your career.
CodeSOD: Magical Bytes
1 day ago
4 comments:
Programming languages are neither masters nor servants, they are facilitators between people, as well between people and machines.
Those languages which can facilitate the work of diverse teams are financially beneficial to the companies that use them.
Those languages which in practise require a lot of unproductive ego-soothing of primadonnas, such as Lisp and Ruby, aren't so financially beneficial, even if they do feed some blog-egos and enable book authors who aren't good enough to break in to more saturated markets sell some books.
My overall point was that it isn't the job of a programming language to constrain you, and if the language takes on that role, it will harm your learning.
What makes you think that Lisp and Ruby require blog egos to be programmed?
I've not read any Ruby books, but Practical Common Lisp is certainly above the usual standard for technical books.
In C and Lisp, you are the master over the language.
That's like saying you're the master over a hammer vs a nail gun as you can choose the nail and how hard you hit it. Good luck trying to make a house with a normal hammer (yes it can be done but will take longer and your forearm will hurt).
To me "master vs servant" means how quickly can I take what's in my head and let the language work for me. It isn't "can I make this case statement do exactly what I want in some academically elegant way"
I'll go along with your analogy..
If you're the servant, the nailgun operator, then in those cases where the nailgun won't fit, you'll have to redesign part of the house so that you can use the nailgun on it.
If you're the master, the builder/architect, you'll be able to figure out some other solution.
In other words, as long as you are more intelligent than your tools, you should be allowed to use them in any way you like.
"To me "master vs servant" means how quickly can I take what's in my head and let the language work for me."
I would have thought it would be "how directly", rather than "how quickly". In an unexpressive language, you can certainly learn to code the workarounds quickly. Over time you start to think in terms of those workarounds, and then give them names, like Singleton, Visitor, etc.
"It isn't "can I make this case statement do exactly what I want in some academically elegant way""
Yawn. I didn't intend the switch statement to be a brilliant example - but it has been mentioned before in relation to Java 7. There are certainly much better flow control constructs that languages just don't support natively. Being able to invent your own lets you work out which ones are good. It's hard for Java programmers to reason about switches on Strings, because they've never had it, and can't have it without editing the compiler source code.
For more interesting examples, see CL's with-open-file macro, CL's loop macro, or Neal Gafter's blog.
Post a Comment