From: Rod Speed on
Steve O'Hara-Smith <steveo(a)eircom.net> wrote
> Rod Speed <rod.speed.aaa(a)gmail.com> wrote

>> Corse he should be using a spreadsheet, not a progamming language.

> Nah a programming language is portable - spreadsheet code is not.

Excel is as portable as you need, the free spreadsheets support it fine.


From: daestrom on

"Morris Dovey" <mrdovey(a)iedu.com> wrote in message
news:45926006$0$495$815e3792(a)news.qwest.net...
> "Rod Speed" <rod.speed.aaa(a)gmail.com> wrote in message
> news:4ve4g7F1bilo1U1(a)mid.individual.net...
> | Morris Dovey <mrdovey(a)iedu.com> wrote
> | > <nicksanspam(a)ece.villanova.edu> wrote
> |
> | >> I use BASIC for calcs and TMY2 simulations. Readability is
> important,
> | >> and floating point and log and trig functions. The platform cost
> | >> isn't important for design calcs, but low cost and low power are
> | >> important for things like a smart whole house fan controller.
> |
> | > Readability is more or less a matter of writing
> | > code to be readable, regardless of language.
> |
> | Yes, but dinosaur Basic is harder to produce clean readable code
> | with, so that doesnt happen in practice with amateurs like Nick.
>
> I think it's less a matter of difficulty than motivation. It's
> possible to use the same techniques to produce readability in BASIC
> source code as are used in other programming languages (indentation,
> whitespace, etc)
>
> | > Here's a transliteration of one of your recent snippets:
> |
> | > #include <stdio.h>
> | > #include <math.h>
> |
> | > int main(void)
> | > { double panes, sun, loss;
> |
> | > for (panes=1; panes<=10; panes++)
> | > { sun = 1000 * pow(0.9, panes);
> | > loss = 24 * (70 - 30) / panes;
> | > printf("%.0lf %8.4lf\n", panes, sun - loss);
> | > }
> | > return 0;
> | > }
> |
> | > Following the Borland example, some implementations of C
> | > (for CPUs without FPUs) include emulation code. I've written
> | > a couple of software floating point libraries in C to do basic
> | > operations (add, subtract, multiply, divide, square root, and
> | > sine/cosine) and they're not exactly socket surgery.
> |
> | > For one-off projects, none of this probably matters very much.
> |
> | The ones handed out to others are just the ones that
> | need to be readable, if only to check the logic etc.
>
> There's more to the issue if the code is anything other than just a
> throw-away "doodle". Readability is an important part of
> "maintainability". When code is revisited (for correction, expansion
> of function, etc) it needs to be readily understood by the maintainer,
> who may or may not be the original author. If the code is such a mess
> that it can't be understood/maintained, the best that can be hoped for
> is to re-develop from scratch (expensive); and the very worst that can
> happen is that a maintainer "take his best shot" at patching in
> something he hopes will effect the appropriate change(s). This latter
> usually has the effect of making the code still less maintainable -
> and frequently introduces a fresh set of problems.
>
> All this is difficult for people who only dabble at coding to grasp.
>

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.

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.

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

From: Joe Fischer on
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). :-)

Joe Fischer

From: rst0wxyz on

Joe Fischer wrote:
> 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

Now, if you had used a debugger, your development time could be cut by
75%.

> 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). :-)
>
> Joe Fischer

From: Morris Dovey on
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.

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