Re: what does "serialization" mean?

From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 07/01/04 

Date: 30 Jun 2004 17:09:06 -0700

Programmer Dude <Chris@Sonnack.com> wrote in message news:<6sr0e051rjesmhvb2onhbg8kb32eueem3u@4ax.com>...
> Edward G. Nilges writes:
>
> >> Subject to change, at this point, VB.Net doesn't interest me (for
> >> resource reasons).
> >>
> > You can get the framework and the compiler (minus the GUI) for
> > absolute free from Microsoft.
>
> [grin] The resource in question is time, not money. I have plenty of
> money--I lack time.
>
>
> >> What your student may have been expressing is that, if J*8 is KNOWN to
> >> be constant, you are being--in effect--dishonest in your code. Code
> >> expresses intent (as do most other forms of text writing) and as with
> >> other forms of writing saying what you really mean to say is a writing
> >> skill that must be acquired.
> >
> > This response, while very intelligent, is a misinterpretation of
> > Kernighan's law: code what you mean.
>
> Ed, you are already throwing down the glove here by naming one view of
> things as a "misinterpretation" and another--always yours--as proper.
>
> My general inclination at this point is to go back to calling you a
> goddamn jackass, but let's see if early prevention is worthwhile...
>
> No, it is not a MISinterpretation, it is an interpretation. More than
> one can exist and more than one can be valid.

But one can be "more" valid, useful, illuminating and in general
classier.

All I am saying is that I was rather "present at the creation" of
structured programming. I read F. T. Baker's article on its real-world
application to the rapid development, in 1972 and in PL/I of an
information and clippings bank at the New York Times which is still in
use.

I applied the lessons in this article and elsewhere to assembler
language programming and found that my productivity increased to the
point where I was able to develop a primitive data base in 8K.

Now, at that time, "structured programming" and "code what you mean"
had precise meanings. In particular "structured programming" had a
mathematical meaning then and now, and "code what you mean" was never
intended to conceal how a program was executed according to the fixed
rules of syntax and semantics (quite the opposite).

But what I found in subsequent praxis was that many managers and
programmers reinterpreted both lessons in an overgeneral fashion as an
excuse for laziness and flaccidity of thought, which was a
pre-existing feature of American corporations...to the extent that by
1979, "structured" meant "I understand it".

In Basic, the fact that the For limit value (whether constant,
variable, or expression) is a defacto standard similar to the fact
that the index is one greater or one less than the limit when the Step
is one.

Therefore, the use of an expression in the For loop is not only
acceptable it's good style because it forces the reader to understand.

This is not so much an "opinion" or even an "interpretation" to be
ranged alongside other opinions in a neat little row, and accepted or
rejected randomly or depending on the personal prejudices of the
reviewer...in the corporate style. It is instead a narrative. And with
all due respect, I don't believe you can devise one for your view.

>
> > That is because you assume that in
> >
> > For i = 1 to j*8
> > bnoog
> > Next i
> >
> > you have assumed that the reader will assume, in turn, that the scope
> > of the For is from the F, so to speak to the end.
>
> Yes, that is, in fact, exactly the assumption, and it is a highly
> defensible assumption, regardless of...

Not at all. If the reader doesn't understand the language he must get
up to speed. Using an expression will force him to get up to speed.

Furthermore, the sloppy rule "the scope of the for begins with its
leading f" when applied to C's and Java's for yields complete nonsense
since the initialization clause is to the right of the f and if the
reader of a C or Java program believes that the initialization clause
must be "efficient" because it is "repeatedly executed" he is not a
qualified reader, should not be reading code, and he isn't someone
with whom we need be concerned.

>
> > Whereas many intelligent programmers know that the For line includes
> > one-time code, including the calculation and stacking of j*8.
>
> Understood, however this depends on specific knowledge of how a given
> language works. Worse, in VB's case, this knowledge can only come from
> experimenting or reverse-engineering. And in the absense of a published
> spec, can one count on the behavior remaining constant from, say, VB6
> SP3 to VB6 SP4?
>
One can count on this because with all its faults, Microsoft was
honest about the seismic semantic shift that occured from VB6 SP4 to
VB.Net, while also documenting the previous changes.

I believe that the semantics ARE documented. Certainly many texts
published inside and outside MS document the For behavior.

Furthermore, what's wrong with "experiment"? When you get a new
release, try the feature out and use your native intelligence to
reason that unless the Microsoft compiler developers are complete
bozos, the next SP release won't change it. If you're concerned, send
them email or post the question to this group.

