Re: What databases have taught me

From: erk <eric.kaun_at_gmail.com>
Date: 28 Jun 2006 08:33:05 -0700
Message-ID: <1151508785.176638.93800_at_i40g2000cwc.googlegroups.com>


Dan wrote:
> erk wrote:
> > Dan wrote:
> > > Absolutely true! Relational or object-oriented, it doesn't matter,
> > > it's the thought process and ability to apply critical analysis to
> > > problems that makes or breaks the project or solves the problem in the
> > > most elegant way possible.
> >
> > This seems to imply that the languages and other formalisms are all the
> > same, though,
>
> How so? Is this your logic?
>
> 1. If the RM designer is unskilled then the implemented solution
> sucks.
> 2. If the OO programmer is unskilled then the implemented solution
> sucks.
> 3. For any language x, if the programmer/architect/designer is
> unskilled and ignorant, the implemented solution y sucks.
>
> Therefore all languages and formalisms are the same. ????

The above 3 statements are correct, but that's not my argument. It seemed you were implying that the languages and tools had little bearing on the solution, which is false. A good OO designer might create a solution which is better than a poor RM designer's, but that doesn't say anything about OO vs. RM. The case can only be argued from the point of view of an "average" practicioner in each, but that is difficult and doesn't factor in the attraction of various abstractions to different people.

Toolsets are limiting; Dijkstra tells the story of an intelligent student who clearly understood Dijkstra's arguments, yet was unable to formalize it because his mind was shackled by limitations in Fortran's subscripting (limitations which didn't exist in Dijkstra's notations, nor in ALGOL). The student knew Fortran, and was hobbled by it. I don't believe the hobbling need be permanent, but it's present.

Language is more than a tool; it shapes the mind, and the thoughts produced by that mind. An inferior or misused abstraction results in poor solutions to problems (solutions which introduce more problems). So the critical analysis ability you speak of above must apply to choosing abstractions as well.

After years of both OO, as much RM as I could get through SQL, and functional programming through Lisp, I feel that OO is the inferior abstraction framework, especially as implemented in Java and C++ (and Ruby and Python don't give me any special reason to re-embrace OO, though I appreciate their functional aspects). It's more limited, more limiting, and while it has its place, can be satisfactorily replaced by aspects of the other abstractions.

> and I don't think that's true at all. Yes, you can write
> > horrid code using Lisp, Haskell, Java, assembler, XML, SQL tables,
> > relations, etc., and you can write good systems in them as well, but
> > that doesn't mean that some languages and constructs aren't better all
> > around than some others.
>
> Did it appear as though I made such a claim? If so, I take it back.

Yes, it did appear that way - sorry if I've kneed a strawman in the groin.

> To assert otherwise is to assert that
> > languages and systems have no impact on the way we think, and I think
> > that's silly.
>
> Again, I fail to see the validity of the logic. How does the assertion
> or claim that some languages or constructs are not better than others
> necessarily lead to the conclusion that languages and systems have no
> impact on the way we think?

I was unclear in my statement, so I'll try again with your statement:
> > > Absolutely true! Relational or object-oriented, it doesn't matter,
> > > it's the thought process and ability to apply critical analysis to
> > > problems that makes or breaks the project or solves the problem in the
> > > most elegant way possible.

By "elegant way," I assume you mean the end result. But the end result is an abstraction, a design. If that can be reached regardless of the "starting set" of abstractions, then that "starting set" is irrelevant.

Abstractions affect the way we think. They're more than just tools to implement a plan - they shape the plan, and our goals (because any number of different pieces of code can behave identically to a user). The solution mirrors (or in the best case IS) the set of abstractions we've chosen (and not been forced into).

Given all that, it seems obvious that some abstractions will lead us to produce better and more elegant solutions than others.

> Regardless, what is the objective function for determining "better"?

There's not a single one. Elegance is too vague, and others are each incomplete: lines of code, referential transparency, substitutability. Testability, for the agile folks.

> and does your statements then mean that users of some languages and
> constructs are "better" thinkers?

Certainly. If that weren't the case, it would mean the abstractions can't improve or degrade thinking ability. It doesn't mean there aren't geniuses coding in assembler; it simply means that (assuming some level of mental flexibility, which could in fact have been degraded by the language) they would do much more with more powerful abstractions.

My own mental capabilities, for example, have been degraded by O-O and Java. I am struggling to reverse this alarming trend. Studying RM helped; studying Lisp helps; studying various type formalisms helps. Getting a job using these tools, especially with a community for support, will help immensely.

> Was Dijkstra an RM user? Wirth? Aristotle?

I don't know if Dijkstra knew anything about the RM, but he understood predicate logic, set theory, and constraints probably better than anyone here. Perhaps he used more powerful abstractions that might be beyond my power of understanding; he advocated crafting notations to match the problem, and developing the solution and proof simultaneously.

I don't know much about Wirth.

Aristotle would certainly have been able to do even armed with the developments in logic since his day. Why would he not?

  • erk
Received on Wed Jun 28 2006 - 17:33:05 CEST

Original text of this message