what's the future of Object Oriented Programming
VV
future is of Object Oriented programming.
I have spend most of my career with object oriented concepts (12+ years
) but recently with AJAX and the free tools, I really wonder what the
future of OO is.
I recently launched a business written completely with free tools like
php and AJAX. I worked hard to give everything a structure like we OO
programmers are so particular about but honestly there was minimal
dependence on OO.
The extend of my reusability might have been include pages, constants
etc.
Are many of you finding widespread use of OO in the web world?
Vibi Varghese
www.problima.com
A place to bring problems
..and to get paid to solve them
Phlip
> I have spend most of my career with object oriented concepts (12+ years
> ) but recently with AJAX and the free tools, I really wonder what the
> future of OO is.
>
> I recently launched a business written completely with free tools like
> php and AJAX. I worked hard to give everything a structure like we OO
> programmers are so particular about but honestly there was minimal
> dependence on OO.
That makes me wonder what you think OO is, if you didn't see it all over
your project.
> The extend of my reusability might have been include pages, constants
> etc.
Re-use is a happy side-effect of good designs. The primary goal is managing
dependencies between modules, by making them more pluggable. Your web page
can work in any browser, so the HTTP and HTML are like adapter layers. The
actual browser gives alternate behaviors to the common inputs.
For example, AJAX is a data stream to an Object - any web browser. The data
stream is a Message, where the JavaScript in the web page in the browser is
the Method that responds to that Message. Pure OO.
So the future of OO is ... you are soaking in it!
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
VV
> your project.
later, you would think I would know something about OO.
I understand that the operating system and the browser uses OO to
expose a variety of functionality.
My question was simply.
How much of OO is really needed in todays web based technology
environment. How much OO concepts do sites like amazon.com, eBay,
myspace and Google use.
I personally found that the web based stateless environment is not that
conducive to taking advantage of OO. We ended up borrowing a lot of
benefits exposed by procedural languages but minimal from OO.
I am wondering if others have a similar experience? If so, where does
OO fit in with high level applications (not system based) on the web.
Vibi
Phlip
> How much of OO is really needed in todays web based technology
> environment.
All of it. You need OO each time you see code that use 'if' or 'switch'
flagged by some value that is a type, not a scalar.
Common example: Your users come in two types, Guest and Premium. So you
store the boolean isPremium in the database, and then all over your project,
from the data layer to the JavaScript, you write "if (isPremium) (whatever}
else {whateverElse}" everywhere.
You need polymorphic types there. You should instead have a user type with
two sub-classes. User.whatever() will call one behavior for the Guests, and
another for the Premiums.
> How much OO concepts do sites like amazon.com, eBay,
> myspace and Google use.
All of it. Those guys generally resolve the types like I suggested.
Greg Bittar
I know you're concentrating upon the threat to OO from other programming
paradigms, but I have a different set of concerns.
When I look back on my projects, the one which was thoroughly OO used
GemStone. With a fully OO enterprise application server/database which
allows callbacks (unlike EJB), it was natural to apply the OO paradigm
to the modeling of business rules.
Outside of that, I've seen applications that access data from several
sources concurrently. For this, again, it was wise to have the
application act as arbiter, by specifying business rules.
However, what about the case where database transactions reference one
relational database at a time? In this case, I think there's a strong
argument that 'the methods go with the data', i.e. in stored procedures.
This is a good way to meet the ACID test and ensure reusability. (Of
course, sometimes there are contraints which prevent an application from
making multiple queries to the database, so business rules must reside
in the application.)
If it weren't for the flexibility of SQL, I would imagine that OO would
have proliferated onto the server, database side, a long time ago. So,
this is the limiter, in my experience.
But let me say something else: I've seen applications built with Java
that weren't OO in the slightest, and the reality, I think, is that in
the Java community, there isn't often as much of a warm embrace of OO as
I would like.
- Greg
Oliver Wong
"Phlip" <phli...@yahoo.com> wrote in message
news:5mjMg.2431$MF1....@newssvr25.news.prodigy.net...
> VV wrote:
>
>> How much of OO is really needed in todays web based technology
>> environment.
>
> All of it. You need OO each time you see code that use 'if' or 'switch'
> flagged by some value that is a type, not a scalar.
>
> Common example: Your users come in two types, Guest and Premium. So you
> store the boolean isPremium in the database, and then all over your
> project, from the data layer to the JavaScript, you write "if (isPremium)
> (whatever} else {whateverElse}" everywhere.
>
> You need polymorphic types there. You should instead have a user type with
> two sub-classes. User.whatever() will call one behavior for the Guests,
> and another for the Premiums.
Usually the PHP code is like:
Include.php:
function checkPremiumFlag() {
if (isPremium) {
return.
} else {
display offer to upgrade account.
stop further processing.
}
}
checkPremiumFlag()
PageA.php:
include('Include.PHP');
Display Page A contents.
PageB.php:
include('Include.PHP');
Display Page B contents.
Are you're proposing something like:
Guest.php:
class Guest {
displayPageAContents() {
display offer to upgrade account.
}
displayPageBContents() {
display offer to upgrade account.
}
}
Premium.php:
class PremiumUser {
displayPageAContents() {
Display Page A contents.
}
displayPageBContents() {
Display Page B contents.
}
}
PageA.php:
user.displayPageAContents()
PageB.php:
user.displayPageBContents()
?
- Oliver
Phlip
> Are you're proposing something like:
>
> Guest.php:
> class Guest {
> displayPageAContents() {
> display offer to upgrade account.
> }
>
> displayPageBContents() {
> display offer to upgrade account.
> }
> }
>
> Premium.php:
> class PremiumUser {
> displayPageAContents() {
> Display Page A contents.
> }
>
> displayPageBContents() {
> Display Page B contents.
> }
> }
>
> PageA.php:
> user.displayPageAContents()
>
> PageB.php:
> user.displayPageBContents()
>
> ?
What's the narrowest thing, if any, that differs over the two pages?
Put everything else into the calling routine. (Abstract Template Pattern.)
Your system duplicates a lot of stuff. We can see that duplication easily,
without even inspecting the source of displayPageAContents(), if we follow a
careful naming convention. Many elements of the names of
displayPageAContents() and displayPageBContents() duplicate!
To remove duplication without adding complexity, one often must use OO
techniques. So OO is relevant to all programming.
fre...@gmail.com
> php and AJAX. I worked hard to give everything a structure like we OO
> programmers are so particular about but honestly there was minimal
> dependence on OO.
>
> The extend of my reusability might have been include pages, constants
> etc.
>
> Are many of you finding widespread use of OO in the web world?
First, what is your definition of OO? As you see people claim that HTML
and web browsers are OO. So what is not OO? For some OO is everything,
and everything is OO.
For the rest of us, the main thing with OO is that it can handle
polymorphism in an improved way. The benefits of OO is only obvious if
your problem space contains a lot of polymorphic types. For average web
business/enterprise application, this is simply not the case. And it is
also very easy to overuse polymorphism. Types like customers and
employess is normally not polymorphic. In many cases, OO programming
languages (like Java) has a big disadvantage because they force you to
use objects for everything, even in situations when you only need
functions (the main method for example).
OO is a useful technology that you may benefit from in some situations.
But it should only be used as a complement to other technologies. This
is exactly the path the web languages like PHP, Python and Ruby is
walking.
Fredrik Bertilsson
http://frebe.php0h.com
fre...@gmail.com
> dependencies between modules, by making them more pluggable. Your web page
> can work in any browser, so the HTTP and HTML are like adapter layers. The
> actual browser gives alternate behaviors to the common inputs.
>
> For example, AJAX is a data stream to an Object - any web browser. The data
> stream is a Message, where the JavaScript in the web page in the browser is
> the Method that responds to that Message. Pure OO.
Maybe COBOL is OO too? Or even SQL?
Fredrik Bertilsson
http://frebe.php0h.com
fre...@gmail.com
> conducive to taking advantage of OO. We ended up borrowing a lot of
> benefits exposed by procedural languages but minimal from OO.
This is the same for all distributed applications, not only web
applications. You have the data in one tier, functionallity in another
tier. How can encapsulation be achieved under these circumstances?
A stateless application server publish a number of functions. Objects
can only be used within single server calls.
> I am wondering if others have a similar experience?
You are not alone.
> If so, where does OO fit in with high level applications (not system based) on the
> web.
OO fit when you have polymorphic types.
Fredrik Bertilsson
http://frebe.php0h.com
fre...@gmail.com
> store the boolean isPremium in the database, and then all over your project,
> from the data layer to the JavaScript, you write "if (isPremium) (whatever}
> else {whateverElse}" everywhere.
>
> You need polymorphic types there. You should instead have a user type with
> two sub-classes. User.whatever() will call one behavior for the Guests, and
> another for the Premiums.
Is Guest/Premium the only way you need to classify users? What if you
later find it that you need to have different functionality for
domestic and international users? How would the user subtypes look like
(DomestGuestUser, InternationalGuestUser, DomesticPremiumUser,
InternationalPremiumUser)? What if yet another dimension is introduced.
Subtyping can be very dangerous. It is very unlikely that a entity such
as user only need to be classified in only one dimension.
Fredrik Bertilsson
http://frebe.php0h.com
Phlip
> First, what is your definition of OO? As you see people claim that HTML
> and web browsers are OO. So what is not OO? For some OO is everything,
> and everything is OO.
I said, "Your web page can work in any browser, so the HTTP and HTML are
like adapter layers." Going from there to "everything is OO" is a slur,
which I don't appreciate.
What verbiage in this thread lead you to "For some OO is everything"?
Phlip
>> Common example: Your users come in two types, Guest and Premium. So you
>> store the boolean isPremium in the database, and then all over your
>> project,
>> from the data layer to the JavaScript, you write "if (isPremium)
>> (whatever}
>> else {whateverElse}" everywhere.
>>
>> You need polymorphic types there. You should instead have a user type
>> with
>> two sub-classes. User.whatever() will call one behavior for the Guests,
>> and
>> another for the Premiums.
>
> Is Guest/Premium the only way you need to classify users?
Absolutely yes. That's the only criteria that gets OO'd.
> What if you
> later find it that you need to have different functionality for
> domestic and international users?
Uh, put their functionality into two subclasses with a parent class
HailsFrom? Give each Customer instance a delegating link to a HailsFrom
instance?
> How would the user subtypes look like
> (DomestGuestUser, InternationalGuestUser, DomesticPremiumUser,
> InternationalPremiumUser)? What if yet another dimension is introduced.
Wow! That problem could happen to anything in OO, not just in lite web
sites!
How about we ... don't do that?
> Subtyping can be very dangerous. It is very unlikely that a entity such
> as user only need to be classified in only one dimension.
Duplicating code all over the place can be very risky. If a given OO pattern
reduces the duplication, use it. Otherwise ... don't!
Phlip
>> For example, AJAX is a data stream to an Object - any web browser. The
>> data
>> stream is a Message, where the JavaScript in the web page in the browser
>> is
>> the Method that responds to that Message. Pure OO.
>
> Maybe COBOL is OO too? Or even SQL?
Sure, but only when used in the JavaScript layer.
VV
way to use OO within the context of todays web sites.
One clarification to the earlier post.
I define the benefits of OO as the additional benefits above and beyond
what procedural programming already offered.
For e.g. reducing dependency was already solved with procedural
languages using libraries and include files. As a result, we should
ignore this as a value of OO. You get my gist.
Borrowing an idea from a previous poster, I guess I could have created
objects to represent types of users at my sites. In our case - users
and solution providers. All methods related to these objects would then
be encapsulated within the objects. It would be easy to maintain and
extend and such a site.
But I guess my biggest problem is simply that web sites do not
naturally lend itself to OO the way apps do. In an app, everything is
an object with functions. For e.g. In windows you have windows,
applications, programs - all objects. Web sites have pages, not
objects. So if you build sites with OO yes its possible but it just
doesn't feel like a natural fit.
Please let me know your thoughts.
Regards.
Vibi Varghese
Phlip
> For e.g. reducing dependency was already solved with procedural
> languages using libraries and include files. As a result, we should
> ignore this as a value of OO. You get my gist.
OO allows old code (library code) to call new code more easily. Without OO
support in your language, you must pass a function pointer to the old code,
and this calls your function back as a callback, to specialize it. The
callback typically comes with a void *, to pass your application-specific
data through.
Under an OO system, you derive from a library class, and overrride a
function. This is also a callback (the procedural language enabled a form of
OO), but it's typesafe, more accurate, and easier to upgrade and extend.
> Borrowing an idea from a previous poster, I guess I could have created
> objects to represent types of users at my sites. In our case - users
> and solution providers. All methods related to these objects would then
> be encapsulated within the objects. It would be easy to maintain and
> extend and such a site.
Don't create a class as a "compilable comment", to name a category of
entities. Create one if you have behavior to abstract.
Have you read /Design Patterns/ yet?
> But I guess my biggest problem is simply that web sites do not
> naturally lend itself to OO the way apps do. In an app, everything is
> an object with functions. For e.g. In windows you have windows,
> applications, programs - all objects. Web sites have pages, not
> objects. So if you build sites with OO yes its possible but it just
> doesn't feel like a natural fit.
An HTML page is a declarative expression, not a program, so naturally its OO
aspects are more subtle.
One big twist in web programming is you typically need aspects of your
objects to appear in several layers. Database, server-side, HTML, DOM, and
JavaScript. Of course you don't clone the code of each object and port it to
the next language. The best way to flatten this complexity is a variation of
the Observer Pattern called Model View Controller. That's, roughly, a triad
of 3 observers watching each other. So the only "objects" in your JavaScript
are thin things that observe your data model, and reflect its changes onto
the screen.
Now look up Ruby on Rails, if you think OO can't accelerate web development!
Bruno Desthuilliers
(snip)
> But I guess my biggest problem is simply that web sites do not
> naturally lend itself to OO the way apps do.
Depends on what kind of "web site" - and what kind of application. An
e-commerce solution usually includes a non-trivial part of applicative
code...
> In an app, everything is
> an object with functions. For e.g. In windows you have windows,
> applications, programs - all objects. Web sites have pages, not
> objects. So if you build sites with OO yes its possible but it just
> doesn't feel like a natural fit.
One other possible approach is too represent pages (and their content)
as objects, and store the whole thing in a OODBMS - this is mostly how
Zope2.x works (ok, Zope sucks, but that's another problem).
You can have a look at Trac's components/plugins architecture or at the
CherryPy web application server to see how web-programming can benefit
from OO.
My 2 cents...
H. S. Lahman
> I am interested in hearing everyone's opinion on what they think the
> future is of Object Oriented programming.
>
> I have spend most of my career with object oriented concepts (12+ years
> ) but recently with AJAX and the free tools, I really wonder what the
> future of OO is.
>
> I recently launched a business written completely with free tools like
> php and AJAX. I worked hard to give everything a structure like we OO
> programmers are so particular about but honestly there was minimal
> dependence on OO.
Huh? It is true that a lot of the RAD CRUD/USER tools and layered model
infrastructure are object-based at best. In addition, OSes like
Windows and interoperability infrastructures are pretty much a bunch of
class wrappers overlaid on function libraries.
But the OOness lies in the OOA/D of the application, which is largely
independent of the specific implementation technologies. (The
transformation engines used for full code generation from UML OOA models
routinely target languages like C or even Assembly for the output.)
> The extend of my reusability might have been include pages, constants
> etc.
Reuse is nice but not a major consideration in using OO techniques. The
real objective of OO development is to create maintainable applications
in the face of volatile requirements over the product life cycle.
To answer your title question, OO programming is still the only game in
town for producing maintainable software. Unfortunately there is a lot
of software called "OO" that is just C or FORTRAN programming with
strong typing.
The long term future of OO lies in UML as a 4GL. Currently UML is the
only truly general purpose 4GL available and the OO paradigm's emphasis
on abstraction is ideally suited to 4GLs because it allows independence
from the local computing environment.
Currently we are just moving into a paradigm shift similar to the shift
from 2GLs (BAL) to 3GLs in the early '60s. In another 10-15 years I
fully expect 3GL programmers to be as rare as Assembly programmers
today. Currently the only vehicle in town for that shift is the OO
paradigm.
> Are many of you finding widespread use of OO in the web world?
From what little I've seen, no. Much of current web development seems
to be a throwback to the '60s. That's sad because there really
shouldn't be anything different about web development than one finds in
typical R-T/E environments. You've got a remote client and asynchronous
messages. What's new about that?
[Apocryphal anecdote. A couple of years ago I saw an article in a
journal where the author actually claimed the first markup language was
invented in 1986. How soon they forget and repeat past mistakes.
Markup and scripting languages were very much in vogue in the late '50s
and '60s. But there was a reason why they were abandoned by the early
'70s.]
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
in...@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
fre...@gmail.com
> > and web browsers are OO. So what is not OO? For some OO is everything,
> > and everything is OO.
>
> I said, "Your web page can work in any browser, so the HTTP and HTML are
> like adapter layers." Going from there to "everything is OO" is a slur,
> which I don't appreciate.
>
> What verbiage in this thread lead you to "For some OO is everything"?
You also said:
"AJAX is a data stream to an Object - any web browser. The data
stream is a Message, where the JavaScript in the web page in the
browser is
the Method that responds to that Message. Pure OO."
Using HTML, JavaScript and AJAX is mostly done with minimal use of OO.
But you claim that it is OO just because it can med modelled as
objects. Because (almost) anything can be modelled as objects,
everything is OO, according to you.
I can model a HTML page using the relational model, but that doesn't
mean that you use the relational model when you write a HTML page.
Fredrik Bertilsson
http://frebe.php0h.com
Patrick May
> "H. S. Lahman" <h.la...@verizon.net> writes:
>>[Apocryphal anecdote. A couple of years ago I saw an article in a
>>journal where the author actually claimed the first markup language was
>>invented in 1986. How soon they forget and repeat past mistakes.
>>Markup and scripting languages were very much in vogue in the late '50s
>>and '60s. But there was a reason why they were abandoned by the early
>>'70s.]
>
> where I can learn more about this, with names or examples of
> these languages and an explanation why they were abandoned?
I'd start with the history of SGML. Google coughed up this link:
http://www.sgmlsource.com/history/index.htm
No doubt Mr. Lahman, with his advantage of greater age^H^H^H
experience[*] can provide more pointers.
Regards,
Patrick
* ;-)
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
fre...@gmail.com
> >> store the boolean isPremium in the database, and then all over your
> >> project,
> >> from the data layer to the JavaScript, you write "if (isPremium)
> >> (whatever}
> >> else {whateverElse}" everywhere.
> >>
> >> You need polymorphic types there. You should instead have a user type
> >> with
> >> two sub-classes. User.whatever() will call one behavior for the Guests,
> >> and
> >> another for the Premiums.
> >
> > Is Guest/Premium the only way you need to classify users?
>
> Absolutely yes. That's the only criteria that gets OO'd.
>
> > What if you
> > later find it that you need to have different functionality for
> > domestic and international users?
>
> Uh, put their functionality into two subclasses with a parent class
> HailsFrom? Give each Customer instance a delegating link to a HailsFrom
> instance?
Lets say we have a method processOrder and the behavior of this method
depends both on the premium and domestic/international criteria. Where
will we put the implementation? (I am not saying that subtyping and
inheritence is a bad thing, I only trying to say that it is not very
likely to be used a lot in enterprise (web) applications, as the OP
already has found out).
Fredrik Bertilsson
http://frebe.php0h.com
Rick Elbers
I think you are absolutely right. While every application model could
be described in object terms, a lot of them dont need it. Quite a lot
of money is invested an earned in essentially CREDO applications
(CRUD + Overview). Those applications might as well be constructed
using a good two-tier framework. If we, for instance, look at what
objects do in most applicatons using NHibernate or another ORMapper
you would be very willing to consider those "empty" objects more like
the "cost" of development then having anything to do with what OO
promisses us.
Regards,
Rick
ps: A good two-tier framework is still not constructed imho. Even .net
doesnt have for instance updatableViews.
Op 8 Sep 2006 07:41:29 -0700 schreef "VV" <vvarg...@gmail.com>:
Phlip
"Rick Elbers" <ri...@elbers.org> wrote in message
news:kpf8g2dad2nrrncp5...@4ax.com...
> Dear W,
>
> I think you are absolutely right. While every application model could
> be described in object terms, a lot of them dont need it. Quite a lot
> of money is invested an earned in essentially CREDO applications
> (CRUD + Overview). Those applications might as well be constructed
> using a good two-tier framework. If we, for instance, look at what
> objects do in most applicatons using NHibernate or another ORMapper
> you would be very willing to consider those "empty" objects more like
> the "cost" of development then having anything to do with what OO
> promisses us.
That is an example why OO is not a "description" process.
It's a system to make direct calls into indirect calls. That technique is
useful in all situations where excess coupling should be replaced by
extensibility.
H. S. Lahman
>>[Apocryphal anecdote. A couple of years ago I saw an article in a
>>journal where the author actually claimed the first markup language was
>>invented in 1986. How soon they forget and repeat past mistakes.
>>Markup and scripting languages were very much in vogue in the late '50s
>>and '60s. But there was a reason why they were abandoned by the early
>>'70s.]
>
>
> Is there a source (preferably accessible via the Internet)
> where I can learn more about this, with names or examples of
> these languages and an explanation why they were abandoned?
Not that I know of. Most online DBs weren't around prior to '84 and
there hasn't been a lot of backfilling for earlier work. Having been
there, though, I can provide some factoids.
MLs were very popular for things like report generation where the
formatting was handled by markups. I forget the acronyms but every
computer vendor and a bunch of other people provided one.
Scripting was also very popular, starting with OS Job Control Languages
used in the card-deck-and-batch processing days. They were also widely
used for initial interactive applications like online defect reporting
systems for OSes like IBM's TSO. At one point they were so popular that
an entire operating system -- Wylbur -- was constructed with scripts.
Why were they abandoned? Maintainability.
Rick Elbers
Am I excused when I dont understand what in heavens name you talk
about?
Rick
Op Sun, 10 Sep 2006 17:15:30 GMT schreef "Phlip" <phli...@yahoo.com>:
Phlip
> Am I excused when I dont understand what in heavens name you talk
> about?
Yup sorry - I was too brief.
> I think you are absolutely right. While every application model could
> be described in object terms, a lot of them dont need it.
You don't use OO to describe application models. You use it when those
models are too coupled.
> Quite a lot
> of money is invested an earned in essentially CREDO applications
> (CRUD + Overview). Those applications might as well be constructed
> using a good two-tier framework. If we, for instance, look at what
> objects do in most applicatons using NHibernate or another ORMapper
> you would be very willing to consider those "empty" objects more like
> the "cost" of development then having anything to do with what OO
> promisses us.
I think here you simply describe object abuse. Is a CREDO application one
bound to an Object Database? Do such databases force you to create too many
objects?
Rick Elbers
We seem to agree on the way we see things. No matter that the reality
seems to be that a lot of those two-tier applications are constructed
in object oriented frameworks( .net) en with object oriented
libraries(Nhibernate for instance) and with a lot of property bag kind
of "objects". Since there are quit a big bundle of them, and they also
*want uml* I think we cant ditch those as being OO abuse. For a lot of
people its their work to work that way with object, object frameworks
and object libraries. I dont want to be elitair in the sense that I
say "they dont get it, period ".
Rick
Op Sun, 10 Sep 2006 19:41:38 GMT schreef "Phlip" <phli...@yahoo.com>:
topmind
VV wrote:
>
> Borrowing an idea from a previous poster, I guess I could have created
> objects to represent types of users at my sites.
I don't think "types" is a good way to model users. "Roles", based on
set theory, is usually more flexible, and if the differences between
users are not complex enough to justify roles, then hierarchical
categories are probably overkill also, and, hierarchies don't scale
well. Roles are easily implimented in relational database many-to-many
tables.
-T-
topmind
> Reuse is nice but not a major consideration in using OO techniques. The
> real objective of OO development is to create maintainable applications
> in the face of volatile requirements over the product life cycle.
>
> To answer your title question, OO programming is still the only game in
> town for producing maintainable software.
I beg to differ. There is no evidence for this, at least outside of
systems software.
> Unfortunately there is a lot
> of software called "OO" that is just C or FORTRAN programming with
> strong typing.
>
> The long term future of OO lies in UML as a 4GL. Currently UML is the
> only truly general purpose 4GL available and the OO paradigm's emphasis
> on abstraction is ideally suited to 4GLs because it allows independence
> from the local computing environment.
UML is the navigational hell that motivated Dr. Codd to create
relational. Sets are more change-friendly than webs of pointers because
they are less shaped by initial uses and more by universal facts about
nouns, REGARDLESS of how they are used.
>
> Currently we are just moving into a paradigm shift similar to the shift
> from 2GLs (BAL) to 3GLs in the early '60s. In another 10-15 years I
> fully expect 3GL programmers to be as rare as Assembly programmers
> today. Currently the only vehicle in town for that shift is the OO
> paradigm.
IMO, OOP is 60's navigational ressurected by those who don't get the
utility of set theory.
OOP was a nice idea on paper, but didn't materialize to be nearly as
neat as the initial shape and animal examples used to sell it.
-T-
topmind
> Responding to Ram...
>
> >>[Apocryphal anecdote. A couple of years ago I saw an article in a
> >>journal where the author actually claimed the first markup language was
> >>invented in 1986. How soon they forget and repeat past mistakes.
> >>Markup and scripting languages were very much in vogue in the late '50s
> >>and '60s. But there was a reason why they were abandoned by the early
> >>'70s.]
> >
> >
> > Is there a source (preferably accessible via the Internet)
> > where I can learn more about this, with names or examples of
> > these languages and an explanation why they were abandoned?
>
> Not that I know of. Most online DBs weren't around prior to '84 and
> there hasn't been a lot of backfilling for earlier work. Having been
> there, though, I can provide some factoids.
>
> MLs were very popular for things like report generation where the
> formatting was handled by markups. I forget the acronyms but every
> computer vendor and a bunch of other people provided one.
>
> Scripting was also very popular, starting with OS Job Control Languages
> used in the card-deck-and-batch processing days. They were also widely
> used for initial interactive applications like online defect reporting
> systems for OSes like IBM's TSO. At one point they were so popular that
> an entire operating system -- Wylbur -- was constructed with scripts.
>
> Why were they abandoned? Maintainability.
JCL is *not* the pinnacle of scripting nor markup languages by any
stretch. The biggest problem with JCL is that it was stretched way
beyond its original intention, kind of like SQL has been.
Lisp is perhaps a better example of a scripting language that came out
of the late 50's. Not that I would want to use it in production because
it takes a long time to train your brain to track parenthesis in very
monotonous syntax, but it certainly had the right idea.
>
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
-T-
Patrick May
> H. S. Lahman wrote:
>> Reuse is nice but not a major consideration in using OO techniques.
>> The real objective of OO development is to create maintainable
>> applications in the face of volatile requirements over the product
>> life cycle.
>>
>> To answer your title question, OO programming is still the only
>> game in town for producing maintainable software.
>
> I beg to differ. There is no evidence for this, at least outside of
> systems software.
Actually, there is considerable evidence that some of the
concepts typically grouped together under the term "object oriented"
provide significant benefits in managing dependencies between software
components, which results in more maintainable software. I don't know
of anyone who has used OO in a large project and regretted having
those tools available. "The only game in town" is overstating the
case a bit, because similar techniques can be applied in most non-OO
languages and functional languages, for example, offer still other
approaches.
Out of curiosity, what do you mean by "systems software?"
Sincerely,
Patrick
topmind
Patrick May wrote:
> "topmind" <top...@technologist.com> writes:
> > H. S. Lahman wrote:
> >> Reuse is nice but not a major consideration in using OO techniques.
> >> The real objective of OO development is to create maintainable
> >> applications in the face of volatile requirements over the product
> >> life cycle.
> >>
> >> To answer your title question, OO programming is still the only
> >> game in town for producing maintainable software.
> >
> > I beg to differ. There is no evidence for this, at least outside of
> > systems software.
>
> Actually, there is considerable evidence that some of the
> concepts typically grouped together under the term "object oriented"
> provide significant benefits in managing dependencies between software
> components, which results in more maintainable software.
The only examples I've seen are from people who didn't know how to use
procedural and databases well.
> I don't know
> of anyone who has used OO in a large project and regretted having
> those tools available.
I've heard mumblings of things not going so smooth. Satisfaction
surveys by Yourdon showed no improvement. Further, OOP tends to
*create* large projects. Procedural/relational projects tend to break
big problems into smaller applications that feed off of databases. The
database is the Nile and small apps are villages on the shore. Thus,
one mostly only has to know about the schemas and a few sanctioned
library routines.
> "The only game in town" is overstating the
> case a bit, because similar techniques can be applied in most non-OO
> languages and functional languages, for example, offer still other
> approaches.
>
> Out of curiosity, what do you mean by "systems software?"
Tool building, such as OS's, RDBMS engines, compilers, device drivers,
network engines, etc. Polymorphism seems to have more use there.
>
> Sincerely,
>
> Patrick
>
-T-
Patrick May
> Patrick May wrote:
>> "topmind" <top...@technologist.com> writes:
>> > H. S. Lahman wrote:
>> >> Reuse is nice but not a major consideration in using OO
>> >> techniques. The real objective of OO development is to create
>> >> maintainable applications in the face of volatile requirements
>> >> over the product life cycle.
>> >>
>> >> To answer your title question, OO programming is still the only
>> >> game in town for producing maintainable software.
>> >
>> > I beg to differ. There is no evidence for this, at least outside of
>> > systems software.
>>
>> Actually, there is considerable evidence that some of the
>> concepts typically grouped together under the term "object
>> oriented" provide significant benefits in managing dependencies
>> between software components, which results in more maintainable
>> software.
>
> The only examples I've seen are from people who didn't know how to
> use procedural and databases well.
You need to get out more. ;-)
I started out after college working for a CASE tool company that
ate its own dog food by using the tool to deliver projects. It was
entirely based on E-R and dataflow modeling (Gane-Sarson,
Yourdon-DeMarco, etc.). We delivered a lot of systems on time and
within budget. Fast forward a few years and I encountered OO for the
first time in the guise of Zortech C++. Some of the techniques were
unlike what I knew, but many were logical extensions of good
procedural practices. OO was more evolutionary than revolutionary and
definitely a valuable addition to my virtual toolbox.
Most of the experienced developers I know who have proven their
ability to deliver quality software have similar backgrounds. They
understand and use the procedural and relational approach very well,
and they also have OO techniques to draw on.
>> I don't know of anyone who has used OO in a large project and
>> regretted having those tools available.
>
> I've heard mumblings of things not going so smooth. Satisfaction
> surveys by Yourdon showed no improvement.
Creating new things in the real world can be difficult. Complex
projects never go completely smoothly. In my experience and that of
other competent software developers I know, OO techniques provide
mechanisms for managing dependencies and complexity that result in
better quality software delivered more reliably.
Where have you used OO techniques and found this not to be the
case?
> Further, OOP tends to *create* large projects.
This is not my experience. Having more techniques available to
manage dependencies and complexity helps to make systems as simple as
possible. Restricting the available tools adds to the effort.
What project have you worked on where the use of OO techniques
resulted in a larger amount of effort for the same level of quality
that could have been attained more simply without them?
> Procedural/relational projects tend to break big problems into
> smaller applications that feed off of databases. The database is the
> Nile and small apps are villages on the shore. Thus, one mostly only
> has to know about the schemas and a few sanctioned library routines.
First, OO techniques permit just as much if not more functional
decomposition as procedural. OO subsumes procedural techniques.
Second, the "big central database" architecture is not
universally applicable. Even when it is possible to architect a
system that way, it does not always provide the best structure for the
solution.
>> "The only game in town" is overstating the case a bit, because
>> similar techniques can be applied in most non-OO languages and
>> functional languages, for example, offer still other approaches.
>>
>> Out of curiosity, what do you mean by "systems software?"
>
> Tool building, such as OS's, RDBMS engines, compilers, device
> drivers, network engines, etc. Polymorphism seems to have more use
> there.
I have personally seen OO techniques used successfully in domains
ranging from broadcast video to pharmaceuticals to finance to
telecommunications. These are commonly considered "business
applications." Where have you seen OO techniques fail in such
systems?
topmind
Nobody ever agrees on when to use which paradigm. Plus, mixing
gajillion paradigms can create quite a mess and confusion and
translation effort between them.
>
> >> I don't know of anyone who has used OO in a large project and
> >> regretted having those tools available.
> >
> > I've heard mumblings of things not going so smooth. Satisfaction
> > surveys by Yourdon showed no improvement.
>
> Creating new things in the real world can be difficult. Complex
> projects never go completely smoothly. In my experience and that of
> other competent software developers I know, OO techniques provide
> mechanisms for managing dependencies and complexity that result in
> better quality software delivered more reliably.
I have yet to see coded examples of it being better in my domain.
>
> Where have you used OO techniques and found this not to be the
> case?
I cannot remember specific details, but putting OO in the code did not
improve the app any way that I saw.
>
> > Further, OOP tends to *create* large projects.
>
> This is not my experience. Having more techniques available to
> manage dependencies and complexity helps to make systems as simple as
> possible. Restricting the available tools adds to the effort.
To a point, but paradigm potpourri has its own downsides, as described
above.
>
> What project have you worked on where the use of OO techniques
> resulted in a larger amount of effort for the same level of quality
> that could have been attained more simply without them?
Polymorphism is too course a granulation of variation management. I
find set theoery better and OOP does not natively support set theory.
OO's other approach to variation management, aggregation and
composition are the same kind of navigational messes that prompted Dr.
Codd to rework navigational structures. OO results in a big sea of
classes with no easy to way navigate them all. Graph-oriented query
systems to sift and study the pointer sea (navigational) thus far
stink. They sucked in the 60's and they still suck as classes/objects.
The Document Object Model is another example of an OO mess.
>
> > Procedural/relational projects tend to break big problems into
> > smaller applications that feed off of databases. The database is the
> > Nile and small apps are villages on the shore. Thus, one mostly only
> > has to know about the schemas and a few sanctioned library routines.
>
> First, OO techniques permit just as much if not more functional
> decomposition as procedural. OO subsumes procedural techniques.
They are both Turing Equivalent.
>
> Second, the "big central database" architecture is not
> universally applicable. Even when it is possible to architect a
> system that way, it does not always provide the best structure for the
> solution.
For 90%+ of all biz apps I've worked on, it was, especially if
nimble/local database engines are provided to suppliment big-iron DB's.
Ironically, chasing OO is one reason why vendors abandoned nimble/local
DB engines in tools in the 90's, setting app development back a decade.
>
> >> "The only game in town" is overstating the case a bit, because
> >> similar techniques can be applied in most non-OO languages and
> >> functional languages, for example, offer still other approaches.
> >>
> >> Out of curiosity, what do you mean by "systems software?"
> >
> > Tool building, such as OS's, RDBMS engines, compilers, device
> > drivers, network engines, etc. Polymorphism seems to have more use
> > there.
>
> I have personally seen OO techniques used successfully in domains
> ranging from broadcast video to pharmaceuticals to finance to
> telecommunications. These are commonly considered "business
> applications." Where have you seen OO techniques fail in such
> systems?
I don't think they outright fail. They are just harder to get right and
are messier than alternatives. There are no consistent, tested, and
documented rule for converting biz logic to OO, and the issue of
categorization and classification of things/objects/nouns/variations
tend to fight with RDBMS for that role. Classification of business
nouns belongs in the database IMO, not app code, and if you do that,
you take away what OO usually does.
>
> Sincerely,
>
> Patrick
>
-T-
Patrick May
I was responding to your statement that people who find benefits
in OO techniques don't understand procedural and relational
techniques. That's not at all the case.
> Plus, mixing gajillion paradigms can create quite a mess and
> confusion and translation effort between them.
The nice thing about software development is that it gives us so
many ways to cause ourselves problems. Your objection is just as
valid within a "single paradigm" as a "multi paradigm" environment.
I used the scare quotes because the term "paradigm" is overused
and emphasizes the differences between two somewhat arbitrary sets of
techniques at the expense of the similarities. OO is a superset of
procedural. It may be difficult to use an OO style interface from
some procedural languages, but the reverse is not often the case.
The solution to some problems is expressed better declaratively
than procedurally, others better in an OO style than declaratively,
still others better functionally than object orientedly (to coin an
inelegant phrase). Simply knowing these approaches allows one to see
more solutions. Having all of these techniques available is what
distinguishes a master developer from an apprentice.
>> >> I don't know of anyone who has used OO in a large project and
>> >> regretted having those tools available.
>> >
>> > I've heard mumblings of things not going so smooth. Satisfaction
>> > surveys by Yourdon showed no improvement.
>>
>> Creating new things in the real world can be difficult.
>> Complex projects never go completely smoothly. In my experience
>> and that of other competent software developers I know, OO
>> techniques provide mechanisms for managing dependencies and
>> complexity that result in better quality software delivered more
>> reliably.
>
> I have yet to see coded examples of it being better in my domain.
What industry do you specialize in? What kinds of projects? I
can't imagine a situation where having fewer options would be
preferable.
>> Where have you used OO techniques and found this not to be the
>> case?
>
> I cannot remember specific details, but putting OO in the code did
> not improve the app any way that I saw.
Your statements contradict my experience and that of many people
I've worked with. I'd like to understand where OO techniques have
failed to add value for other people and why that was the case. Any
specifics you can provide would help.
>> > Further, OOP tends to *create* large projects.
>>
>> This is not my experience. Having more techniques available
>> to manage dependencies and complexity helps to make systems as
>> simple as possible. Restricting the available tools adds to the
>> effort.
>
> To a point, but paradigm potpourri has its own downsides, as
> described above.
Again, I haven't found this to be the case in general. I've been
using service oriented architectures (SOAs) over the past few years.
One of the advantages of SOA is that the implementation of each
service can use the most appropriate technology.
>> What project have you worked on where the use of OO techniques
>> resulted in a larger amount of effort for the same level of quality
>> that could have been attained more simply without them?
>
> Polymorphism is too course a granulation of variation management.
But where, specifically, have you used OO techniques and found
that it resulted in a greater amount of effort for the same functional
and non-functional capabilities that could have been more easily
delivered using only procedural and relational techniques?
>> > Procedural/relational projects tend to break big problems into
>> > smaller applications that feed off of databases. The database is
>> > the Nile and small apps are villages on the shore. Thus, one
>> > mostly only has to know about the schemas and a few sanctioned
>> > library routines.
>>
>> First, OO techniques permit just as much if not more
>> functional decomposition as procedural. OO subsumes procedural
>> techniques.
>
> They are both Turing Equivalent.
So is INTERCAL, at least in theory. Turing equivalence is
meaningless in practice -- what's important is expressiveness. Having
more tools in the virtual toolbox allows for greater expressiveness.
>> Second, the "big central database" architecture is not
>> universally applicable. Even when it is possible to architect a
>> system that way, it does not always provide the best structure for
>> the solution.
>
> For 90%+ of all biz apps I've worked on, it was, especially if
> nimble/local database engines are provided to suppliment big-iron
> DB's.
This doesn't correspond with my experience, nor with that of many
people I've worked with. What details can you provide about your last
three or four projects without violating any NDAs?
The most obvious case in which the centralized database
architecture cannot work is when a system must interact with an
external system. A vendor will send flat files and may even provide a
Web Service, but none will share a database.
Another example comes from telecommunications. Even a small
network operator will have a wide variety of systems including
billing, rating, CRM, MRP/ERP, provisioning, network management, OMS,
and MIS. Some of these systems will have been developed in house
while others are off-the-shelf packages. Numerous business processes
will require solutions that coordinate functionality from multiple
components, none of which share a database.
Yet another example comes from finance. Clearing and settlement
of trades requires matching (within fuzzy ranges), ordering (based on
multiple, sometimes conflicting priorities), provisioning, automatic
and manual loan generation, settlement, and synchronization with other
clearinghouses. There isn't a machine big enough to run a single
database that can support all this activity.
Speaking of performance, another reason to discount the
centralized database architecture is that it can't always meet the
NFRs. The database becomes a single point of failure, but there is no
reason for most companies to stop accepting orders, for example, just
because one of the backend systems is down. Hardware cost is another
significant issue -- it can be much cheaper to develop, deploy, and
operate a distributed system running on blades than the same
functionality on an F15k.
The last project I can remember where I used a single centralized
database was to build a system to support clinical trials of new drugs
on humans. The functionality wasn't too complex, but the FDA
requirements were amazingly rigorous (which is to be expected when one
of the "adverse events" being tracked is "death"). At its core, it
was a CRUD system
I'd be interested in hearing about additional systems where this
architecture has proven useful.
>> >> "The only game in town" is overstating the case a bit, because
>> >> similar techniques can be applied in most non-OO languages and
>> >> functional languages, for example, offer still other approaches.
>> >>
>> >> Out of curiosity, what do you mean by "systems software?"
>> >
>> > Tool building, such as OS's, RDBMS engines, compilers, device
>> > drivers, network engines, etc. Polymorphism seems to have more use
>> > there.
>>
>> I have personally seen OO techniques used successfully in
>> domains ranging from broadcast video to pharmaceuticals to finance
>> to telecommunications. These are commonly considered "business
>> applications." Where have you seen OO techniques fail in such
>> systems?
>
> I don't think they outright fail. They are just harder to get right
> and are messier than alternatives.
How are they messier? What alternatives? What problem domains?
> There are no consistent, tested, and documented rule for converting
> biz logic to OO
OO isn't unique in this regard. If there were rules for
converting business logic into code, I'd automate it. Where possible,
I do. The implementation techniques are a separate issue.
> Classification of business nouns belongs in the database IMO, not
> app code, and if you do that, you take away what OO usually does.
I don't understand your point here. Could you please provide an
example from an actual project where the use of OO techniques was
inferior to the use of relational techniques by a particular metric?
Barkster
topmind
It is what I encounter.
>
> > Plus, mixing gajillion paradigms can create quite a mess and
> > confusion and translation effort between them.
>
> The nice thing about software development is that it gives us so
> many ways to cause ourselves problems. Your objection is just as
> valid within a "single paradigm" as a "multi paradigm" environment.
I am not sure what you mean. Additional tools that add only marginal
improvements are often not worth it. Only add additional tools/layers
if it adds *significant* improvement. It makes staffing more difficult
for managers also. Perhaps as developers we don't care because staffing
is not our concern, but affects the bottom line.
>
> I used the scare quotes because the term "paradigm" is overused
> and emphasizes the differences between two somewhat arbitrary sets of
> techniques at the expense of the similarities. OO is a superset of
> procedural. It may be difficult to use an OO style interface from
> some procedural languages, but the reverse is not often the case.
>
> The solution to some problems is expressed better declaratively
> than procedurally, others better in an OO style than declaratively,
> still others better functionally than object orientedly (to coin an
> inelegant phrase). Simply knowing these approaches allows one to see
> more solutions. Having all of these techniques available is what
> distinguishes a master developer from an apprentice.
Or somebody who wants to pad their resume with buzzwords.
> >> Where have you used OO techniques and found this not to be the
> >> case?
> >
> > I cannot remember specific details, but putting OO in the code did
> > not improve the app any way that I saw.
>
> Your statements contradict my experience and that of many people
> I've worked with. I'd like to understand where OO techniques have
> failed to add value for other people and why that was the case. Any
> specifics you can provide would help.
I have not seen code where it has clearly *added* value, outside of
systems software.
>
> >> > Further, OOP tends to *create* large projects.
> >>
> >> This is not my experience. Having more techniques available
> >> to manage dependencies and complexity helps to make systems as
> >> simple as possible. Restricting the available tools adds to the
> >> effort.
> >
> > To a point, but paradigm potpourri has its own downsides, as
> > described above.
>
> Again, I haven't found this to be the case in general. I've been
> using service oriented architectures (SOAs) over the past few years.
> One of the advantages of SOA is that the implementation of each
> service can use the most appropriate technology.
>
> >> What project have you worked on where the use of OO techniques
> >> resulted in a larger amount of effort for the same level of quality
> >> that could have been attained more simply without them?
> >
> > Polymorphism is too course a granulation of variation management.
>
> But where, specifically, have you used OO techniques and found
> that it resulted in a greater amount of effort for the same functional
> and non-functional capabilities that could have been more easily
> delivered using only procedural and relational techniques?
http://www.geocities.com/tablizer/struc.htm
> >> Second, the "big central database" architecture is not
> >> universally applicable. Even when it is possible to architect a
> >> system that way, it does not always provide the best structure for
> >> the solution.
> >
> > For 90%+ of all biz apps I've worked on, it was, especially if
> > nimble/local database engines are provided to suppliment big-iron
> > DB's.
>
> This doesn't correspond with my experience, nor with that of many
> people I've worked with. What details can you provide about your last
> three or four projects without violating any NDAs?
Not really. It's proprietary.
>
> The most obvious case in which the centralized database
> architecture cannot work is when a system must interact with an
> external system. A vendor will send flat files and may even provide a
> Web Service, but none will share a database.
Well, if they make tools that only use communication protocol X, that
is not the fault of the paradigm/technique itself. But web services and
flat files are merely transfer mechanisms. One could transfer stuff to
and from a database also using those.
>
> Another example comes from telecommunications. Even a small
> network operator will have a wide variety of systems including
> billing, rating, CRM, MRP/ERP, provisioning, network management, OMS,
> and MIS. Some of these systems will have been developed in house
> while others are off-the-shelf packages. Numerous business processes
> will require solutions that coordinate functionality from multiple
> components, none of which share a database.
>
> Yet another example comes from finance. Clearing and settlement
> of trades requires matching (within fuzzy ranges), ordering (based on
> multiple, sometimes conflicting priorities), provisioning, automatic
> and manual loan generation, settlement, and synchronization with other
> clearinghouses. There isn't a machine big enough to run a single
> database that can support all this activity.
I cannot verify such scaling issues here, but if you need multiple DB's
for hardware reasons then so be it. One may have to divide no matter
what technique is being used in some cases.
>
> Speaking of performance, another reason to discount the
> centralized database architecture is that it can't always meet the
> NFRs. The database becomes a single point of failure, but there is no
> reason for most companies to stop accepting orders, for example, just
> because one of the backend systems is down.
High-end Oracle servers have all kinds of fail-safe gizmos such as
mirroring and parellel updates if you have the money. But if you need
to split and decentralize for whatever reason, then so be it. However,
it just may result in lots of smaller failures rather than a few big
ones.
> Hardware cost is another
> significant issue -- it can be much cheaper to develop, deploy, and
> operate a distributed system running on blades than the same
> functionality on an F15k.
Are you saying that RDBMS are too expensive? There are a wide variety
of options both commercial and open-source, and RDBMS is a fairly
mature (road tested) technology compared to the alternatives.
>
> The last project I can remember where I used a single centralized
> database was to build a system to support clinical trials of new drugs
> on humans. The functionality wasn't too complex, but the FDA
> requirements were amazingly rigorous (which is to be expected when one
> of the "adverse events" being tracked is "death"). At its core, it
> was a CRUD system
It is hard to beat the A.C.I.D. features of RDBMS when losing or
curruption info is a no no. What alternative to ACID do you have in
mind?
>
> I'd be interested in hearing about additional systems where this
> architecture has proven useful.
>
> >> >> "The only game in town" is overstating the case a bit, because
> >> >> similar techniques can be applied in most non-OO languages and
> >> >> functional languages, for example, offer still other approaches.
> >> >>
> >> >> Out of curiosity, what do you mean by "systems software?"
> >> >
> >> > Tool building, such as OS's, RDBMS engines, compilers, device
> >> > drivers, network engines, etc. Polymorphism seems to have more use
> >> > there.
> >>
> >> I have personally seen OO techniques used successfully in
> >> domains ranging from broadcast video to pharmaceuticals to finance
> >> to telecommunications. These are commonly considered "business
> >> applications." Where have you seen OO techniques fail in such
> >> systems?
> >
> > I don't think they outright fail. They are just harder to get right
> > and are messier than alternatives.
>
> How are they messier? What alternatives? What problem domains?
>
> > There are no consistent, tested, and documented rule for converting
> > biz logic to OO
>
> OO isn't unique in this regard. If there were rules for
> converting business logic into code, I'd automate it. Where possible,
> I do. The implementation techniques are a separate issue.
I see far more variations or potential variations in OO designs than
procedural/relational ones. Relational normalization rules tend to
narrow the potential "creativity". Navigational (OOP) has no documented
equivalent. There are too many ways to do the same thing, and this
makes it harder to learn and absorb a newly-encountered set of
software.
Decent procedural usually breaks the problem down to a bunch of smaller
tasks or events that feed off the DB. One can even use the DB to track,
study, and report on the tasks/events. The "big picture" is usually
found in the schema's, NOT the program code. Again, it is like a bunch
of small shore villages that live off the Nile (RDBMS). I just see a
tangled web in OO with no easy way to query the web to study it. A
bunch of pasta is dumped on one's desk.
>
> Patrick
>
-T-
Patrick May
> Patrick May wrote:
>> I was responding to your statement that people who find
>> benefits in OO techniques don't understand procedural and
>> relational techniques. That's not at all the case.
>
> It is what I encounter.
Just to be clear, are you stating that everyone who finds some
benefits in OO techniques does not understand procedural and
relational techniques?
>> > Plus, mixing gajillion paradigms can create quite a mess and
>> > confusion and translation effort between them.
>>
>> The nice thing about software development is that it gives us
>> so many ways to cause ourselves problems. Your objection is just
>> as valid within a "single paradigm" as a "multi paradigm"
>> environment.
>
> I am not sure what you mean.
Software development "paradigms" have fuzzy boundaries. Talking
about mixing them implies that they are discrete, when in fact they
are pre-mixed to some degree. One of the reasons I prefer C++ to Java
(Heretic! Burn him!) in some cases is that it supports OO,
procedural, and generic programming simultaneously.
What causes confusion isn't mixing paradigms but inconsistent use
of the available techniques. This can and does compromise
maintainability and extensibility. The answer is project standards,
not tool restrictions.
> Additional tools that add only marginal improvements are often not
> worth it. Only add additional tools/layers if it adds *significant*
> improvement.
In my experience and the experience of other developers I've
worked with, the dependency management benefits of using OO techniques
provide real value and are no more difficult to use than procedural
techniques. In fact, OO languages express and support certain
techniques directly that must be implemented by developers using
procedural languages.
What environments have you worked in where OO was demonstrated
not to provide value? What languages were used? What techniques were
tried?
> It makes staffing more difficult for managers also. Perhaps as
> developers we don't care because staffing is not our concern, but
> affects the bottom line.
I do a fair bit of interviewing and hiring. One of the first
questions I ask is "What languages other than Java do you know well?"
Another couple are "What are the disadvantages of your favorite
language?" and "What are the advantages of your least favorite
language?" If someone interviewing for a senior developer or
technical architect role isn't familiar with several different
paradigms and a half-dozen languages from across the spectrum, they
are unlikely to be the type of person I'm looking for. A team of
developers who are enthusiastic about technology and capable of
providing multiple perspectives on the solution to a problem are what
will really affect the bottom line -- positively.
>> The solution to some problems is expressed better
>> declaratively than procedurally, others better in an OO style than
>> declaratively, still others better functionally than object
>> orientedly (to coin an inelegant phrase). Simply knowing these
>> approaches allows one to see more solutions. Having all of these
>> techniques available is what distinguishes a master developer from
>> an apprentice.
>
> Or somebody who wants to pad their resume with buzzwords.
That's uncharitable to the point of bitterness. Certainly there
are some people who hop from project to project in order to pad their
resume. I'm referring to people who actually understand and can apply
those techniques. Eric S. Raymond put it very well:
Lisp is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make
you a better programmer for the rest of your days, even if you
never actually use Lisp itself a lot.
The same applies (to a lesser degree ;-) to learning any new
development techniques. Even if you don't use them, knowing them will
change the way you think about solving problems.
>> >> Where have you used OO techniques and found this not to be
>> >> the case?
>> >
>> > I cannot remember specific details, but putting OO in the code did
>> > not improve the app any way that I saw.
>>
>> Your statements contradict my experience and that of many
>> people I've worked with. I'd like to understand where OO
>> techniques have failed to add value for other people and why that
>> was the case. Any specifics you can provide would help.
>
> I have not seen code where it has clearly *added* value, outside of
> systems software.
Where, specifically, have you used OO techniques and found no
additional value? What techniques were you using? What languages?
What were your metrics for measuring value?
>> >> What project have you worked on where the use of OO
>> >> techniques resulted in a larger amount of effort for the same
>> >> level of quality that could have been attained more simply
>> >> without them?
>> >
>> > Polymorphism is too course a granulation of variation management.
>>
>> But where, specifically, have you used OO techniques and found
>> that it resulted in a greater amount of effort for the same
>> functional and non-functional capabilities that could have been
>> more easily delivered using only procedural and relational
>> techniques?
>
> http://www.geocities.com/tablizer/struc.htm
Is that an example from an actual project or simply one you
contrived for your website? If it is from an actual project, what
was the OO design that was proposed instead? If it isn't from an
actual project, under what circumstances have you used OO techniques
and found that they required a greater amount of effort to meet the
same functional and non-functional requirements that could be more
easily delivered via procedural and relational techniques?
>> >> Second, the "big central database" architecture is not
>> >> universally applicable. Even when it is possible to architect a
>> >> system that way, it does not always provide the best structure
>> >> for the solution.
>> >
>> > For 90%+ of all biz apps I've worked on, it was, especially if
>> > nimble/local database engines are provided to suppliment big-iron
>> > DB's.
>>
>> This doesn't correspond with my experience, nor with that of many
>> people I've worked with. What details can you provide about your last
>> three or four projects without violating any NDAs?
>
> Not really. It's proprietary.
Fair enough. Surely, though, you could describe the general
domain, the languages used, and the alternative architectures you
considered?
>> The most obvious case in which the centralized database
>> architecture cannot work is when a system must interact with an
>> external system. A vendor will send flat files and may even
>> provide a Web Service, but none will share a database.
>
> Well, if they make tools that only use communication protocol X,
> that is not the fault of the paradigm/technique itself. But web
> services and flat files are merely transfer mechanisms. One could
> transfer stuff to and from a database also using those.
The point is that the centralized database architecture is not
appropriate for all, or even most, large systems.
>> Another example comes from telecommunications. Even a small
>> network operator will have a wide variety of systems including
>> billing, rating, CRM, MRP/ERP, provisioning, network management,
>> OMS, and MIS. Some of these systems will have been developed in
>> house while others are off-the-shelf packages. Numerous business
>> processes will require solutions that coordinate functionality from
>> multiple components, none of which share a database.
>>
>> Yet another example comes from finance. Clearing and
>> settlement of trades requires matching (within fuzzy ranges),
>> ordering (based on multiple, sometimes conflicting priorities),
>> provisioning, automatic and manual loan generation, settlement, and
>> synchronization with other clearinghouses. There isn't a machine
>> big enough to run a single database that can support all this
>> activity.
>
> I cannot verify such scaling issues here, but if you need multiple
> DB's for hardware reasons then so be it. One may have to divide no
> matter what technique is being used in some cases.
Exactly. So the centralized database architecture you prefer is
not applicable in many problem domains.
>> Speaking of performance, another reason to discount the
>> centralized database architecture is that it can't always meet the
>> NFRs. The database becomes a single point of failure, but there is
>> no reason for most companies to stop accepting orders, for example,
>> just because one of the backend systems is down.
>
> High-end Oracle servers have all kinds of fail-safe gizmos such as
> mirroring and parellel updates if you have the money.
Yes, but part of defining an architecture is taking the hardware
costs into consideration. There may not be a business case for a
project that requires purchasing an F15k (even the individual boards
are several hundred thousand dollars), but the same functionality
running on a rack of T2000s might provide real, measurable business
value.
We need to use tools and techniques that let us provide that
value.
> But if you need to split and decentralize for whatever reason, then
> so be it. However, it just may result in lots of smaller failures
> rather than a few big ones.
That's an advantage. On Wednesday night, one of my clients had a
failure of their MRP/ERP system. The overall system was architected
such that the OMS could keep taking orders even if all backend systems
were down. When the MRP/ERP system came online on Thursday, all of
those orders went through. That means real money that would otherwise
have been lost.
>> Hardware cost is another significant issue -- it can be much
>> cheaper to develop, deploy, and operate a distributed system
>> running on blades than the same functionality on an F15k.
>
> Are you saying that RDBMS are too expensive? There are a wide
> variety of options both commercial and open-source, and RDBMS is a
> fairly mature (road tested) technology compared to the alternatives.
I'm saying that big iron is expensive, so alternatives to the
centralized database architecture are necessary.
>> The last project I can remember where I used a single
>> centralized database was to build a system to support clinical
>> trials of new drugs on humans. The functionality wasn't too
>> complex, but the FDA requirements were amazingly rigorous (which is
>> to be expected when one of the "adverse events" being tracked is
>> "death"). At its core, it was a CRUD system
>
> It is hard to beat the A.C.I.D. features of RDBMS when losing or
> curruption info is a no no. What alternative to ACID do you have in
> mind?
None whatsoever, whatever gave you that idea? Distributed
systems have guaranteed points of delivery and other mechanisms for
meeting the NFRs of resiliency, scalability, and transactional
integrity. A centralized database architecture isn't the only way to
meet those.
>> >> I have personally seen OO techniques used successfully in
>> >> domains ranging from broadcast video to pharmaceuticals to
>> >> finance to telecommunications. These are commonly considered
>> >> "business applications." Where have you seen OO techniques fail
>> >> in such systems?
>> >
>> > I don't think they outright fail. They are just harder to get
>> > right and are messier than alternatives.
>>
>> How are they messier? What alternatives? What problem
>> domains?
You skipped these questions. Your statements are not consistent
with my experience nor that of many developers I work with. I'm
interested in understanding how you came to hold those views.
>> > There are no consistent, tested, and documented rule for
>> > converting biz logic to OO
>>
>> OO isn't unique in this regard. If there were rules for
>> converting business logic into code, I'd automate it. Where
>> possible, I do. The implementation techniques are a separate
>> issue.
>
> I see far more variations or potential variations in OO designs than
> procedural/relational ones.
I'm not sure what you mean by this. Are you suggesting that the
greater expressiveness of language that supports both OO and
procedural techniques is a disadvantage?
> Relational normalization rules tend to narrow the potential
> "creativity".
Database schemas used in systems that implement behavior using OO
techniques are typically normalized (modulo performance hacks and
legacy issues). Relational techniques are another tool in the virtual
toolbox.
> Decent procedural usually breaks the problem down to a bunch of
> smaller tasks or events that feed off the DB.
You've said this before, but it ignores the facts that OO
techniques are equally if not more capable of decomposing problems and
the centralized database architecture is not universally applicable.
> I just see a tangled web in OO with no easy way to query the web to
> study it. A bunch of pasta is dumped on one's desk.
This may be getting to the core of our different experiences.
How many projects have you seen this happen on? What OO languages
have you used on those projects? What design methodology? What
problem domains? How, specifically, did the use of OO techniques
cause actual problems?
topmind
> "topmind" <top...@technologist.com> writes:
> > Patrick May wrote:
> >> I was responding to your statement that people who find
> >> benefits in OO techniques don't understand procedural and
> >> relational techniques. That's not at all the case.
> >
> > It is what I encounter.
>
> Just to be clear, are you stating that everyone who finds some
> benefits in OO techniques does not understand procedural and
> relational techniques?
No. I am only stating my experience. Anecdotes are all any of us have
so far.
>
> >> > Plus, mixing gajillion paradigms can create quite a mess and
> >> > confusion and translation effort between them.
> >>
> >> The nice thing about software development is that it gives us
> >> so many ways to cause ourselves problems. Your objection is just
> >> as valid within a "single paradigm" as a "multi paradigm"
> >> environment.
> >
> > I am not sure what you mean.
>
> Software development "paradigms" have fuzzy boundaries. Talking
> about mixing them implies that they are discrete, when in fact they
> are pre-mixed to some degree. One of the reasons I prefer C++ to Java
> (Heretic! Burn him!) in some cases is that it supports OO,
> procedural, and generic programming simultaneously.
>
> What causes confusion isn't mixing paradigms but inconsistent use
> of the available techniques. This can and does compromise
> maintainability and extensibility. The answer is project standards,
> not tool restrictions.
Yet more techniques/paradigms is not going to help the consistency
situation. It produces more different ways to solve the same problem.
>
> > Additional tools that add only marginal improvements are often not
> > worth it. Only add additional tools/layers if it adds *significant*
> > improvement.
>
> In my experience and the experience of other developers I've
> worked with, the dependency management benefits of using OO techniques
> provide real value and are no more difficult to use than procedural
> techniques. In fact, OO languages express and support certain
> techniques directly that must be implemented by developers using
> procedural languages.
A practical business example?
>
> What environments have you worked in where OO was demonstrated
> not to provide value? What languages were used? What techniques were
> tried?
I would have to give too much background of the domain first. I'm not
even sure I remember enough of it. I'll think about it to see if I can
find a compact way to describe such.
But the problem is that they didn't add any known improvement. It's a
class, but so what. What is it supposed to help? Future changes? I
don't think so. I could anticipate fairly likely realistic changes that
would have kicked the class in the gonads.
They just stood there being classes.
On the flip side, can you offer an example class/object that was
clearly better than the procedural/relational alternative and is not a
language-specific fault?
>
> > It makes staffing more difficult for managers also. Perhaps as
> > developers we don't care because staffing is not our concern, but
> > affects the bottom line.
>
> I do a fair bit of interviewing and hiring. One of the first
> questions I ask is "What languages other than Java do you know well?"
> Another couple are "What are the disadvantages of your favorite
> language?" and "What are the advantages of your least favorite
> language?" If someone interviewing for a senior developer or
> technical architect role isn't familiar with several different
> paradigms and a half-dozen languages from across the spectrum, they
> are unlikely to be the type of person I'm looking for. A team of
> developers who are enthusiastic about technology and capable of
> providing multiple perspectives on the solution to a problem are what
> will really affect the bottom line -- positively.
Providing multiple perspectives is good, but even better is describing
*why* it is better. Making a class instead of a procedural module is
offering multiple perspectives, but of limited use of one cannot show
clearly why it is better.
(I don't claim my techniques are always objectively better, just not
objectively worse. A lot of it is fitting a person's pscychology.)
>
> >> The solution to some problems is expressed better
> >> declaratively than procedurally, others better in an OO style than
> >> declaratively, still others better functionally than object
> >> orientedly (to coin an inelegant phrase). Simply knowing these
> >> approaches allows one to see more solutions. Having all of these
> >> techniques available is what distinguishes a master developer from
> >> an apprentice.
> >
> > Or somebody who wants to pad their resume with buzzwords.
>
> That's uncharitable to the point of bitterness. Certainly there
> are some people who hop from project to project in order to pad their
> resume. I'm referring to people who actually understand and can apply
> those techniques. Eric S. Raymond put it very well:
>
> Lisp is worth learning for the profound enlightenment experience
> you will have when you finally get it; that experience will make
> you a better programmer for the rest of your days, even if you
> never actually use Lisp itself a lot.
Agreed, but some "experiment on the job" excessively. I did not accuse
you or all OO'ers of that, but only saying it happens fairly often and
that one has to be careful. One should expand their mind outside of
production projects. Develop a demo first, for example, and get
feedback on it. Don't try a transharmonic multidimensional inverted
visitor pattern for the first time on something due in 3 weeks.
>
> The same applies (to a lesser degree ;-) to learning any new
> development techniques. Even if you don't use them, knowing them will
> change the way you think about solving problems.
>
> >> >> Where have you used OO techniques and found this not to be
> >> >> the case?
> >> >
> >> > I cannot remember specific details, but putting OO in the code did
> >> > not improve the app any way that I saw.
> >>
> >> Your statements contradict my experience and that of many
> >> people I've worked with. I'd like to understand where OO
> >> techniques have failed to add value for other people and why that
> >> was the case. Any specifics you can provide would help.
> >
> > I have not seen code where it has clearly *added* value, outside of
> > systems software.
>
> Where, specifically, have you used OO techniques and found no
> additional value? What techniques were you using? What languages?
> What were your metrics for measuring value?
Some of this was already discussed above. As far as what metric, this
is another contentious area. Nobody even agrees on what metric OO does
better on. Reuse was the big claim early on, but it is dying out. The
newer claims are more elusive and subjective, including "coupling and
cohesion". I've tried to get others to form objective C&C metrics
without success.
>
> >> >> What project have you worked on where the use of OO
> >> >> techniques resulted in a larger amount of effort for the same
> >> >> level of quality that could have been attained more simply
> >> >> without them?
> >> >
> >> > Polymorphism is too course a granulation of variation management.
> >>
> >> But where, specifically, have you used OO techniques and found
> >> that it resulted in a greater amount of effort for the same
> >> functional and non-functional capabilities that could have been
> >> more easily delivered using only procedural and relational
> >> techniques?
> >
> > http://www.geocities.com/tablizer/struc.htm
>
> Is that an example from an actual project or simply one you
> contrived for your website? If it is from an actual project, what
> was the OO design that was proposed instead? If it isn't from an
> actual project, under what circumstances have you used OO techniques
> and found that they required a greater amount of effort to meet the
> same functional and non-functional requirements that could be more
> easily delivered via procedural and relational techniques?
It is based on textbook OO examples. Could you present a case that an
OO approach would be superior for that given example?
>
> >> The most obvious case in which the centralized database
> >> architecture cannot work is when a system must interact with an
> >> external system. A vendor will send flat files and may even
> >> provide a Web Service, but none will share a database.
> >
> > Well, if they make tools that only use communication protocol X,
> > that is not the fault of the paradigm/technique itself. But web
> > services and flat files are merely transfer mechanisms. One could
> > transfer stuff to and from a database also using those.
>
> The point is that the centralized database architecture is not
> appropriate for all, or even most, large systems.
I don't see how something like say an airline reservation system could
be built without one. How do you keep one customer in NY and another in
Calif from booking the same seat number on the same flight if they
called at the same time, for example?
>
> >> Another example comes from telecommunications. Even a small
> >> network operator will have a wide variety of systems including
> >> billing, rating, CRM, MRP/ERP, provisioning, network management,
> >> OMS, and MIS. Some of these systems will have been developed in
> >> house while others are off-the-shelf packages. Numerous business
> >> processes will require solutions that coordinate functionality from
> >> multiple components, none of which share a database.
> >>
> >> Yet another example comes from finance. Clearing and
> >> settlement of trades requires matching (within fuzzy ranges),
> >> ordering (based on multiple, sometimes conflicting priorities),
> >> provisioning, automatic and manual loan generation, settlement, and
> >> synchronization with other clearinghouses. There isn't a machine
> >> big enough to run a single database that can support all this
> >> activity.
> >
> > I cannot verify such scaling issues here, but if you need multiple
> > DB's for hardware reasons then so be it. One may have to divide no
> > matter what technique is being used in some cases.
>
> Exactly. So the centralized database architecture you prefer is
> not applicable in many problem domains.
Is the issue here databases or centralization? Most places use a
combination. Some transactions need heavy coordination to prevent
duplicates, etc. Centralized A.C.I.D. is just about the only realistic
way to provide such. Other tasks, such as customer buying pattern
research, can be done with replicated (distributed) data (unless we
want same-day feedback).
>
> >> Speaking of performance, another reason to discount the
> >> centralized database architecture is that it can't always meet the
> >> NFRs. The database becomes a single point of failure, but there is
> >> no reason for most companies to stop accepting orders, for example,
> >> just because one of the backend systems is down.
> >
> > High-end Oracle servers have all kinds of fail-safe gizmos such as
> > mirroring and parellel updates if you have the money.
>
> Yes, but part of defining an architecture is taking the hardware
> costs into consideration. There may not be a business case for a
> project that requires purchasing an F15k (even the individual boards
> are several hundred thousand dollars), but the same functionality
> running on a rack of T2000s might provide real, measurable business
> value.
>
> We need to use tools and techniques that let us provide that
> value.
With large, critical projects, software maintenance costs are usually
far more than hardware costs. Lack of ACID and data integrity can run
up huge labor bills.
>
> > But if you need to split and decentralize for whatever reason, then
> > so be it. However, it just may result in lots of smaller failures
> > rather than a few big ones.
>
> That's an advantage. On Wednesday night, one of my clients had a
> failure of their MRP/ERP system. The overall system was architected
> such that the OMS could keep taking orders even if all backend systems
> were down. When the MRP/ERP system came online on Thursday, all of
> those orders went through. That means real money that would otherwise
> have been lost.
Some portions can indeed be decentralized. Sales at given stores, for
example, is generally a decentralized operation. Stores generally don't
need to coordinate info between each other in real time. Each store
might have its own DB. But not all domains or operations are like this.
>
> >> Hardware cost is another significant issue -- it can be much
> >> cheaper to develop, deploy, and operate a distributed system
> >> running on blades than the same functionality on an F15k.
> >
> > Are you saying that RDBMS are too expensive? There are a wide
> > variety of options both commercial and open-source, and RDBMS is a
> > fairly mature (road tested) technology compared to the alternatives.
>
> I'm saying that big iron is expensive, so alternatives to the
> centralized database architecture are necessary.
Again, the cost bottleneck is usually software, not hardware.
>
> >> The last project I can remember where I used a single
> >> centralized database was to build a system to support clinical
> >> trials of new drugs on humans. The functionality wasn't too
> >> complex, but the FDA requirements were amazingly rigorous (which is
> >> to be expected when one of the "adverse events" being tracked is
> >> "death"). At its core, it was a CRUD system
> >
> > It is hard to beat the A.C.I.D. features of RDBMS when losing or
> > curruption info is a no no. What alternative to ACID do you have in
> > mind?
>
> None whatsoever, whatever gave you that idea? Distributed
> systems have guaranteed points of delivery and other mechanisms for
> meeting the NFRs of resiliency, scalability, and transactional
> integrity. A centralized database architecture isn't the only way to
> meet those.
Coordinating after-the-fact asynchronous info can be sticky. At this
point I am a skeptic.
> >> > There are no consistent, tested, and documented rule for
> >> > converting biz logic to OO
> >>
> >> OO isn't unique in this regard. If there were rules for
> >> converting business logic into code, I'd automate it. Where
> >> possible, I do. The implementation techniques are a separate
> >> issue.
> >
> > I see far more variations or potential variations in OO designs than
> > procedural/relational ones.
>
> I'm not sure what you mean by this. Are you suggesting that the
> greater expressiveness of language that supports both OO and
> procedural techniques is a disadvantage?
Perhaps another way to say this is that OO "lacks standards" in an
informal sense. Everybody is their own software Picasso. OO designs
often remind me of a shanty town. RDBMS normalization rules and the
task-oriented nature of procedural modules/events tend to produce
somewhat similar looking designs such that there are fewer surprises.
One should not abandon consistency unless the rewards are large. OO
does not offer enough.
> > Decent procedural usually breaks the problem down to a bunch of
> > smaller tasks or events that feed off the DB.
>
> You've said this before, but it ignores the facts that OO
> techniques are equally if not more capable of decomposing problems
Please show me the code of OO being better.
> and
> the centralized database architecture is not universally applicable.
Perhaps not, but for the most part it is highly applicable to custom
biz apps. I've already agreed that other domains or special needs may
favor different paradigms/tools/techniques.
>
> Sincerely,
>
> Patrick
>
-T-
Patrick May
>> >> I was responding to your statement that people who find
>> >> benefits in OO techniques don't understand procedural and
>> >> relational techniques. That's not at all the case.
>> >
>> > It is what I encounter.
>>
>> Just to be clear, are you stating that everyone who finds some
>> benefits in OO techniques does not understand procedural and
>> relational techniques?
>
> No. I am only stating my experience.
So you have never encountered a single developer who understands
procedural and relational programming but still finds value in OO
techniques? Not one?
> Anecdotes are all any of us have so far.
In this forum, in the absence of shared experience, we are indeed
limited to descriptions of our experience and occasional references to
often limited documentation of projects. That's why I'm asking
questions of you -- your statements regarding OO are strongly at
variance with my experience and that of developers I have worked
with.
>> What environments have you worked in where OO was demonstrated
>> not to provide value? What languages were used? What techniques
>> were tried?
>
> I would have to give too much background of the domain first. I'm
> not even sure I remember enough of it. I'll think about it to see
> if I can find a compact way to describe such.
Start simple. How long ago was it? What was the general domain?
What languages were used? What specific problems did you encounter?
From your description, it sounds like you've only used OO on one
project. Is this the only OO project you've ever worked on? If not,
in what other domains have you applied OO technology? What specific
problems did you encounter there?
> But the problem is that they didn't add any known improvement. It's
> a class, but so what. What is it supposed to help? Future changes? I
> don't think so. I could anticipate fairly likely realistic changes
> that would have kicked the class in the gonads.
>
> They just stood there being classes.
Again, this suggests that you've only been exposed to OO
techniques on one project. Is that the case? It also suggests that
the design wasn't particularly behavior driven. What design
methodology was used?
>> Where, specifically, have you used OO techniques and found no
>> additional value? What techniques were you using? What languages?
>> What were your metrics for measuring value?
>
> Some of this was already discussed above. As far as what metric,
> this is another contentious area. Nobody even agrees on what metric
> OO does better on.
Well, you said that OO techniques didn't add value. What metric
were you using in that statement?
>> > http://www.geocities.com/tablizer/struc.htm
>>
>> Is that an example from an actual project or simply one you
>> contrived for your website? If it is from an actual project, what
>> was the OO design that was proposed instead? If it isn't from an
>> actual project, under what circumstances have you used OO
>> techniques and found that they required a greater amount of effort
>> to meet the same functional and non-functional requirements that
>> could be more easily delivered via procedural and relational
>> techniques?
>
> It is based on textbook OO examples.
Textbook examples are of necessity limited and aimed at
demonstrating one or a few particular points. Your statements
indicate that you have seen the use of OO techniques fail to deliver
value in a production development. Under what circumstances have you
used OO techniques and found that they required a greater amount of
effort to meet the same functional and non-functional requirements
that could be more easily delivered via procedural and relational
techniques?
>> I'm saying that big iron is expensive, so alternatives to the
>> centralized database architecture are necessary.
>
> Again, the cost bottleneck is usually software, not hardware.
That also does not correspond to my experience, but it is a side
issue so I'm not going to go further into it.
I'd like to understand the basis for the differences in our
viewpoints. Perhaps it will inform me about domains where OO
techniques aren't particularly applicable. Perhaps it will suggest a
way for me to explain my experience in terms of yours. At the very
least, it should help to explain the sweeping statements you have made
regarding OO.
To aid in achieving this understanding, in addition to the
questions above, what OO languages do you know well enough to use in
production code?
Nick Malik [Microsoft]
news:1157793451.4...@i42g2000cwa.googlegroups.com...
>
> Is Guest/Premium the only way you need to classify users? What if you
> later find it that you need to have different functionality for
> (DomestGuestUser, InternationalGuestUser, DomesticPremiumUser,
> InternationalPremiumUser)? What if yet another dimension is introduced.
> Subtyping can be very dangerous. It is very unlikely that a entity such
> as user only need to be classified in only one dimension.
Bridge Pattern
Haven't you read Design Patterns?
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
Nick Malik [Microsoft]
news:1157899409.1...@b28g2000cwb.googlegroups.com...
> Lets say we have a method processOrder and the behavior of this method
> depends both on the premium and domestic/international criteria. Where
> will we put the implementation? (I am not saying that subtyping and
> inheritence is a bad thing, I only trying to say that it is not very
> likely to be used a lot in enterprise (web) applications, as the OP
> already has found out).
>
Strategy pattern or Bridge pattern should take care of this rather nicely.
One Order object, with one ProcessOrder method.
Specific parts of the processing can be delegated to child objects
(strategy). If the order object itself is subclassed, then you have Bridge.
I don't know enough about the actual variations in this example to decide on
which implementation may work, but regardless, you do NOT have an explosion
of types if you use actual design patterns.
Useful Reference: http://en.wikipedia.org/wiki/Bridge_pattern
Nick Malik [Microsoft]
news:markup-200...@ram.dialup.fu-berlin.de...
>>journal where the author actually claimed the first markup language was
>>invented in 1986. How soon they forget and repeat past mistakes.
>>Markup and scripting languages were very much in vogue in the late '50s
>>and '60s. But there was a reason why they were abandoned by the early
>>'70s.]
>
> Is there a source (preferably accessible via the Internet)
> where I can learn more about this, with names or examples of
> these languages and an explanation why they were abandoned?
>
There were literally dozens of markup languages. The markup language HTML
is a simplified version of SGML, which was not a language I personally
worked with. However, I did work with a couple of others (back in 1980,
when I was a technical markup editor).
Note: I define 'markup language' as any data format that is designed to
respresent the formatting of text whereby a human being would insert
'commands' directly into the text stream to indicate the formatting that
should be applied to the text by a computer program.
{Special note: if the language is so complex that a non-programmer cannot be
reasonably expected to learn it, and/or it is normally written by computer
programs as a storage and retrieval format, then I am not considering that
language to be a markup language, but rather a data storage mechanism.}
Examples of markup languages:
TRS-80 Scripsit http://en.wikipedia.org/wiki/Scripsit
PDP-11 TJ-2 http://en.wikipedia.org/wiki/TJ-2
Knuth's TEX: http://en.wikipedia.org/wiki/TeX
Wordstar: http://en.wikipedia.org/wiki/WordStar
What killed the markup language? WYSIWYG editing, notably including
Microsoft Word, Borland Amipro and, of course, WordPerfect.
When I first opened up an HTML page and looked inside, I felt like I tripped
back DECADES. I still feel that way sometimes as I watch the web make most
of the same decisions, however slowly, that evolved into client/server
computing on the Windows platform. Fashion and computing both appear to run
in multi-decade cycles.
Nick Malik [Microsoft]
news:m2irjo5...@Dagney.local...
> "topmind" <top...@technologist.com> writes:
>> Patrick May wrote:
>>> "topmind" <top...@technologist.com> writes:
>>> >> I was responding to your statement that people who find
>>> >> benefits in OO techniques don't understand procedural and
>>> >> relational techniques. That's not at all the case.
>>> >
>>> > It is what I encounter.
>>>
>>> Just to be clear, are you stating that everyone who finds some
>>> benefits in OO techniques does not understand procedural and
>>> relational techniques?
>>
>> No. I am only stating my experience.
>
> So you have never encountered a single developer who understands
> procedural and relational programming but still finds value in OO
> techniques? Not one?
Hello Patrick,
The person who calls himself 'topmind', while an intelligent and outspoken
individual, has been haunting this board for quite some time. He has been
challenged by dozens of folks, including yourself. Many of these folks *do*
understand both procedural and relational programming techniques. However,
if any of them came down on the side of OO, then -T- does not appear to
change his approach or ideas based on their feedback.
He is a dedicated individual, as you have discovered. I mean that as a
compliment. From his threads, topmind does not consider it to be 'evidence'
of anything if the preponderance of individuals whom he meets on this board
disagree with him. That would simply be an example of someone that he has
yet to convince.
With all due respect to -T-, many great thinkers were not appreciated by
their peers, but they persisted. That said, for every good idea that has
been championed by dedicated folks now recognized as visionary, there were
one hundred more ideas championed by people who were just as lucid,
dedicated, and persistent, but whose ideas have since been forgotten. In
the rapidly changing world of computing, I expect that any effect that
'topmind' hopes to create in the computing world will occur in the
relatively near-term future.
It's fun to discuss OO vs Relational with topmind... once. Some try more
than once. Don't expect to change his opinion, though.
Nick Malik [Microsoft]
news:kpf8g2dad2nrrncp5...@4ax.com...
<<clip>>
> ps: A good two-tier framework is still not constructed imho. Even .net
> doesnt have for instance updatableViews.
>
Common misconception. The Dataset object is, in fact, completely updatable.
Since you can derive objects from this object, you can create a very clean,
typesafe, updatable view. See
http://msdn2.microsoft.com/en-us/library/esbykkzb.aspx
Patrick May
> "Patrick May" <p...@spe.com> wrote in message
>> procedural and relational programming but still finds value in OO
>> techniques? Not one?
>
> Hello Patrick,
>
> The person who calls himself 'topmind', while an intelligent and
> outspoken individual, has been haunting this board for quite some
> time. He has been challenged by dozens of folks, including
> yourself.
Nick,
I was in an optimistic mood when I saw the original post that
started this subthread. I'm hoping that, eventually if not now, he'll
realize that his sweeping claims aren't compelling when people don't
understand his basis for them. I'd personally like to know how he has
reached conclusions so different from mine and those of people I've
worked with over the years.
> With all due respect to -T-, many great thinkers were not
> appreciated by their peers, but they persisted. That said, for
> every good idea that has been championed by dedicated folks now
> recognized as visionary, there were one hundred more ideas
> championed by people who were just as lucid, dedicated, and
> persistent, but whose ideas have since been forgotten.
"They laughed at Galileo, they laughed at Newton, but they also
laughed at Bozo the Clown."
> It's fun to discuss OO vs Relational with topmind... once. Some try
> more than once. Don't expect to change his opinion, though.
At this point I'm just trying to understand the path he took to
get to his current position.
Regards,
fre...@gmail.com
> > depends both on the premium and domestic/international criteria. Where
> > will we put the implementation? (I am not saying that subtyping and
> > inheritence is a bad thing, I only trying to say that it is not very
> > likely to be used a lot in enterprise (web) applications, as the OP
> > already has found out).
>
> Strategy pattern or Bridge pattern should take care of this rather nicely.
> One Order object, with one ProcessOrder method.
> Specific parts of the processing can be delegated to child objects
> (strategy). If the order object itself is subclassed, then you have Bridge.
> I don't know enough about the actual variations in this example to decide on
> which implementation may work, but regardless, you do NOT have an explosion
> of types if you use actual design patterns.
If you are careful about when to use polyorphism, you will not have an
explosion of types. Using strategy pattern, processOrder method in the
Customer class is not a polymorphic method. My point is that it is not
very likely to be any polymorphic methods in classes like "User" or
"Customer". In classes with much less responsibilities, like
"PremiumStrategy" or "ShippingStrategy", polymorphism may be useful.
But these will in many cases be reduced to a single function pointer.
Fredrik Bertilsson
http://frebe.php0h.com
fre...@gmail.com
> > later find it that you need to have different functionality for
> > domestic and international users? How would the user subtypes look like
> > (DomestGuestUser, InternationalGuestUser, DomesticPremiumUser,
> > InternationalPremiumUser)? What if yet another dimension is introduced.
> > Subtyping can be very dangerous. It is very unlikely that a entity such
> > as user only need to be classified in only one dimension.
>
> Bridge Pattern
>
> Haven't you read Design Patterns?
Yes, I have. But this debate is about advantages and disadvantages of
polymorphism. Not about different design patterns.
Fredrik Bertilsson
http://frebe.php0h.com
Bruno Desthuilliers
I clearly see how polymorphism can help, but I fail to see what the
"disadvantages" of polymorphism could be (unless you count "doesn't
solve my actual problem" as a "disadvantage").
Bruno Desthuilliers
(snip)
>
> The long term future of OO lies in UML as a 4GL.
Lord, have mercy :(
fre...@gmail.com
> "disadvantages" of polymorphism could be (unless you count "doesn't
> solve my actual problem" as a "disadvantage")
Read my previous postings in this thread more carefully.
Fredrik Bertilsson
http://frebe.php0h.com
Bruno Desthuilliers
>
>>It's fun to discuss OO vs Relational with topmind... once. Some try
>>more than once. Don't expect to change his opinion, though.
>
>
> At this point I'm just trying to understand the path he took to
> get to his current position.
I'm afraid it boils down to having tried OOP with something like VB5/6
and any braindead "OO for dummies" book once...
fre...@gmail.com
> Microsoft Word, Borland Amipro and, of course, WordPerfect.
But WYSIWYG editors didn't entirely kill HTML. For unexperienced web
designers, WYSIWYG editors are a good help. But people making web
applications for a living, normally prefer working directly with HTML.
> When I first opened up an HTML page and looked inside, I felt like I tripped
> back DECADES.
Doesn't the huge sucess of HTML show that it picked up forgotten
wisdom?
> I still feel that way sometimes as I watch the web make most
> of the same decisions, however slowly, that evolved into client/server
> computing on the Windows platform.
Are you saying that building a GUI using imperative languages for
constructing GUI widgets, is better than a declarative GUI definition?
> Fashion and computing both appear to run
> in multi-decade cycles.
Indeed, just look at the reinvention of network databases, called OO
databases.
Fredrik Bertilsson
http://frebe.php0h.com
Rick Elbers
This is a common misconception. updatableViews lets clarify the name.
An updatableView is something which allows you to insert/delete and
update in a view( which is an arbitrary join of tables) as if you
where working with a table. Micro$ doesnt deliver anything like that
yet. Maybe if they understand what it is, they might in the future :-)
Or maybe you show me how to work with a view of 4 related tables,
inserting a few records in all tables, including new records related
to new records in other tables and then and let the Dataset handle the
sequence of inserts ?
Rick
Op Sat, 16 Sep 2006 18:09:27 -0700 schreef "Nick Malik [Microsoft]"
<nick...@hotmail.nospam.com>:
Phlip
>>>Haven't you read Design Patterns?
>> Yes, I have. But this debate is about advantages and disadvantages of
>> polymorphism. Not about different design patterns.
> I clearly see how polymorphism can help, but I fail to see what the
> "disadvantages" of polymorphism could be (unless you count "doesn't solve
> my actual problem" as a "disadvantage").
I tend to ask "Have you read /Design Patterns/" as short-hand for "Have you
seen examples of OO techniques being used correctly, to simplify programs?"
Bruno Desthuilliers wrote:
> H. S. Lahman a écrit :
>> The long term future of OO lies in UML as a 4GL.
> Lord, have mercy :(
How can you test-first that??
Don't you have to then debug the contents of the UML diagram - the
behaviors?
Patrick May wrote:
> "They laughed at Galileo, they laughed at Newton, but they also
> laughed at Bozo the Clown."
They laughed at my theories! Because my theories are funny!!
The great thing about Topmind is he has learned so much OO theory, here,
that he knows exactly what to say to lead anyone here to the pro-OO reply he
expects.
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
topmind
Patrick May wrote:
> "topmind" <top...@technologist.com> writes:
> > Patrick May wrote:
> >> "topmind" <top...@technologist.com> writes:
> >> >> I was responding to your statement that people who find
> >> >> benefits in OO techniques don't understand procedural and
> >> >> relational techniques. That's not at all the case.
> >> >
> >> > It is what I encounter.
> >>
> >> Just to be clear, are you stating that everyone who finds some
> >> benefits in OO techniques does not understand procedural and
> >> relational techniques?
> >
> > No. I am only stating my experience.
>
> So you have never encountered a single developer who understands
> procedural and relational programming but still finds value in OO
> techniques? Not one?
The OO proponents didn't give a lot of insight why they liked OO
versions of applications. They were unable to provide solid
articulation on the benefits, as if it is something that has to be
experienced over time only. It strikes me as resembling an
eastern-style of philosophy instead of western reductionalism,
isolation, and dissection that makes it easier to openly analyze.
I have found this to be common. It has been difficult for the OO
community to articulate precisely why they think OO is better, at least
outside of systems software. I've thus formed a working theory that
their preferrence is a subjective mind-fit. I won't dispute that OO
fans think better with objects. I am only bothered when they try to
extrapolate their preferences to everybody else.
And, I cannot remember the domain rules from the OO-centric projects
well enough to describe them here. Lately I've haven't been in shops
pushing OO, so I don't have any recent memories I can convey in usable
detail.
>
> > Anecdotes are all any of us have so far.
>
> In this forum, in the absence of shared experience, we are indeed
> limited to descriptions of our experience and occasional references to
> often limited documentation of projects. That's why I'm asking
> questions of you -- your statements regarding OO are strongly at
> variance with my experience and that of developers I have worked
> with.
Companies tend to hire like minds, such that you may have naturally
been hired by other OO-favoring minds. Such a group will be more at
home with OO.
> It also suggests that
> the design wasn't particularly behavior driven.
Perhaps this is the crux of my distaste for OO. I tend to try to
refactor behavior-driven designs into attribute-driven designs. I like
to put most of the controlling attributes into tables, or at least data
structures, and then the "engine" processes the attributes. It is
easier to reason about, report on, and query attributes than behavior I
have found. I find it a higher abstraction, or at least an abstraction
that is easier for me to work with.
Plus it allows a division of labor: attribute suppliers and attribute
processor builders. It is roughly analogous to interface builders
versus interface users.
>
> >> Where, specifically, have you used OO techniques and found no
> >> additional value? What techniques were you using? What languages?
> >> What were your metrics for measuring value?
> >
> > Some of this was already discussed above. As far as what metric,
> > this is another contentious area. Nobody even agrees on what metric
> > OO does better on.
>
> Well, you said that OO techniques didn't add value. What metric
> were you using in that statement?
I just didn't see any value. I just plain didn't. Like I already
stated, I did not see it making changes easier to deal with, for one.
The OO proponents seemed to have a misguided sense about what kind of
future changes were more likely. We perceived likely future change
probabilities differently based on our experience and could not
reconcile that. Other than that, I don't know what metric(s) the OO
proponents were using.
> At the very
> least, it should help to explain the sweeping statements you have made
> regarding OO.
I didn't make any sweeping statements about OO that I know of, other
than I have never seen good objective evidence that OO was better for
custom biz apps either in production or in books. Is that sweeping?
> Sincerely,
>
> Patrick
>
-T-
topmind
Are you suggesting that *votes alone* are sufficient evidence? If so,
then let's be more scientific about the voting process. Comp.object is
not a representative example of software designers, for one. In
practice, most are ambivalent about OO in my observation, liking it for
GUI's, but not necessarily for biz modeling.
I expect something more tangable, something along the lines as being
less code or less code to change or less key-strokes per change
scenario. The best metrics are quantifiable. Not that I will
necessarily dismiss non-quantifiable evidence, but that it creates the
risk of differing subjective interpretation.
I am simply asking for the scientific process, or at least something
reasonable close to it. If that makes me "bad", then so be it.
-T-
topmind
If Java or Ruby is where OO kicks ass, then show us all this
ass-kicking in progress with inspectable code and realistic change
scenarios with change tallies. Use evidence, not language and people
bashing. Such is for intellectual cowards only.
-T-
Patrick May
> Patrick May wrote:
>> So you have never encountered a single developer who
>> understands procedural and relational programming but still finds
>> value in OO techniques? Not one?
>
> The OO proponents didn't give a lot of insight why they liked OO
> versions of applications. They were unable to provide solid
> articulation on the benefits, as if it is something that has to be
> experienced over time only. It strikes me as resembling an
> eastern-style of philosophy instead of western reductionalism,
> isolation, and dissection that makes it easier to openly analyze.
Software development is still more of a craft than an engineering
discipline. What works in practice can sometimes be best explained
through demonstration rather than explanation. Similarly, theoretical
objections can turn out to be unimportant in practice.
> I have found this to be common. It has been difficult for the OO
> community to articulate precisely why they think OO is better, at
> least outside of systems software.
There is an enormous amount of literature on OO techniques, some
of which is excellent. "Design Patterns", for example, explains how
to use OO techniques to solve particular dependency problems.
In order to understand those explanations, it is important to
have at least some shared background or a willingness to use them in
practice.
> And, I cannot remember the domain rules from the OO-centric projects
> well enough to describe them here. Lately I've haven't been in shops
> pushing OO, so I don't have any recent memories I can convey in usable
> detail.
>
>>
>> > Anecdotes are all any of us have so far.
>>
>> In this forum, in the absence of shared experience, we are
>> indeed limited to descriptions of our experience and occasional
>> references to often limited documentation of projects. That's why
>> I'm asking questions of you -- your statements regarding OO are
>> strongly at variance with my experience and that of developers I
>> have worked with.
>
> Companies tend to hire like minds, such that you may have naturally
> been hired by other OO-favoring minds. Such a group will be more at
> home with OO.
My clients hire me to solve problems. In most cases the choice
of technology is negotiable. I find that people with exposure to
multiple paradigms are better at solving problems than people with
only one tool in their virtual toolbox.
>> At the very least, it should help to explain the sweeping
>> statements you have made regarding OO.
>
> I didn't make any sweeping statements about OO that I know of, other
> than I have never seen good objective evidence that OO was better
> for custom biz apps either in production or in books. Is that
> sweeping?
Well, yes. The absolute "never" is sweeping. You've also made
comments like these in this thread alone:
"The only examples I've seen are from people who didn't know how
to use procedural and databases well."
"I cannot remember specific details, but putting OO in the code
did not improve the app any way that I saw."
"OO results in a big sea of classes with no easy to way navigate
them all."
"Classification of business nouns belongs in the database IMO,
not app code, and if you do that, you take away what OO usually
does."
"It has been difficult for the OO community to articulate
precisely why they think OO is better, at least outside of
systems software."
All of these are broad (sweeping) claims that are not in accord with
my experience nor with the experience of many developers I've worked
with.
You've refrained from answering a number of questions I've
asked regarding your background. That, combined with some of your
phrasing when describing previous projects, leads me to the
conclusions that you were tangentially exposed to OO in one project in
your past, that you do not have personal experience of using OO in the
development of production systems, and that you are not proficient in
any OO languages. Is this accurate?
If so, isn't it possible that your failure to see any value in OO
techniques stems from your lack of experience rather than from any
inherent flaw in those techniques?
topmind
Patrick May wrote:
> "topmind" <top...@technologist.com> writes:
> > Patrick May wrote:
> >> So you have never encountered a single developer who
> >> understands procedural and relational programming but still finds
> >> value in OO techniques? Not one?
> >
> > The OO proponents didn't give a lot of insight why they liked OO
> > versions of applications. They were unable to provide solid
> > articulation on the benefits, as if it is something that has to be
> > experienced over time only. It strikes me as resembling an
> > eastern-style of philosophy instead of western reductionalism,
> > isolation, and dissection that makes it easier to openly analyze.
>
> Software development is still more of a craft than an engineering
> discipline. What works in practice can sometimes be best explained
> through demonstration rather than explanation. Similarly, theoretical
> objections can turn out to be unimportant in practice.
This fits my view that paradigms/techniques are largely subjective.
There are many ways to solve the same problem.
>
> > I have found this to be common. It has been difficult for the OO
> > community to articulate precisely why they think OO is better, at
> > least outside of systems software.
>
> There is an enormous amount of literature on OO techniques, some
> of which is excellent. "Design Patterns", for example, explains how
> to use OO techniques to solve particular dependency problems.
Most of the examples in Design Patterns are geared toward systems
software. I didn't find their analysis applicable to custom biz apps.
If you know the answers, then please write "Design Patterns for
Business Modeling: How, When, and Why". It should be a top seller
because there is no current competition. (Fowler has produced some biz
titles, but I've disagreed with some of his designs and suggestions.)
If I want to write a device driver or text editor from scratch, then
the GOF pattern book may indeed be applicable. But that is not what I
do. Nor many others.
>
> In order to understand those explanations, it is important to
> have at least some shared background or a willingness to use them in
> practice.
That is what many want to see: examples of them used in practice, and
the detailed reasons they are allegedly better.
> >> At the very least, it should help to explain the sweeping
> >> statements you have made regarding OO.
> >
> > I didn't make any sweeping statements about OO that I know of, other
> > than I have never seen good objective evidence that OO was better
> > for custom biz apps either in production or in books. Is that
> > sweeping?
>
> Well, yes. The absolute "never" is sweeping. You've also made
> comments like these in this thread alone:
>
> "The only examples I've seen are from people who didn't know how
> to use procedural and databases well."
That is not sweeping generalization. That is a personal observation.
>
> "I cannot remember specific details, but putting OO in the code
> did not improve the app any way that I saw."
Same thing. I am only reporting what I've witnessed. You've also
reported what you witnessed.
>
> "OO results in a big sea of classes with no easy to way navigate
> them all."
Okay, that is sweeping, but if you disagree, then simply show easy ways
to navigate and prove me wrong. If I say, "There are no unicorns", then
you can prove me wrong by producing a single unicorn.
>
> "Classification of business nouns belongs in the database IMO,
> not app code, and if you do that, you take away what OO usually
> does."
IMO = In my opinion.
>
> "It has been difficult for the OO community to articulate
> precisely why they think OO is better, at least outside of
> systems software."
See unicorn example above. Counter by showing clear articulation. If it
exists, where is it???
>
> All of these are broad (sweeping) claims that are not in accord with
> my experience nor with the experience of many developers I've worked
> with.
>
> You've refrained from answering a number of questions I've
> asked regarding your background.
I cannot give those specifics. I didn't keep detailed notes about the
domain and classes involved, and signed NDA. Mentioning languages will
start language fights.
> [...]
> If so, isn't it possible that your failure to see any value in OO
> techniques stems from your lack of experience rather than from any
> inherent flaw in those techniques?
It is not my burden to prove OOP is better. Despite all the lip service
it gets, it is still not the predominate paradigm. Even languages like
Java that are supposed to force one to write OO have proved that
language-oriented-spanking doesn't work. And, I never claimed OO
objectively worse. It is an added paradigm with no documented added
benefits (outside of systems software).
If you have all the insight about how to make custom biz apps better
with OOP, then I suggest you find a way to produce a public case for
it, because there currently is none and nobody should be forced to suck
down anecdotes at face value. We have open-source software, why not
open-source evidence?
Use an airline reservation system or campus grade tracking system as an
example use-case if you need one.
It appears to me a small group of zealots are forcing their personal
preferences on everybody else by using false elistism and technobabble.
>
> Sincerely,
>
> Patrick
>
-T-
topmind
> Bruno Desthuilliers wrote:
>
> >>>Haven't you read Design Patterns?
>
> >> Yes, I have. But this debate is about advantages and disadvantages of
> >> polymorphism. Not about different design patterns.
>
> > I clearly see how polymorphism can help, but I fail to see what the
> > "disadvantages" of polymorphism could be (unless you count "doesn't solve
> > my actual problem" as a "disadvantage").
I have a list of potential down-falls of polymorphism on my website.
However, I can sum most of them up with one sentence: Polymorphism does
not easily lend it itself to SET THEORY.
I often find it easier to describe an instance or variation on a theme
as sets or a set expression. Polymorphism seems fundimentally against
this. At least it does not naturally help it.
After exploration, you will eventually have to agree that it is better
to model something like an Employee using sets rather than
polymorphism. Polymorphism is simply too limiting. Sure, you can use it
to make strategy patterns etc. that are a kind of set engine, but there
are usually more convenient ways to get the same thing without OO,
especially if you want to query the set info.
>
> I tend to ask "Have you read /Design Patterns/" as short-hand for "Have you
> seen examples of OO techniques being used correctly, to simplify programs?"
>
Like I said elsewhere, the Design Patterns books is geared toward
systems software. It's lessons so far appear not applicable to other
domains, such as custom business software. I do not question OO's
abilities for systems software, but that is not my domain.
-T-
Bruno Desthuilliers
>>I fail to see what the
>>"disadvantages" of polymorphism could be (unless you count "doesn't
>>solve my actual problem" as a "disadvantage")
>
>
> Read my previous postings in this thread more carefully.
Read my question more carefully.
Dmitry A. Kazakov
> Phlip wrote:
>> Bruno Desthuilliers wrote:
>>
>>>>>Haven't you read Design Patterns?
>>
>>>> Yes, I have. But this debate is about advantages and disadvantages of
>>>> polymorphism. Not about different design patterns.
>>
>>> I clearly see how polymorphism can help, but I fail to see what the
>>> "disadvantages" of polymorphism could be (unless you count "doesn't solve
>>> my actual problem" as a "disadvantage").
>
> I have a list of potential down-falls of polymorphism on my website.
> However, I can sum most of them up with one sentence: Polymorphism does
> not easily lend it itself to SET THEORY.
>
> I often find it easier to describe an instance or variation on a theme
> as sets or a set expression. Polymorphism seems fundimentally against
> this.
In what sense it does? And what is the definition of polymorphism, you are
using? Because under the definitions I met, so far, your sentence is
nonsensical. Could it happen that you meant pleomorphism? Ectomorphism?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Patrick May
> Patrick May wrote:
>> Software development is still more of a craft than an
>> engineering discipline. What works in practice can sometimes be
>> best explained through demonstration rather than explanation.
>> Similarly, theoretical objections can turn out to be unimportant in
>> practice.
>
> This fits my view that paradigms/techniques are largely subjective.
> There are many ways to solve the same problem.
That doesn't follow from what I wrote. My point is that armchair
theorizing is insufficient to understand the costs and benefits of a
particular software development technique. You have to get your hands
dirty.
>> There is an enormous amount of literature on OO techniques,
>> some of which is excellent. "Design Patterns", for example,
>> explains how to use OO techniques to solve particular dependency
>> problems.
>
> Most of the examples in Design Patterns are geared toward systems
> software. I didn't find their analysis applicable to custom biz
> apps.
A quick perusal of my copy shows examples that include windowing
systems, commands (widely applicable to business applications),
parsing (also widely applicable to business applications),
model-view-controller (again, widely applicable to business
applications), various means of manipulating data structures
efficiently, a way of sharing complex information, several techniques
for managing dependencies, and much more. This book is by no means
limited to systems software.
>> >> At the very least, it should help to explain the sweeping
>> >> statements you have made regarding OO.
>> >
>> > I didn't make any sweeping statements about OO that I know of,
>> > other than I have never seen good objective evidence that OO was
>> > better for custom biz apps either in production or in books. Is
>> > that sweeping?
>>
>> Well, yes. The absolute "never" is sweeping. You've also made
>> comments like these in this thread alone:
>>
>> "The only examples I've seen are from people who didn't know how
>> to use procedural and databases well."
>
> That is not sweeping generalization. That is a personal observation.
Referring to personal observations raises the legitimate
question: From what projects?
>> "I cannot remember specific details, but putting OO in the code
>> did not improve the app any way that I saw."
>
> Same thing. I am only reporting what I've witnessed. You've also
> reported what you witnessed.
Again, from what projects?
>> "OO results in a big sea of classes with no easy to way navigate
>> them all."
>
> Okay, that is sweeping, but if you disagree, then simply show easy
> ways to navigate and prove me wrong. If I say, "There are no
> unicorns", then you can prove me wrong by producing a single
> unicorn.
You are attempting to reverse the burden of proof. You've made a
sweeping claim, it is a reasonable response to ask for details of the
experience that caused you to make that claim.
>> "Classification of business nouns belongs in the database IMO,
>> not app code, and if you do that, you take away what OO
>> usually does."
>
> IMO = In my opinion.
"And we are all told from the moment we open our eyes, that
everyone is entitled to his or her opinion. Well, that's
horsepuckey, of course. We are not entitled to our opinions; we
are entitled to our informed opinions. Without research, without
background, without understanding, it's nothing."
-- Harlan Ellison
>> All of these are broad (sweeping) claims that are not in accord
>> with my experience nor with the experience of many developers I've
>> worked with.
>>
>> You've refrained from answering a number of questions I've
>> asked regarding your background.
>
> I cannot give those specifics.
The questions were quite straightforward. Allow me to repeat the
part you snipped:
You've refrained from answering a number of questions I've asked
regarding your background. That, combined with some of your phrasing
when describing previous projects, leads me to the conclusions that
you were tangentially exposed to OO in one project in your past, that
you do not have personal experience of using OO in the development of
production systems, and that you are not proficient in any OO
languages. Is this accurate?
Why can you not answer this question directly?
topmind
I find it tough to explore these things using definitions, and thus
like to explore specific scenarios instead. In fact, I doubt you can
find a definition that 60+ percent of OOP proponents will agree on.
>
> --
> Regards,
> Dmitry A. Kazakov
-T-
topmind
> "topmind" <top...@technologist.com> writes:
> > Patrick May wrote:
> >> Software development is still more of a craft than an
> >> engineering discipline. What works in practice can sometimes be
> >> best explained through demonstration rather than explanation.
> >> Similarly, theoretical objections can turn out to be unimportant in
> >> practice.
> >
> > This fits my view that paradigms/techniques are largely subjective.
> > There are many ways to solve the same problem.
>
> That doesn't follow from what I wrote. My point is that armchair
> theorizing is insufficient to understand the costs and benefits of a
> particular software development technique. You have to get your hands
> dirty.
That implies that it resists attempts at documentation, which implies
it may be subjective. I know you didn't outright say this, but
something that resists scientific dissection tends to be subjective in
many cases. What alternative explanation would you give for lack of
dissection ability?
>
> >> There is an enormous amount of literature on OO techniques,
> >> some of which is excellent. "Design Patterns", for example,
> >> explains how to use OO techniques to solve particular dependency
> >> problems.
> >
> > Most of the examples in Design Patterns are geared toward systems
> > software. I didn't find their analysis applicable to custom biz
> > apps.
>
> A quick perusal of my copy shows examples that include windowing
> systems, commands (widely applicable to business applications),
> parsing (also widely applicable to business applications),
I meant custom business applications. One generally does not write GUI
systems from scratch for custom biz apps. That is too expensive. Or,
parsers either (Note that most dynamic languages come with built-in
expression evaluators so that one could say put expressions in database
tables if needed).
> model-view-controller (again, widely applicable to business
> applications),
I never liked MVC implimentations, and nobody really agrees on what MVC
is or isn't anyhow. I prefer event-driven and attribute-driven GUI
frameworks (some claim these are MVC, others dispute it).
> various means of manipulating data structures
> efficiently, a way of sharing complex information, several techniques
> for managing dependencies, and much more. This book is by no means
> limited to systems software.
Could you point out a specific one? (I don't have a copy now, but can
probably barrow one.)
Also, the GOF book didn't really compare their designs with
procedural/relational designs very often that I saw. They may run, but
being less code or easier to change was not comparatively justified.
Nobody is questioning whether they run.
The existence of a pattern alone is not evidence it is better than
alternatives. This is the main reason why the GOF book is overrated.
>
> >> >> At the very least, it should help to explain the sweeping
> >> >> statements you have made regarding OO.
> >> >
> >> > I didn't make any sweeping statements about OO that I know of,
> >> > other than I have never seen good objective evidence that OO was
> >> > better for custom biz apps either in production or in books. Is
> >> > that sweeping?
> >>
> >> Well, yes. The absolute "never" is sweeping. You've also made
> >> comments like these in this thread alone:
> >>
> >> "The only examples I've seen are from people who didn't know how
> >> to use procedural and databases well."
> >
> > That is not sweeping generalization. That is a personal observation.
>
> Referring to personal observations raises the legitimate
> question: From what projects?
Both sides have the same boogyman.
>
> >> "I cannot remember specific details, but putting OO in the code
> >> did not improve the app any way that I saw."
> >
> > Same thing. I am only reporting what I've witnessed. You've also
> > reported what you witnessed.
>
> Again, from what projects?
>
> >> "OO results in a big sea of classes with no easy to way navigate
> >> them all."
> >
> > Okay, that is sweeping, but if you disagree, then simply show easy
> > ways to navigate and prove me wrong. If I say, "There are no
> > unicorns", then you can prove me wrong by producing a single
> > unicorn.
>
> You are attempting to reverse the burden of proof. You've made a
> sweeping claim, it is a reasonable response to ask for details of the
> experience that caused you to make that claim.
I demote it to "subjective impression" then. The point I was trying to
make is that I can find no documentation how to deal with a bunch of
classes. How does one "get their mind" around a bunch of classes?
Suppose you are a consultant and you are dumped into the middle of an
OOP project and dumped on your lap is 1,000 classes. I know
categorization techniques that usually work for procedural/relational
code, but not OO.
>
> >> "Classification of business nouns belongs in the database IMO,
> >> not app code, and if you do that, you take away what OO
> >> usually does."
> >
> > IMO = In my opinion.
>
> "And we are all told from the moment we open our eyes, that
> everyone is entitled to his or her opinion. Well, that's
> horsepuckey, of course. We are not entitled to our opinions; we
> are entitled to our informed opinions. Without research, without
> background, without understanding, it's nothing."
> -- Harlan Ellison
Both sides face the same boogyman.
>
> >> All of these are broad (sweeping) claims that are not in accord
> >> with my experience nor with the experience of many developers I've
> >> worked with.
> >>
> >> You've refrained from answering a number of questions I've
> >> asked regarding your background.
> >
> > I cannot give those specifics.
>
> The questions were quite straightforward. Allow me to repeat the
> part you snipped:
>
> You've refrained from answering a number of questions I've asked
> regarding your background. That, combined with some of your phrasing
> when describing previous projects, leads me to the conclusions that
> you were tangentially exposed to OO in one project in your past, that
> you do not have personal experience of using OO in the development of
> production systems, and that you are not proficient in any OO
> languages. Is this accurate?
Not any more. I stopped using them and am now rusty. But thats besides
the point. I want to see somebody *else's* evidence that OOP is better
for custom biz apps. If you don't have any, then I guess we are done
here.
>
> Why can you not answer this question directly?
I believe because you are asking the wrong questions. Let's focus on
something that we can publicly present and dissect. You seem to want
to compare resumes, but I want to compare publicly viewable projects
and examples. That way everybody can get involved and offer
viewpoints. Discussions are better that way. That is the spirit of
open-source also, I would note.
>
> Sincerely,
>
> Patrick
>
-T-
Patrick May
>> >> Software development is still more of a craft than an
>> >> engineering discipline. What works in practice can sometimes be
>> >> best explained through demonstration rather than explanation.
>> >> Similarly, theoretical objections can turn out to be unimportant
>> >> in practice.
>> >
>> > This fits my view that paradigms/techniques are largely
>> > subjective. There are many ways to solve the same problem.
>>
>> That doesn't follow from what I wrote. My point is that
>> armchair theorizing is insufficient to understand the costs and
>> benefits of a particular software development technique. You have
>> to get your hands dirty.
>
> That implies that it resists attempts at documentation, which
> implies it may be subjective.
That doesn't follow at all. Give someone who doesn't know how to
swim a book describing swimming. Let him read it. Toss him in the
deep end of a pool. He'll sink. Objectively.
>> > Most of the examples in Design Patterns are geared toward systems
>> > software. I didn't find their analysis applicable to custom biz
>> > apps.
>>
>> A quick perusal of my copy shows examples that include
>> windowing systems, commands (widely applicable to business
>> applications), parsing (also widely applicable to business
>> applications),
>
> I meant custom business applications. One generally does not write GUI
> systems from scratch for custom biz apps. That is too expensive.
The techniques used to manage the dependencies between components
in a windowing system can also be used to manage dependencies in other
domains. Numerous developers have done just that.
> Or, parsers either
I find the requirement to parse unusual file formats, often
created by legacy, custom systems, to be not unusual when building
business applications.
>> model-view-controller (again, widely applicable to business
>> applications),
>
> I never liked MVC implimentations,
Neither that, nor any of your other issues, supports your claim
that "Most of the examples in Design Patterns are geared toward
systems software." That's simply not the case.
>> >> "The only examples I've seen are from people who didn't
>> >> know how to use procedural and databases well."
>> >
>> > That is not sweeping generalization. That is a personal
>> > observation.
It is sweeping in that it generalizes over every single OO
developer you have encountered. The implication you'd like people to
draw is clear.
>> Referring to personal observations raises the legitimate
>> question: From what projects?
>
> Both sides have the same boogyman.
That doesn't answer the question. I'm trying to understand how
you have come to hold the views you do. Initially I thought such
understanding might allow me to present my experience in a way that
would be more compelling to you, but I am coming to the conclusion
that I was overly optimistic.
>> >> "I cannot remember specific details, but putting OO in the
>> >> code did not improve the app any way that I saw."
>> >
>> > Same thing. I am only reporting what I've witnessed. You've also
>> > reported what you witnessed.
>>
>> Again, from what projects?
You haven't answered this question.
>> >> "OO results in a big sea of classes with no easy to way
>> >> navigate them all."
>> >
>> > Okay, that is sweeping, but if you disagree, then simply show
>> > easy ways to navigate and prove me wrong. If I say, "There are no
>> > unicorns", then you can prove me wrong by producing a single
>> > unicorn.
>>
>> You are attempting to reverse the burden of proof. You've
>> made a sweeping claim, it is a reasonable response to ask for
>> details of the experience that caused you to make that claim.
>
> I demote it to "subjective impression" then.
It certainly isn't phrased as a subjective impression. If you
couldn't support the claim, you shouldn't have made it in the first
place.
>> >> "Classification of business nouns belongs in the database
>> >> IMO, not app code, and if you do that, you take away what
>> >> OO usually does."
>> >
>> > IMO = In my opinion.
>>
>> "And we are all told from the moment we open our eyes, that
>> everyone is entitled to his or her opinion. Well, that's
>> horsepuckey, of course. We are not entitled to our opinions;
>> we are entitled to our informed opinions. Without research,
>> without background, without understanding, it's nothing."
>> -- Harlan Ellison
>
> Both sides face the same boogyman.
I've presented some of my background and referred to projects
where I've used OO techniques successfully. You are making claims
that appear to be based on your experience, but whenever you are
invited to explain that experience, you refuse.
The conclusion that I'm rapidly reaching is that you lack the
necessary experience to have an informed opinion.
>> You've refrained from answering a number of questions I've
>> asked regarding your background. That, combined with some of your
>> phrasing when describing previous projects, leads me to the
>> conclusions that you were tangentially exposed to OO in one project
>> in your past, that you do not have personal experience of using OO
>> in the development of production systems, and that you are not
>> proficient in any OO languages. Is this accurate?
>
> Not any more. I stopped using them and am now rusty. But thats
> besides the point.
No, it is exactly the point. You have so little experience with
OO techniques that you can't even remember the details of the one
project where you encountered them. You do not use OO techniques in
your daily work. You are not proficient in any OO languages.
Despite this lack of experience, you very frequently involve
yourself in discussions of the application of OO. You make sweeping
generalizations that are completely at odds with the experience of
developers with far more practical exposure to those techniques.
Never do you preface your remarks with any context such as "I haven't
and don't use OO, but . . . ."
Most of the participants on comp.object are experienced enough
that this isn't an issue for them, but you also make these statements
in reply to less experienced people coming here for advice. It seems
less than forthright for you to do so without any caveats.
> I want to see somebody *else's* evidence that OOP is better for
> custom biz apps.
Do you really? It appears that you just want to rant about OO
for reasons known only to you. There is no evidence that will
convince you to change your mind.
> I guess we are done here.
I am, at least. The last word is yours.
Phlip
> topmind writes:
> > Most of the examples in Design Patterns are geared toward systems
> > software. I didn't find their analysis applicable to custom biz
> > apps.
> Neither that, nor any of your other issues, supports your claim
> that "Most of the examples in Design Patterns are geared toward
> systems software." That's simply not the case.
Welcome. To the Topmind Zone.
topmind
Patrick May wrote:
> "topmind" <top...@technologist.com> writes:
> > Patrick May wrote:
> >> "topmind" <top...@technologist.com> writes:
> >> >> Software development is still more of a craft than an
> >> >> engineering discipline. What works in practice can sometimes be
> >> >> best explained through demonstration rather than explanation.
> >> >> Similarly, theoretical objections can turn out to be unimportant
> >> >> in practice.
> >> >
> >> > This fits my view that paradigms/techniques are largely
> >> > subjective. There are many ways to solve the same problem.
> >>
> >> That doesn't follow from what I wrote. My point is that
> >> armchair theorizing is insufficient to understand the costs and
> >> benefits of a particular software development technique. You have
> >> to get your hands dirty.
> >
> > That implies that it resists attempts at documentation, which
> > implies it may be subjective.
>
> That doesn't follow at all. Give someone who doesn't know how to
> swim a book describing swimming. Let him read it. Toss him in the
> deep end of a pool. He'll sink. Objectively.
Are you suggesting that documenting benefits are simply not possible? I
didn't suggest that the documentation should be geared toward newbies.
But I have not seen biz benefits documented for experienced developers
either.
>
> >> > Most of the examples in Design Patterns are geared toward systems
> >> > software. I didn't find their analysis applicable to custom biz
> >> > apps.
> >>
> >> A quick perusal of my copy shows examples that include
> >> windowing systems, commands (widely applicable to business
> >> applications), parsing (also widely applicable to business
> >> applications),
> >
> > I meant custom business applications. One generally does not write GUI
> > systems from scratch for custom biz apps. That is too expensive.
>
> The techniques used to manage the dependencies between components
> in a windowing system can also be used to manage dependencies in other
> domains. Numerous developers have done just that.
I am skeptical. I have not seen sufficient biz examples. The fact that
books mostly use systems software examples is further evidence of this.
Others have agreed with me on this.
Either way, nobody can point to such evidence at this stage. It is all
anecdotal evidence.
>
> > Or, parsers either
>
> I find the requirement to parse unusual file formats, often
> created by legacy, custom systems, to be not unusual when building
> business applications.
I agree, but it is usually a different flavor than building say a
language parser. But, can you provide inspectable evidence that OOP or
GOF help in building such?
Can you show GOF patterns making *better* code for data file parsing
than procedural/relational?
>
> >> model-view-controller (again, widely applicable to business
> >> applications),
> >
> > I never liked MVC implimentations,
>
> Neither that, nor any of your other issues, supports your claim
> that "Most of the examples in Design Patterns are geared toward
> systems software." That's simply not the case.
I never claimed that MVC nor GOF patterns "don't run". The issue is
betterment, not mere running. Nobody has shown MVC etc. being better
than alternatives.
>
> >> >> "The only examples I've seen are from people who didn't
> >> >> know how to use procedural and databases well."
> >> >
> >> > That is not sweeping generalization. That is a personal
> >> > observation.
>
> It is sweeping in that it generalizes over every single OO
> developer you have encountered. The implication you'd like people to
> draw is clear.
I was not impressed with the OO'ers I've encountered. If they were
brilliant, I could not detect it.
Note that many times we have also disagreed over the probability of
various change scenarios. They percieve change differently than I do.
We would look at a design, and both sides assign very different
probabilities to the listed change scenarios.
OO'ers just seem to view change differently. I don't know how to
reconcile such. Suggestions welcomes.
>
> >> Referring to personal observations raises the legitimate
> >> question: From what projects?
> >
> > Both sides have the same boogyman.
>
> That doesn't answer the question. I'm trying to understand how
> you have come to hold the views you do. Initially I thought such
> understanding might allow me to present my experience in a way that
> would be more compelling to you, but I am coming to the conclusion
> that I was overly optimistic.
I am sorry, but I cannot answer your questions about my past projects.
Please try another approach or give up.
> >> >> "OO results in a big sea of classes with no easy to way
> >> >> navigate them all."
> >> >
> >> > Okay, that is sweeping, but if you disagree, then simply show
> >> > easy ways to navigate and prove me wrong. If I say, "There are no
> >> > unicorns", then you can prove me wrong by producing a single
> >> > unicorn.
> >>
> >> You are attempting to reverse the burden of proof. You've
> >> made a sweeping claim, it is a reasonable response to ask for
> >> details of the experience that caused you to make that claim.
> >
> > I demote it to "subjective impression" then.
>
> It certainly isn't phrased as a subjective impression. If you
> couldn't support the claim, you shouldn't have made it in the first
> place.
I was just trying to communicate my impressions, not make court
testimony. If you want, I will put <claim></claim> tags around claims
to clarify.
>
> >> >> "Classification of business nouns belongs in the database
> >> >> IMO, not app code, and if you do that, you take away what
> >> >> OO usually does."
> >> >
> >> > IMO = In my opinion.
> >>
> >> "And we are all told from the moment we open our eyes, that
> >> everyone is entitled to his or her opinion. Well, that's
> >> horsepuckey, of course. We are not entitled to our opinions;
> >> we are entitled to our informed opinions. Without research,
> >> without background, without understanding, it's nothing."
> >> -- Harlan Ellison
> >
> > Both sides face the same boogyman.
>
> I've presented some of my background and referred to projects
> where I've used OO techniques successfully.
I want to see actual code, not listen do anecdotes. I've heard enough
of them already, to be frank. I don't mean to insult or belittle your
background, by my experience is that anecodotes won't settle these
kinds of issues. I am just the messenger.
We've been down Anecdote Alley already.
> You are making claims
> that appear to be based on your experience, but whenever you are
> invited to explain that experience, you refuse.
>
> The conclusion that I'm rapidly reaching is that you lack the
> necessary experience to have an informed opinion.
Have I said something outright wrong about OO? Making blanket
accusations about my OO knowledge without some objective test is not
very polite.
>
> >> You've refrained from answering a number of questions I've
> >> asked regarding your background. That, combined with some of your
> >> phrasing when describing previous projects, leads me to the
> >> conclusions that you were tangentially exposed to OO in one project
> >> in your past, that you do not have personal experience of using OO
> >> in the development of production systems, and that you are not
> >> proficient in any OO languages. Is this accurate?
> >
> > Not any more. I stopped using them and am now rusty. But thats
> > besides the point.
>
> No, it is exactly the point. You have so little experience with
> OO techniques that you can't even remember the details of the one
> project where you encountered them.
I've forgotten a lot of the details of the domains I've worked in. I
used to be a contractor and after 3 or so different places/projects, my
brain cleans out the details of past projects. I can only remember
*general* ideas of what went down, but that is not enough to recall
what the classes were for. I don't recall what the specific classes
did, nor what changes messed them up. I just don't.
> > I want to see somebody *else's* evidence that OOP is better for
> > custom biz apps.
>
> Do you really?
Try me!
> It appears that you just want to rant about OO
> for reasons known only to you. There is no evidence that will
> convince you to change your mind.
There is no applicable evidence, period. WHEN there is and then I
reject it, you then have a legitimate complaint.
I just want science, or something as close to it as possible.
>
> > I guess we are done here.
>
> I am, at least. The last word is yours.
>
> Sincerely,
>
> Patrick
>
-T-
Nick Malik [Microsoft]
news:1158506491.8...@h48g2000cwc.googlegroups.com...
>> What killed the markup language? WYSIWYG editing, notably including
>> Microsoft Word, Borland Amipro and, of course, WordPerfect.
>
> But WYSIWYG editors didn't entirely kill HTML. For unexperienced web
> designers, WYSIWYG editors are a good help. But people making web
> applications for a living, normally prefer working directly with HTML.
>
Markup languages "died" before HTML re-emerged. In the early 80's, most
markup languages were fading fast. The only real survivor to re-emerge was
HTML. I'm talking about the events that occured before the world
'discovered' the world-wide web.
>> When I first opened up an HTML page and looked inside, I felt like I
>> tripped
>> back DECADES.
>
> Doesn't the huge sucess of HTML show that it picked up forgotten
> wisdom?
Um... no. HTML showed the value of an open format that is human readable.
None of the main markup languages did that. It isn't forgotten wisdom if
the success is based on an idea that hadn't been tried before.
The success of HTML was taking an idea whose time had passed (text markup)
and combining it with an idea that was becoming really hot: standardized and
simple mechanisms for communication (HTML, HTTP, SMTP, and later RSS and
XML). Even then, it had serious limitiations, especially with respect to
formalism. There are a dozen different ways that Tim Berners-Lee could
have gone. My guess is that he chose this one primarily because it was
simple to describe and explain. It worked. No point in arguing with it.
Note that markup made a comeback with Wiki as well, but less spectacularly.
>
>> I still feel that way sometimes as I watch the web make most
>> of the same decisions, however slowly, that evolved into client/server
>> computing on the Windows platform.
>
> Are you saying that building a GUI using imperative languages for
> constructing GUI widgets, is better than a declarative GUI definition?
I am sorry if I was not sufficiently clear. I was not talking about
languages, but rather architectures. The first architectures were very
centralized (think IBM 360). Later came stand-alone architectures (PDP-11,
DECSystem, HP3000) in smaller and smaller form factors. The PC put a
stand-alone system on everyones desktop. Then the network hit it's tipping
point, and everyone had to have one or two or ten.
Computing power immediately moved from the mainframe to the personal
computer, with some predicting the end of the server. This is akin to
processing moving from the web server to the rich web client. The
development of client/server systems resulted in a shared infrastructure.
However, you give up a lot of control, so eventually some of the work
returns to the server, and distributed systems begin to take shape.
The web was a restart. It had no respect for the mainframe, but it did
start over with a central computer... this time based on Unix and quickly
thereafter, Windows. The architecture was centralized. We had returned to
1975. Most of the first wave of the web was based on the model of
centralized computing.
Web 2.0 sees a resurgence in interest in moving processing off of the center
and move it back to the edge. Browser programming capabilities have been
present for a long time, but the idea for Ajax took off organically soon
after Google demonstrated what could be done in a cross-platform brower like
Firefox. All of a sudden, Javascript was not a proprietary technology and
Google had shown the world how to do this right. The growth of AJAX and RSS
are part of this trend.
I pin my longer term expectations on web services and SOA as the distributed
systems model that will, eventually, emerge as the clear consensus
architecture for the majority of non-trivial systems. It is a LOT like
CORBA and COM in many respects.
It's deja vu' all over again.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
Nick Malik [Microsoft]
> Nick,
>
> This is a common misconception. updatableViews lets clarify the name.
> An updatableView is something which allows you to insert/delete and
> update in a view( which is an arbitrary join of tables) as if you
> where working with a table. Micro$ doesnt deliver anything like that
> yet. Maybe if they understand what it is, they might in the future :-)
>
> Or maybe you show me how to work with a view of 4 related tables,
> inserting a few records in all tables, including new records related
> to new records in other tables and then and let the Dataset handle the
> sequence of inserts ?
>
>
> Rick
>
Hello Rick,
Perhaps we start by easing up on the MS-bashing a bit.
I was mistaken in my interpretation of the noun 'updatableView' and offered
an incorrect answer. The term is not common as far as I can tell, and I was
not able to find it readily defined any reference works, including
Wikipedia, at the time of this writing. Therefore, I guessed as to your
intended meaning and, apparently, my guess was incorrect. My regrets.
That said, my reply is hardly evidence of a failure to understand the
problem or to offer a solution to it.
In your example, you have a join of four tables. Now, normally a simple
join of four tables produces a wide and flat result set with column values
that repeat depending on the origin table's position in the query. The
problem with inserting a row in this wide and flat result is the fact that
the values are not deterministic in their distribution. Additional mapping
logic has to be specified to allow the 'shredding' of the new data into
proper tables. The problem comes when you attempt to create this mapping
logic, because it is difficult to create a deterministic mechanism for
describing the shredding process given the artificial constraint of a wide
and flat result set.
To truly make updatable views deterministic, you need your result set to be
more complex than a flat result set... you need a hierarchical result set.
With that result, adding elements and changing elements in the data and
sending it back to the database should cause data to be inserted in the
correct tables in the relational model.
The feature that I describe is called 'Using an Annotated Schema with SQL
Server 2005'
See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sql25xmlbp.asp
This is a built-in feature of SQL Server 2005.
Please let me know if there is a business benefit of your concept of
'updatableView' that cannot be met through the XML capabilities of SQL
Server.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
Nick Malik [Microsoft]
news:1158615511.9...@h48g2000cwc.googlegroups.com...
> Phlip wrote:
>>
>> I tend to ask "Have you read /Design Patterns/" as short-hand for "Have
>> you
>> seen examples of OO techniques being used correctly, to simplify
>> programs?"
>>
>
> Like I said elsewhere, the Design Patterns books is geared toward
> systems software. It's lessons so far appear not applicable to other
> domains, such as custom business software. I do not question OO's
> abilities for systems software, but that is not my domain.
>
Well, you've answered my original question. Many if not most of the
examples of design patterns in the DP literature (both the DP book and other
books) use business software examples. Note: I consider systems software to
mean "operating systems" as in device drivers, hardware abstraction layers,
file storage drivers, system navigation and configuration functions, etc.
(before someone jumps on me, being from Microsoft: I consider things like
browsers and media players to be "extra features," like the radio that you
get when you buy a new car... you can get the car without it, but why would
you... And most people are happy with the one that comes with the car. You
haven't seen Bose complain because Toyota includes a Japanese radio
"bundled" in their new cars.)
I do not consider graphics packages, personnel systems, inventory systems,
and the like, to be systems software. Examples of using OO in these cases
abound.
So, the answer you gave is the one I expected: No. You have made no real
attempt to understand that which you criticize.
Look: I've listened to you, and tried to understand your viewpoint. I am a
fair person. On occasion, you make a good point. But most of the time, I
cannot imagine how you are drawing the conclusions you are drawing. I can
only assume you are considering different input than I am... or following
different logic. An understanding of Object Oriented software appears to be
one of the inputs on which our understanding varies. Perhaps our criteria
for a good result varies as well. I don't believe, from your words, that
you understand OO software. Perhaps I am wrong, but I do not believe that
to be the case.
You have every right to be here, and to discuss issues as you do. However,
it is difficult to convince anyone, or even earn a minimum of respect, when
you speak poorly of techniques that you cannot speak well of.
topmind
> "topmind" <top...@technologist.com> wrote in message
> news:1158615511.9...@h48g2000cwc.googlegroups.com...
> > Phlip wrote:
> >>
> >> I tend to ask "Have you read /Design Patterns/" as short-hand for "Have
> >> you
> >> seen examples of OO techniques being used correctly, to simplify
> >> programs?"
> >>
> >
> > Like I said elsewhere, the Design Patterns books is geared toward
> > systems software. It's lessons so far appear not applicable to other
> > domains, such as custom business software. I do not question OO's
> > abilities for systems software, but that is not my domain.
> >
>
> Well, you've answered my original question. Many if not most of the
> examples of design patterns in the DP literature (both the DP book and other
> books) use business software examples. Note: I consider systems software to
> mean "operating systems" as in device drivers, hardware abstraction layers,
> file storage drivers, system navigation and configuration functions, etc.
>
> I do not consider graphics packages, personnel systems, inventory systems,
> and the like, to be systems software. Examples of using OO in these cases
> abound.
Note that I said *custom* business software. This would not include
graphics packages. Most businesses are not going to pay somebody to
build Adobe Photoshop from scratch for their internal stuff (yes, there
are probably rare exceptions.)
If they "abound", where are they?
>
> So, the answer you gave is the one I expected: No. You have made no real
> attempt to understand that which you criticize.
You have not pointed out specifics. Can you name at least 3 GOF
patterns that are shown with custom biz examples *in* the GOF book?
>
> Look: I've listened to you, and tried to understand your viewpoint. I am a
> fair person. On occasion, you make a good point. But most of the time, I
> cannot imagine how you are drawing the conclusions you are drawing. I can
> only assume you are considering different input than I am... or following
> different logic. An understanding of Object Oriented software appears to be
> one of the inputs on which our understanding varies. Perhaps our criteria
> for a good result varies as well. I don't believe, from your words, that
> you understand OO software. Perhaps I am wrong, but I do not believe that
> to be the case.
You have not presented a single public-viewable example of OO being
better at custom biz-ware. I don't want to remenis about what I did in
1999. Why the hell should I? I cannot even spell remenis.
>
> You have every right to be here, and to discuss issues as you do. However,
> it is difficult to convince anyone, or even earn a minimum of respect, when
> you speak poorly of techniques that you cannot speak well of.
Screw words then and show code. Show me OO code being better for custom
biz apps. If you cannot deliver, then we should part ways.
-T-
verm...@gmail.com
any conversation going on here and say something that's blindingly
obvious to everyone else. I think may be what I'm about to do.
>>> Like I said elsewhere, the Design Patterns books is geared toward
>>> systems software. It's lessons so far appear not applicable to other
>>> domains, such as custom business software. I do not question OO's
>>> abilities for systems software, but that is not my domain.
*snip*
> If they "abound", where are they?
If you're looking for examples of GOF patterns in business software,
have you checked out Craig Larman's book?
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691
If I remember correctly, he builds up a POS system design from the
ground up in the book using many of the GOF patterns.
topmind
> You know, the beauty of these newsgroups is that anybody can jump in on
> any conversation going on here and say something that's blindingly
> obvious to everyone else. I think may be what I'm about to do.
>
> >>> Like I said elsewhere, the Design Patterns books is geared toward
> >>> systems software. It's lessons so far appear not applicable to other
> >>> domains, such as custom business software. I do not question OO's
> >>> abilities for systems software, but that is not my domain.
>
> *snip*
>
> > If they "abound", where are they?
>
> If you're looking for examples of GOF patterns in business software,
> have you checked out Craig Larman's book?
>
> http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691
>
> If I remember correctly, he builds up a POS system design from the
> ground up in the book using many of the GOF patterns.
Are you confident that the POS design is better than an equivalent
procedural/relational version of the same thing? Remember, I don't
question that design patterns run and produce the correct output.
Running is not the issue. The issue is whether it is better from a
programmer productivity and/or software *maintenance* point of view.
Thus, before I fork over the money and time for such a book, I shall
request some specifics about what to look for and what to compare and
what kind of metric you are using. Does the author provide the
comparison and metrics? If not, where do I get them from?
I believe these are fair questions.
(I think I browsed that book in the store once and was not very
impressed with it, but can't remember why at the moment.)
-T-
Craig Vermeer
> verm...@gmail.com wrote:
>> You know, the beauty of these newsgroups is that anybody can jump in on
>> any conversation going on here and say something that's blindingly
>> obvious to everyone else. I think may be what I'm about to do.
>>
>>>>> Like I said elsewhere, the Design Patterns books is geared toward
>>>>> systems software. It's lessons so far appear not applicable to other
>>>>> domains, such as custom business software. I do not question OO's
>>>>> abilities for systems software, but that is not my domain.
>> *snip*
>>
>>> If they "abound", where are they?
>> If you're looking for examples of GOF patterns in business software,
>> have you checked out Craig Larman's book?
>>
>> http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691
>>
>> If I remember correctly, he builds up a POS system design from the
>> ground up in the book using many of the GOF patterns.
>
> Are you confident that the POS design is better than an equivalent
> procedural/relational version of the same thing? Remember, I don't
> question that design patterns run and produce the correct output.
> Running is not the issue. The issue is whether it is better from a
> programmer productivity and/or software *maintenance* point of view.
>
Am _I_ confident? Sure, but I like OO programming more than I like
procedural programming. I was just giving what I seem to remember as an
example of successfully applying OO techniques to a business app. As
with any implementation (OO or otherwise), I'm sure that people could
pick it apart and point out ways to make it better.
> Thus, before I fork over the money and time for such a book, I shall
> request some specifics about what to look for and what to compare and
> what kind of metric you are using. Does the author provide the
> comparison and metrics? If not, where do I get them from?
>
Nope, because the point of his book wasn't to compare OO and procedural
programming as to which is 'better'. The book was about applying UML
and GOF patterns to software design and implementation.
topmind
> > Thus, before I fork over the money and time for such a book, I shall
> > request some specifics about what to look for and what to compare and
> > what kind of metric you are using. Does the author provide the
> > comparison and metrics? If not, where do I get them from?
> >
>
> Nope, because the point of his book wasn't to compare OO and procedural
> programming as to which is 'better'. The book was about applying UML
> and GOF patterns to software design and implementation.
Again, I don't question that OO based on UML can be made to run and
produce the correct output. But, that is not the issue at hand.
Assembly language can also be made to run and produce the correct
output. But, I don't want to program in assembly because my
productivity is low in it, both for creation and maintenance.
(A lot of UML is more or less Entity-Relationship diagrams with
different symbols, I would note. Mirroring database schemas in
application code is poor abstraction and unnecessary duplication of
structure much of the time.)
>
> > I believe these are fair questions.
> >
Thank you for your opinion.
-T-
Craig Vermeer
> Craig Vermeer wrote:
>
>>> Thus, before I fork over the money and time for such a book, I shall
>>> request some specifics about what to look for and what to compare and
>>> what kind of metric you are using. Does the author provide the
>>> comparison and metrics? If not, where do I get them from?
>>>
>> Nope, because the point of his book wasn't to compare OO and procedural
>> programming as to which is 'better'. The book was about applying UML
>> and GOF patterns to software design and implementation.
>
> Again, I don't question that OO based on UML can be made to run and
> produce the correct output. But, that is not the issue at hand.
> Assembly language can also be made to run and produce the correct
> output. But, I don't want to program in assembly because my
> productivity is low in it, both for creation and maintenance.
>
'better'. I was just trying to provide a data point that you may or may
not have been aware of regarding examples of patterns in business
software, and not trying to address all of the issues you raise in the
larger debate. Again, the beauty of having a few thousand people
listening in on the conversation is that anyone can jump in and
contribute as little as they want :-D
I know _I_ write better software using OO than I did using procedural
programming, but then again as I gained experience I moved toward OO, so
it may be a chicken and egg thing where my additional experience is
the main reason for better software. YMM(and obviously does)V.
topmind
> topmind wrote:
> > Craig Vermeer wrote:
> >
> >>> Thus, before I fork over the money and time for such a book, I shall
> >>> request some specifics about what to look for and what to compare and
> >>> what kind of metric you are using. Does the author provide the
> >>> comparison and metrics? If not, where do I get them from?
> >>>
> >> Nope, because the point of his book wasn't to compare OO and procedural
> >> programming as to which is 'better'. The book was about applying UML
> >> and GOF patterns to software design and implementation.
> >
> > Again, I don't question that OO based on UML can be made to run and
> > produce the correct output. But, that is not the issue at hand.
> > Assembly language can also be made to run and produce the correct
> > output. But, I don't want to program in assembly because my
> > productivity is low in it, both for creation and maintenance.
> >
> And I wasn't questioning your stance that procedural programming is
> 'better'. I was just trying to provide a data point that you may or may
> not have been aware of regarding examples of patterns in business
> software, and not trying to address all of the issues you raise in the
> larger debate.
Okay. If your point is that biz examples exist in OO books, regardless
of whether they are evidence of betterment or not, then I generally
concur. Martin Fowler also has a book or two with biz examples, I
would note.
> Again, the beauty of having a few thousand people
> listening in on the conversation is that anyone can jump in and
> contribute as little as they want :-D
Few thousand? I don't think too many people care what we say here. We
are boring and bicker too much. Maybe a hundred or so when the weather
outside is bad.
>
> I know _I_ write better software using OO than I did using procedural
> programming, but then again as I gained experience I moved toward OO, so
> it may be a chicken and egg thing where my additional experience is
> the main reason for better software. YMM(and obviously does)V.
If you could turn that knowledge into publicly-inspectable examples
comparing and demonstrating clear benefits, that would be great (and
rare). You would be going where no man has gone before, without even
leaving the Blue Planet.
>
> > (A lot of UML is more or less Entity-Relationship diagrams with
> > different symbols, I would note. Mirroring database schemas in
> > application code is poor abstraction and unnecessary duplication of
> > structure much of the time.)
> >
> >>> I believe these are fair questions.
> >>>
> >
> > Thank you for your opinion.
Ditto.
-T-