From: rst0wxyz on

Morris Dovey wrote:
> Joe Fischer wrote:
>
> | but I have written a lot of code, and never (possibly
> | on one occasion) been able to use the same module
> | a second time without modification.
>
> The second is the most probable cause of the first. Re-usability is
> hardly ever an accident - generally it involves generalizing a task to
> the n-th degree and then writing a (very broadly applicable) general
> solution.
>
> | And I have never used a debugger, but then
> | I never had the agony of working in a team. :-)
>
> I've only used a debugger a few times; but I've worked as part of a
> team many times. Whether it's agony or ecstasy is very dependent on
> the team - and I've had the very real pleasure of working with some
> absolutely first-class teams. I can guarantee that you've missed out
> on a lot of excitement.
>
> | So line number BASIC is my preference for
> | programs that will fit on one or two screens, and I
> | have used GWBASIC for 20 years (and still use it
> | as a calculator). :-)
>
> Hard to argue with a preference <g> - Mine is for APL (which no one

I have never seen APL used anywhere except in IBM, so you must be
working for IBM.

> can read) because of the wealth of operators provided. It makes a
> gee-whiz desk calculator because of its matrix manipulation
> capabilities.
>
> --
> Morris Dovey
> DeSoto Solar
> DeSoto, Iowa USA
> http://www.iedu.com/DeSoto

From: daestrom on

"Joe Fischer" <joe(a)westpointracing.com> wrote in message
news:31d8p2tcres5cgvivn1r92kat7u88kup14(a)4ax.com...
> On Thu, 28 Dec 2006 12:36:47 -0500, "daestrom"
> <daestrom(a)NO_SPAM_HEREtwcny.rr.com> wrote:
>
>>Having had to maintain other people's code, (some of it 20 year old
>>FORTRAN
>>'66), I can certainly agree with this. Heck, over the years I've had to
>>go
>>back and maintain my own old code and sometimes wished I had done a better
>>job 15 years ago when I wrote it the first time :-) The more spaghetti,
>>the
>>more likely a 'fix' is going to create yet another problem.
>
> A person that makes spaghetti in line number BASIC
> can make more in some C compilers if they allow GOTO to
> jump to another function.
> I think line number BASIC is preferred to present
> short problems in a public forum, at least the B in
> BASIC stands for "Begin........".
> If anybody wants to run it in visual basic, it should
> not be difficult.
>
>>Another thing to consider though is reusability. Nick often starts a new
>>thread with a new simulation of a new idea. All well and good, but often
>>leaves out some detail of the model that may/may-not be relevent. If
>>something like reusable objects were his mainstay, then each 'refinement'
>>to
>>a particular piece would not be lost each time he 'starts over'.
>>Furthermore, when a project uncovers a need for a refinement to the
>>modeling
>>of something (say, adding radiant heat transfer to/from a surface where
>>before only conduction/convection were modeled), all previous
>>models/projects can quickly be recompiled/linked to use this new
>>refinement.
>>(as long as the interface is maintained, and even if it needs to be
>>changed,
>>it's simpler than starting from scratch). But Nick's code often
>>'reinvents
>>the wheel' each time. That's prone to errors.
>
> The concept of reusable code or modules fails to
> consider the variety of possible programs and the many
> ways algorithms can be juxtaposed.
>
>
>>Good production-quality coding is not easy. Often, it's a choice between
>>'what we have time to do', and 'what we should do'. Forcing oneself to
>>refactor, split off another class, cut-out duplicate code and put in a
>>separate subroutine/function/method, etc... is the price one pays for
>>maintainability and reliability. Somewhat like fully normalizing a
>>database
>>structure (no duplicate information!!!), once in a while good structures
>>cost a couple of CPU cycles. But more often then not it also
>>prevents/finds
>>bugs before it goes to testing, much less production. But even so, a few
>>careful 'GOTO's, just like an extra column in a table, can sometimes be
>>justified for performance.
>>daestrom
>
> There may be egoists who will not believe this,
> but I have written a lot of code, and never (possibly
> on one occasion) been able to use the same module
> a second time without modification.
> And I have never used a debugger, but then
> I never had the agony of working in a team. :-)
>
> So line number BASIC is my preference for
> programs that will fit on one or two screens, and I
> have used GWBASIC for 20 years (and still use it
> as a calculator). :-)
>

