Interesting take on Paradigms (OO vs Procedural)

A challenge to this point of view -  not disputing the real world fact to
which it applies!

What percentage of the people that have so "voted", Pete, are actually
qualified?  I.e., what percentage of them have complete familiarity with
BOTH procedural and OO concepts?  You have, as do other people that comment
in this group; therefore your and their opinions must be taken seriously.
But judging by comments about the putative behaviour of Java and other
programmers should they be required to soil themselves with Cobol - they are
acting strictly from their own prejudices, not in any reasoned manner.
After all, most of them have as their first language Java or C++.  All of us
are canalized to a certain extent by what we learn first; so this is not
suprising.  But it isn't and should not be taken to be a rational thing.
(Remember the "arguments" for using goto-less programs - and I don't want to
start a debate on that: "GOTO's suck".  "Don't use GOTO's - ever".  QED.
Such a standard of debate would be sneered off the planet if rationality
were to rule).  Put another way: how far would you trust the conclusions of
a hardware consultant who states that the only thing he's familiar with is
Solaris?  So why should one accept the opinion of somebody whose ONLY
experience is in Java?

PL

Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:65572qF2devk5U1@mid.individual.net...
 
>
> Very interesting post, Richard. I didn't know the terms came from
> Simulation. I liked your examples.
>
> I think the whole debate over OO is pointless. The world has voted with
its
> feet. Trying to pretend there is nothing different or advantageous in
using
> OO, over standard COBOL, is like trying to pretend that a car is really
just
> a horse...
>
> That is not to say there are not some things for which a horse is better
> suited than a car, but saying that, in no way diminishes cars...or horses
> :-)
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>
>

"tlmfru" <lacey@mts.net> wrote in message
news:h59Ij.101602$Ft5.46083@newsfe15.lga...
>A challenge to this point of view -  not disputing the real world fact to
> which it applies!
>
> What percentage of the people that have so "voted", Pete, are actually
> qualified?

As you agree that this is the reality, it really doesn't matter, does it?

However, I'll respond to your point...

I said "the World" has voted with its feet and embraced OO. So the key
things here are what I mean by "the World", and what you mean by
"qualified"...

You defined what you meant in the next sentence.

So maybe I need to expand a little on what I was talking about.

"The World" in this context is the world of in house development. That isn't
just programmers. It is analysts, managers, and everyone who is affected by
the paradigm in use (even including the Business...). (So often (in CLC) the
bigger picture is lost sight of...)

The fact is that the introduction of an Object based paradigm has caused
complete re-thinks in HOW systems are developed, and was one of the primary
things which led to the death of the Waterfall as a static development
process. (I'm not claiming that Waterfall development is dead; it is alive
and well on many sites, but most  of them have not embraced Object
technology...sites that have, for the most part, are using Object based
development methodologies that involve OOD,  Object modelling, RAD, and
Active style interactive development.) They are more responsive, more
flexible, and less expensive, than their procedural counterparts. They have
no trouble getting staff because the universities are churning out people at
all levels who have been taught the Object paradigm. Object modelling, joint
development, prototyping, distributed components and architectures like SOA,
Web based applications, are all "the norm" for these people, many of whom
have no intention of being programmers.

(in fact, with the advent of really smart visual tools, programming skill
requirements are actually becoming moot... I was evaluating a new
development tool last w and it just left me gasping... I produced a
database-driven web based application, with three tiers of C# code,
annotated stubs for "tailoring " if required, complete DB connection,
access, and update, and click once deployment to a web server, in 6 hours.

This included the DB design. (OK, it wasn't difficult and I've had a lot of
practice at it, but neither was it completely trivial...6 tables, 7
referential integrity constraints, 3 inverted relationships...)

The code produced by the tool is incredible, clear and efficient. The user
interface is stunning, with toolbars and menu options all generated and
driven from the database. I checked out the presentation layer and all the
C# code behind pages, master pages, CSS images, icons, toolbars, etc. I
reckon to write it all manually would have been at least 2 months work. I
will need to do some tailoring for some of the trickier stuff with one or
two complex multiple table joins, and some tweaking of the User Interface
(although this will be really minimal), but I estimate it to be about a
w's work. The finished application would normally take three months to
produce. It would not be feasible without Object technology. I was able to
produce a working DB model and application prototype, in support of a
proposal which is being put together by a client. If this goes ahead and
they get the funding they are looking for, I'll post links to the finished
application here and you can check it out for yourselves.)

