From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: Linus burned by Transmeta JIT morphing optimizations?
Date: Fri, 02 Jan 2004 09:20:23 +0100
Message-ID: <bt39k8$4ko$1@osl016lin.hda.hydro.com>

Tarjei T. Jensen wrote:
> Seems reasonable to me. Except that you will find this everywhere: People
> will insist on doing things in C/C++ even if it would be a lot easier to do
> it in Cobol.

Except that I've yet to see a reasonable example of code that is
actually easier in Cobol.

I used to believe that Cobol would at least be near-optimal for a
process that consisted of reading in 80-col card images, extracting a
number of ascii-encoded fields, sort & aggregate the data in various
ways, and then print out a sorted result list.

However, when I rewrote the 16-page Cobol program in Pascal, the result
was 6 pages, i.e. 62.5% less, even though I had re-implement both the
input unpacking and parsing, and the sorting procedures.

Yes, there was more blank space in the Cobol version, but not nearly
enough to explain the huge difference.

I.e. Cobol is simply too verbose, imho.

Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: Linus burned by Transmeta JIT morphing optimizations?
Date: Fri, 02 Jan 2004 14:13:43 +0100
Message-ID: <bt3qq8$erk$1@osl016lin.hda.hydro.com>

Casper H.S. Dik wrote:
> Christoph Breitkopf <chris@chr-breitkopf.de> writes:
>
>>I have seen too many wrong comments (i.e. comments disagreeing
>>with the code) and much too much long-winded code to believe
>>this. Consider Strunks and White's "The Elements of Style". Clarity
>>of expression is often best achieved by brevity. I don't think
>>there is much of a difference in that between natural and computer
>>language.
>
> I think APL is the canonical counter example; it's extremely compact
> and I've heard that the typical way to fix bugs one line APL functions
> (which is the usual length for an APL function) is to read the comment
> describing the function and reimplementing it from scratch, properly
> this time, possibly adding a comment about the bug fixed.