I'm not saying BASIC is 'bad'. But a lot of wannabe programmers have
written some God-awful code with it. Of course, the same can be said for
just about any computer language :-)

Having a line number on every line doesn't really add anything useful
though. Probably why later versions made it optional. Numbering only the
lines that are targets of some flow-control (GOTO, ON GOTO, etc...) can make
it easier to find them. Somewhat like FORTRAN's labeling. But sadly,
FORTRAN labels are not required to be in 'numerical order', so some
beginners when they find they need one more label in between label number
'10' and '11', will just insert something like '111' (UGHH!!!). At least
some versions of BASIC have a 'renumber' scheme where you can straighten
that out without having to manually find all the references to a given label
when you want to change it.

A debugger can be a great tool when unit-testing. Step-by-step through
every line/branch of code and you'd be surprised the things you can find
early on that would have lain dormant for quite a while till the end user
happens to find it. Sure single-stepping and looking at all the variables
in a function is a bit time consuming, but it really *does* pay off on
anything more than about 50 lines of code.

When writing functions, I've found 'design by contract' very useful. If you
carefully think about the in/out and what-ifs, you can get some pretty good
code the first time around (instead of fourth or fifth).

As far as re-usability, guess it depends on how closely related projects are
and how 'generic' you make the code. Certainly an object built for a
billing department application to represent an inventory item is not going
to be very useful for a simulation model of an assembly. But I've found
that 'centrifugal pump' (a subclass of 'pump') or 'fluid heat exchanger' can
be used in many different simulations. Just initialize with the internal
parameters for a given instance and off we go. Want to enhance the
'centrifugal pump' model to consider some obscure feature that only shows up
in some rare instances? No problem, update the class's 'DetermineHead'
function (or whatever) and it's there. Add some new code to the unit-test,
run all the unit-tests to be sure we didn't break any of the old tests and
we're off and running. I seldom have to worry about 'did I code all the
salient features I need for *this* particular project, because once they are
'in the object', they stay there.

I've worked on a few team projects (n-tiered web apps that interface
between orders, assembly and parts inventory was one monster). Biggest
issues where getting nailed down exactly what each layer was responsible for
and standardizing the interfacing between layers. Some wanted COM, DCOM,
some pushed for 'open' technologies like CORBA, while a few were 'in love'
with BEANS. Design by contract was a must for this (always verify inputs,
never trust the caller, and fail 'gracefully').

Those that rant about GOTO are often the same folks that sing praises of
exception handling technologies. But the two technologies are much alike
(when something goes wrong, GOTO an exception handler, if the nearest
handler doesn't like it, GOTO the next handler 'upstream'). I've actually
seen code written to throw exceptions as a way of exiting out of a deep
layer of functions when something perfectly normal happens. It worked. But
they didn't *document* it well so when another programmer, working in an
intermediate layer of the call stack added their own handler for a problem,
they couldn't figure out why they were 'catching' an exception they didn't
generate themselves.

daestrom

From: Morris Dovey on
rst0wxyz(a)yahoo.com wrote:
| Morris Dovey wrote:

|| Hard to argue with a preference <g> - Mine is for APL (which no one
|
| I have never seen APL used anywhere except in IBM, so you must be
| working for IBM.

From '69 to '75 - and that /was/ where I started using it. The IBM5081
portable computer was a favorite in many company's R&D labs; and it
ran both APL and CALL360-BASIC.

Somewhere around '80 a free APL went into circulation; and there's a
(free) PC version that'll run under Windows. If you're interested, I
suspect that Google can provide a number of download sites.

A word of warning: It's addictive. <vbg>

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto


From: daestrom on

"Morris Dovey" <mrdovey(a)iedu.com> wrote in message
news:459442a3$0$503$815e3792(a)news.qwest.net...
> Joe Fischer wrote:
>
> | but I have written a lot of code, and never (possibly
> | on one occasion) been able to use the same module
> | a second time without modification.
>
> The second is the most probable cause of the first. Re-usability is
> hardly ever an accident - generally it involves generalizing a task to
> the n-th degree and then writing a (very broadly applicable) general
> solution.
>
> | And I have never used a debugger, but then
> | I never had the agony of working in a team. :-)
>
> I've only used a debugger a few times; but I've worked as part of a
> team many times. Whether it's agony or ecstasy is very dependent on
> the team - and I've had the very real pleasure of working with some
> absolutely first-class teams. I can guarantee that you've missed out
> on a lot of excitement.
>
> | So line number BASIC is my preference for
> | programs that will fit on one or two screens, and I
> | have used GWBASIC for 20 years (and still use it
> | as a calculator). :-)
>
> Hard to argue with a preference <g> - Mine is for APL (which no one
> can read) because of the wealth of operators provided. It makes a
> gee-whiz desk calculator because of its matrix manipulation
> capabilities.
>

