[ale] Any language (wuz: Assembly Language?)

Mon Oct 28 13:28:27 EDT 2013

I must admin that mandatory whitespace felt odd at first. But after 15+
years of OPC (Other People's Code) I'm convinced that ALL languages should
fail to compile/run on sloppy code. Maybe a bit of tough love on a group I
now consider to be highly unprofessional would thin the herd a bit.

I started on Fortran which had it's own idiosyncrasies on punch cards.
Pascal was a bad experience. Years of perl introduced a plethora of Really
Bad Habits. Bash let me shoot myself in the foot so much that I forced
myself to clean up just to preserve my sanity. Python was a breath of fresh
air in the clutter that was my VIm screen. I don't do much in python now
but I pretty much kept the just so everything else is readable later. OPC
is expected to be bad, unreadable crap. When you start putting your own
code in the OPC category, it's time to rethink some bad habits.

On Mon, Oct 28, 2013 at 1:18 PM, Byron Jeff <byronjeff at mail.clayton.edu>wrote:

> On Sun, Oct 27, 2013 at 03:10:11PM -0400, Ron Frazier (ALE) wrote:
> > Hi Byron,
> >
> > Interestingly enough, the indentation you showed didn't appear on my
> reader until I hit reply.  Now, I can see it.
>
> I still use a text E-mail reader: mutt. Sometimes it's difficult to know
> when my posts are going to format properly.
>
> >
> > It's been a LONG time since I've actively programmed in Clipper.  I
> > assume the compiler would enforce a rule like you mentioned to tie the
> > else clause to the closest open if statement.  However, I believe you
> > could use braces, parentheses, etc. to delimit things where the automatic
> > syntax parser would get confused.  I cannot remember for sure.  Another
> > way to avoid ambiguity is to always include the if, then, else, endif
> > keywords in languages that support that.
>
> All true. Personally I added ELSEIF and ENDIF constructs to all the
> languages I designed over the years along with one statement per line so
> that explicit statement terminators (semicolon) were unnecessary.
>
> >
> > I do believe humans should indent code so other humans can read it.  I
> > just don't believe that not doing so should cause a compile failure or a
> > runtime failure.
>
> The key is that in this instance the indentations cleans up the language
> significantly. Here are the two examples with endifs:
>
>
> if a > 5:
>    if b < 3:
>       call_small_b()
>    else
>       call_big_b()
>    endif
> endif
>
> as opposed to:
>
> if a > 5:
>    if b < 3:
>       call_small_b()
>    endif
> else
>    call_small_a()
> endif
>
> I agree that the endifs disambiguate each by the appropriate closing of the
> if. The problem is that now each and every control structure now is
> extended by an extra line of code that conveys little meaning if the code
> is properly indented.
>
> My point is that enforced indentation both makes the code syntatically
> cleaner, while at the same time makes it more readable. It literally
> creates a semantic contract between the code author and the
> compilation/runtime system. Less typing, less maintenance, less errors.
>
> Personally I think the minor annoyance is worth the winning features, IMHO.
>
> BAJ
>
>
> >
> > Sincerely,
> >
> > Ron
> >
> >
> >
> > Byron Jeff <byronjeff at mail.clayton.edu> wrote:
> >
> > >On Sun, Oct 27, 2013 at 09:31:39AM -0400, Ron Frazier (ALE) wrote:
> > >
> > >> In my opinion, the best language should ignore all white space AND
> > >NOT
> > >> require any curly braces or semicolons except as syntactically
> > >required
> > >> delimiters for lists and arrays, etc.  That's the way Clipper was,
> > >and it
> > >> was a real pleasure that the compiler wasn't always bugging me about
> > >> formatting yet still figured out how to compile the program.
> > >
> > >I cannot see how it can be without braces. How do you differentiate
> > >this:
> > >
> > >if a > 5 then if b < 3 then call_small_b() else do_you
> > >call_small_a_or_big_b ()
> > >
> > >Python makes it clear:
> > >
> > >if a > 5:
> > >   if b < 3:
> > >      call_small_b()
> > >   else
> > >      call_big_b()
> > >
> > >as opposed to:
> > >
> > >if a > 5:
> > >   if b < 3:
> > >      call_small_b()
> > >else
> > >   call_small_a()
> > >
> > >Braces can disambiguate the two also. But unless a rule is imposed that
> > >else is always associated with the closest open if, then the original
> > >construct is ambiguous. And if that rule is imposed, then there's no
> > >way to
> > >do the second construct.
> > >
> > >Then there is the philosophical issue of indentation. Indentation is
> > >rarely
> > >for the benefit of the compiler. It's task is to create organization
> > >for
> > >human readers. Reading improperly indented code is one of the biggest
> > >headaches. And as a Professor is unfortunately a task I have to do more
> > >often than I like.
> > >
> > >Python's use of significant whitespace is one of the tools that
> > >actually
> > >simplifies the language syntax. One statement per line so no semicolons
> > >are
> > >required. Indentation replaces braces. It also enhances readability. If
> > >my
> > >E-mail is properly formatted, then the two constructs above are
> > >visually
> > >clear in their intent, while the original is ambiguous because there is
> > >no
> > >imposed structure.
> > >
> > >Of course all this is IMHO.
> > >
> > >BAJ
> > >
> > >
> >
> > -snip-
> >
> > >
> > >--
> > >Byron A. Jeff
> > >Chair: Department of Computer Science and Information Technology
> > >College of Information and Mathematical Sciences
> > >Clayton State University
> > >http://faculty.clayton.edu/bjeff
> >
> >
> >
> > --
> >
> > Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9
> Mail.
> > Please excuse my potential brevity if I'm typing on the touch screen.
> >
> > (PS - If you email me and don't get a quick response, you might want to
> > call on the phone.  I get about 300 emails per day from alternate energy
> > mailing lists and such.  I don't always see new email messages very
> quickly.)
> >
> > Ron Frazier
> > 770-205-9422 (O)   Leave a message.
> > linuxdude AT techstarship.com
> > Litecoin: LZzAJu9rZEWzALxDhAHnWLRvybVAVgwTh3
> > Bitcoin: 15s3aLVsxm8EuQvT8gUDw3RWqvuY9hPGUU
> >
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
>
> --
> Byron A. Jeff
> Chair: Department of Computer Science and Information Technology
> College of Information and Mathematical Sciences
> Clayton State University
> http://faculty.clayton.edu/bjeff
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>

-- 
-- 
James P. Kinney III
*
*Every time you stop a school, you will have to build a jail. What you gain
at one end you lose at the other. It's like feeding a dog on his own tail.
It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
*
http://heretothereideas.blogspot.com/
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20131028/04486cb5/attachment-0001.html>