If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: Bad programming practices encouraged.... namely VB!

Dan
> That's a real shame. Be careful your employer doesn't catch on. Most
> code owners like to believe (real or illusion) that their code assets
> can be reused.

Well I disagree. Here are some of my thoughts on the matter so you know
where I stand. This is a 1st draft so please excuse the various errors.

Code Reuse and the Burden of Interpretation
----------------------------------------------

Experience shows that code re-use is not, in any useful sense, achievable.
It is interesting to note that code reuse per se is not the generic goal;
instead of focusing on reusing code it is more useful to think of solution
reuse where a solution can be thought of as either direct solution code or,
less obviously, as abstract solution code in the form of a problem
definition coupled to a code generator.

The current paradigm states that code and solution are one and the same
thing. This statement is false when humans are allowed to generate the code.
Humans will inevitably interpret the solution they implement as they
implement it. Hence their code represents their solution and must be infused
with personal interpretation. Thus each code component does not directly
equate to an absolute solution but is, instead, an abstracted, interpreted
isomorph whose detailed internal dependencies are to some degree unique to
the particular coder's design. All structured programming, naming
conventions etc are just so many attempts to agree on a general code
topology that allows the various isomorphs of a given solution (generated by
individual human coders) to be interchangeable. They fail because humans are
irreducibly different.

Interestingly this observation predicts that coders will tend to be loners.
An isolated individual is not subject to the effect described above for the
simple reason that isomorphs are relative. An isolated 'isomorph' is, in
fact, an internally consistent paradigm when viewed from the individual
coder's perspective. For an individual working alone the direct mapping
between code and solution is restored. Thus most coders ultimately prefer to
'do it their own way' if the solution space is small enough for individual
analysis.

Leading on from this is realization that the problem with code reuse is not
one of technique but is instead a far more subtle and fundamental emergent
property of interacting human interpretations. Now it can be understood why
the only path to code reuse in a multi-coder environment is that of
restriction and convention because such rules result in an agreed, if highly
brittle, code topology whose specific function is to preclude an
individual's interpretation. Since humans must by definition make a priori
interpretations of anything they understand, then it can clearly be seen
that this approach is flawed at its root axiom; the very rules designed to
preclude interpretation are themselves subject to it before they can be
understood and applied.

From this it can be seen that code reuse would be greatly enhanced by
preventing the coder from applying their personal interpretation to a given
solution. If it is the case that the incompatible boundaries between
isomorphic solutions are indeed responsible for the lack of code reuse then
removing the coder will also remove inevitable variability of solution
interpretation and so enhance the prospects of reusing solution code.

The corollary to the observation that coders should not be involved with
solution code is that code reuse is only possible with code that has been
automatically generated by a consistent, non-interpretative framework.
Unfortunately this is not possible for the obvious reason that machines
cannot act as a prime mover, they cannot solve problems (even if they can
generate exquisite code solutions) because linear machines cannot define
problems without an initial, lateral input of a type currently available
only via a human intelligence. It is therefore impossible to eliminate human
interpretation from the ultimate solution code.

However the perfect should not be allowed to become the enemy of the good. A
fundamental revision of the coder's place in the process of solution
generation with the purpose of reducing the interpretation pollution they
engender is a worthy goal and should bring with it an increase in the reuse
of code. Put simply, the coder's task should be shifted from defining the
solution to defining the problem. Problem definitions vary far less then
their corresponding, isomorphic solution-sets and therefore problem
definitions hold out the possibility of being amenable to rigorous control.
Of course problem definitions must be subject to the same forces of
individual human interpretation but it seems likely that the interpretation
burden will be less. The notion of code reuse would also undergo a dramatic
revision with all attempts at solution-isomorph reuse being subsumed by the
reuse of problem-definition code.

To enable such a paradigm shift, a consistent yet generic code/solution
generator that consumes well-formed problem definitions is required.
Evolutionary programming provides such a system. The iterative logic of
selection provides the generic and consistent framework and the fitness
tests they consume are nothing more than definitions of the problem to be
solved. What is missing is the rigorous and consistent syntax for the coding
of fitness tests i.e. problem definitions. Should such a language become
available then it may be a simple matter for coders to make the required
shift from defining solutions to defining problems.

