When technology is not designed from a human-centered point of view, it doesn't reduce the incidence of human error nor minimize the impact when errors do occur. Yes, people do indeed err. Therefore the technology should be designed to take this well-known fact into account. Instead, the tendency is to blame the person who errs, even though the fault might lie with the technology, even though to err is indeed very human.
Now, read this quote from James Gosling that I took from the introduction, by Richard Gabriel, to "Successful Lisp" by David Lamkins:
Very dynamic languages like Lisp, TCL, and Smalltalk are often used for prototyping. One of the reasons for their success at this is that they are very robust...Another reason...is that they don't require you to pin down decisions early on. Java has exactly the opposite property, it forces you to make choices explicitly
Contrast it with the following quote from Niall Ross during his keynote speech at Smalltalk Solutions:
... back to language comparison: static-typing is the ultimate up-front optimisation
- C#, Java, etc.: designed by and for those who expect to be right first time
- Smalltalk: designed by and for those who don’t
We, Smalltalkers, Lispers, and dynamic language lovers everywhere, embrace the human in all of us and make the machine conform to us not the other way around. We understand that we err and we're not going to get it right upfront. But, Java and the static hounds think that we should blame the programmer for being human. Make the language easy for the computer and not the poor programmer. And right there, I think you have the split between the two camps. One is machine-centric (Java, C, C++, C#, etc) and the other is human-centric (Smalltalk, Lisp, Ruby, Self, Python, Io, Slate, etc). I know which one I pick. Sad thing is that we've had these human-centric languages since 1960 (or was it 1958?).
I can't wait to read the rest of the book!
Posts
11 comments:
I couldn't agree more.
What's really sad, is that not only have we had these languages since the 60's, but some of them (I'm mostly thinking of Lisp) have had most of the major features of most of todays modern languages since the 60's.
Another example of Worse is Better.
read this quote from James Gosling
How much credence should we give to a selective quote, that's had words removed in 3 places (2 elipsis and the concluding sentences from the paragraph)?
1) "Lisp, TCL, and Smalltalk ... are very robust
The missing words tell us that, by "very robust", Gosling means disallowing pointer arithmetic and manual memory alloc/dealloc - so Java is also "very robust".
2) From the selective quote, we might be tricked into thinking Gosling believed "Another reason... is that they don't require you to pin down decisions early on."
From the original text, we find something quite different. Gosling said - "Another reason given for these languages being good at prototyping...".
It's something other people believed, not something Gosling believed.
3) The missing final sentences contradict your implication that "Java and the static hounds" "expect to be right first time"
"...make choices explicitly. Along with these choices come a lot of assistance: you can write method invocations and if you get something wrong, you get told about it early, without waiting until you're deep into executing the program."
Here's the full text:
"Very dynamic languages like Lisp, TCL and Smalltalk are often used for prototyping. One of the reasons for their success at this is that they are very robust: you don't have to worry about freeing or corrupting memory. Programmers can be relatively fearless about dealing with memory because they don't have to worry about it getting messed up. JAVA has this property and it has been found to be very liberating. Another reason given for these languages being good for prototyping is that they don't require you to pin down decisions early on. JAVA has exactly the opposite property: it forces you to make choices explicitly. Along with these choices come a lot of assistance: you can write method invocations and if you get something wrong, you get told about it early, without waiting until you're deep into executing the program. You can also get a lot of flexibility by using interfaces instead of classes."
Java: an Overview (pdf) p4
To Isaac:
I'm sorry I didn't include the entire quote, I was quoting from another source and didn't know where the original came from. I apologize. But, I think the meaning is the same. For example:
they don't require you to pin down decisions early on. JAVA has exactly the opposite property: it forces you to make choices explicitly
Still means what I meant it to which is that Java forces you to make decisions early where in late-bound languages you can delay. I don't think it changes the meaning.
Besides, in dynamic languages you're always running the program and there is no distinction between compile and run-time. Your program is always running. Besides, static typing only finds 1% of the bugs. The obvious "duh" bugs. It doesn't get the major logic errors. Granted, this still happens in dynamic languages, but not as much because we are always running the program. The cycle between coding and running is very small. There's a reason Kent Beck and other Agile guys talk about a short cycle between coding and running. It's to catch those. But, I'm off topic now. Besides, until casting is disallowed, you're still going to have that vulnerability. The new generics in 1.5 help in that regard. But, what about methods expecting Object as an argument in frameworks? You still have to cast.
I will agree that interfaces are better than classes. I believe the behavior is more important. But, I have found it rare for java developers to use them. I only used interfaces in my arguments of my public methods. This way I never cared what was passed in, but adhered to that interface. It drove a lot of developers mad. Again, I'm off topic.
And one more thing, one commenter expressed that it was easier to understand APIs in java than in a dynamic language. I usually figure out an API by running it and playing with it. To me, that is way more helpful than a static, dead listing of a file. It's like trying to figure out what a person is like after they're dead and you can't talk to anyone they knew. I'd rather learn while they are still alive. Besides, properly written code in any language is obvious to what it does. If it isn't obsious, then it's poorly written. A bad API is a bad API whether it's java or Smalltalk.
I know this might come as a shock, but I don't hate java. I use it at work. Well-written code is always a joy to work with. It's just that I can express my ideas more succintly in dynamic languages and change my mind more frequently. This means if I paint myself into a corner, I can get out with less effort. Simple refactoring is always easy, but major design changes is where a language is put to its test in my opinion.
1) the meaning is the same
No - the omitted words changed the meaning, let's take your example: they don't require you to pin down decisions early on.
Gosling wrote: "Another reason given for these languages being good for prototyping is that they don't require you to pin down decisions early on."
Clearly, Gosling was correct - it is a reason some people (you yourself) give.
Gosling did not write that he agreed with that reason - but the selective quotation misleadingly makes it seem that he did.
2) Besides, in dynamic languages you're always
You seem to be mistakenly conflating the Smalltalk image with file-based languages like Ruby, Python...
3) Besides, static typing only finds 1% of the bugs
Really! Got any evidence?
4) The obvious "duh" bugs
Even primitive static typing would have caught this GNU Smalltalk bug
http://lists.gnu.org/archive/html/help-smalltalk/2005-07/msg00019.html
5) until casting is disallowed
Now it seems that you would like more static type checking than Java provides? If that's what you want, it is available - try OCaml/SML, Haskell, Nice, Scala...
6) Simple refactoring is always easy, but major design changes
I'm told that IntelliJ IDEA now includes a rewrite engine - "Structural Search and Replace" - that's how we should do major design changes.
Gosling did not write that he agreed with that reason - but the selective quotation misleadingly makes it seem that he did.
It doesn't matter what I think Gosling liked or agreed with the reason. He was simply stating why they are good at prototyping. It changes NOTHING of my point.
You seem to be mistakenly conflating the Smalltalk image with file-based languages like Ruby, Python..
HUH?! No, I am not. You are constantly running your code in a Smalltalk image just like in Ruby and Python. It's called an interpreter.
1% bugs comment...
Really! Got any evidence?
Only the evidence that I observed from working on several java projects. There's no substitute for unit testing. We all want robust systems. I just think we come from two different mind shares. We both get our jobs done and both of our ways makes us successful. The static vs dynamic typing debate will go on forever. We view the robust problem in radically different ways.
Now it seems that you would like more static type checking than Java provides? If that's what you want, it is available - try OCaml/SML, Haskell, Nice, Scala...
NO. You are putting words in my mouth. I'm simply stating that Java typing system is broken and does not provide the safety that you proclaim it does. I have indeed seen and studied Haskell. I do like their type system better. But, I prefer to type less.
I'm told that IntelliJ IDEA now includes a rewrite engine - "Structural Search and Replace" - that's how we should do major design changes.
Gee, we have that too. The refactoring browser started in Smalltalk. Fire up VisualWorks and there's a very sophisticated rewrite tool that allows structural search and replace. It's been ported to Squeak recently as well.
1) It changes NOTHING of my point.
Perhaps you'd like to restate your point.
2) constantly running your code in a Smalltalk image just like in Ruby and Python. It's called an interpreter
#1 Let's write some Python code in a text-editor.
#2 Let's run that Python source code file from the command-line.
Seems like the program was only "running" in step #2. (Maybe you're conflating "interpreter" with REPL?)
3) 1% bugs comment... Only the evidence that I observed...
So you haven't watched the programmers on those Java projects, and recorded how many errors were caught by the compiler?
"The static vs dynamic typing debate will go on forever" as long as people invent evidence!
"this might come as a shock" but I wrote Smalltalk day-in day-out for 10 years.
5) Java typing system is broken and does not provide the safety that you proclaim it does
Where exactly did I proclaim that?
6) Gee, we have that too
Pardon me, it seemed from "Simple refactoring is always easy, but major design changes..." that you hadn't used a rewrite engine to make major design changes.
#1 Let's write some Python code in a text-editor.
#2 Let's run that Python source code file from the command-line.
Seems like the program was only "running" in step #2. (Maybe you're conflating "interpreter" with REPL?)
You are right. But, isn't the E in REPL an interpreter? Besides, when I program in Ruby. I have a Ruby VM running and just re-load my file. It's not much different than the way I program in Lisp. If I hose things up, I just restart the VM.
So you haven't watched the programmers on those Java projects, and recorded how many errors were caught by the compiler?
I'm sorry I have not done due deligence on that one. It has been my experience that the compiler catches the simple bugs and not the logic bugs which are the trickier ones anyway. Simple bugs do still happen in Smalltalk, but they are caught early in life. It's been rare and only the result of a sloppy programmer to get those types of bugs in production code. Java seems to penalize all programmers for the habits of sloppy programmers.
"The static vs dynamic typing debate will go on forever" as long as people invent evidence!
I think people have been successful on both sides. Thus, with different experiences, you can come off with different view points. To me, it's the difference between liberal and conservative. There's nothing wrong in either's view. They just look at the problems differently. I'm more successful in dynamic languages, thus my bias.
5) Java typing system is broken and does not provide the safety that you proclaim it does
Where exactly did I proclaim that?
You didn't. It was a wrong implication on my part. I apologize.
2) You are right. But, isn't the E in REPL an interpreter?
iirc this started with "Besides, in dynamic languages you're always running the program".
Now we've agreed that you are talking about REPL, the obvious question is 'do statically typed languages have REPL?'
REPL for Java
REPL for OCaml
3) I'm sorry I have not done due diligence on that one.
Here's the problem, you made the claim "static typing only finds 1% of the bugs" - and now all those Java and static hounds can use that false claim to demonstrate that Smalltalk advocates make self-serving claims which are simply untrue.
It has been my experience that the compiler catches the simple bugs and not the logic bugs which are the trickier ones anyway.
But once again, I doubt that you have recorded what errors the compiler traps, even during your own programming sessions - so what you call "experience" is actually just guesswork.
Simple bugs do still happen in Smalltalk, but they are caught early in life. It's been rare and only the result of a sloppy programmer to get those types of bugs in production code.
I have a great deal of respect for the expertise and professionalism of the VW engineering team. Here's the VW 7.2.1 Fix List. Many of the items are new or changed functionality, but let's pretend they are all bugs.
imo At minimum 5% (and at most 15%) of those items could have been detected by static type checking.
Errare humanum est.
"Java has exactly the opposite property, it forces you to make choices explicitly"
This is a misconception. There's no reason you can't change types any time you like in a Java program, and refactoring IDE's make it easy. In fact, renaming a method or changing its signature is far easier in Eclipse or IntelliJ than it is using Python and emacs.
In an XP project, the design can change radically from one week to the next. There's nothing about Java that prevents this, if you have the right tools.
(What I meant was that you do have to say what type you want today, but you can always change your mind tomorrow. It's explicit but very changable.)
Post a Comment