Whose Fish?

http://www.coudal.com/thefish.php

I was once given this question at a job interview (my boss liked to
stress people out). Although I didn't finish the question during the
interview, I still got the job.

So this weekend I created an OO program that solves the problem within
1 to 29 seconds, depending on what order my attributes are initially
entered.

Mine is totally OO and uses no relation database at all, however, it
seems like a great problem to throw at a relational database, which I
would guess may be able to solve it faster.

Any takers? <ahem> ;^)


Jordan

On May 9, 10:43 am, Jordan Marr <jnm...{}hotmail.com> wrote:
> http://www.coudal.com/thefish.php
>
> I was once given this question at a job interview (my boss liked to
> stress people out). Although I didn't finish the question during the
> interview, I still got the job.
>
> So this weekend I created an OO program that solves the problem within
> 1 to 29 seconds, depending on what order my attributes are initially
> entered.
>
> Mine is totally OO and uses no relation database at all, however, it
> seems like a great problem to throw at a relational database, which I
> would guess may be able to solve it faster.
>
> Any takers? <ahem> ;^)
>
> Jordan

Personally, I don't think these kinds of puzzles are very useful for
comparing the real-world utility of paradigms. Perhaps they are good
for training newbies or practicing concepts, but *not* for comparing
the relative *value* of techniques in a realistic setting/domain.
They are sort of analogous to slam-dunk contests to the game of
basketball. The best slam-dunker is not necessarily the best player. I
have similar complaints about the shape, animal, and device-driver
examples heavily used in OO books.

(BTW, I submitted my source-coded version of Robert C. Martin's
payroll example here a few weeks ago in an attempt to spark debate on
a semi-realistic example.)

-T-

> 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".


> Perhaps they are good
> for training newbies or practicing concepts, but *not* for comparing
> the relative *value* of techniques in a realistic setting/domain.

If this is "newbie training" then you should have no problems
designing a solution.

Btw, this NG is not called "comp.object.businessapps", it's called
"comp.object". You continually try to shove every thread you
participate in to your little "business app domain" where they don't
all belong.

> They are sort of analogous to slam-dunk contests to the game of
> basketball. The best slam-dunker is not necessarily the best player. I
> have similar complaints about the shape, animal, and device-driver
> examples heavily used in OO books.

Relax, I'm not attacking your programming style of choice! I
genuinely want to see this problem solved with a DB. I know it can be
done, and it may even work better. This is supposed to be a fun,
intellectual challenge.

But you are so used to disagreeing with everyone that you are not
seeing it that way.

You're the one that comes in here and attacks OOP on an OOP discussion
board. If you are going to come in with your big soap box rants, why
do you think YOU get to set all the parameters? "No no, it CAN'T be a
shapes app.. it CAN'T be this.. it CAN'T be about variations..."

Guess what? IT CAN.

That's like someone trying to show me the "ultimate defensive fighting
maneuver" and saying, "attack me! No.. you can't attack me that way!
Attack me with your LEFT hand.. yeah.. BAM! I win again!!"


> (BTW, I submitted my source-coded version of Robert C. Martin's
> payroll example here a few weeks ago in an attempt to spark debate on
> a semi-realistic example.)

Like I said... that has zero to do with THIS thread. Thank you. Oh
right, you're trying to stand on the nearly off topic soap box AND
control the parameters of the argument at the same time. ;^)

Jordan

> 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*."



Jordan

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).

>
> Jordan

-T-

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.

>
> > Perhaps they are good
> > for training newbies or practicing concepts, but *not* for comparing
> > the relative *value* of techniques in a realistic setting/domain.
>
> If this is "newbie training" then you should have no problems
> designing a solution.

I don't care about solving training/lab examples anymore. That was 20
odd years ago. I care about real-world stuff now. A tool that helps me
insert my knee into my ear is not going to be of much use unless I
join the circus.

>
> Btw, this NG is not called "comp.object.businessapps", it's called
> "comp.object". You continually try to shove every thread you
> participate in to your little "business app domain" where they don't
> all belong.

But there is already a glut of lab/training examples. We need more of
them like holes in the head.

>
> > They are sort of analogous to slam-dunk contests to the game of
> > basketball. The best slam-dunker is not necessarily the best player. I
> > have similar complaints about the shape, animal, and device-driver
> > examples heavily used in OO books.
>
> Relax, I'm not attacking your programming style of choice! I
> genuinely want to see this problem solved with a DB. I know it can be
> done, and it may even work better. This is supposed to be a fun,
> intellectual challenge.
>
> But you are so used to disagreeing with everyone that you are not
> seeing it that way.

No, I am right. It's that simple.

>
> You're the one that comes in here and attacks OOP on an OOP discussion
> board. If you are going to come in with your big soap box rants, why
> do you think YOU get to set all the parameters? "No no, it CAN'T be a
> shapes app.. it CAN'T be this.. it CAN'T be about variations..."
>
> Guess what? IT CAN.

I didn't "set all the parameters". I simply gave an opinion on
something. If you don't like my opinion, then either challenge it
directly on the topic, or ignore it. Complaining about me complaining
is recursive hypocracy. If you feel a rant is off topic or
unimportant, simply ignore it. Ranting about rants just leads to more
rants.

>
> That's like someone trying to show me the "ultimate defensive fighting
> maneuver" and saying, "attack me! No.. you can't attack me that way!
> Attack me with your LEFT hand.. yeah.. BAM! I win again!!"
>
>
> > (BTW, I submitted my source-coded version of Robert C. Martin's
> > payroll example here a few weeks ago in an attempt to spark debate on
> > a semi-realistic example.)
>
> Like I said... that has zero to do with THIS thread. Thank you. Oh
> right, you're trying to stand on the nearly off topic soap box AND
> control the parameters of the argument at the same time. ;^)
>
> Jordan

-T-
oop.ismad.com

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".

Actually, this puzzle is very "real world" .
And here is a USA-specific example :

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

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.

> 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.
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.


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.
What is that now? Variance apps, drivers, reusable frameworks, CAD
based, and ANYTHING other that CRUD "business apps".

Nice. Where do I sign up?!

Jordan

> 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!).

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!

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.



Jordan


>
> 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).
>
>
>
> > Jordan
>
> -T-