«

On 2012-09-28, Rainer Weikusat <> wrote:
> Rainer Weikusat <> writes:
>
> [...]
>
>> let's assume the problem is "I want a coffee!". Neither the ground
>> coffee beans nor
>
> I was actually being to conservative: As demonstrated by
> ' !Iaaceeffnotw', stating the problem already requires a lot of things
> with absolutely no inherent relation to it.

Well, you need a language. You need symbols, and the representation of
symbols and how they map to concepts is arbitrary.

But a solution using one symbols is isomorphic to another one using
different symbols for the same thing. (It can be symbol-for-symbol isomorphic.)

If you don't understand the conventions of the language, then an utterance may
not look like gibberish to you, but that's not the same thing as lacking
inherent expressivity.

Expressivity *demands* reliance on material that has been internalized between
the originator of the message and the recipient: some common language,
common understanding of domain abstractions and so on.

Expressivity means putting less information in, and relying on "exformation".
(I didn't make up that word and I'm using it consistently with:
http://en.wikipedia.org/wiki/Exformation)

> Not even the morphemes or
> the sounds the spoken sentence would be composed have any: All just

For the purpose of expressivity, we don't look at morphemes unless they act as
independent symbols. Morphemes which are just fragments of the representation
of a symbol are uninteresting, because symbols are atoms, and could be
replaced by other atoms in a way that preserves meaning, if the replacement
is consistent.

The pattern of morphemes is valuable only to the extent that when it occurs
twice in the utterance (and in the same context), it refers to the same thing.

Mladen Gogala <> writes:
> On Fri, 28 Sep 2012 11:50:37 +0100, Rainer Weikusat wrote:
>
>> This is simply not true: Over the lifetime of a program, the amortized
>> impplementation cost of every infrastructure facility contained in it is
>> zero provided that it actually works and works as it would need to work.
>
> Rainer, I agree with you about the DB usage, I disagree about the
> ORM,

I didn't write anything about my opinion of object-relational
mapping developer support software, I just stated the fact that
'database interaction' is a relatively tiny and ancilliary part of
almost all programs which include database interactions I've either
written or encountered so far. The same happens to be true for all
other kinds of problem-independent infrastructure code: It's always
there and it is always just an insignificant amount compared with the
problem specific code and further, it is not only the smaller part but
also the part which is a lot easier to implement and get
right (I'm actually fairly convinced that such an ungodly amount of
'generalized infrastructure code' exists on the internet because
this is code dealing with inherently simple problems. Simple enough,
to be precise, that horrendously complicated ways of dealing with them
don't just collapse under their own weight, as they would if the
problem was complicated, meaning, getting half of the corner cases
which shouldn't have been lumped together to begin with more or less
subtly wrong would render the thing itself completely unusuable).

In Perl, I've so far been able to get by with using a slowly expanding
subset of the DBI functionality and the reason why I employ relational
database management systems is because the nature of a given problem
is such that doing so provides an advantage. Consequently, I don't
quite understand why I would want to use some middlewhere whose sole
purpose is to hide the RDBMS behind a simpler (and thus, less
flexible) abstraction: If 'simpler but less flexible' seems a viable
option, I can simply not use a database.

In any case, I'm convinced that learning how to employ a database
engine is well worth the effort. Eg, something Hibernate is very fond
of are n:m mapping tables linking different kinds of 'objects'
together: Since I'm not fond of dealing with this explicitly at all,
I'm always accessing the data with the help of suitably defined views
so that the database pulls the different parts together for me. I
would go so far as to say that using joins in application code is
usually a mistake: The database should be worrying about that, not
the guy who tries to make sense of the code.