APL is indeed the canonical 'Write-Only' language. :-(

> In the case of Pascal I doubt that that is the case as Pascal is
> a fairly straight-forward language.  The power of the built-in
> operators (semantic density of operators, as it where) seems to be
> the deciding factor in my ability to easily read code; languages at
> the wrong side of the semantic density gap are generally write-only.
> (Perhaps easy to write but exceedingly hard to maintain)  I believe this
> to be the case for C++ and perl.

Both C++ and Perl can be very readable, but that usually means limiting
yourself to a somewhat sane subset of the total language capabilities.

Start hiding what you're really doing behind multiple layers of
templates, objects, operator overload, typedef's and #defines, and
you've got something which can be easier to reverse engineer from the
binary than the source code.

Even plain C can do this however, i.e. 'The C Obfuscation Contest'. :-(

Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: Linus burned by Transmeta JIT morphing optimizations?
Date: Fri, 02 Jan 2004 12:35:50 +0100
Message-ID: <bt3l2n$bla$1@osl016lin.hda.hydro.com>

Tarjei T. Jensen wrote:
> Terje Mathisen  wrote:
>
>>Except that I've yet to see a reasonable example of code that is
>>actually easier in Cobol.
>
> I belive your understanding of easy may differ from mine.

Probably, since we're (obviously!) coming from different backgrounds.

>
>>I used to believe that Cobol would at least be near-optimal for a
>>process that consisted of reading in 80-col card images, extracting a
>>number of ascii-encoded fields, sort & aggregate the data in various
>>ways, and then print out a sorted result list.
>>
>>However, when I rewrote the 16-page Cobol program in Pascal, the result
>>was 6 pages, i.e. 62.5% less, even though I had re-implement both the
>>input unpacking and parsing, and the sorting procedures.
>
> How long did it take to write each version (including time to get it to

I didn't write the Cobol version, it dated from the time this operation
was handled on a Unisys 1100 series mainframe. It was however written by
a very bright and experienced programmer, so it probably didn't take him
too long.

My version was more or less written from scratch, because it was _much_
easier (for me) to work from the original specification than to
understand what the Cobol program did.

After I had written the Pascal version, the Cobol became significantly
more readable since I knew what it had to do.

Anyway, total time for my version was 2-3 hours, this includes all
debugging etc over the 8-year lifetime of the program.

> work)? Would it be easy for the maintainers to understand your non-Cobol
> program?

If a maintainer (not needed, see above!) came from (say) a C background,
I believe my version would have been easier to follow. In fact, for
anything but a Cobol programmer, the Cobol program would have been less
easy.

> Compact usually means reads badly. Hence it is hard to maintain.

Compact in this case simply meant 'less verbose and/or obfuscated'.

>
>>Yes, there was more blank space in the Cobol version, but not nearly
>>enough to explain the huge difference.
>>
>>I.e. Cobol is simply too verbose, imho.
>
> I have a hard time believing in the concept "too verbose" for software that
> is maintained for decades.

The capability to express an algorithm in a (print or screen) page or
two is _very_ important. As soon as you require significantly more than
this, few programmers are capable of grokking it.

I know that I get into trouble this way. :-(

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: Linus burned by Transmeta JIT morphing optimizations?
Date: Fri, 02 Jan 2004 16:03:10 +0100
Message-ID: <bt417f$iuj$1@osl016lin.hda.hydro.com>

Tarjei T. Jensen wrote:
> "Terje Mathisen" wrote:
>
>>After I had written the Pascal version, the Cobol became significantly
>>more readable since I knew what it had to do.
>>
>>Anyway, total time for my version was 2-3 hours, this includes all
>>debugging etc over the 8-year lifetime of the program.
>
>
> If you can create a working program which consists of around 350 lines of
> code in 2-3 hour then you are an incredible programmer. Most people would
> use more than a day to get such a program to work.

Not incredible at all, there's lots of programmers who regularly do a
lot more, I'd bet Linus is one of them.

I know John Carmack used to pull stunts like writing a sw OpenGL driver
over a weekend, just to get a fallback implementation for when no hw
support was available.

I have (once!) written 1600+ effective lines of very tight asm code,
from scratch, to implement an MsDos print server for locally attached
slave printers:

Event driven double buffered network io, interrupt driven & polled
printer handling etc. Self-relocating/packing code in the init handler
to minimize the runtime footprint.

At the same time I wrote the Pascal sw in my central print server to
handle the other end of the communication, which came to another ~300
lines of code. (I used some previously written network code as the base
layer here.)

Started around 0900 in the morning, everything worked as soon as the
syntax check got rid of a few typos, after less than 6 hours total.

OTOH, it really helps to write a _lot_ of code: When I did the above
hack I'd written ~18 MB Pascal over a few years, along with ~3 MB asm.

This was around 1988 or so.

Two weeks ago I had to write a brand new Pascal MsDos program, it took
me a couple of hours just to lookup and verify the lowlevel bios/dos
interface specs that I used to remember. :-(

Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: Linus burned by Transmeta JIT morphing optimizations?
Date: Fri, 02 Jan 2004 20:03:47 +0100
Message-ID: <bt4fak$r8l$1@osl016lin.hda.hydro.com>

Bob Summers wrote:
> On Fri, 02 Jan 2004 09:20:23 +0100, Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
>
>
>>Tarjei T. Jensen wrote:
>>
>>>Seems reasonable to me. Except that you will find this everywhere: People
>>>will insist on doing things in C/C++ even if it would be a lot easier to do
>>>it in Cobol.
>>
>>Except that I've yet to see a reasonable example of code that is
>>actually easier in Cobol.
>>
>
> <snip>
>
>>Terje
>>--
>>- <Terje.Mathisen@hda.hydro.com>
>>"almost all programming can be viewed as an exercise in caching"
>>
>
>
> How about transforming between 2 record layouts? Where the transform
> includes rearrangement, width changes, and converting some fields
> from binary to BCD, BCD to ASCII and vice versa?
>
> In COBOL, you can define the two layouts and then the conversion is
> just a single "MOVE CORRESPONDING OLD TO NEW." statement.

Writing the same in perl would seem like an obvious choice, and the
resulting program would consist of just a couple of lines inside a loop,
something like this:

while (<INFILE>) {
   chomp;
   ($foo, $bar, ...) = unpack(..);
   printf(OUTFILE "%s\n", pack(...));
}

To keep it even more flexible, you'd do the unpack operation into an
array instead of named fields, and then use array element lists as input
for the pack operation.

The Cobol format specifications would be more readable than the
pack/unpack strings, but they would also require a _lot_ more space.

> I used to work with a database that used that technique to reorganize
> tables.  It occasionally stumbled over a mis-specified hardware operation
> involving the sign of a BCD field.

See? Perl would have been better! :-)

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: Linus burned by Transmeta JIT morphing optimizations?
Date: Sat, 03 Jan 2004 21:01:46 +0100
Message-ID: <bt773b$966$1@osl016lin.hda.hydro.com>

Stephen Fuld wrote:

> "Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
>>To keep it even more flexible, you'd do the unpack operation into an
>>array instead of named fields, and then use array element lists as input
>>for the pack operation.
>
> We have had this discussion before, and IIRC no other language (except ADA,
> which adopted the feature) gives you the flexibility of formatting output
> that COBOL does.  Does PERL support things like automatically putting
> negative numbers in parentheses (accounting style), adding separator
> characters every three colums of a numberic field, or the other things that
> PICTURE clauses support?

Some of these might require a tiny helper function, but I wouldn't bet
against a good perl programmer being able to do it all. :-)

OTOH, at that point the code would probably be a shoo-in for an
obfuscated perl contest. :-)

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: Linus burned by Transmeta JIT morphing optimizations?
Date: Wed, 07 Jan 2004 22:28:24 +0100
Message-ID: <bthtlo$bsg$1@osl016lin.hda.hydro.com>

Stephen Fuld wrote:

> "Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
> news:btgfdd$f6b$1@osl016lin.hda.hydro.com...
>
>>Stephen Fuld wrote:
>>
>>>Let me repeat what I said in another related post.  You can do almost
>>>anything in almost any language.  The real question is the ease of
>>>doing so. Terje talked about not finding any task where COBOL was a
>>>easier (though he used lines of code as synonymous with ease -
>>>something that is not always true, as the APL examples show).  I
>>>maintain, and still do, that formatting output in complex ways is
>>>easier in COBOL than in most other languages. If
>
>>As I wrote in my original post: I also believed this until I wrote my
>>Pascal program and realized that it was 60%+ shorter than the Cobol,
>>even though the actual task to be handled was tailormade for Cobol, with
>>both input and output formats designed by a Cobol programmer.
>
>
> Yes, but you didn't make clear in your original post whether the output was
> using any of the "complex" formatting capabilities of the picture clause, or
> only the things nativly available in Pascal.  From your description, I
> assumed the latter i.e. strings and simple numeric formatting without
> floating currency indicators, three digit separation characters or other
> than minus sign handling of negative values.  If I surmised wrong, I
> apologize.

No problem!

The application did contain and use one very particular Cobol'ism:

A three-digit field, repeated six times, used to hold values from 0 to
100. When the range was extended to 0-1000, the top value would overflow
the field and print as '***'.

This was OK because the input parsing recognized this and knew that it
meant '1000'.

> Also, let me repeat that concision of source representation is not
> necessrily the best representation of ease of development.  I think COBOL
> goes overboard in its requirement for textual strings for documentation
> purposes (division headers, etc.), but at least they are "boilerplate" and
> easy to generate automatically.

The logic was a little bit too complicated to map exactly to Cobol:

Sørlandsgaloppen is 30+ year old orienteering competition held in
sourthern Norway during the summer. It consists of 6 events, with the 4
best races for each competitor used as the basis for the final result
list in each class.

To this we added the 'Family Cup', to select the best family in the event:

For each family, consisting of 3+ members, select the four best races
for each family member, sum these, and then sum the three best results,
with the caveat that at least two generations must be represented, i.e.
with three kids beating dad (or grandmother), dad still had to be
included in the family sum.

Sort the final list into family order, and print the results, with each
family listed with the three vaid members first, followed by any others.

For each family member show the results that was used and the sum.

Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

From: henry@spsystems.net (Henry Spencer)
Newsgroups: comp.compilers
Subject: Re: Languages that are hard to parse
Date: 21 May 2005 00:01:25 -0400
Message-ID: <05-05-192@comp.compilers>
Keywords: parse, Cobol

Our moderator writes:
>[...The reason that PL/I doesn't have
>reserved words is that COBOL has a huge list, so that programmers either
>need to keep a chart of them on the office wall to consult every time they
>invent a new name, or be sure every name includes a hyphen or digit to
>be sure it doesn't collide with one. -John]

Actually, it's worse than that.  The usual approach is to keep a chart on
the wall of the *keywords* that have hyphens in them -- there are some --
and always put at least one hyphen in your names.  The hyphenated-keywords
chart is a lot more manageable than the full keywords chart.

(In my last undergrad year, by accident I had a rather light schedule in
one term, so I threw in the COBOL class.  The language was as disgusting
as I expected, but some of the coverage of practical aspects of business
data processing was quite educational.  For example, on the first
assignment, the prof told us that we would be graded on how our code
performed on *his* test data, warned us that it was full of errors and
inconsistencies, and said that we would be penalized heavily for every
data problem that our code failed to detect and report.  I can think of
some compiler writers who should have taken that course...)
--
"Think outside the box -- the box isn't our friend."    |   Henry Spencer
                                -- George Herbert       | henry@spsystems.net

Newsgroups: alt.folklore.computers,comp.arch
Subject: Re: Architectural Diversity
From: Morten Reistad <first@last.name>
Message-ID: <oiq7rg.2kj2.ln@eden.reistad.name>
Date: Sat, 4 Apr 2009 16:24:24 +0200

In article <gr7j67424r6@news5.newsguy.com>, jmfbahciv  <jmfbahciv@aol> wrote:
>CBFalconer wrote:
>> jmfbahciv wrote:
>>> CBFalconer wrote:
>>>> nmm1@cam.ac.uk wrote:
>>>>
>> ... snip ...
>>>>> And, no, you don't have to write COBOL, but many people did.
>>>> Bwauugh.  I can still remember being forced to use Cobol.
>>> COBOL was wonderful if used in the spirit it was designed.
>>
>> It was designed to be understandable by idiots who could barely
>> read their own name.
>>
>Which you apparently are one.  You should listen to an expert
>COBOL coder some day.  Charlie could tell you some really nice
>tales about tax laws and writing the code to reflect the latest
>politicians' tweaking.  You do NOT want to have to that shit
>in machine language.

There is a half-joke that Swedish tax legislation is written
in Cobol. In a sense, it is true. They publish cobol source code
as a reference as the tax authorities' interpretation of the
current legislation. Since tax law is so complex, and important
points are based on interpretation the cobol has become more
authoritative than the legal text plus the two feet thick set
of court rulings on the matter.

MP's have even been known to consult the COBOL while proposing
tax changes. Tax lawyers often do so.

-- mrr