Whose Fish?

> > What is not "real world" about solving variance problems? There are
> > plenty of business uses here. Oh wait, you must mean "real world", as
> > in "Topmind's world".
>
> Actually, this puzzle is very "real world" .
> And here is a USA-specific example :

It really is; but you have to be an abstract thinker to be able to
look at a very specific problem (ex: "whose fish"), and be able to
abstract it into a generic variance problem framework. The ability to
solve this example is the ability to solve many "paying" i.e. business
problems. In your example we're getting into US government level
problems. Hooketh me up!!

> In IEEE Spectrum last year (I don't recall if it was the issue focussing on
> counter-terrorism or just a regular article - I think it was the former) ,
> there was an article regarding a company who had a system that was building
> an info base of facts akin to the puzzle, that could then establish
> relationships between entities in the info base.
>
> This system was being used for intelligence/counter-terrorism purposes (the
> system also had a good feature in that it was able to 'anonymise' the info
> base so that the query/execution engine operated without revealing
> human-valued data - names, addresses, acquaintances, bank accounts etc) .
>
> Regarding best implementation, declarative systems (logic programming etc)
> are usually best-suited for solving problems akin to the puzzle
>
> [ Complaints about topmind always attempting to change the goal-posts
> regarding any problem domain other than the ill-defined "biz app" ,
> snipped but read and acknowledged. ]
>
> Regards,
> Steven Perryman

Jordan Marr wrote:
> > It is *not* representative of the apps and issues I have faced. Maybe
> > I live in a bubble somehow, but perhaps you do also. If I can be
> > mislead, so can you. You are not the center of the universe; we each
> > only have one lifetime to live.
>
> MOST of the business apps I have coded have been pretty straight
> forward CRUD style apps, current project included. I'm not cocky
> enough to say I've mastered those, but I feel pretty confident in
> them.

CRUD apps are often not trivial because they are often marred in tons
of funny little business rules. I often consider business modeling the
modeling of the current manager's/owner's/customer's personality and
whims rather than a striving for a "one true" math or science.

Sometimes techies will indeed say, "this is what the framework gives
you and you will live with it", which simplifies developement (at
least initially), but users are not happy with such.

I will agree they were simpler in the pre-web days because desktop
GUI's were easier and richer than the web equivalent (although harder
to deploy), but funny little biz rules and exceptions to the rules
still complicated things.

If it was easy, it would all be automated by now. I find most CRUD
abstractions fall prey to the 80/20 rule where the abstraction handles
80% of the cases, but 20% muck it up and need nitty gritty diddling.

> But I have also worked on some reallllly cool apps, and this example
> could easily factor in to one of the cooler projects I aspire to work
> on in my career. You know, the "fun stuff" that you still get paid
> for. (Actually, I find all programming fun, even the CRUD stuff is
> entertaining to me).
>
> It seems like your mission on here is to fix something that's not
> broken. Most programmers already know how to program CRUD business
> apps, so you're beating a dead horse.

Many also do a bad job on them. They may "run", but maintainability is
out the door.

>
> So let's go ahead and add "apps that deal with variance" to your ever
> growing list of apps that PR can't deal with well.

Reframe your example in terms of a fairly common business need/example
instead of classroom back-page stuff, and maybe I will comment on it.
Otherwise, failing to comment on it does not necessarily make PR flunk
it. If it is a common biz need like you imply, then such a reframing
should be fairly easy for you. Why produce shapes and animals when you
can do invoices, orders, products, etc. to illustrate the same
thing???

> What is that now? Variance apps, drivers, reusable frameworks, CAD
> based, and ANYTHING other that CRUD "business apps".

Let's see your reusable CRUD framework that bends to user requirements
well. Dispite the prevalence of CRUD, nobody has mastered such a
framework. The most effective, or at least popular, solutions seemed
to be things like Visual Basic and PowerBuilder that let one create
crap fast. Businesses figure if the end result is always messy, you
might as well make creating that mess a quicker process. If you have
to go to the dentist for a root-canal, might as well take the short
road.

>
> Nice. Where do I sign up?!
>
> Jordan

-T-

