Re: Observer pattern limitations

On 22 Jul 2006 03:16:53 -0700, David Barrett-Lennard wrote:

Dmitry A. Kazakov wrote:

On 20 Jul 2006 09:07:27 -0700, David Barrett-Lennard wrote:

Dmitry A. Kazakov wrote:
The point is simple,
transactions cannot enforce integrity.

Sure they can, subject to a reasonable definition of integrity.

Ah, with a "reasonable" definition cigarette stubs can do it as well.

You wrote above that semantics (to which
integrity belongs to) is not transaction's business. Here you are. End of
story.

Huh? Transactions are defined at the application level - this tells
the underlying persistence system what's atomic. That allows it to do
its job correctly without knowing about the application level
semantics. What's the problem?

That transactions aren't at the application level.

Every transactional system that I'm aware of provides transactions for
the application programmer. Are you suggesting that a system would
declare transactions at a lower level?

Yes

This is not a question of the functionality of the software.

Of course it is. Consistency of a test is defined that way.

It would be silly for functional requirements to specify a consistency
requirement such that days or weeks of data collection have to be
thrown away because it's incomplete.

You can argue that years of designing fusion reactor shouldn't be thrown
away, yet that would not give you a single joule of energy.

[...]
Unfortunately "save" in most programs simply
overwrites the old file, making it quite dangerous.

You mean Windows programs. *Normal* programs save temp things in temp
files.

Modern file
systems like NTFS support journaling but that doesn't protect the file
content when a file is overwritten.

OS shouldn't have file systems at all.

In a complex system that manages gigabytes of data, it is vital that
some form of database be used that enforces some low-level integrity
constraints. Working directly with files is error prone and can
easily result in excessive data loss.

There should be no files, but solely objects.

For that matter DBMS is just a tool, it has no
right to say. In particular, there might be a higher abstraction layer
which considers some DB states as transitional ones of some larger "atomic"
action. As Robert Martin nicely said, DB is a bucket of bits.

No that will lead to trouble. The whole system may crash and burn one
day when it recovers to an "intermediate" state that breaks your
higher-level integrity constraint. You have no way of ensuring this
can't happen.

Oh, there are multiple ways to do it with a high probability of success.
(BTW, the system I described didn't use a DB, which were too slow anyway)

The persistent object store I implemented in the last few years is as
fast as the file system, and yet fully supports atomicity, recovery,
incremental backup, hot standby etc. It demonstrates that a
transactional approach doesn't imply poor performance.

DB /= transactional approach. Transaction is an atomic operation which can
be reverted.

If you define it static as above, they cannot. But I don't want it static.

What do you mean?

The example above specifies all dependencies at compile time.

Isn't that implicit to that particular problem?

It is not for the general problem.

[...]
So I cannot connect Mandelbrot to a imageWidth that itself depends on
something?

No, that's easy. You can easily chain dependencies.

So imageWidth is not independent. q.e.d.

[...]
I want to see how the concept helps software design. In particular, how
decomposition is done. So far, there is no substance in
independents/dependents.

The separation between independents / dependents is easy to understand.
Do you agree that it is generally possible to write a program that
meets the functional requirements that avoids caching of any kind,
neglecting performance issues?

No, it is impossible. Fundamentally, inputs have to be cached, as well as
outputs. For the same reason distributed and concurrent programs
fundamentally cannot be written without it.

Do you agree that such a program is
often easier to write than one that needs to perform caching?

If you are going to argue that FP is easier than other techniques then you
are wrong. Sometimes it is, sometimes it is not.

I don't think you can even assume it. Each computer has clock, differently
clocked controllers and chips, input devices emitting interrupts etc.

I regard those as inputs. Eg a CPU may have an instruction to
digitize a white noise source. That doesn't detract from the
computer being able to represent a Turing machine.

So?

You think the FP perspective is too simplistic, one reason being that
computers have clocks etc. What does that have to with the dependency
graph? The computer is still *able* to calculate in a deterministic
fashion.

Since when "able X" = "is X"?

That's exactly where we disagree. You require "is" for some reason.

I don't. You claimed that computerized systems are deterministic. This is
plainly wrong.

My job isn't to write emulators of Turing machine, but to design
software systems. These systems include inputs and their sources.

So? How does that spell trouble for the pure FP perspective for
dependency graphs?

It does not. Surely FP can be applied to some graphs. But your claim was
that it would solve some problems outside graph theory, namely
publisher-subscriber issues, or?

I don't know what you mean by that.

[...]
I don't see how the ability for a computer to read a clock is at odds
with these claims.

No, your claim was that you had a solution to some problem. Though, neither
the problem nor the solution was formulated by you. Rather it was backed by
some hazy reasoning about equivalence computerized systems to Turing
systems.

Sorry, I cannot decipher the above. My point was that immutability has
little to do with independency analysis. Intervals were used to illustrate
the point.

You may well be saying something useful and important, but I don't
understand you. Can you elaborate?

http://en.wikipedia.org/wiki/Interval_arithmetic
http://en.wikipedia.org/wiki/Statistical_independence
http://en.wikipedia.org/wiki/Joint_distribution

Then you said that deterministic nature of Turing machine
somehow refutes the corresponding parts of mathematics altogether, or at
least for CS. That's rubbish to me.

That's not what I'm saying.

I'm a great believer in the idea of "less is more". It's often
possible to impose strong constraints on a problem or way of thinking
and paradoxically find that it solves a much larger range of problems
than initially expected. This makes me very willing to impose
heavy-handed rules to see where it leads. Eg
1. Anything calculated is called a dependent.
2. Dependents are not allowed to "change camps"
3. Dependent recalculation must not involve side effects.
4. Dependents can never be synchronously recalculated
5. Dependents cannot form part of the logical state. Eg dependent
members of a class must not be used for equivalence testing.

Strong rules can be compared to mathematical systems with strong
axioms. It often allows for richer theorems (ie outcomes). That
represents problem solving power. For example, I have a powerful,
efficient generic algorithm for recalculating dependents. This power
only comes from constraining the solution space.

You have to show a relevance of the constraints above to the problem at
hand. For example, even more strict constraint would be designing programs
standing on oneself's head...

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Observer pattern limitations
    ... that's exactly what you must do or you won't have integrity. ... transactions cannot enforce integrity. ... class Mandelbrot: public Window ... The two mutable members represent dependents. ...
    (comp.object)
  • Re: Observer pattern limitations
    ... that's exactly what you must do or you won't have integrity. ... If transactions are simple and fine grained it is generally quite ... class Mandelbrot: public Window ... The two mutable members represent dependents. ...
    (comp.object)
  • Re: Observer pattern limitations
    ... subject to a reasonable definition of integrity. ... When you claim "transactions cannot enforce integrity" do you mean ... The separation between independents / dependents is easy to understand. ... we're discussing here: Dependency graphs. ...
    (comp.object)
  • RE: Automatically cycle through a list of Parameters
    ... This sounds like a good idea but for a different reason. ... cumulative batch file based on the transactions previously reffered to. ... reports and I always use the same parameters. ... I would like to find a way to this in VBA. ...
    (microsoft.public.access.modulesdaovba)
  • Re: Productivity
    ... Closing, payroll, billing, grades, etc. need to be run for particular ... we made sure transactions would not get posted while we ... this can be achieved, without batch processing. ... Provided you have security and backups in place, I see no reason why you ...
    (comp.lang.cobol)