Stylistic note on loops

[Robert Klemme]

I find that it looks like pseudo-programming. Sure, it can be executed,
but it's the writer who should be.

Uh, oh... Where can I get my "one cross each"?

Let's just bring back APL, why don't we?

Cheers

robert

 

[Robert Klemme]

when faced with the choice of learning python or ruby I chose python.
ruby looked a bit strange. Having skimmed the tutorial you mention it
looks a lot less strange!

I'm really curious what you found strange initially and what points made
you change your mind. That might help improve the next "Ruby for X
coders" guide.

But if you write pseudo code like this then
heaven help your collegues!

ARGF.each { |line| print line if line =~ /Ruby/ }

Well, you basically only need to know that ARGF iterates over all files
in ARGV or reads from stdin if ARGV is empty. I think the rest is
pretty self explanatory, isn't it?

Kind regards

robert

 

[Robert Klemme]

For an entire set of tasks I therefore used Perl,
starting with 4.019. I got good with it, and never understood why anyone had
serious problems with it, including the so-called "line noise" "problem"
that was never a problem for me. I found that universal software engineering
principles (modularity, proper naming conventions, understanding scope) took
care of problems in Perl that people always seemed to be complaining about,
that are in fact problems in practically every other programming language.

Few years back I was used to Perl, too. But nowadays I have forgotten
all the subtleties of references arrays, scalars and implicit
conversions going on. That makes me wary and I wouldn't be so sure
whether I can properly decode a Perl program without going back and
forth through documentation nowadays. I would not say the same about C
for example which I do not use for several years as well. I would still
consider it more readable than Perl and this is what makes be believe
that Perl has real disadvantages compared to other similar languages.

Kind regards

robert

 

[Niklas Holsti]

So in effect you are saying that the C family of languages is "trending
towards" Ada since they already have "{}" as a way of representing an
empty (do-nothing) statement.

I said nothing about trends in the "C family". The trend I see is in
this discussion of how to use C syntax to write an empty loop body. The
postings to which I replied try to make the empty loop body more
visible, and less likely to be the result of a typing mistake or syntax
goof, than is the case if just the C null statement ";" is used.

Stefan Ram imagined a language with a specific symbol, Ø, for the null
statement, so I wanted to comment that Ada takes that approach,
specifically to make null statements more visible.

Then you (Lew) noted that the empty compound statement {} is also a
representation of "do nothing" in C. I think that is a good point, and
{} is certainly more visible than a single semicolon. As one reads it
from left to right, it suggests the same things as the Ada form: '{'
suggests "here the loop body begins"; the empty interior suggests "do
nothing"; and '}' suggests "here the loop body ends".

I think it would be a good idea for future C standards to deprecate the
single semicolon as a null statement, in favour of {}. The C99 standard
does not suggest using {}, as far as I could see.

No, that's backwards. C came before Ada. So actually, Ada is trending
towards C because it has "null" as a synonym for C's "{}".

I was not speaking of the trends in language evolution, but of trends in
this discussion. But I do see some small convergence in these languages.
For one thing, Ada 2012 is introducing conditional expressions (if cond
then value1 else value2), corresponding to the C conditional cond ?
value1 : value2.

 

[Nick Keighley]

I'm really curious what you found strange initially and what points made
you change your mind.  That might help improve the next "Ruby for X
coders" guide.



Well, you basically only need to know that ARGF iterates over all files
in ARGV or reads from stdin if ARGV is empty.  I think the rest is
pretty self explanatory, isn't it?