On 9 May 2007 22:04:13 -0700, topmind <topmind{}technologist.com>
wrote:

>
>Jordan Marr wrote:
>> > Personally, I don't think these kinds of puzzles are very useful for
>> > comparing the real-world utility of paradigms.
>>
>> What is not "real world" about solving variance problems? There are
>> plenty of business uses here. Oh wait, you must mean "real world", as
>> in "Topmind's world".
>
>It is *not* representative of the apps and issues I have faced. Maybe
>I live in a bubble somehow, but perhaps you do also. If I can be
>mislead, so can you. You are not the center of the universe; we each
>only have one lifetime to live.
>

Sorry I managed to delete the first few posts in the thread, so this
post is really directed at the first one as well as this one.

In my mind there are two issues that I have problems with. The first
one is where someone is trying to convert a 'logic' problem to an OO
one. I have an issue with this because to me, logic is not
condusive to facilitating object oriented conceptualising which as far
as I am concerned requires a great deal of fuzzyness.

To me, logic will always equate to procedural thinking (and should not
be equated to being a bad thing - it is, in its place a good thing).
But I will say that to me an object may contain logic parts and in
that regard one could also say that an object may contain procedural
parts, but that does not mean to me that objects are always logical
entities.

I have noticed over the years that some people require contextual
detail when doing OO and some people don't. I wonder if that culture
defines whether someone does OO following rigerous methods and
techniques (OO Principles) or if they just go with the flow so to
speak. i.e. does the 'context' of ones culture (whether they are
naturally high or low context people) affect the way people approach
OO.


The second issue more directly relates the problem being solved to the
solution provided. That is, to me this type of problem (logic
problems) are usually solved by some form of mathematical equation.
I think that in software development I have always referred to these
types of equations as 'algorithms' which are usually I think
implemented in a single high level function call (often to a bunch of
smaller detailed function calls). Given this, I cant say how one
could claim to have developed an object oriented solution when
implementing a single algorithm when the whole meta structure of
executing an algorigm is nothing more (to me) than the procedural
implementation of a logical set of steps (calculations). I think
one could say they have used object oriented techniques to solve the
problem (such as encapsulation, polymorphism and abstraction), but I
dont think one should suggest that the result is in its nature object
oriented, as I do not see an algorithm as being 'oriented towards
objects' (its more oriented towards being a service) since it can be
executed as a function/method call which to me at best perhaps is
merely part of an object.





----------------
AndyW,
Mercenary Software Developer

Jordan Marr wrote:
> > Fine, if you are the one in a hundred who are actually writing an
> > animal, shape, or device driver app, use OO.
>
> I don't write drivers, but writing reusable frameworks is basically
> the same, and I do write those all the time. The idea is, instead of
> solving a problem once in a very app specific way, you abstract and
> encapsulate the solution to the problem in a OO way that is reusable
> for ANY problem (especially including business domain problems!).

