From: Solar Flare on
Trouble is some of the more modern languages such a Visual Basic have
some very poor and hard to follow structures in them also.

EXITIF. Basically a goto with a hard to follow destination. A
supposedly structured statement that encourages confusion. Notice how
it become difficult how far to exit out of loops and usually the
definition of the EXITIF statement has to be loked up to remeber how
deep to exit form. These examples are compounded by multiple page code
writing.

Examine both examples and see how there is less confusion in the GOTO
statements. I won't address the flag method of exiting successive
loops.

For i = 1 to umteen
initialize_some stuff
for j= 1 to umpteenNo2
initialize_some_k_stuff
for k= 1 to unpteenNo3
next k
EXITIF j=k and j=i
do_some_loop_stuff
next j
do_some_outer_loop_stuff
EXITIF j=k or world_ended
finalize_some_stuff
next i
line_of_code

For i = 1 to umteen
initialize_some stuff
for j= 1 to umpteenNo2
initialize_some_k_stuff
for k= 1 to unpteenNo3
next k
IF j=k and j=i GOTO OUT1
do_some_loop_stuff
next j
OUT1
do_some_outer_loop_stuff
IF j=k or world_ended GOTO OUT2
finalize_some_stuff
next i
OUT2
line_of_code

GOTOs can be part of structured code if you use them correctly. Some
people can make confusing code out of any structure. C can be the
worst and Forth can be be the clearest to read if done properly.


"Rod Speed" <rod.speed.aaa(a)gmail.com> wrote in message
news:4vefjgF1benflU1(a)mid.individual.net...
> Joe Fischer <joe(a)westpointracing.com> wrote
>> Rod Speed <rod.speed.aaa(a)gmail.com> wrote:
>>> Joe Fischer <joe(a)westpointracing.com> wrote
>>>> dold(a)04.usenet.us.com wrote
>
>>>>>> the fascist prof gave me an F on that program because I used a
>>>>>> GOTO :-)
>
>>>>> That statement deserves a smiley, because it's laughable.
>
>>>> The concept that there is something wrong with GOTO is what is
>>>> laughable,
>
>>> Nope.
>
>>>> there direct machine instructions for the 386 family that does
>>>> precisely that.
>
>>> Irrelevant.
>
>>>> What can possibly be wrong with using a machine instruction?
>
>>> It can make the code hard to read.
>
>> That depends on where the jump GOes TO in the code.
>
> Nope, its basically where it comes from.
>
> It can produce more readable code in a very few specialised
> situations, like when bailing to a general error handler etc, but
> the problem is that while ever the language allows it, clowns
> who dont understand what structured code is about inevitably
> use it to write very messy and hard to read code instead.
>
>> It is sad that the opinion of one or a few early programmer
>> teachers would put a taboo on programming style.
>
> Anyone with a clue can grasp the advantages of structured code.
>
> You dont qualify obviously.
>
>> Line number BASIC code usually was poor programming style.
>
> Yes, because it encourages fools to write poorly structured code.
>
>> And the GOTO was often used just because the programmer
>> didn't plan the structure and ran out of room. :-)
>
> Nope, its usually used by fools who wouldnt know what properly
> structured code was if it bit them on their lard arses.
>
> You do qualify there.
>
>> But that doesn't give a teacher a good
>> enough reason to mark a paper in a way that
>> can affect the student for the rest of her life.
>
> Mindlessly silly exaggeration.
>


From: Solar Flare on
Very unbreadable language. I wrote a C compiler one in assembly and
when I got to pointers I discovered the confusion was built into the C
language. C definitions conflict with themselves in the Kernigan and
Ritchie (??) standard definitions. They break their own rules and
flavour of structure.

If a language is used for clarity it should be Pascal. It is a
structured easy to read by all Algol type language, inline code. C is
an easily confused, easily cryptic language with lots of hidden
meanings, needing to make use of libraries most have never seen and
very low level, maeaning it has no error correction for the young at
code writing to fall into.

Now who has a Pascal compiler?

"Morris Dovey" <mrdovey(a)iedu.com> wrote in message
news:45919fdf$0$509$815e3792(a)news.qwest.net...
> <nicksanspam(a)ece.villanova.edu> wrote in message
> news:ems4h0$ikq(a)acadia.ece.villanova.edu...
>
> | 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. 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. 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.
>
> --
> Morris Dovey
> DeSoto Solar
> DeSoto, Iowa USA
> http://www.iedu.com/DeSoto
>
>
>


From: Solar Flare on
Sometimes GOTO makes code more structured.

