| Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#1
| |||
| |||
| 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 |
|
#2
| |||
| |||
| 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- |
|
#3
| |||
| |||
| > 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 |
|
#4
| |||
| |||
| > 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 |
|
#5
| |||
| |||
| 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- |
|
#6
| |||
| |||
| 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 |
|
#7
| |||
| |||
| 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 |
|
#8
| |||
| |||
| 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. |
|
#9
| |||
| |||
| > 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 |
|
#10
| |||
| |||
| > 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- |
![]() |
| Thread Tools | |
| Display Modes | |
In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.