"Reuse" has seemed to fall out of favor as a top claim of OOP.
("Making programs easier to change" seems to be the top claim by my
observation in many debates, closely followed by "models human
thinking better"[1].) Even OO proponents generally don't claim reuse
improvement much anymore. If you wish to show OO being better reuse,
be my guest.

>
> In fact, to solve this "unrealistic" problem, I reused my very own OO
> <gasp!> reusable <gasp!> business framework<gasp!>, and I also created
> a new reusable OO class that I will most certainly use at some point
> in the future on a... you guessed it... business app!

Sounds great. Now show the code and show how it kicks P/R's butt. I
finished my example with runnable source code (R. Martin's payroll).
Your turn. Verbal claims don't cut it here.

>
> Yeah, that's right, because the definition of "business app" really ==
> "any project that is important enough to be funded". So I'm coming
> out of this exercise ahead and more OO for the wear.
>

Not usable info.

>
> Jordan
>

[1] This is perhaps true on a relative scale. OO may indeed model some
people's head better, but you can't assume everybody's head is the
same. This issue is one of the reasons I chose "topmind" as my handle:
because my head best fits Table Oriented Programming.

-T-

Daniel T. wrote:
> topmind <topmind{}technologist.com> wrote:
>
> > On May 9, 11:32 am, Jordan Marr <jnm...{}hotmail.com> wrote:
> > > > I have similar complaints about the shape, animal, and device-driver
> > > > examples heavily used in OO books.
> > >
> > > Sentence should read:
> > >
> > > "I have similar complaints about the shape, animal, and device-driver
> > > examples heavily used in *real-life*."
> >
> > Fine, if you are the one in a hundred who are actually writing an
> > animal, shape, or device driver app, use OO.
> >
> > In biology, there are actually usually multiple candidate taxonomies
> > such that it is not a clean tree. I think it would be better to keep
> > such info in a database so that different researchers can access them
> > with different tools rather than force them all to use Java or Python,
> > etc.
> >
> > Further, most device driver writers are being outsourced to 3rd world
> > anyhow. The further you are from end-user requirements, the more
> > likely your job is to be offshored (for good or bad).
>
> I think it is important to remember why Simula was developed in the
> first place. If your problem domain does not involve doing simulations,
> then OO may very well not be appropriate.

If the industry agreed that OO generally only shines for physical
simulations and not push it into nearly all domains, then I would not
be ranting against it. You may feel it is meant for mostly physical
niches, but that is not the consensus among OO proponents

-T-

> > I don't write drivers, but writing reusable frameworks is basically
> > the same, and I do write those all the time. The idea is, instead of
> > solving a problem once in a very app specific way, you abstract and
> > encapsulate the solution to the problem in a OO way that is reusable
> > for ANY problem (especially including business domain problems!).
>
> "Reuse" has seemed to fall out of favor as a top claim of OOP.
> ("Making programs easier to change" seems to be the top claim by my
> observation in many debates, closely followed by "models human
> thinking better"[1].) Even OO proponents generally don't claim reuse
> improvement much anymore. If you wish to show OO being better reuse,
> be my guest.

These days every program consists of two or three parts:
Language Framework: the framework of preexisting *reusable* classes
provided by the language developer. This framework is OO and
excercises the *reuse* that I am touting.

User Frameworks: frameworks created by users. These can be pre-
existing frameworks that were created before the project that are
generic and abstract enough to be reused to solve the same kinds of
problems continually. An example would be a business framework that
encapsulates dealing with business validation rules. In my mind this
also includes the business domain layer, which can serve multiple apps
(but usually only serves one).

The Application itself: This is where the procedural programming
comes into play. This layer calls upon all the framework objects it
needs to solve the needs of the application at hand.
When I start an app I first check to see if the tools I need to solve
the problem already exist in the language framework. If I need more
tools, my next stop is to look in the public domain arena for well
abstracted classes that are generic enough to be resued in my app.
Finally, if none exist, I create my own reusable object.

As an example, say my app requires that I pick a random number between
1 and 10,000. First I would look to the language framework for a
random number generator (which .net has one already). An object
should have one purpose, and .net's random number generator does just
that.. this allows it to be used in many projects.

If a random generator did not exist, I would create my own reusable
random generator class, and then plug it into my app.

Now, what many non OO people would do is to write the random number
generator algorithm directly inside their application layer
somewhere... perhaps they parameterize it and put it in a method
somewhere, or even worse, maybe they integrate the algorithm right in
with the button even where it is required.

> Sounds great. Now show the code and show how it kicks P/R's butt. I
> finished my example with runnable source code (R. Martin's payroll).
> Your turn. Verbal claims don't cut it here.

OK, but I don't really have anywhere to post it unless I simply post
the source here.

Jordan

> CRUD apps are often not trivial because they are often marred in tons
> of funny little business rules. I often consider business modeling the
> modeling of the current manager's/owner's/customer's personality and
> whims rather than a striving for a "one true" math or science.
>
> Sometimes techies will indeed say, "this is what the framework gives
> you and you will live with it", which simplifies developement (at
> least initially), but users are not happy with such.

Artificial constraints (technology or whatever) should never define
the results. I believe the results should be stated ideally, and then
everyone should strive to satisfy that goal.

A good app meets every last one of the client's needs as stated in the
specs, regardless of whether its P/R or OO.

> I will agree they were simpler in the pre-web days because desktop
> GUI's were easier and richer than the web equivalent (although harder
> to deploy), but funny little biz rules and exceptions to the rules
> still complicated things.

Indeed.

> If it was easy, it would all be automated by now. I find most CRUD
> abstractions fall prey to the 80/20 rule where the abstraction handles
> 80% of the cases, but 20% muck it up and need nitty gritty diddling.

I agree.

> > It seems like your mission on here is to fix something that's not
> > broken. Most programmers already know how to program CRUD business
> > apps, so you're beating a dead horse.
>
> Many also do a bad job on them. They may "run", but maintainability is
> out the door.

I agree, many do a horrible job. I always strive for maintainability
while designing and coding a problem.. The temptation is always there
to take a shortcut and simply solve the problem at the expense of
future maintainability. But a little bit of forethought can really do
a lot for the future of an app!

> Reframe your example in terms of a fairly common business need/example
> instead of classroom back-page stuff, and maybe I will comment on it.
> Otherwise, failing to comment on it does not necessarily make PR flunk
> it. If it is a common biz need like you imply, then such a reframing
> should be fairly easy for you. Why produce shapes and animals when you
> can do invoices, orders, products, etc. to illustrate the same
> thing???

Once again, you want me to conform to your conditions, and then,
MAYBE, you will grace me with a comment! lol. That is rich!

No, reframing that question would NOT be fairly easy, and I can see it
would be a waste of my time, as you would probably just dismiss it for
one reason or another.

While I will not re create a perfectly good problem, I will suggest a
possible variation of the problem and let your imagination do the
rest:

Consider the human genome project. Goals:
- identify all the approximately 20,000-25,000 genes in human DNA
- determine the sequences of the 3 billion chemical base pairs that
make up human DNA
- store this information in databases
- improve tools for data analysis

Notice they said "store" this information in a database. hehe.

This problem is very similar to "whose fish", and you can't see why,
I'm not telling you! ;^)

> Let's see your reusable CRUD framework that bends to user requirements
> well. Dispite the prevalence of CRUD, nobody has mastered such a
> framework. The most effective, or at least popular, solutions seemed
> to be things like Visual Basic and PowerBuilder that let one create
> crap fast. Businesses figure if the end result is always messy, you
> might as well make creating that mess a quicker process. If you have
> to go to the dentist for a root-canal, might as well take the short
> road.

My apps bend just fine to user requirements. That's why I have so
much time to debate with you.


Jordan

Jordan Marr wrote:
> > > I don't write drivers, but writing reusable frameworks is basically
> > > the same, and I do write those all the time. The idea is, instead of
> > > solving a problem once in a very app specific way, you abstract and
> > > encapsulate the solution to the problem in a OO way that is reusable
> > > for ANY problem (especially including business domain problems!).
> >
> > "Reuse" has seemed to fall out of favor as a top claim of OOP.
> > ("Making programs easier to change" seems to be the top claim by my
> > observation in many debates, closely followed by "models human
> > thinking better"[1].) Even OO proponents generally don't claim reuse
> > improvement much anymore. If you wish to show OO being better reuse,
> > be my guest.
>
> These days every program consists of two or three parts:
> Language Framework: the framework of preexisting *reusable* classes
> provided by the language developer. This framework is OO and
> excercises the *reuse* that I am touting.
>
> User Frameworks: frameworks created by users. These can be pre-
> existing frameworks that were created before the project that are
> generic and abstract enough to be reused to solve the same kinds of
> problems continually. An example would be a business framework that
> encapsulates dealing with business validation rules. In my mind this
> also includes the business domain layer, which can serve multiple apps
> (but usually only serves one).
>
> The Application itself: This is where the procedural programming
> comes into play. This layer calls upon all the framework objects it
> needs to solve the needs of the application at hand.
> When I start an app I first check to see if the tools I need to solve
> the problem already exist in the language framework. If I need more
> tools, my next stop is to look in the public domain arena for well
> abstracted classes that are generic enough to be resued in my app.
> Finally, if none exist, I create my own reusable object.
>
> As an example, say my app requires that I pick a random number between
> 1 and 10,000. First I would look to the language framework for a
> random number generator (which .net has one already). An object
> should have one purpose, and .net's random number generator does just
> that.. this allows it to be used in many projects.
>
> If a random generator did not exist, I would create my own reusable
> random generator class, and then plug it into my app.
>
> Now, what many non OO people would do is to write the random number
> generator algorithm directly inside their application layer
> somewhere... perhaps they parameterize it and put it in a method
> somewhere, or even worse, maybe they integrate the algorithm right in
> with the button even where it is required.

What is wrong with putting such in a function? An entire class is
overkill. Also, as far as reuse, I lean toward mix-and-match "helpers
instead of wrappers" because one-size-fits-all genericy is not a
realizable goal I've found out the hard way. More on this:

http://c2.com/cgi/wiki?HelpersInsteadOfWrappers

>
> > Sounds great. Now show the code and show how it kicks P/R's butt. I
> > finished my example with runnable source code (R. Martin's payroll).
> > Your turn. Verbal claims don't cut it here.
>
> OK, but I don't really have anywhere to post it unless I simply post
> the source here.

It's fairly easy to have your own web-log these days (if you don't
mind annoying ads).

>
> Jordan

-T-

> In my mind there are two issues that I have problems with. The first
> one is where someone is trying to convert a 'logic' problem to an OO
> one. I have an issue with this because to me, logic is not
> condusive to facilitating object oriented conceptualising which as far
> as I am concerned requires a great deal of fuzzyness.
>
> To me, logic will always equate to procedural thinking (and should not
> be equated to being a bad thing - it is, in its place a good thing).
> But I will say that to me an object may contain logic parts and in
> that regard one could also say that an object may contain procedural
> parts, but that does not mean to me that objects are always logical
> entities.

Andy,
In fact, all software applications have logic. They all have user
input, some sort of logic processing on the input, and finally some
sort of output, to the screen, printer, network, db, or somewhere. An
OO software without any logic would simple be a abstracted model of
the problem domain that didn't do anything!

> I have noticed over the years that some people require contextual
> detail when doing OO and some people don't. I wonder if that culture
> defines whether someone does OO following rigerous methods and
> techniques (OO Principles) or if they just go with the flow so to
> speak. i.e. does the 'context' of ones culture (whether they are
> naturally high or low context people) affect the way people approach
> OO.

I think that people who are not good at abstracting problems will
definitely be more productive writing strictly procedural code. Of
course they will have to master OO techniques only enough to
understand how to utilize the OO framework tools that are already in
place to help them. Those reusable framework tools are of course
created by abstract thinkers who intended to create a generic tool to
solve many peoples' problems, instead of the immediate issue at hand.

> The second issue more directly relates the problem being solved to the
> solution provided. That is, to me this type of problem (logic
> problems) are usually solved by some form of mathematical equation.
> I think that in software development I have always referred to these
> types of equations as 'algorithms' which are usually I think
> implemented in a single high level function call (often to a bunch of
> smaller detailed function calls). Given this, I cant say how one
> could claim to have developed an object oriented solution when
> implementing a single algorithm when the whole meta structure of
> executing an algorigm is nothing more (to me) than the procedural
> implementation of a logical set of steps (calculations).

It is all in how you percieve the problem domain and how you choose to
model it.

> I think
> one could say they have used object oriented techniques to solve the
> problem (such as encapsulation, polymorphism and abstraction), but I
> dont think one should suggest that the result is in its nature object
> oriented, as I do not see an algorithm as being 'oriented towards
> objects' (its more oriented towards being a service) since it can be
> executed as a function/method call which to me at best perhaps is
> merely part of an object.

Modelling the problem domain into software objects is IMO an OO
solution.

Jordan

> > I think it is important to remember why Simula was developed in the
> > first place. If your problem domain does not involve doing simulations,
> > then OO may very well not be appropriate.
>
> If the industry agreed that OO generally only shines for physical
> simulations and not push it into nearly all domains, then I would not
> be ranting against it. You may feel it is meant for mostly physical
> niches, but that is not the consensus among OO proponents

All problems model the physical domain and can be modelled in an OO
fashion.

Jordan