Post #106,663
6/20/03 10:23:14 AM
|
question from a non programmer
your two examples made equal sense to me. If I am programming something I am thinking rules based event handling. Make sure that every event is evaluated and a rule is fired for each instance. If the module does not match a rule then an error event kicks in. I have not had any formal language instruction other than digging thru other folks code and watching over shoulders plus reading a book or two so am missing large chunks of whys and whereafores. thanx, bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
questions, help? [link|mailto:pappas@catholic.org|email pappas at catholic.org]
As the Poets have mournfully sung. Death takes the innocent young, The rolling in money, the screamingly funny, And those who are very well hung. W.H. Auden
|
Post #106,666
6/20/03 10:40:07 AM
|
Second through fourth sentences are a blur
Could you restate :) ? Neither example refers to rules or events or modules. There are "messages" in there somewhere, but that's all.
--
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,670
6/20/03 10:49:42 AM
|
sorry, I went from your specific
example about message referencing to a broad overview of how I look at the task of programming regardless of language used. thanx, bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
questions, help? [link|mailto:pappas@catholic.org|email pappas at catholic.org]
As the Poets have mournfully sung. Death takes the innocent young, The rolling in money, the screamingly funny, And those who are very well hung. W.H. Auden
|
Post #106,675
6/20/03 11:14:55 AM
|
Well...
in Smalltalk (dear Smalltalkers, please correct me where I am wrong), a program execution is an exchange of messages between objects. An object has a method that gets called when a particular message arrives. The object "true" belongs to class "True", and because of that it has a method to execute on message "ifTrue:" The method consists of sending a "do"(?) message to the argument that was passed :
(notation is wrong - I don't remember the proper Smalltalk file out notation)
ifTrue: aBlock "execute the block passed to us" aBlock do. ^self.
"false", on the other hand, belongs to the class "False", and thus has a different method for "ifTrue:" message :
ifTrue: aBlock "ignore the block that got passed to us" ^self.
Of course, there is more. But compare this to the C++ idiom:
if (condition) operator1; else operator1;
Which one is easier to grasp? And, this is not just a learning curve issue. Most people can understand Smalltalk's approach. But they don't find it easier to create, to think at Smalltalk's level. C++ is easier not only to learn, but to live with.
--
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,676
6/20/03 11:25:14 AM
|
I am not smart enough to detect the difference
Small talk appears to have events bound by rules called objects. C++ appears to have events based on rule detection in a linear test condition. thanx, bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
questions, help? [link|mailto:pappas@catholic.org|email pappas at catholic.org]
As the Poets have mournfully sung. Death takes the innocent young, The rolling in money, the screamingly funny, And those who are very well hung. W.H. Auden
|
Post #106,679
6/20/03 11:34:47 AM
|
In C++, "if" is simple
"Do this or that depending on the value". It's a narrative.
In Smalltalk, a simple "if" requires understanding of complex concepts such as class and block.
--
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,680
6/20/03 11:51:41 AM
|
I think I disagree, maybe
In Smalltalk, a simple "if" requires understanding of complex concepts such as class and block. Doing an if/else in c++ also requires understanding of block. I've seen plenty of code (not c++, but ones with similar syntax) written by people who didn't have this understanding. Maybe the truth is that c++ allows you to think you understand what you're doing, when you really don't. So maybe (because I haven't done smalltalk) smalltalk requires that you actually do understand concpets before you're able to use them.
===
Implicitly condoning stupidity since 2001.
|
Post #106,682
6/20/03 12:13:50 PM
|
Re: I think I disagree, maybe
C's block and Smalltalk block are very different
C's one is a scoping construct, almost purely syntactic. People who do not understand C blocks aren't programmers at all. Not even bad ones, much less average. They should not even pretend.
Smaltalk's block is an object, a semantical thing. When you say [do. something.] you're not grouping 2 actions together. You're creating an instance of Closure class. And, oh by the way, it can also look like this:
[ :a :b| a + b]
or like this
[ :a :b | ^a+b]
The one above returns sum of a and be The one below terminates the method, returning the sum as method's result.
And, ofcourse, you can say
^[something]
returning a block itself as the result of method.
--
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,683
6/20/03 1:10:29 PM
|
I was right
I *haven't* done enough with Smalltalk to understand your point.
===
Implicitly condoning stupidity since 2001.
|
Post #106,771
6/21/03 12:09:13 AM
|
Re: I think I disagree, maybe
"C's block and Smalltalk block are very different"
Generally this is true. But in the context of your original post they act the same.
if(condition) { /* true stuff to do */ } else { /* false stuff to do */ }
acts exactly the same as
condition ifTrue: [ true stuff to do ] ifFalse: [ false stuff to do ]
the fact that they are lexical scopes in the former and actual objects in the latter isn't terribly important in this context.
"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,824
6/21/03 4:46:43 PM
6/21/03 4:47:22 PM
|
Perl 6 will take that idea farther
In Perl 6 all blocks will become closures. But with semantic sugar to make them tend to act in ways that C programmers find familiar.
Ruby already goes farther along this line than Perl 5, if not as far as Perl 6 plans to.
Incidentally my pet theory on some of this thread is that Larry Wall is onto something when he says that humans have built in wiring to decode a certain amount of syntax. (Like most people who get hold of a good idea, he can be accused of taking it too far...) The more "academic" languages tend to realize (with Lisp being an extreme) that encoding some things as syntax and others in terms of a computing model causes all sorts of artificial barriers that cost you and buy you nothing on a theoretical level, and so they tend to use less semi-naturalistic syntax. Which is completely not a problem if you are capable of building a layer of abstraction, understanding it, then building on that. But is a huge barrier for many people you find in the programming world who whether for reasons of inclination or capacity tend to draw a comprehensional barrier between "this is the language" and "this is what has been built within this language". (A barrier roughly corresponding to the division between what they follow by linguistic reflex, and what is actually thought about.)
Cheers, Ben
"good ideas and bad code build communities, the other three combinations do not" - [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
Edited by ben_tilly
June 21, 2003, 04:47:22 PM EDT
|
Post #106,960
6/23/03 7:53:30 AM
|
+5 Informative.
I've been programming in my current job for 18 months, now, and that's more than long enough for me to have seen exactly what you mean. The core problem with the way our Indian contractors programmed was their inability to abstract. At one extreme, they cut-n-pasted code instead of making it an object or even a function; at the other end they didn't want to tinker with our own API...
We almost had a similar problem with our latest recruit. I hadn't quite seen it, but my colleague noticed that he had trouble coding without fully documented interfaces. His current learning curve is appreciating how configurable a lot of our code has to be... and how many things accomodate simple changes in the configuration area. :-)
Wade.
Is it enough to love Is it enough to breathe Somebody rip my heart out And leave me here to bleed
| | Is it enough to die Somebody save my life I'd rather be Anything but Ordinary Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|