in reply to TIEOWTTI
What is difficult is mapping your problem domain to the language. I often find myself wanting to attack a problem in a certain way, and after frustrating myself for an hour or two, come to the conclusion that it's not possible, so I have to throw away the code and start off on a different tack. It comes down to second-guessing the language designer, thinking how they thought, trying and come up with an approach that will fit in with the language.
In this sense, it's a much more constraining experience. You're not actually expressing yourself, you're just trying to get a job completed by trying to slot your square pegs into the language's round holes.
Another aspect of this debate is orthogonality. The word gets bandied about a lot, and I'm not sure everyone agrees on what it means, I'm not sure I even understand it myself. But what it means for me is that something you pick up in one corner of the language can successfully be applied to another part of the language... and it will work! Perl excels at this sort of thing, like the notion of the last expression in a block is returned, and lazy evaluation and what not.
Visual Basic is an utterly unorthogonal language. It has a sort of object dot notation syntax, so you can say
a = obj.foo.bar.blot(22)
... but, in some instances, that doesn't work. For reasons that escape me (no doubt due to the evolution of the language over the years (god only knows what the parser source looks like)), you come across strange cases, where you have to do something like
dim otmp as some_obj otmp = obj.foo.bar a = otmp.blot(22)
And that is the only way to do it! Okay, it's a bit of a pathological case, but I think you get the picture. Languages that let you do the same thing in different ways by definition tend to stay out of your way, so that you can concentrate on the task, and not have to keep adjusting to the tool.
update: missing "from" noted by tye. Thanks :)
|
|---|