From: Rod Speed on
Joe Fischer <joe(a)westpointracing.com> wrote:
> On Tue, "Morris Dovey" <mrdovey(a)iedu.com> wrote:
>
>> "Joe Fischer" <joe(a)westpointracing.com> wrote:
>>> That overlooks the fact that the BASIC text file
>>> source code is easier to use by anyone with a copy
>>> of a BASIC interpreter, and easier to change parameters,
>>> in the shortest possible source code, ___without___
>>> compiling.
>>
>> That's only true if one ignores C interpreters (I do.)
>
> I tried to learn C for 20 years and didn't know
> there was a C interpreter available. :-)
>
>>> Compiled programs are good for certain things,
>>> line number BASIC has it's merits, one being the
>>> ability for a user to change it easy.
>>
>> Integrated development environments (IDEs) make this a non-argument.
>> They allow making a source change and clicking on a "RUN" button to
>> automatically compile, link edit, and execute quicker than you can
>> type "RUN".
>
> I think I was using the first IDE compiler in the
> early 1980s (if it was Borland Turbo Pascal 2.x).
>
>>> But there are BASIC compilers that don't
>>> need the RUNxxxxx support files, although that
>>> defeats the purpose of writing source code that
>>> can be translated to human understanding of
>>> the calculations.
>>
>> True; but also a non-argument. If it's written to be readable, then
>> it will be.
>
> Right, almost any construct can be made hard
> to read, but it is more difficult in line number BASIC
> to make it hard to read. In C, it can be made so
> that nobody but the programmer understands it,
> but this is partly because in C, the included modules
> must be understood by the person reading the code.
> In line number BASIC, that is not a factor.
>
>>> When doing any energy calculations, it
>>> helps to be able to work directly with the source
>>> code and an interpreter.
>>
>> This pre-supposes that the person writing the code has, at best, an
>> incomplete understanding of the problem. A person who understands the
>> problem and the tools being used implements the solution directly.
>
> It assumes that the person using the sample code
> is not a professional programmer, whether or not they
> know much about energy or physics.
>
>>> And there are even people who object to
>>> just being the slave of the programmer and
>>> just fill in the values when prompted, but
>>> to each his own.
>>
>> "Slave of the programmer" describes an unhealthy environment.
>
> It works for cases where the inputs are rigidly
> required, in the source code posted here that may
> not be true, for instance, the area may not be
> described as a rectangle, and the code may need
> to be changed, try that with a compiled program.
>
>> In a
>> healthy situation, the programmer is the slave of a functional
>> specification. If your situation is different, you should be
>> considering replacing either the person responsible for the
>> specification or the programmer.
>
> I don't think all programs can be written as strictly
> well specified. Which is why line number BASIC was
> popular, it allows jumping into the problem, and changing
> things along the way.
>
> All this does not even resemble large team projects
> with a rigid specification.
>
> A sample program in line number BASIC is perfect
> for presenting to a wide range of users, who may need
> to modify the code to fit a specific use, and one or two
> GOTOs might actually make it more readable.

Nope, its better to use a proper structured Basic instead and to
only use a GOTO when its use makes the code more readable.

Functions in spades.


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

| Corse he should be using a spreadsheet, not a progamming language.
|
| > OTOH, if the object is to produce large quantities
| > and to achieve performance objectives while using
| > a slower uC, then the savings can be huge.
|
| That has nothing to do with whether code is readable or not.

You're right - readability is only one of the factors that contribute
to the worth of a program. Still, it /is/ important.

In the context of Nick's stated objective, the ability to produce a
reliable controller at a cost that allows the greatest number of
people to afford and use it /is/ the point.

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



From: Morris Dovey on
"Joe Fischer" <joe(a)westpointracing.com> wrote in message
news:mnm3p294o2e5bvg7ov89q4dgfjbgh3a7a5(a)4ax.com...
| On Tue, "Morris Dovey" <mrdovey(a)iedu.com> wrote:
|
| >"Joe Fischer" <joe(a)westpointracing.com> wrote:
| >| That overlooks the fact that the BASIC text file
| >| source code is easier to use by anyone with a copy
| >| of a BASIC interpreter, and easier to change parameters,
| >| in the shortest possible source code, ___without___
| >| compiling.
| >
| >That's only true if one ignores C interpreters (I do.)
|
| I tried to learn C for 20 years and didn't know
| there was a C interpreter available. :-)
|
| >| Compiled programs are good for certain things,
| >| line number BASIC has it's merits, one being the
| >| ability for a user to change it easy.
| >
| >Integrated development environments (IDEs) make this a
non-argument.
| >They allow making a source change and clicking on a "RUN" button to
| >automatically compile, link edit, and execute quicker than you can
| >type "RUN".
|
| I think I was using the first IDE compiler in the
| early 1980s (if it was Borland Turbo Pascal 2.x).
|
| >| But there are BASIC compilers that don't
| >| need the RUNxxxxx support files, although that
| >| defeats the purpose of writing source code that
| >| can be translated to human understanding of
| >| the calculations.
| >
| >True; but also a non-argument. If it's written to be readable, then
it
| >will be.
|
| Right, almost any construct can be made hard
| to read, but it is more difficult in line number BASIC
| to make it hard to read. In C, it can be made so
| that nobody but the programmer understands it,
| but this is partly because in C, the included modules
| must be understood by the person reading the code.
| In line number BASIC, that is not a factor.

