Re: Been a slice...
From: Maarten Wiltink (maarten_at_kittensandcats.net)
Date: 10/31/04
- Next message: Tom de Neef: "Re: delimit string in a textfile"
- Previous message: J French: "Re: Closing another App..."
- In reply to:(deleted message) L D Blake: "Re: Been a slice..."
- Next in thread: Bjørge Sæther: "Re: Been a slice..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 31 Oct 2004 12:40:45 +0100
"L D Blake" <not@any.adr> wrote in message
news:2u28o0tmlc1col4aepkk6uak9o7j53mjgg@4ax.com...
[...]
(I can never resist talking into empty space)
> Well, I can't summarize anyone's positions but my own...
So can we all.
> There are two general groups of errors.
>
> The first group occurs outside our code, occuring randomly beyond
> our control: disk read errors, missing files, memory not available etc.
>
> The second group are errors that occur within our own code as our own
> creation: a file parser that encounters an unexpected character a
> display string that gets too long, etc.
And exceptions teach us that they can be unified into a single scheme
that lets us handle or ignore whatever we want.
[...]
> The second kind, made necessary by multitasking, is an operating
> system based mechanism for notifying programs of errors that have
> occured asynchronously with our code: out of memory, disk not
> available, file system changes etc.
But these are not asynchronous errors. There is always a causality:
out of memory errors will occur in response to memory allocation
requests, disk not available errors will not happen if nobody asks
to access the disk... operating systems have worked for forty years
returning only status codes.
File system changes don't sound like errors, but it might be worth
observing that registering yourself for notifications involves
supplying a callback function.
[...]
> The third is Object Oriented Program where the distinction between
> code and data gets blurred so that everything as all part of a Class
> or an Object and the methods of the Class operate on the Properties
> of the same class... producing an unordered and hopefully coherent
> result.
There is nothing unordered about grouping code as you do data.
Object-orientation is first and foremost about modelling. You have to
switch from a CPU-based view to a model-based view of programming to
benefit from this. Until you do that, it will not make sense that the
model _is_ the program, and entities can switch behaviour according to
their type, without switching names.
> [...] I write diagnostics, utilities, single purpose applications,
> things like that. In all my work I've created only two really large
> applications ...
Small, isolated programs have little or nothing to gain from OO. For
large programs, it can become impossible to keep the model straight in
your head while manipulating it at the register level. Staying closer
to the model makes it easier to create a coherent program and to work
on data transformations without making errors.
> It is also correct to observe that I am perhaps one of few remaining
> people who worries much about program size.
It's only fair to point out that among those who do (and there are
still many, too many), you're one of the _very_ few who have a good
reason for it.
> [...] When cramped quarters aren't the issue, smaller code amounts
> to better, more stable programs and often it can produce interesting
> leaps in speed as well. ...
This is totally dependent on the type of program. For larger programs,
careful design and careful implementation are what leads to better, more
stable programs. Emphasis on smaller code leads to local optimisation
and as such, evolution instead of revolution. It rules out _quantum_
leaps in speed through algorithmical improvement.
The first half of that paragraph, I will take personal responsibility
for. The second half I'm only echoing accepted wisdom, which is not to
say that it isn't true and I don't stand behind it.
> [...] the whole Delphi concept stikes me as a hideously complicated
> way of doing some very basic things. No offense to anyone on this
> list but Delphi's RAD tools strike me as "programming for dummies"...
> you get to produce code without even really knowing what you've
> written!
Nobody here will fight this. But there is a difference between RAD
drag & drop pseudo-programming, and OO application design.
> (Of course there are some very smart people using Delphi... but the
> philosophy of the IDE seems to be that of giving access to programming
> tasks to people who have no programming skills.)
Well, yes. It's a bigger market than people who know what they are
doing.
You're not the only one working in a subset of what the IDE offers.
> [...] Certain parts of the OP underpinnings were "bent" to play
> nicely with RAD and VCL developement. These are fairly minor...
> mostly involving the creation of objects in places where I would
> not normally consider using them.
You mention RAD development and VCL development, but the one you miss
is plain OO development. And it's this one for which Object Pascal
involves objects during exception handling. It simply sticks with
its paradigm, to great effect which you are determined to stay blind
to.
> Ok... back to the beginning... In the world of errors the most
> meaningful descriptor of an error is it's Code number. "Error 666"
> means a lot more and provides a ton more information than "Error
> EDemonicPosession". One can argue that both convey the same
> information, but one does so in a simple D word and the other carries
> a ton of baggage along with it. Also if you look at the base
> definition of the Exception Class you will discover the error code
> isn't even stored! This struck me as totally ridiculous...
> abstraction to the degree of meaningless...
*Of course* exception object classes convey the same information as
error codes! The code is mapped to the class; even when the mapping is
not exactly one-to-one, they will be semantically equivalent as far as
required on a case-by-case basis. One is simply replaced by the other.
Bascially, "EDemonicPossession" is a _name_ for "666".
The baggage also is not random. Exactly that information can be added
to an error that is felt to be useful.
[...]
> Then Diane Lask showed up...
And nothing changed as far as I'm concerned. What you do in private is
private.
The flip side of the coin is that you do not get to complain here about
what happens to you in private. You can say you're having a bad day, and
we'll duly express sympathy, but you can't use it to counter complaints
about other people's suffering at the hand of incompetent predecessors.
Because not writing code that will cause the programmer who inherits it
grief _is_ about good programming practice, and not calling the RCMP to
have someone rousted out of their bed in the middle of the night is not.
> From there, things have been going badly. The attitudes of people
> here changed very pronouncedly. Suddenly I find myself constantly
> challenged. Nothing I say is left to stand. One writer here called
> it "Kicking in the shins" and I gotta tell you, that's excactly what
> it feels like.
Yes. That was me. I quote: "I am kicking your shins harder than
anybody's. You haven't seen half of the replies I started composing
when you were, again!, telling people to use Delphi to not a hundredth
of its potential." (Someone else then wanted to be acknowledged to be
kicking your shins even harder for that.)
What it all comes down to is that when you say interesting things,
controversial things, they will be challenged. This isn't personal,
or bad. If you can fend off the challenge, that's okay. If you can't,
that's okay - it needed that challenge even more. It's still not
personal.
> So, I waited for a while and then asked about the second half of
> Delphi's exception handling, the Try/Finally construct. I wasn't
> really determined to change it all around. I was mostly interested
> in learning how people would improve it, if they could... thinking
> that perhaps I could find a way to incorporate those changes without
> causing too much havoc with the basic Delphi functions... like I did
> with try/except.
>
> Next thing I know my professional qualifications and business practices
> are being ripped apart --apparently by Borland employees-- and somehow
> the notion that I might change Delphi is offensive and dangerous to
> everyone here.
I could say so much about this. But I'll keep it brief.
* Presentation matters. At the very least, ask one question at a time.
* In a discussion, be prepared to answer questions, too. Even if you
don't like them. Especially if you don't like them.
* If the thread drifts, let it. It's not yours, it's everybody's.
* Being an elephant on Usenet requires a thick hide. As the Dutch say,
tall trees catch a lot of wind.
> Ultimately... I really don't think any of what happened in the last
> few days had a damned thing to do with programming or Delphi. A
> couple of you did eventually settle in and we had a very good
> conversation about several aspects of SEH and it's inner workings...
> but mostly I was simply challenged, because it was felt that I had
> to be challenged.
_You_ weren't challenged. Nobody said "it can't be much, coming from
you". People did say "doing this will break existing code, in this
exact way". And "this and that feature are lost when you do that".
People also wanted to discuss Delphi exception handling on its own
terms. Hardly surprising, in a Delphi newsgroup, but you never stopped
yelling that it was about Windows SEH, and nothing but Windows SEH.
With the exception of the last paragraph, I hope the usefulness of this
post goes beyond the person I'm ostensibly replying to... who killfiled
me, I'm aware of that.
Groetjes,
Maarten Wiltink
- Next message: Tom de Neef: "Re: delimit string in a textfile"
- Previous message: J French: "Re: Closing another App..."
- In reply to:(deleted message) L D Blake: "Re: Been a slice..."
- Next in thread: Bjørge Sæther: "Re: Been a slice..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