In summary it can be seen that likelihood of code reuse varies inversely
with the level of solution interpretation. Solution interpretation can be
greatly reduced by allowing machines to generate consistent code. Machines
can do this only if they are provided with problem definitions. Only humans
can generate the required primary problem definitions and so interpretation
cannot be eliminated entirely. The observation of greatest importance is
that the coder must shift from being a solution provider to a problem provid
er. The code that would be re-used would be the problem definitions.

Evolutionary programming appears to provide both the consistent solution
generation mechanism as well as a suitable problem definition framework.

Re: Bad programming practices encouraged.... namely VB!

Re: Bad programming practices encouraged.... namely VB!

On Thu, 12 Apr 2001 17:48:10 -0700, "Jonny" <jonny@joyofvb.com> wrote:
>You forgot to tag your statement with a reference to BitDancing and so

ROFLMAO!!!

Hey Jonny, welcome back. Btw, Zach has hit the road with Emily
(apparently his new girl-friend, I wonder if I saw it coming before he
did?). I hear Pheonix is on the schedule, and I know what that means.
Give the kid a big hug for me OK - he's one of the best.

Re: Bad programming practices encouraged.... namely VB!

Sjoerd,
> Note: most of the noted points are still more sentiment than hard fact.
But
> don't underestimate the power of sentiment: it's what keeps Java alive

There was a reason I was asking Jonny, I hadn't heard his opinion. I have
heard yours, and in other posts you have gotten somewhat closer than in this
one to my question of which/why/how. Just to clarify, what I think you did
understand, I mean at a technical level, not an sentimental one.

VS.Net has the potential to be a player with Java. But that is benefitted by
current VB programmers making the switch with as few subtle gotchas as
possible.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

Re: Bad programming practices encouraged.... namely VB!

Jonny,
> So if you want me to stop my roller-coaster of learning and start
nitpicking
> over some trivial detail so that I can look good in front of my friends
then
> fair enough, but I know you don't really - I know you want to have a party
> too.

Way too much fun, isn't it? And you are still doing WebForms? Gotta' get my
box set up better to play with that. Just did a PITA file transfer thing in
ADO.classic in ADO.Net that is fabulous. What else have you tried. Yes,
let's party.

But let's split this joint for the Technical bar. It has better beer, and
the music is more to my taste. There are some fun lurkers back in the
shadows there also.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

Re: Bad programming practices encouraged.... namely VB!

Kathleen
> But let's split this joint for the Technical bar. It has better beer, and
> the music is more to my taste. There are some fun lurkers back in the
> shadows there also.

I am roaming through both groups and even sent a few lines to the OR (gasp)
so I guess I must be bored. Its true, I need to go home now [sob] I have
been in the desert for nearly a month now and Scotland feels like a distant
dream.

BTW, I am sticking to my guns about *only* doing webforms. Its a blast and a
quite a radical change from doing VB.Classic win apps. Maybe thats why I
have no patience with the posturing of the bitwise-guys; everything is so
different now that the nit-picking just gets swamped out by all the novelty.

Re: Bad programming practices encouraged.... namely VB!

On Thu, 12 Apr 2001 17:43:21 -0700, "Jonny" <jonny@joyofvb.com> wrote:
>There is so much that is new, vast undulating plains of novelty. The power!
>Can you feel it? It makes me go a little crazy.

Yeah, we noticed.
>And then I come up here to
>share my joy only to find a NG ruled by tinpot dictators and self-styled
>harbingers of Doom. Why is nobody telling these boring moaners to shut up?

I thought that was your job?
>What is wrong with y'all that you are not having a party. I do not
>understand it.

We don't like what you're smokin'.
>
>So if you want me to stop my roller-coaster of learning and start nitpicking
>over some trivial detail so that I can look good in front of my friends then
>fair enough, but I know you don't really - I know you want to have a party
>too.

Not with you we don't. Anyway, isn't there a curfew where you live?
>Hang on - I think I may be bordering on discussing dotnet here and I know
>Patrick does not like that so I better shut up (or maybe its saying '****'
>he doesn't like, there are so many rules I just get plain confused).

Confusion just gets in the way of having a party, ain't that the
truth!