Eh? Any language (including English) can be made hard to read.

In C only the _function_ of the included modules need be understood.
For example, if I include a module to calculate the sine of an angle,
I need only understand that if I give it an angle, it will return a
value between -1 and +1 corresponding to that angle.

| >| When doing any energy calculations, it
| >| helps to be able to work directly with the source
| >| code and an interpreter.
| >
| >This pre-supposes that the person writing the code has, at best, an
| >incomplete understanding of the problem. A person who understands
the
| >problem and the tools being used implements the solution directly.
|
| It assumes that the person using the sample code
| is not a professional programmer, whether or not they
| know much about energy or physics.

Not even that. It assumes only that the person using a tool is
competant to use that tool. It applies equally to any programming
language.

| >| And there are even people who object to
| >| just being the slave of the programmer and
| >| just fill in the values when prompted, but
| >| to each his own.
| >
| >"Slave of the programmer" describes an unhealthy environment.
|
| It works for cases where the inputs are rigidly
| required, in the source code posted here that may
| not be true, for instance, the area may not be
| described as a rectangle, and the code may need
| to be changed, try that with a compiled program.

It's a non-challenge either way. Just write a function with a single
area parameter instead of height/width/radius/? parameters.

If I happen to be working in C, I make changes to the source code just
as I would with BASIC (or Algol or APL or Fortran or ...) and click on
the "RUN" button (except that with GWBASIC I'd actually need to type
"RUN".)

| >In a
| >healthy situation, the programmer is the slave of a functional
| >specification. If your situation is different, you should be
| >considering replacing either the person responsible for the
| >specification or the programmer.
|
| I don't think all programs can be written as strictly
| well specified. Which is why line number BASIC was
| popular, it allows jumping into the problem, and changing
| things along the way.

BASIC became popular because there was so little for a beginner to
learn. That's how it got its name!

Jumping into the middle of a solution (note that a program isn't a
problem, it's a solution) without understanding the problem is
indicative of a lack of discipline (immature behavior) - regardless of
the activity or technology.

| All this does not even resemble large team projects
| with a rigid specification.

Not been involved with many of those, have you? <g>

Specifications aren't rigid, _especially_ in "large team projects".
They're an attempt to verbalize a single understanding of a project in
order that the understanding can be shared. The larger the project -
especially if research is involved - the more likely a specification
is to change along the way. What's important about specifications is
that at any given point in time, all of the participants share a
common vision of the problem and the solution. The goal to be achieved
is usually more rigid - but even that is subject to change as new
information becomes available during the course of the project.

| A sample program in line number BASIC is perfect
| for presenting to a wide range of users, who may need
| to modify the code to fit a specific use, and one or two
| GOTOs might actually make it more readable.

I disagree. Closer to perfect is well-written prose and the inclusion
of all the diagrams, tables, and equations needed for all participants
to understand. Giving a "wide range of users" a solution without
imparting an understanding of the problem solved is of, at best,
questionable value. Computer codes (in any source language) should
probably be relegated to an appendix.

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



From: Jeff on
Morris Dovey wrote:
> "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.
>
> | Corse he should be using a spreadsheet, not a progamming language.
> |
> | > OTOH, if the object is to produce large quantities
> | > and to achieve performance objectives while using
> | > a slower uC, then the savings can be huge.
> |
> | That has nothing to do with whether code is readable or not.
>
> You're right - readability is only one of the factors that contribute
> to the worth of a program. Still, it /is/ important.
>
> In the context of Nick's stated objective, the ability to produce a
> reliable controller at a cost that allows the greatest number of
> people to afford and use it /is/ the point.

Perhaps I've missed something. I regularly read Nicks posts and I can't
remember any that were anything but a hypothetical solar collection
situation. I don't remember any of the code samples being useable in a
controller.

1) So, it seems fine that they are written in Basic because they would
never control anything.

2) Whatever the language chosen for any of our solar projects, on
whatever platform, it would have more than enough speed to suit our
needs. The most critical thing any of us do is Duane's trackers and I
doubt even they need much horsepower.

3) Didn't we just have a long thread about *where* solar gain was
considered in a "block" house and no one could get Nick to explain where
that was added, although all of understood the commented code and most
of us were programmers? Just proves we can argue over anything and Nick
can be as obtuse as he wants!

Jeff



>
> --
> Morris Dovey
> DeSoto Solar
> DeSoto, Iowa USA
> http://www.iedu.com/DeSoto
>
>
>
From: nicksanspam on
Jeff <dont_bug_me(a)all.uk> wrote:

>3) Didn't we just have a long thread about *where* solar gain was
>considered in a "block" house and no one could get Nick to explain
>where that was added...

Is a "block house" a D-cube? I don't recall any unanswered questions.

If you do, feel free to ask them now.

Nick