Post #106,770
6/21/03 12:04:55 AM
|
Your brain is damaged
from the order in which you've encountered programming languages. :-)
if(condition) block
is no more intuitive to a complete novice than
condition ifTrue: block
The fact that the Smalltalk block closure is actually an object vs the C block simply being a lexical scope is not at all visible to the novice and need never come up.
I continue to be amazed at developers who insist that
map.put(key,object);
is somehow clearer than
dictionary at: key put: object.
They say that the Smalltalk message syntax is "weird" but its really only unfamiliar. After working with it for awhile I began to find it more natural. For one thing, you can read it out loud and understand it. The arguments are clearly labeled.
Compare the following calls:
(NSWindow alloc) initWithContentRect:aRect styleMask: NSTitledWindowMask backing:NSBackingStoreBuffered defer:YES screen:(NSScreen defaultScreen).
vs the java-ized
new NSWindow(rect,NSTitledWindowMask,NSBackingStoreBuffered,YES,NSScreen.getDefaultScreen())
So I don't think I agree with your thesis. In fact, I don't agree with people who say that so-called advanced languages like Smalltalk are somehow "too dangerous" for average programmers.
Go take a couple groups of RPG programmers - teach one Visualworks and the other Java/swing and see who is more productive. Its typically the VW guys every time.
"Smalltalk, with its emphasis on the human side of programming, was a nurturing environment in which to grow Extreme Programming. Smalltalk is still technically superior for reducing the cost of change over the life of a project, a key component in enabling XP." -- Kent Beck
|
Post #106,809
6/21/03 2:12:46 PM
|
I am not saying
that Smalltalk syntax is weird. It's just another syntax.
What I am saying is that Smalltalk's (and Lisp's, and TCL's) syntax is minimalistic. Most of those languages' functionality has nothing to do with syntax.
But this is not even my main thesis. My main thesis is that Java and C++ are narratives ("If he goes left, he loses his steed. If he goes right, he loses his head"), and Smalltalk and Lisp are acts of creation. Even the simplest constructs in Smalltalk have depth unheard of in the C world. It is more powerfule and expressive, but it cannot be used by 90% of the people. Average programmers are good at writing down stories. They are no good at creating worlds.
We've just had a testimony from an average guy. Can you argue with that? You have to be disabused of the notion that all people can think like you do, it's only a matter of education or initiative. No amount of education would allow Warmachine or Tablizer to enjoy Smalltalk. Use it - yes. Enjoy it - no.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #106,846
6/21/03 9:29:32 PM
|
Average guy? Come here and say that! :)
Average programmer? That's fighting talk! I'll have you know I sat 'O' level Mathematics 2 years early and got grade A. Alright, that was a long, long time ago but I'm still a fan of mathematics and popular science. Alas, I'm an engineer by profession, not an academic, so I stick to straightforward, narrative code, rather than elegant and flexible class designs. If the complete behaviour of a function can be contained within half a screen using a switch statement and a few private, member variables, rather than the scattered among the classes implementing the more elegant State design pattern(1), then its better for maintenance programmers.
Now, you might say the State design pattern is a more maintainable solution than switch statements and I'd agree with you. Except most people won't understand it. I'm studying a new computing module aimed at 3rd year undergrad level and it designs Finite State Automata using switch statements (in C++), not the State design pattern. This is from the same university that teaches Smalltalk (at 2nd year undergrad level). I kid you not! If the academics don't grok the expressiveness and elegance of Smalltalk, there is no point expecting others to do the same. Hence, I stick to the more clunky and restrictive Java.
Oh, and it also scared me to be mentioned in the same breath as Tablizer. :)
(1) Design Patterns: Elements of Reusable Object-Oriented Software, pp305-313, Erich Gamma et al, published by Addison Wesley, 1995.
Matthew Greet
But we must kill them. We must incinerate them. Pig after pig, cow after cow, village after village, army after army. And they call me an assassin. What do you call it when the assassins accuse the assassin? They lie. They lie and we must be merciful to those who lie.
- Colonol Kurtz, Apocalypse Now.
|
Post #106,852
6/21/03 11:21:03 PM
|
Either you are, or...
>>>>>>>>>>>>>>>>
Now, you might say the State design pattern is a more maintainable solution than switch statements and I'd agree with you. Except most people won't understand it.
<<<<<<<<<<<<<<<<
..you work with them. You're giving me the best possible arguments, thank you.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #106,879
6/22/03 9:33:31 AM
|
Yep! But give it more time.
It's simply inertia, people are too used to C syntax and are still getting used to the idea of 'tell, don't ask'. I've seen developers learn and adopt the design patterns of Factory, Proxy, Singleton and Template. Adoption of Strategy still seems slow. Double dispatching (Visitor) and block closures are still a long way off.
Matthew Greet
But we must kill them. We must incinerate them. Pig after pig, cow after cow, village after village, army after army. And they call me an assassin. What do you call it when the assassins accuse the assassin? They lie. They lie and we must be merciful to those who lie.
- Colonol Kurtz, Apocalypse Now.
|
Post #106,864
6/22/03 12:50:49 AM
|
What's this got to do with the price of oil in Baghdad?
I'm an engineer too. And I also sometimes act as an academic (teach CS at undergrad level). The university system has been remade into a set of fancy vocational schools though so lets not try to tell anything by what goes on there. I mean, christ, I just had to explain to Professor Cay Horstman that his most recent [link|http://www.artima.com/weblogs/viewpost.jsp?thread=4744|article] was [link|http://www.artima.com/forums/flat.jsp?forum=106&thread=4744&start=15&msRange=15|horsepucky].
As to the rest of your post - you're talking about eschewing a state pattern design and preferring switch statements. Fine. This is a 100% language independent decision. What's it got to do with Smalltalk vs Java? Smalltalk has a switch statement (most do - you can write one in a minute of yours doesn't).
As for most of the patterns, I've found that a lot of them simply vanish in Smalltalk. It seems that many of them are workarounds for poor language design decisions in Java and C++.
"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
|
Post #106,878
6/22/03 9:01:00 AM
|
Oops! You're right.
I must have purged switch in Smalltalk from my memory when teaching myself to write in a less procedural fashion. Smalltalk is looking more attractive as a commercial language. Still want strong typechecking, though.
Matthew Greet
But we must kill them. We must incinerate them. Pig after pig, cow after cow, village after village, army after army. And they call me an assassin. What do you call it when the assassins accuse the assassin? They lie. They lie and we must be merciful to those who lie.
- Colonol Kurtz, Apocalypse Now.
|
Post #106,885
6/22/03 1:43:11 PM
|
You've missed something I think
Still want strong typechecking, though. We've already [link|http://z.iwethey.org/forums/render/content/show?contentid=101330|discussed] this and I think concluded that the benefits of strong type checking are grossly overrated. It seems some of its proponents like Robert C Martin are also coming to this conclusion.
"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
|
Post #106,889
6/22/03 1:58:49 PM
|
Re: Oops! You're right.
Still want strong typechecking, though. I agree, although I'm perfectly happy with dynamic strong types. It doesn't have to be static. --
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #106,856
6/22/03 12:17:49 AM
|
OK that's true
it was some guy on the Artemis weblogs that asserted that Java syntax is more "natural" than Smalltalk.
But the narrative thing I think I still disagree with. Smalltalk can be read out loud and understood. You can't say the same thing about java.
dictionary at: x put: y.
is a narrative.
map.put(x,y) is much more cryptic about what is going on.
The really funny thing about Smalltalk is that it was designed to be used by children. For the most part, they get it. Its a little above some children - but not so far. Check out some of the kid projects at [link|http://www.squeakland.org|http://www.squeakland.org] to see kids programming robots using Smalltalk.
So my point is going to remain that its the biases instilled in the programmer by the more "conventional" languages that make Smalltalk "hard". You don't need to use all the depth. You can go as deep as you like and still get things done.
"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
|
Post #106,866
6/22/03 1:09:55 AM
|
Smalltalk for Small Tykes
The really funny thing about Smalltalk is that it was designed to be used by children.
I was teaching my 10 year old daughter Smalltalk at one point. I would have never considered using C or C++ instead.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #106,882
6/22/03 12:02:45 PM
|
Wrong sense of "narrative".
May be I am misusing the word.
In your example, Smalltalk and C++ are actually rather equivalent. In my examples, they are vastly different. Simple syntax in C causes simple conceptual things to happen. Everybody knows what "if-then-else" means. In Samlltalk, simple syntax causes conceptually complex[*] things to happen, even if the result is the same as for simple things. For example, my insufficient knowlege of Smalltalk fails me when I think of if-then-else statement: is it
blah ifTrue:[thenpart] ifFalse:[elsepart].
or is it
blah ifTrue:[thenpart]; ifFalse:[elsepart].
(I suspect it's the second one)
It depends on what returned from ifXXX: : result of block or self. I know where to look for the answer. Somebody who just expects C++ syntax does not. He/she will grumble about dumb computers.
Another example: how do you do chained ifs? You should not have to, but what if you do? I can see that Smalltalk has to have a better primitive for that than nested blocks. I'd go looking in True and False classes, or in collections. If it's not there, I'll write it. The other kind of programmer will simply write it off oas computer's stupidity and use the inconvenient nested blocks.
[*] "complex" in certain sence. I am comfortable with Smalltalk complexity, but I am lost with computational mathematics, which is also called complex. And I've seen really smart people who have it the other way around. "Average programmer" can be extremely smart person, and still not grock Smalltalk/Lisp way.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #106,883
6/22/03 12:07:50 PM
|
(Oops)
Serves me right for posting before checking.
Of course, Smalltalk has ifTrueifFalse method. I think my ideas still stand, though :).
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #106,900
6/22/03 5:04:41 PM
|
modeling English
"if(condition) block" is no more intuitive to a complete novice than "condition ifTrue: block"
One could argue that if they are native English speakers, the first is more intuitive. It fits english ordering better. "If the amount he gives you is less than the bank statement amount, then divorce the hording bastard."
I continue to be amazed at developers who insist that "map.put(key,object)"
is somehow clearer than "dictionary at: key put: object."
IMO, it depends on how often it is used. Named parameters (which the second resembles) are clearer when you encounter something for the first time in code. However, if it is repeated multiple times, than positional parameters are quicker on the eye.
________________
oop.ismad.com
|
