Whose Fish?

Jordan Marr wrote:
> > 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.

I have to dissagree. It is not economical to supply all features as
requested. Compromises should be made and fitting the existing
technology should probably be part of it. I've seen time/money wasted
up the wazoo to cater to dumb whims of prima dona executives.

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

Spec-based development is sort of becomming a thing of the past
because if you have a clear spec, it is offshored. Thus, onshore
projects tend to be those that are more interactive (give-and-take) in
nature.

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

Its a matter of balance. There are extremists on both sides, such as
XP'ers who only impliment here-and-now requirements, and on the other
those who over-engineer the thing.

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

I am only stating the conditions on which I will respond. If you don't
like them, then simply ignore them. Its that simple.

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

As long as it is a good reason.

>
> 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! ;^)

But that's a very specialized domain. You would spend most of your
time educating the reader about biology and DNA. How are we going to
evaluate the frequency of suggested change scenarios if we are not
biologists? For that reason, it would probably not make a very good
example.

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

Yes, but that is still anecdotal evidence. Everybody claims their
favorite tool/paradigm is better and faster and cheaper, etc. We need
a way to evaluate such common claims in order to filter the hop from
the hype.

>
>
> Jordan


-T-

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

There is nothing "wrong" with parameterizing it and putting it in a
function inside the application layer, and in fact, many programmers
do just that.

But it does defeat the ability to easily reuse the existing code in
another application.

> An entire class is overkill.

I do not share your opinion here at all.

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

I do not advocate encapsulating everything into reusable objects all
the time. It's easy enough to go back and refactor code in this way
if needed.

I'm simply pointing out that intra-app code reuse is an OO advantage
that I often utilize.

There are some things that do not lend themselves to this kind of
reuse. Random number generation, OTOH, is a pretty generic concept.
The reusable object does not need any application specific code in
it. A well designed reusable framework will have virtual methods that
allow someone to import the object and still easily create a
descendent object with any application specific modifications
needed.

Jordan

On May 11, 8:12 am, Jordan Marr <jnm...{}hotmail.com> wrote:
> > > 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

They do? Stocks, debt, crime laws, software licenses, and sales credit
are not physical. Yes, we can model them with paper and clerks with
bins, but equivalency is not the same as being.

> and can be modelled in an OO
> fashion

I think it is understood we are talking about being "geared toward"
rather than merely running. Otherwise, it is just a declaration of
Turing Equivalency, which doesn't tell us anything useful. We already
know one can write a Smalltalk interpreter in Fortran and visa versa.

When one talks about physical simulation, generally they mean things
like modeling tugboat movement and loading docks.

>
> Jordan

-T-

On May 11, 9:36 am, Jordan Marr <jnm...{}hotmail.com> wrote:
> > > 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?
>
> There is nothing "wrong" with parameterizing it and putting it in a
> function inside the application layer, and in fact, many programmers
> do just that.
>
> But it does defeat the ability to easily reuse the existing code in
> another application.

How so? I don't know what difficulties or behavior you are mentally
comparing.

>
> > An entire class is overkill.
>
> I do not share your opinion here at all.
>
> > 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:
>
> I do not advocate encapsulating everything into reusable objects all
> the time. It's easy enough to go back and refactor code in this way
> if needed.
>
> I'm simply pointing out that intra-app code reuse is an OO advantage
> that I often utilize.
>
> There are some things that do not lend themselves to this kind of
> reuse. Random number generation, OTOH, is a pretty generic concept.
> The reusable object does not need any application specific code in
> it. A well designed reusable framework will have virtual methods that
> allow someone to import the object and still easily create a
> descendent object with any application specific modifications
> needed.
>
> Jordan

-T-

> > > 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
>
> They do? Stocks, debt, crime laws, software licenses, and sales credit
> are not physical. Yes, we can model them with paper and clerks with
> bins, but equivalency is not the same as being.

You can still model anything, physical or conceptual, in OO software.

On May 11, 5:01 pm, topmind <topm...{}technologist.com> wrote:
> On May 11, 9:36 am, Jordan Marr <jnm...{}hotmail.com> wrote:
>
> > > > 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?
>
> > There is nothing "wrong" with parameterizing it and putting it in a
> > function inside the application layer, and in fact, many programmers
> > do just that.
>
> > But it does defeat the ability to easily reuse the existing code in
> > another application.
>
> How so? I don't know what difficulties or behavior you are mentally
> comparing.
>
>
>
>
>
>
>
> > > An entire class is overkill.
>
> > I do not share your opinion here at all.
>
> > > 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:
>
> > I do not advocate encapsulating everything into reusable objects all
> > the time. It's easy enough to go back and refactor code in this way
> > if needed.
>
> > I'm simply pointing out that intra-app code reuse is an OO advantage
> > that I often utilize.
>
> > There are some things that do not lend themselves to this kind of
> > reuse. Random number generation, OTOH, is a pretty generic concept.
> > The reusable object does not need any application specific code in
> > it. A well designed reusable framework will have virtual methods that
> > allow someone to import the object and still easily create a
> > descendent object with any application specific modifications
> > needed.
>
> > Jordan
>
> -T-- Hide quoted text -
>
> - Show quoted text -

At least with parameterized methods you can copy and paste the source
code itself into another project. But most frameworks are precompiled
into their own library that can be easily distributed w/out the source
code.


Jordan

topmind <topmind{}technologist.com> wrote:
> Daniel T. wrote:

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

Wait, why the restriction of "physical" simulations? Simula and other OO
languages are excellent at modeling simulations, "physical" or otherwise.

On 11 May 2007 08:10:23 -0700, Jordan Marr <jnmarr{}hotmail.com> wrote:

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

Sorry, I think you may be missing my point. Back several decades ago
(before the OO craze), one wrote software using logic techniques taken
from mathematics. The perception then was that one needed to be good
at math to be able to write software as math taught the disciple of
using logical thought process. Thus, many of the programming
techniques were taken from math.

Given that, programming theory of the time stated that good code
consisted of a problem broken down into a clearly defined set of steps
set out in 'logical' order. This is the definition of logic that I am
using.

Later, in the 80s when the modern OO craze really started to take off,
there was a suggestion that the best OO practitioners seemed to not be
good at math. The hypothesis was that perhaps the more involved one
was in logic the harder it became to 'get' or understand the
principles of OO. That is, it was suggested that logical people
cannot abstract as well as those with no logic training.



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

On May 11, 2:42 pm, Jordan Marr <jnm...{}hotmail.com> wrote:
> > > > 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
>
> > They do? Stocks, debt, crime laws, software licenses, and sales credit
> > are not physical. Yes, we can model them with paper and clerks with
> > bins, but equivalency is not the same as being.
>
> You can still model anything, physical or conceptual, in OO software.


Again, Turing Equivalency does not tell us anything useful. We can
also write it all in Assembler language or BrainF*ck language.

-T-

On May 11, 5:40 pm, "Daniel T." <danie...{}earthlink.net> wrote:
> topmind <topm...{}technologist.com> wrote:
> > Daniel T. wrote:
> > > 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.
>
> Wait, why the restriction of "physical" simulations? Simula and other OO
> languages are excellent at modeling simulations, "physical" or otherwise.

I am not sure what your point is. There appears to be context
confusion.

-T-