Never worked in APL. But for *truly* unreadable code, try BRAINFU__ (you
can probably guess the last two letters). More of a lark than a serious
language, but goes to show the lengths some geeks can go to :-)

Guess I don't understand you non-debugger types. With an IDE, stepping
through code in a debugger is a blessing. Can find all sorts of silly
mistakes in seconds. Beats the heck out of the old days of adding a bunch
of 'DEBUGPRINT' statements to track down *what* and *where*. (yeah, I know,
you guys don't make silly mistakes, right? right... :-)

I agree about the reusability. You do have to really think in 'generic'
terms. Break it right down to what truly *is* the core essentials of the
object/routine; what am I taking for granted here?

daestrom

From: Rod Speed on
Joe Fischer <joe(a)westpointracing.com> wrote
> daestrom <daestrom(a)NO_SPAM_HEREtwcny.rr.com> wrote

>> Having had to maintain other people's code, (some of it 20 year old
>> FORTRAN '66), I can certainly agree with this. Heck, over the years
>> I've had to go back and maintain my own old code and sometimes
>> wished I had done a better job 15 years ago when I wrote it the
>> first time :-) The more spaghetti, the more likely a 'fix' is going
>> to create yet another problem.

> A person that makes spaghetti in line number BASIC
> can make more in some C compilers if they allow GOTO to
> jump to another function.

Yes, C is even worse than line number basic, if only
because its much less readable by those who havent
come across it before. Anyone can read basic.

> I think line number BASIC is preferred to present short problems
> in a public forum, at least the B in BASIC stands for "Begin........".

More fool you. It makes a lot more sense to use Visual Basic instead.

> If anybody wants to run it in visual basic, it should not be difficult.

It makes a lot more sense to use Visual Basic instead.

>> Another thing to consider though is reusability. Nick often starts
>> a new thread with a new simulation of a new idea. All well and
>> good, but often leaves out some detail of the model that may/may-not
>> be relevent. If something like reusable objects were his mainstay,
>> then each 'refinement' to a particular piece would not be lost each
>> time he 'starts over'. Furthermore, when a project uncovers a need
>> for a refinement to the modeling of something (say, adding radiant
>> heat transfer to/from a surface where before only
>> conduction/convection were modeled), all previous models/projects
>> can quickly be recompiled/linked to use this new refinement. (as
>> long as the interface is maintained, and even if it needs to be
>> changed, it's simpler than starting from scratch). But Nick's code
>> often 'reinvents the wheel' each time. That's prone to errors.

> The concept of reusable code or modules fails
> to consider the variety of possible programs and
> the many ways algorithms can be juxtaposed.

Nope, thats what module design is about.

>> Good production-quality coding is not easy. Often, it's a choice
>> between 'what we have time to do', and 'what we should do'. Forcing
>> oneself to refactor, split off another class, cut-out duplicate code
>> and put in a separate subroutine/function/method, etc... is the
>> price one pays for maintainability and reliability. Somewhat like
>> fully normalizing a database structure (no duplicate
>> information!!!), once in a while good structures cost a couple of
>> CPU cycles. But more often then not it also prevents/finds bugs
>> before it goes to testing, much less production. But even so, a few
>> careful 'GOTO's, just like an extra column in a table, can sometimes
>> be justified for performance.

> There may be egoists who will not believe this,
> but I have written a lot of code, and never (possibly
> on one occasion) been able to use the same module
> a second time without modification.

Because you didnt design it properly.

> And I have never used a debugger,

More fool you.

> but then I never had the agony of working in a team. :-)

That aint the only time when a debugger makes sense.

> So line number BASIC is my preference for
> programs that will fit on one or two screens,

More fool you. Visual Basic is a significant improvement on that.

> and I have used GWBASIC for 20 years

More fool you.

> (and still use it as a calculator). :-)

In spades. You should be using a spreadsheet for that.

Thanks for that completely superfluous proof
that you're just another bone headed dinosaur.