The point is that the Object paradigm has benefits not just for programmers.
If it were up to programmers only, the results might be different than they
observably are. It is no good saying that choices were made by people
"unqualified" to choose; "the World" is larger than just the programming
bullpen...and adopting the Object based model is not JUST about programming.

Programmers generally don't get to vote on what language will be used on the
sites where they work. Instead, the site mandates certain languages and
approaches, and then recruits people with those skills. And that is
reasonable, because programmers are generally not concerned with the welfare
of a given site (apart from the fact that if it goes broke they are faced
wth the inconvenience of getting another job); rather, they are concerned
primarily with making a living.

You might think that would make them aware of changing technology and eager
to embrace new ideas.

Paradoxically, it doesn't. Having invested years in gaining proficiency with
a given language, they then s to protect their investment by resisting
change and trying to persuade others that it is unnecessary and inefficient.

Only when the site management actually insist that the new stuff be
implemented, and when many other sites have adopted it and thereby changed
the market place for programming skills, will you find some of them getting
down to coming to grips with it.

>I.e., what percentage of them have complete familiarity with
> BOTH procedural and OO concepts?

Do you need to have full understanding of both concepts to see that one of
them has more benefits for the installation as a whole, than the other?

The financial bottom lines cannot be denied; Object based development is
demonstrably cheaper than maintaining code line by line. It is inescapable,
whether it is palatable or not.

You might need understandding of both concepts if you are a programmer. But
it isn't just about programming. If site management can see that things get
done quicker and more easily in places where Objects and components are the
norm, they are going to want a slice of the action. Managers, analysts,
business people... they all talk, Acadaemia is already sold. Soon, "the
buzz" becomes a rumble and the landslide starts...the pebbles don't get to
vote, so they bounce over to CLC and post their frustration here... :-)

The Object paradigm could not have enjoyed the success it has if it was as
flawed as some people here would like to think, or if it were simply a
"re-invention" of existing technology. Yes, there have been disasters; but
there were and are with the procedural approach too...

>You have, as do other people that comment
> in this group; therefore your and their opinions must be taken seriously.

Well, thank you, Peter, but I honestly don't think it is down to programming
experience alone. I believe it is bigger than that.

> But judging by comments about the putative behaviour of Java and other
> programmers should they be required to soil themselves with Cobol - they
> are
> acting strictly from their own prejudices, not in any reasoned manner.

I have worked with Java people, when I was a contract COBOL programmer, and
more recently as a Project Manager. I don't think they are any more
prejudiced or unreasonable than some of the people who post here. In my
experience MOST programmers are pretty fiercely loyal to their language of
choice. (The real secret, is not to have a language of choice and therefore
not get emotional about programming languages; so far, I have not
personallly been able to achieve this...I love C# and am liking it more as I
use it more... but I love COBOL too and am sorry to see its decline, even
though I understand the reasons for it.)

> After all, most of them have as their first language Java or C++.  All of
> us
> are canalized to a certain extent by what we learn first; so this is not
> suprising.  But it isn't and should not be taken to be a rational thing.
> (Remember the "arguments" for using goto-less programs - and I don't want
> to
> start a debate on that: "GOTO's suck".  "Don't use GOTO's - ever".  QED.
> Such a standard of debate would be sneered off the planet if rationality
> were to rule).  Put another way: how far would you trust the conclusions
> of
> a hardware consultant who states that the only thing he's familiar with is
> Solaris?  So why should one accept the opinion of somebody whose ONLY
> experience is in Java?

Well, you shouldn't, unless his statements are qualified to that context. If
it is understood that his background is Java or whatever, then his comments
have as much weight as anybody else's from a similar background.

For me it comes down to results.

The Object paradigm is not better because Java or C++ programmers say so,
any more than you can say that the Procedural paradigm is better because
COBOL, PL/I, or Pascal programmers say so...

Programming is simply ONE aspect of a paradigm. It is an important one, but
it is NOT the ONLY one...

Object and component technology has been embraced by "the World" not just
because component based systems are cheaper and easier to develop and
maintain; it is because the whole approach works better for all of the
stakeholders, NOT just the programmers.

Pete.
--
"I used to write COBOL...now I can do anything."

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13utjs3674qjr8f@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:657mp4F2dooroU1@mid.individual.net... 
> essential 
> between 
> things 
> completely 
> in 
> a 
>
> I used to see objects as real world entities. Now I associate
> real world entites with classes, because the methods in the
> classes repesent behavior.

