Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"

"frebe" <frebe73@xxxxxxxxx> writes:
Do you consider Java more high-level than C? Normally it is very
meaningful to use the terms high- and low-level.

"Normally" in what context? Java has some features such as
garbage collection that C++ lacks, so in that sense it can be
considered higher level, but C++ templates are far more powerful
than Java's generics. High level and low level depend on the
context.

I just want to point out you methods of argumentation. You know that
you can't claim C to be more high-level than Java. Instead you
change the subject to C++ and starts yet another word game.

Actually, that was a reading error on my part. I misread C++
where you wrote C. The same point remains, though, and I note that
you failed to address it. Your predilection for accusing others of
playing word games, when in fact you are the only one doing so in this
thread, grows old.

For many application domains, Java's features provide
abstractions that are better suited to the problems typical of that
domain. In that sense and in that context, Java can be said to be
"higher level" than C. In other domains, particularly those requiring
access to hardware or development of high performance communication
protocols, to give just two examples, the abstractions provided by C
enable the creation of a superior solution.

Do you claim that the use of lists and maps could be considered
being at the same level as using relational algebra?

What do you mean, exactly, by "level"?

Yet another word game. But if it makes you happier: Level of
abstraction and power.

Asking for clear definitions is a word game? You don't seem to
have a clear definition of that term, either.

In any case, given a language such as Common Lisp that has a vast
collection of functions that operate on lists and other sequences, I
don't see a difference in level of abstraction. If you do, please
point it out explicitly.

But now back to the original question. Would you consider list
operations (add, get, remove, etc) as powerful as relational
operations (join, selection, projection, etc)?

Those aren't the only operations possible on lists. Your
question is therefore nonsensical.

Sometimes the solution calls for a structure, sometimes an
object, sometimes a set of tuples, sometimes a directed graph,
and sometimes other structures.

Relations may be used for (logically) model tree structures,
network structures, directed graphs and many other structures.

Building directed graphs from tuples is getting close to the
category of "Stupid SQL tricks."

Why?

You are claiming on the one hand that relations are the only data
structure that should be used and on the other hand that relations can
be used to create "almost" all other data structures. You have not
rationally justified making the effort of going through the extra
hoops of creating other data structures from relations. It may be
possible, but you've shown no clear value in doing so.

That aside, if your claim that relations are the only data
structure that should be used is based on the concept that it is
possible, via sufficient circumlocutions, to construct other data
structures out of relations, that becomes quite uninteresting.

No, it just shows that the relational model is complete and
powerful. There are many things you can't do with a network graph
that can be done with relations (using predicate logic for
example). But it is very hard to find examples of the opposite.

When you take time and space concerns into consideration, it's
very easy to find such examples. The "nearest neighbor" example
provided by, I believe, Mr. Kazakov is one such.

Another example comes from a systems I implemented a few years
ago. We had a directed graph of transactions that had be settled in
the order specified by the edges. That is, a given transaction could
not settle until all of the transactions it pointed to had settled or
it had to settle at the same time as those transactions. The solution
involved identifying all cycles in the graph, converting them to
single, complex transaction nodes, and then doing settlement over the
resulting directed acyclic graph. You might be able to do that with
SQL, but it would take longer to implement and would not perform
within the customer's time constraints.

What you have failed to explain is why you think that only
relations should be used.

They should be used because they are able to model almost all
kind of information.

First, "almost" isn't "all". Second, lists, for example, can
also model a wide range of structures. Why should relations be
preferred to lists?

Because you can fetch relational data using predicate logic.

And, so? Not all uses of data structures are for fetching.

Why should any primitive be treated as sufficient in and of itself?

If you have a complete set of primitives that are sufficient
(relational algebra), you have a comple model (the relational
model).

Sufficient for what? Just because you have a tool, the RDBMS,
that is based on a formal mathematical model doesn't mean that you
automatically can address all real world problems optimally with it.

Common Lisp is based on the lambda calculus. Why should the
relational model be preferred?

Why should other applications limit themselves to a single
primitive to construct their necessary data structures?

The main reason is the power of relational operators compared to
operations for other data structures. They could be used for
virtually everything (assuming you have a suitable relational
database implementation availible), and the resulting application
code will have much fewer lines of code than using other low-level
data structures.

That's another very broad claim. Are you actually asserting that
implementations based on the relational model will always have "much
fewer lines of code" than implementations based on any other paradigm?
That's an extraordinary claim that requires extraordinary evidence.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, middleware, SOA)
.

Relevant Pages

  • Re: Road to Clojure Survey
    ... Java offers low level building material. ... That is used along with a STM and immutable data structures. ... Immutability is the default in Clojure. ...
    (comp.lang.lisp)
  • Re: Need Relational Database Capabilties in Java
    ... originally in a relational database software program. ... the data structures if possible. ... You can access a relational DB from Java via JDBC. ...
    (comp.lang.java.programmer)
  • Re: Data structures in java
    ... implementing your data structures in a low level language like C. ... How is Java's expression of such algorithms in any way inferior ... transformation that Java is inferior. ... The OP mentioned that this was a learning exercise, and already turned down using API classes and methods for that reason. ...
    (comp.lang.java.programmer)
  • Need Relational Database Capabilties in Java
    ... We are looking at converting some legacy apps o Java. ... originally in a relational database software program. ... the data structures if possible. ...
    (comp.lang.java.programmer)
  • Re: Symbolic benchmark
    ... Java to the fact that its allocator and GC must cope with interthread ... data structures. ... Process creation in OCaml takes about 10ms here whereas thread creation ...
    (comp.lang.java.programmer)