Re: What databases have taught me

Frans Bouma wrote:
> [snip]
> What I can say is that if you don't realize that <insert tech /
> paradigm here> is just a tool to get to the goal you want to achieve:

So technologies and paradigms are the same thing? Presumably a "paradigm" (overloaded++) influences how we think about problems and/or solutions, and is thus much more than just a "technology," which (I'm assuming) is a means to an existing end. Paradigms, presumably, alter the ends by our understanding of the domains involved.

> an executable solution to the problem you want to solve, that same
> tech/paradigm will sooner or later bite you because it will have
> limitations and shortcomings.

I disagree with this entire paragraph, and by way of explanation, will quote Dijkstra: "A programming language is a tool that has profound influence on our thinking habits." All languages are not created equal. Turing equivalence, for such purposes, is essentially meaningless.

Some more, tangentially related:

"If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases." - Guy L. Steele

"Object-oriented programming is an exceptionally bad idea which could only have originated in California." - Edsger W. Dijkstra

"A programming language is low level when its programs require attention to the irrelevant." Alan Perlis

"A language that doesn't affect the way you think about programming, is not worth knowing. - Alan Perlis

"If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather than part of its solution. - C.A.R. Hoare [although I disgree with his use of the word "tool," the rest of the thought is accurate]

> True, a good example is a Math library in an OO language runtime
> library. It often is implemented as a library with static methods in
> one big class or several different classes without state nor specific
> type, just a vehicle to hold the static methods together.
>
> That doesn't mean OO sucks, it means for functional problems which can
> be appearing in any domain, it might be best to use a functional /
> procedural approach instead of an OO.

And how many programming problems are truly unique to the domain, and not manifestations of a more general functional pattern? Sadly, I see this in Java all too often - dozens of static methods thrown into "Util" "classes", none of which are actually O-O at all, because Java supports no top-level constructs other than classes. (Clearly other languages can avoid this issue, but it illustrates the greater utility of functions - witness CLOS in Lisp, as an example of objects done right with hooks to meta-object operations.)

> The same applies to using OO-esk constructs in an procedural language.

Don't equate procedural and functional.

> What I can say is that often people are too blinded by the paradigm
> they use. Take for example Object oriented data-access.

What, pray tell, is "object oriented data-access"?  

• erk