Yes, that is fair comment. I used "object" (an instance of a Class) where I
should probably have used "Class".

Certainly the Class has methods which constitute the behaviour of the Class
but until it is instantiated there is no behaviour anyway, so perhaps
"object" is not really so wrong.

> If one is to "simulate" anything,
> it is the behavior that is to be simulated.

Technically that is true. The data isn't simulated. But conceptually it is
the synergy derived from the COMBINATION of behaviours AND data (as a single
encapsulated whole) that makes Objects so powerful.
>
> To simulate a business, the behavior occurs in employees,
> customers, orders, accounts, etc.; but to simulate the
> financial systems of a business the behavior is in clerks, and
> the employees, customers, orders, accounts, etc., become
> just data structures devoid of behavior.

Only if you see it like that. :-)

At this point, I think we diverge.

> This is not much
> different than a card game, where the dealer and players
> have behavior but the cards don't; even though the cards
> are real world entities.

The cards certainly DO exhibit behaviour. If they behave well you go home
rich. :-)

Pete.
--
"I used to write COBOL...now I can do anything."

In article <65dbahF2fprkhU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>Programmers generally don't get to vote on what language will be used on th
e
>sites where they work. Instead, the site mandates certain languages and
>approaches, and then recruits people with those skills. And that is
>reasonable, because programmers are generally not concerned with the welfar
e
>of a given site (apart from the fact that if it goes broke they are faced
>wth the inconvenience of getting another job); rather, they are concerned
>primarily with making a living.
>
>You might think that would make them aware of changing technology and eager
>to embrace new ideas.
>
>Paradoxically, it doesn't. Having invested years in gaining proficiency wit
h
>a given language, they then s to protect their investment by resisting
>change and trying to persuade others that it is unnecessary and inefficient
.
>
>Only when the site management actually insist that the new stuff be
>implemented, and when many other sites have adopted it and thereby changed
>the market place for programming skills, will you find some of them getting
>down to coming to grips with it.

Thanks very much, Mr Dashwood... I'd call that quite mirth-inspiring, as
sweeping generalisations about 'programmers' offer me about as much
amusement as sweeping generalisations about 'mainframers'.

DD

On 29 Mar, 21:47, tim <T...@internet.com> wrote:
> On Sat, 29 Mar 2008 12:01:10 -0700, Alistair wrote: 
> 
> 
> 
> 
>
> This remains true.. But as I understand it a fair amount of the DNA that
> does not produce proteins and thus was classified as junk DNA does in fact
> produce RNA,

Some would be for RNA encoding but the majority of 'junk' has no known
function with  much appearing to be 'blank' encoding.

> which has an important role in regulating cell functions. For
> example, a lot of the mutations that separate humans from their relatives
> seem to be for RNA that controls brain functions.
>
> Tim- Hide quoted text -
>
> - Show quoted text -

<docdwarf@panix.com> wrote in message news:fsru19$pag$1@reader2.panix.com...
> In article <65dbahF2fprkhU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
> 
>
> Thanks very much, Mr Dashwood... I'd call that quite mirth-inspiring, as
> sweeping generalisations about 'programmers' offer me about as much
> amusement as sweeping generalisations about 'mainframers'.
>
> DD
>
Glad it made you smile, Doc.  As Sir Arthur Wing Pinero reminded us: "There
is no harm in laughter".

I was aware of the general nature of my comments; as such, I wouldn't want
them taken too seriously.

Nevertheless, SOME of the generalization would be true for SOME programmers.

Pete.
--
"I used to write COBOL...now I can do anything."

On Apr 2, 10:50=A0am, "Pete Dashwood"
>
> Nevertheless, SOME of the generalization would be true for SOME programmer=[/color
]
s.
>

With these conditions applied then in what way would they still be
'generalizations' ?

"Richard" <riplin@azonic.co.nz> wrote in message
news:67e3cd1d-9034-4d40-8fe7-18bcc1b9cfa3@b5g2000pri.googlegroups.com...
On Apr 2, 10:50 am, "Pete Dashwood"
>
> Nevertheless, SOME of the generalization would be true for SOME
> programmers.
>

With these conditions applied then in what way would they still be
'generalizations' ?

[Pete]

They wouldn't be, that's why I didn't qualify them, originally :-)

Pete.
--
"I used to write COBOL...now I can do anything."