Finally, and with all dues respect, "specific knowledge of how a given
language works" is called knowing yer job.

It is rather curious, to me, that schizophrenically, personnel flacks
and head-hunters (who know diddly squat about "computer science" and
are "unclear on the concept" of mere "data processing) demand that the
hire know (or claim to know in some sufficiently smooth way) all there
is to know about release 1.3.2.4 (and, have "ten years" of experience
in the product, which has been available for ten months)...while at
the same time dismissing the very idea that there could be a "computer
science literacy".

In which, the applicant would have had the experience of having to
implement (let us say by hand on an exam) the simplified assembler
code for a For...to see that there is a choice between using the limit
"by value", and repeatedly evaluating it "by reference", and the
critical spirit to "reverse engineer".

Unfortunately, in the "job market" which is to me less a rational
sphere and more a brutalizing disciplinary sphere in which we "learn
our place", this sort of experience cannot even be described because
the language (which the jobseeker must learn, and use exclusively, at
his peril) makes the narrative not well-formed.
 
> Simply put, the behavior is not guarenteed. Code that relied on it
> would not be as robust as possible.
>
No, the behavior IS guaranteed. Look, Microsoft tried to change the
rules for And and for Or for VB.Net after already announcing that it
was a paradigm shift, and they were forced to go back to the VB-6
syntax and introduce two new operators with the new syntax instead.
 
> >Therefore I do not think it any clearer to code
> >
> > Dim k
> > .
> > .
> > .
> > k = j*8
> > For i = 1 to k
> >
> > In fact I think it to be regressive and clumsy for it introduces
> > an unneeded variable k,...
>
> I can appreciate the feeling! One thing that helped get me over that
> feeling was the understanding that the variable is created under the
> hood anyway. VB needs SOMEPLACE to stash the j*8 result, and the
> actual mechanics don't differ much from a declared variable.

Actually, let's pop the hood here.

What we find is that yes indeed, the j*8 result IS, in the above
example and in VB-6 SP4, stored more efficiently as a double precision
value and on the runtime stack when we code For i = 1 to j*8!

For in the "rewrite" we find instead that the precalculated value is
(1) stored as a Variant, (2) takes up yet Another place in memory, and
(3) loaded to the stack...each time through the For loop evaluation,
thus, completely undercutting my student's original critique of
efficiency.

>
> I've also found the intermediate variables very helpful in debugging,
> as you can inspect their values conveniently.
>
This is true. However, VB-6 makes it easy to get the values in the
Immediate window.
 
> >> Saying "j*8" implies a reason saying it thus, and that reason hints
> >> that j may change and thus the expression is worth evaluating each time.
> >
> > That would be part of its connotation but that is in the mind of the
> > reader.
>
> True, but isn't it a particularly valid assumption to make?

The reader is either as qualified as the writer, OR is to be brought
up to speed by the very act of reading. Missing here is the very idea
of reading as a dynamic process which makes the reader smarter, for it
is, I think, inimical to the reverse motion which takes place in
corporations, wherein overspecialization tends to moronize people over
time.

>
> > To reason that the mere appearance of a variable in an
> > expression hints, implies, connotes "may change" means that
> > expressions shouldn't contain constants either and this is nonsense.
>
> Because you've misstated it. It isn't the appearance of a variable
> in an expression. It is the appearance of an *expression* in a loop
> condition.
>
> If you consider all loop forms of all languages, I'm quite sure the
> bulk of them (by far) evaluate their loop conditional each time
> through the loop. Thus, treating that as "Default Behavior" is not
> at all unreasonable and not putting unnecessary expressions in such
> a place is, I think, a good heuristic.
>
Not so. C is exceptional in this regard, and its crude design of the
For loop has been inherited by the C-worshipers who developed perl,
Java and a host of other languages.
 
> It's not unlike always signaling your car turns regardless of whether
> there is anyone in view to signal. Good practice that might save you
> in a stressful situation.
>
What I note about this analogy is that there is in fact a sharp split
in America between driving theory and praxis that is based on sexism.

[Wash my mouth out with soap after that one.]

But seriously: all sorts of stated rules are completely ignored on the
American road notably the speed limit whenever possible and
convenient, and Asia is preferable for here the rules are clearly
"drive like an effing lunatic", "cut him off", and "when turning
right, get into the left lane and then cross all lanes at the last
minute to make your turn".

In American programming praxis I find in a similar way to American
driving that all sorts of rules are honored in the breach and not in
the observance.

And I have found over thirty years that primarily only women
programmers were actually serious about good style and consistent in
its application, even as I find that women drivers usually drive
better and more within the letter of the law.

I conclude that there is a simultaneous male rage to be both law-giver
and bad boy law-breaker. In fact, this schizophregenic rage is
ultimately resolved for many men by entering the police force. In a
positive sense they find there the satisfaction of breaking a narrow
spectrum of laws "in hot pursuit" to overall serve the law. In a
negative sense they discover, like Serpico, a corrupt "above the law'
situation.
>
> >>> Another issue for me is the definition in C# and C++ of iterators as
> >>> objects. Have you seen this practice and does it make any sense to
> >>> you?
> >>
> >> Absolutely. Love'm! [...snip...]
> >
> > I see no problem with this practice and shall adopt it ASAP. [...]
> >
> > However, one problem is that the concept of "iterator" doesn't
> > parallel any concepts from formal logic outside programming and that
> > is a danger sign.
>
> Whyso?
>
> > Perhaps what one SHOULD do in place of defining, for all or most new
> > objects, an iterator, is defining a set-of that would expose
> > iteration.
>
> Having done both... I prefer the encapsulation of iterators. They also
> have the advantage that each maintains their own state, you can have
> multiple iterations existing simultaneously. You can't do that with an
> exposed "iteration" API.
>
> > The problem is that the cleanest way to implement this would be
> > through multiple inheritance which VB.Net doesn't support.
> >
> > Define the concrete class BunnyRabbit. Have available the abstract
> > class set. A set-of Bunny Rabbits would have to be-a set and inherit
> > collectively all the capabilities of Bunny Rabbits. It would have to
> > Inherit Set and BunnyRabbit.
>
> No,.... doesn't sound right to me.
>
>
> > Seriously, a danger with iteration is that it captures only part of
> > the more meaningful concept that "my object may exist, meaningfully,
> > in a collective or set of objects"....
>
> You went off into outer space or left field here. I lack the time to
> follow... scattered points...
>
> > for ( intIndex1 = 0:
> > intIndex1 < numberOfBeings:
> > intIndex1++ )
> > if ( Man(x) ) assert( Mortal(x) );
> >
> > This loop "breaks" if run in real time, for if during its execution a
> > child is born, numberOfBeings would change. This would be handled in
> > the above C example but not in a Visual Basic For loop, which would
> > take the numberOfBeings applicable on entry to the For.
>
> (Which, incidentally, is why I consider the VB For/Next less favorably
> than I do loop forms that reevaluate the condition.)
>
> > But the loop still assumes that the numbering scheme for the Ten
> > Thousand Things does not change, therefore for each is cleaner:
> >
> > For Each being b
> > If Man(b) Then Assert b & " is mortal"
> > End
>
> I don't see how. Under the hood, much the same thing is happening, and
> the same issues and problems apply.

Relevant Pages

  • Re: Letter to US Sen. Byron Dorgan re unpaid overtime
    ... > Hey, idiot, read my lips - the CONDITION is evaluated before each loop ... expressed my hope that you actually know the sequence of evaluations ... inappropriately with commercial promotion of the C language when I ... Programming Style: code what you mean. ...
    (comp.programming)
  • Re: [EGN] Hoisting Loop Invariants (Was: Re: [EGN] Numerical Accuracy)
    ... outdated language, for manual optimization. ... > such as moving loop invariants outside of loops is not unmaintainable. ... > code might be trivially faster (one of your favorite micro optimizations ... > used programming language on the planet. ...
    (comp.programming)
  • Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > language containing many unsafe features, ... powerful and systems programming language, ... > it at hand anyway, but the gist of it is that, in Ada, loop variables ... > * pointer types cannot be converted to one another. ...
    (comp.lang.cpp)
  • Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > language containing many unsafe features, ... powerful and systems programming language, ... > it at hand anyway, but the gist of it is that, in Ada, loop variables ... > * pointer types cannot be converted to one another. ...
    (comp.lang.ada)
  • Re: Bug/Gross InEfficiency in HeathFields fgetline program
    ... If you think that then C is not the language for you since it is idiomatic. ... you've got to assume that the reader knows C, don't assume that he uses the language more than occasionally. ... Kuyper was talking about interviewing people for C programming jobs. ... Anyone with a C programming job should be able to work out what that loop does during an interview. ...
    (comp.lang.c)