Interesting take on Paradigms (OO vs Procedural)
in [Cobol]
|
From: tim on 29 Mar 2008 16:47 On Sat, 29 Mar 2008 12:01:10 -0700, Alistair wrote: > On 29 Mar, 06:18, tim <T...(a)internet.com> wrote: >> On Sat, 29 Mar 2008 01:15:20 +0000, docdwarf wrote: >> >> > 'Technically' there is even less difference between what you cite and >> > between A-negative and B-positive human blood... now I'd appreciate it if >> > you'd keep away from dealing with transfusions. >> >> > DD >> >> Ditto. No more than one bit might separate a program that works correctly >> and one that fails catastrophically. This is a relevant analogy, because >> DNA is code. >> > > Well said Tim. Most DNA is in fact what is called 'Junk DNA' with no > discernable function and with sections repeated without rhyme or > reason. 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, 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
From: Rick Smith on 29 Mar 2008 19:21 "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:657mp4F2dooroU1(a)mid.individual.net... > > > "Rick Smith" <ricksmith(a)mfi.net> wrote in message > news:13ur5tg3con5ja4(a)corp.supernews.com... > > > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > > news:65553nF2cjsrhU1(a)mid.individual.net... > >> > >> > >> "Rick Smith" <ricksmith(a)mfi.net> wrote in message > >> news:13uq9i0e2sfdd1a(a)corp.supernews.com... > >> > > >> > < http://www.cs.berkeley.edu/~jrs/4/lec/14 > > >> > ----- > >> > Why did the originators of object orientation rename "structures" to > >> > "objects" > >> > and "procedures" to "methods"? Hubris and arrogance, in my opinion. > >> > >> This simply says that the writer has not really understood the essential > >> differences. I read the full article and he/she does a good job of > >> listing > >> the differences, but identifying differences and actually understanding > > the > >> implications of those differences are two different things. > >> > >> The comment above implies that the commentator sees no difference between > > a > >> "structure" and an "object", yet anyone who has worked with these things > > in > >> the real world would understand the essential difference. This is the > >> difference between Acadaemia and Reality. > > > > H'm! Structure, in procedural, is accessed through a pointer. > > Object, in object-based, is accessed through a reference. > > Object, in object-oriented, is accessed through a reference; > > but also holds a "vtable" to accommodate inheritance and > > polymorphism. > > > > The essential difference seems to be the extension of the > > structure to add the "vtable" making the object a bigger > > structure. > > > You are looking only at the mechanics of an implementation. The conceptual > use of objects is WAY more important. But you only come to appreciate that > when you start using them for systems in the real world, and not just to > describe some academic argument. > > Whether objects implement inheritance through a vtable or not is completely > irrelevant to the use of objects. For you, an object is just a structure in > memory; for me, it is much more than that. I visualise objects as > representing a real world entity and having attributes and behaviours that a > structure alone can never have. Perhaps it comes down to imagination and > vision. 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. If one is to "simulate" anything, it is the behavior that is to be simulated. 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. 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.
From: Anonymous on 29 Mar 2008 21:03 In article <657lo7F2e5vr4U1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Alistair" <alistair(a)ld50macca.demon.co.uk> wrote in message >news:69c88c59-3e42-484a-8321-67452c60d5fd(a)s12g2000prg.googlegroups.com... >> On 29 Mar, 06:18, tim <T...(a)internet.com> wrote: >>> On Sat, 29 Mar 2008 01:15:20 +0000, docdwarf wrote: >>> >>> > 'Technically' there is even less difference between what you cite and >>> > between A-negative and B-positive human blood... now I'd appreciate it >>> > if you'd keep away from dealing with transfusions. >>> >>> Ditto. No more than one bit might separate a program that works correctly >>> and one that fails catastrophically. This is a relevant analogy, because >>> DNA is code. >> >> Well said Tim. Most DNA is in fact what is called 'Junk DNA' with no >> discernable function and with sections repeated without rhyme or >> reason. > >I think you need to qualify that to "without rhyme or reason that we can >discern at this time." I agree, Mr Dashwood... now, how often in my postings does one read *that*? The 'junk DNA' stuff is something that strikes me as just plain odd; energy is required to create and maintain it. A left-over here or there I can understand - the little toe or the vermiform appendix - but so much... *stuff* in each and every cell? It just doesn't make sense to me, now... but I will not say 'it will never make sense to anyone, ever.' DD
From: Robert on 30 Mar 2008 01:19 On Sat, 29 Mar 2008 12:01:10 -0700 (PDT), Alistair <alistair(a)ld50macca.demon.co.uk> wrote: >On 29 Mar, 06:18, tim <T...(a)internet.com> wrote: >> On Sat, 29 Mar 2008 01:15:20 +0000, docdwarf wrote: >> >> > 'Technically' there is even less difference between what you cite and >> > between A-negative and B-positive human blood... now I'd appreciate it if >> > you'd keep away from dealing with transfusions. >> >> > DD >> >> Ditto. No more than one bit might separate a program that works correctly >> and one that fails catastrophically. This is a relevant analogy, because >> DNA is code. >> > >Well said Tim. Most DNA is in fact what is called 'Junk DNA' with no >discernable function and with sections repeated without rhyme or >reason. Orgel and Crick called it "Selfish DNA: The Ultimate Parasite" in this article: http://profiles.nlm.nih.gov/SC/B/C/D/G/_/scbcdg.pdf DNA does not make protein directly. It encodes mRNA, which goes to a ribosome, where the protein is actually made. Most DNA doesn't make only one mRNA, it is like a macro that can make many different RNAs depending on parameters. It often makes short temporary RNA (stRNA), which in turn makes more stRNA, which eventually makes 'real' mRNA. There are layers of abstraction and overloading much like programming languages. DNA isn't a simple protein template, it's a meta language. Amoeba dubia have 200 times the DNA of humans. The marbled lungfish and a plant named Fritillaria assyriaca have 40 times as much. It is hard to believe the excess contributes to the host's survival or complexity. You could regard them as old companies burdened with parasitic unionized employees who cost and contribute little, or as cultures with an unusually complex grammar. Why is Mandarin and Russian so much more complex than Spanish? The message is the same. The answer is historic accident.
From: Pete Dashwood on 31 Mar 2008 19:44
"tlmfru" <lacey(a)mts.net> wrote in message news:h59Ij.101602$Ft5.46083(a)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 week 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 week'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 seek 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." |