Re: I think I disagree, maybe

Post #106,771

6/21/03 12:09:13 AM

"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

by ben_tilly

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

Expand All History

Post #106,960

by static

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.

Welcome to IWETHEY!