oh I'm sure i could work it out. But if I were writing p-code it
wouldn't look like that! To me p-code is either to explain something
to someone else or it's to help me figure something out. Hence my p-
code tends to reflect my programming history. It tends to be a
simplified Pascal and Python looks *very* much like my p-code (to such
an extent I thought they were stealing my ideas

 

[Nick Keighley]

I've seen some very readable perl. It had subroutines and comments and
so on. I've also seen some horrid perl.

No, because most English speakers I know regard English as an inferior
language to other more structured, less idiomatic languages with fewer
irregulars.

as a native english speaker I have great sympathy for people learning
english after first learning a language more regular in spelling. Eg.
Italian, German, Dutch well pretty well every european language except
english! But I would not go so far as to call it an inferior
language.The inconsistencies reflect (partly) its multiple roots. This
is one of the strengths of english.

Italian: "english is difficult because there are so many phrases that
don't mean what they seem like they mean"

Nick: "I know, boco di lupo with learning english"


yes but we were talking pseudo code. The more weirdlyidiomatic the
langauge is the less useful it is as a pseudo-code (unless the
audience is veryfamilar with the chosen idiomatic language). I'm sure
APL is very powerful but I wouldn't choose it as a medium to explain
things to other people. Ditto Lisp.

Broken logic.  You can likely become a proficient coder in anything
horrid given enough time---in fact there's a programming language
designed to be specifically difficult, it's name escapes me.

there's a few- Brainfuck is one

 You
might even become a very comfortable insider at using a screwdriver to
pound in a nail.  That does not keep you from saying it's relatively a
terrible idea (an inside judgment), nor does it preclude a fair
outside judgment.  It does not preclude someone from having tried it
as judging it as a bad idea.  If such a thing as coding clearly
exists, then it's antithesis must also, and of all the degrees in
between.  And some languages support this better than others---
regardless of how used to it you can be.

this lisp people speak of "blub"- the language that people use when
they can't see the point of a more powerful language. "well I wrote a
compiler in FOTRAN IV so I don't see why you'd use anything else". If
a language doesn't support recursion then people who program in that
language will see recursion as unnecessary. COBOL programmers are
supposedly unaware of what a global variable is (allegedly everything
is global). The Lisp people of course implicitly believe that all non-
Lisps are a Blub.

 

[Stefan Ram]

this discussion. But I do see some small convergence in these languages.
For one thing, Ada 2012 is introducing conditional expressions (if cond
then value1 else value2), corresponding to the C conditional cond ?
value1 : value2.

... corresponding to the Algol-60 if:

»3.3.2 Examples
(...)
if a<0 then A/B else if b=0 then B/A else z«

http://www.masswerk.at/algol60/report.htm#3

 

[Tom Anderson]

This is a somewhat ?chauvinistic? or ?egocentric? point of
view, by which Russian or Chinese should be ?gross?, too,
because it does not use ?readable? latin letters but
?unreadable? Cyrillic or Chinese symbols. However, it misses
that for someone who has grown up in a culture with Cyrillic
letters the inverse holds.

We cannot judge the readability of a language from the
outside, from the point of view of someone who does not know
the language well, but should judge it from the inside.

perl was my primary language for about four years. I can say as an insider
that it's unreadable. Moreover, that it's dreadful in many ways.

tom

 

[Tom Anderson]

Perl?



Intercal most likely.

Haskell.

tom

 

[Tom Anderson]

(Just in case someone STILL does not have seen this yet

http://imgs.xkcd.com/comics/lisp.jpg

Perl - the language to Get Things Done.

That's a funny (ish) comic, but it honestly isn't accurate. I wrote tons
of perl for years, and it is absolutely *not* an effective way to Get
Things Done for values 'thing' any bigger than a shell script. As soon as
i learned python, i threw perl away and never looked back - i got more
done, faster.

tom

 

[Joshua Cranmer]

This is a somewhat »chauvinistic« or »egocentric« point of
view, by which Russian or Chinese should be »gross«, too,
because it does not use »readable« latin letters but
»unreadable« Cyrillic or Chinese symbols. However, it misses
that for someone who has grown up in a culture with Cyrillic
letters the inverse holds.

To my knowledge, `$' and `|' are not letters in any script in the world,
at least of any with at least 1 million speakers [1]. The situation with
such characters is even worse, since with words as labels, you can go
for some indication of what it means in a native language. On the other
hand, an interpretation of `$|' would rely on knowing the names of the
characters. And `|' is called many different things in English alone:
vertical bar, pipe, bar, half-pipe, etc. And then using the idiomatic
expression that pipes are related to input and output. Note that I'm
assuming it has something to do with stdin; if it doesn't, that makes my
argument about its unreadability even stronger since a native-born
English speaker can't even deduce its meaning.

[1] Putting a cutoff at one million may seem chauvinistic, but with
several thousand languages in the world, some with unusual orthographies
that I am not aware of, "all" is a little bit wider than I dare go. If
we're talking about programming languages, in any case, languages spoken
by fewer than .1% of the world population are not likely going to be
strongly influencing programming language design.

 

[Martin Gregorie]

COBOL programmers are supposedly unaware of what a global variable
is (allegedly everything is global).

There's no allegedly about it: global is a non-term in COBOL. All data
items are defined in one section or another of the program's DATA
DIVISION and have the same scope, i.e. all data is accessible by any
executable statement in the program. The sections of the data division
are functional in that they define how the data in a section is used:
- items in the file section can be read and written with file i/o
- items in linkage section are are the formal arguments if the program
is callable
- items in working-storage are private to the program in the Java sense
of private.

And yet, having written far more COBOL than was ever good for me, I can
confirm that it does a good, if verbose, job in the types of tasks it was
designed for, which are mainly manipulating large amounts of structured
data. Its easy to read if its tolerably written though, like all
programming languages, can also be written dreadfully.

 

[Martin Gregorie]

Java uses Perl(esque) regexes, so no coincidence.

Yes. I use pcre a lot (writing Spamassassin rules) and in the few cases
so far where I've used Java regexes, I've basically written a pcre and
found no surprises.

FWIW there are a few web tools out there that can be used for interactive
pcre development. I think they should also be useful for Java. Here are
the ones I know about.

http://www.fileformat.info/tool/regex.htm - for Java regex development
http://www.solmetra.com/scripts/regex/ - for PHP, Perl and Python regexes

 

[Niklas Holsti]

There's no allegedly about it: global is a non-term in COBOL. All data
items are defined in one section or another of the program's DATA
DIVISION and have the same scope, i.e. all data is accessible by any
executable statement in the program.

According to Wikipedia, that was true for earlier forms of COBOL, but
the current standard includes local variables, too.

 

[Tom Anderson]

There's no allegedly about it: global is a non-term in COBOL. All data
items are defined in one section or another of the program's DATA
DIVISION and have the same scope, i.e. all data is accessible by any
executable statement in the program. The sections of the data division
are functional in that they define how the data in a section is used:
- items in the file section can be read and written with file i/o
- items in linkage section are are the formal arguments if the program
is callable
- items in working-storage are private to the program in the Java sense
of private.

How big is a typical 'program'? If it's the size of a class, then COBOL's
implicit 'global' is really an implicit 'private static'; if it's the size
of a package, then it's really an implicit '/* default */ static'. If it's
the size of an application, then it really is global, and i can imagine
pain results.

A bit of googling reveals that there are various extensions to COBOL for
things like local variables, thread-locals, making programs recursive or
reentrant, etc. And of course there's an Object COBOL.

So, whilst it may be true that for most of its life, and for the time when
it was most important, COBOL's programmers talked as much about global
variables as fish do about water, but i doubt that's been true since, i
would guess, 1990.

tom

 

[Martin Gregorie]

How big is a typical 'program'?

I've written/worked on programs varying from 300 lines (a simple 'grab a
record or two and paint a screen') called module in a mainframe online
database application to 8000 lines or so for a monolithic data analysis
program. It normally would be between 1000 and 3000 lines.

If it's the size of a class, then
COBOL's implicit 'global' is really an implicit 'private static';

It doesn't really map that way: A program is either:

- a monolithic single file which would be broken into a set of classes
if it was written in (Java) or a smaller number of C source modules
if it was written in C.

- or it corresponds to a single subroutine or function in Fortran/Pascal/
C terms.

In the COBOL shops I've worked in its been unusual to break a program
into separate compilation units, probably because the language definition
mandates that the compiler includes a copy library. This allows you to
define 'copy units' which contain arbitrarily large chunks of source and
pull them into a program, altering the names of data items and procedure
division labels as needed to avoid conflicts. A copy unit can define
data, such as a record or print line definition, or procedure division
items which can be anything from a single sentence paragraph to an entire
procedure division section.

Terminology clarification: A statement is called a 'sentence', a
'paragraph has a name (label) and contains one or more sentences and a
'section', which also has a name, contains one or more sections. Sections
and paragraphs can be PERFORMed (equivalent to a procedure call) or
referenced in a GO TO statement and yes, you can legally PERFORM and GO
TO the same paragraph from different parts of the same program.

Since (I think) COBOL 85 its been possible to put a set of related
programs into a single source file, somewhat like using nested classes in
Java, but no shop I've worked in has used this ability.

A bit of googling reveals that there are various extensions to COBOL for
things like local variables, thread-locals, making programs recursive or
reentrant, etc. And of course there's an Object COBOL.

The last version I used seriously was MicroFocus COBOL 90, in around 1995
and a bit of Tandem NonStop COBOL a year or two later. I don't recall
seeing any of those features in either COBOL implementation, but then
again neither needed to use them. The Tandem COBOL formed callable
modules embedded in the Pathway application manager (i.e., equivalent to
using JBOSS or Tomcat). The MicroFocus COBOL code ran in another
application framework, but this one was written in C and optimised for
switching financial messages between an ATM network and the accounting
system on a mainframe. The bank-specific logic was defined by writing
callable COBOL modules.

So, whilst it may be true that for most of its life, and for the time
when it was most important, COBOL's programmers talked as much about
global variables as fish do about water, but i doubt that's been true
since, i would guess, 1990.

I don't know, but then I haven't seen or been involved with any newly
written COBOL since about 1983. All the COBOL I've seen since would
probably have dated from the mid/late 1980s since that was when the kit
it ran on (Tandem Guardian NonStop, Stratus fault tolerant and NCR UNIX
boxes) became widely used, and had been modified to suit changing
requirements since then rather than being rewritten.

 

[Martin Gregorie]

According to Wikipedia, that was true for earlier forms of COBOL, but
the current standard includes local variables, too.

Are you sure? "COBOL 2002 and object-oriented COBOL" mentions locale-
based processing, not local variables, and "Features" says that it
originally had no local variables but not that they have been added.

I suppose if you include callable programs (i.e. with LINKAGE SECTIONs)
in the same source file as the program that calls them you could say the
data items in the data division of the callable programs are local, but
thats about it. In any case I consider the concept of a multi-program
source file to be a misfeature the typical COBOL program is big enough
already without putting several of them in a single source file.

 

[Lew Pitcher]

Are you sure? "COBOL 2002 and object-oriented COBOL" mentions locale-
based processing, not local variables, and "Features" says that it
originally had no local variables but not that they have been added.

IBM's COBOL compilers support the LOCAL-STORAGE SECTION (which provides
a "threadable" or "object" isolated storage) along with the usual
WORKING-STORAGE SECTION (which provides a compile-unit-wide storage).

FWIW, COBOL programs are typically managed in a way similar to C functions;
each COBOL program (typically) represents one callable entrypoint (i.e. a
single "function") with arguments ("LINKAGE SECTION"), local static
variables ("WORKING-STORAGE SECTION"), and (now) thread/object-local static
variables ("LOCAL-STORAGE SECTION").

 

[Arved Sandstrom]

Haskell.

tom

You're kidding, right? Haskell has a steeper learning curve, so may be
considered difficult in that sense, but once you've gotten good at it (which
doesn't take all that long) its ability to write clean, concise, correct
programs dwarfs that of most languages. It certainly wasn't *designed* to be
difficult.

AHS

 

[Mike Schilling]

A bit of googling reveals that there are various extensions to COBOL for
things like local variables, thread-locals, making programs recursive or
reentrant, etc. And of course there's an Object COBOL.

AKA MOVE COBOL + 1 TO COBOL.