"Rod Speed" <rod.speed.aaa(a)gmail.com> wrote in message
news:4vefouF1bq4vkU1(a)mid.individual.net...
> 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: Solar Flare on
Original Basic had not while do, for next or any other stucture. It
was simple.

"Morris Dovey" <mrdovey(a)iedu.com> wrote in message
news:4592903a$0$61929$815e3792(a)news.qwest.net...
> "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: Rod Speed on
Solar Flare <solaerfart(a)hootmail.invalidated> wrote:

> Trouble is some of the more modern languages such a Visual Basic have some very poor and hard to
> follow structures in them also.

Sure, but they still leave dinsoaurs like BASICA and GWBASIC for dead.

> EXITIF. Basically a goto with a hard to follow destination.

Nope, its like any other exit and a lot more obvious than a goto where
you have to work out where the target is relative to the current code.

> A supposedly structured statement that encourages confusion.

You need something like that.

> Notice how it become difficult how far to exit out of loops and usually the
> definition of the EXITIF statement has to be loked up to remeber how deep to exit form. These
> examples are compounded by multiple page code writing.

Sure, like any other construct, it needs to be sensibly used.
The problem with GOTOs is that is much too easy for fools
to produce spaghetti code thats very hard to read.

> Examine both examples and see how there is less confusion in the GOTO
> statements. I won't address the flag method of exiting successive loops.

> For i = 1 to umteen
> initialize_some stuff
> for j= 1 to umpteenNo2
> initialize_some_k_stuff
> for k= 1 to unpteenNo3
> next k
> EXITIF j=k and j=i
> do_some_loop_stuff
> next j
> do_some_outer_loop_stuff
> EXITIF j=k or world_ended
> finalize_some_stuff
> next i
> line_of_code

> For i = 1 to umteen
> initialize_some stuff
> for j= 1 to umpteenNo2
> initialize_some_k_stuff
> for k= 1 to unpteenNo3
> next k
> IF j=k and j=i GOTO OUT1
> do_some_loop_stuff
> next j
> OUT1
> do_some_outer_loop_stuff
> IF j=k or world_ended GOTO OUT2
> finalize_some_stuff
> next i
> OUT2
> line_of_code

> GOTOs can be part of structured code if you use them correctly.

Sure, but the problem is that few do. They get less choice with visual
basic so its harder to produce the most obscenely unstructured code.

> Some people can make confusing code out of any structure. C can be the worst

Sure, but only a fool would claim that C is the epitome of a programming language.

> and Forth can be be the clearest to read if done properly.

It isnt as useful in the situation where Nick drops his code turds.

Neither is C, just because its not so obvious to those who arent fluent in it.

He'd be a lot better off using Visual Basic, and should be using a spreadsheet anyway.


> Rod Speed <rod.speed.aaa(a)gmail.com> wrote
>> Joe Fischer <joe(a)westpointracing.com> wrote
>>> Rod Speed <rod.speed.aaa(a)gmail.com> wrote:
>>>> Joe Fischer <joe(a)westpointracing.com> wrote
>>>>> dold(a)04.usenet.us.com wrote
>>
>>>>>>> the fascist prof gave me an F on that program because I used a
>>>>>>> GOTO :-)
>>
>>>>>> That statement deserves a smiley, because it's laughable.
>>
>>>>> The concept that there is something wrong with GOTO is what is
>>>>> laughable,
>>
>>>> Nope.
>>
>>>>> there direct machine instructions for the 386 family that does
>>>>> precisely that.
>>
>>>> Irrelevant.
>>
>>>>> What can possibly be wrong with using a machine instruction?
>>
>>>> It can make the code hard to read.
>>
>>> That depends on where the jump GOes TO in the code.
>>
>> Nope, its basically where it comes from.
>>
>> It can produce more readable code in a very few specialised
>> situations, like when bailing to a general error handler etc, but
>> the problem is that while ever the language allows it, clowns
>> who dont understand what structured code is about inevitably
>> use it to write very messy and hard to read code instead.
>>
>>> It is sad that the opinion of one or a few early programmer
>>> teachers would put a taboo on programming style.
>>
>> Anyone with a clue can grasp the advantages of structured code.
>>
>> You dont qualify obviously.
>>
>>> Line number BASIC code usually was poor programming style.
>>
>> Yes, because it encourages fools to write poorly structured code.
>>
>>> And the GOTO was often used just because the programmer
>>> didn't plan the structure and ran out of room. :-)
>>
>> Nope, its usually used by fools who wouldnt know what properly
>> structured code was if it bit them on their lard arses.
>>
>> You do qualify there.
>>
>>> But that doesn't give a teacher a good
>>> enough reason to mark a paper in a way that
>>> can affect the student for the rest of her life.
>>
>> Mindlessly silly exaggeration.