|
|
Posted by Jerry Stuckle on 12/17/06 04:39
Double Echo wrote:
> Jerry Stuckle wrote:
>
>> Tim Streater wrote:
>>
>>> In article <NtqdneCPLbONNB_YnZ2dnUVZ_smonZ2d@comcast.com>,
>>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>>
>>>
>>>> Tim Streater wrote:
>>>
>>>
>>>
>>> [...]
>>>
>>>
>>>>> It's just the vogue at the moment. Those of us who have developed a
>>>>> coding style over 40 years to assist maintainers who might be
>>>>> following, think different. Cool is not important - maintainability
>>>>> is (and donkeymentation, of course).
>>>>>
>>>>
>>>> In your opinion, at least. Many others, including us who have been
>>>> programming 39 years (started with Fortran II on an IBM 1401) think
>>>> differently.
>>>>
>>>> Some old-time programmers get so ingrained in one method it's hard
>>>> for them to see a different way of doing things might be better.
>>>> Others find new ways to be much better - including easier to maintain.
>>>
>>>
>>>
>>> I think it's just a vogue. Like when Pascal was the vogue and it was
>>> considered "good" to have only one exit from a procedure. As
>>> excruciating contortions were needed in real-world code to achieve
>>> this, I carried right on using the return statement and ignored the
>>> vogue.
>>>
>>
>> As I say - in your opinion. Millions of programmers disagree with you.
>>
>>>
>>>>> Personally I dislike something like:
>>>>>
>>>>> if (send_packet(params)) {
>>>>> do something
>>>>> }
>>>>>
>>>>> not just because of the braces but also because an "if" is supposed
>>>>> to perform a test - not have as a side effect as it might be
>>>>> sending a packet over the wire.
>>>>
>>>>
>>>> I love it, and use it all the time. First started doing in in C
>>>> over 20 years ago. It's one of the great features of languages like
>>>> C, C++, Java and PHP, and allows for a lot of flexibility.
>>>>
>>>> In your case the if statement is doing a test - but it's just a test
>>>> to see if an action (a dynamic event) completed successfully,
>>>> instead of the static value of a variable.
>>>>
>>>> Let's take it one step further:
>>>>
>>>> result = send_packet(params);
>>>> while (result) {
>>>> do something
>>>> result = send_packet(params);
>>>> }
>>>>
>>>> Or, just
>>>>
>>>> while (send_packet(params)) {
>>>> do something
>>>> }
>>>>
>>>> After all, all a while loop is is a test which is executed
>>>> repeatedly until the condition fails.
>>>
>>>
>>>
>>> If you're doing a test, do a test. If you're sending a packet, send a
>>> packet. These are distinct actions that should be separated.
>>>
>>> That's my style, at any rate.
>>>
>>> -- tim
>>
>>
>> Why? When it makes the code more complicated and harder to understand?
>>
>> It is a test - a test as to whether the action completed successfully
>> or not. But this concept is harder for some old-time programmers to
>> grasp.
>>
>> Just like in my classes - COBOL and FORTRAN programmers had a lot
>> harder time grasping the concept of pointers as implemented in C than
>> new programmers did.
>>
>> And typically the longer someone had been doing structured
>> programming, the more trouble he/she had in grasping OO concepts.
>>
>> It's sometimes hard for old-time programmers to change their habits.
>>
>
> I don't know about age being a true component of the argument, it's more
> about brain function, some people need object orientated stuff, some don't,
> and sometimes it's better to have just the objects you need and the rest
> of the app is simply functions. Whatever the need is, not necessarily all
> or nothing, this way or that. Sometimes the best of both is really what's
> needed. But to suggest that OO is more difficult for old programmers who
> do structured programming is a false argument. Most programmers that are
> any good have a profit motive and are extremely lazy, so they're going to
> do the most efficient thing possible. If I can accomplish an app without
> OO you can darn well bet I'll do it without OO unless it's avoidable. It's
> like a shotgun for killing mosquitos. On the other hand if I'm part of a
> large team and we need the app to have as much components as possible to
> build on for the future, OO might be right, but you can still do large
> projects without OO. It's a nice feature of PHP to be able to do it
> either way. And keep in mind, unless you compile the objects they still
> have to be interpreted, and in an interpreted language, speed is
> everything.
> Your OO may actually be too complex and slow the app down, something to
> watch for.
>
First of all, by "old time programmers" I don't necessarily mean age
wise. But I think you have to admit there aren't many 20-something
programmers around who have been programming since 1967, like I have :-)
As for the OO concepts, I have 16 years of corporate training experience
to fall back on. During that time I've trained thousands of
programmers, many in OO languages.
One thing which I've seen repeatedly is the more experienced the
programmer, the harder he/she has adjusting to new concepts.
For instance, COBOL programmers with several years of experience have a
lot of trouble adjusting to the concept of a pointer variable in C/C++.
The same is true with experienced FORTRAN programmers. That's
because those languages don't have pointers.
OTOH, COBOL or FORTRAN programmers with 1-2 years of experience have
less trouble adjusting to pointer data types because they don't have the
preconceived ideas.
The same is true for OO techniques. I didn't say it is more difficult
to learn - but rather it is more difficult for them to overcome
preconceived ideas.
Now I never said OO was right for every circumstance. And I never said
that you had to use OO in every project. But I did say older
programmers have a hard time changing their way of thinking. I stand by
that statement, and so do all of the other OO instructors I know.
> Happy Holidays!
>
> :-)
>
>
You, too!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|