Brandon S. Allbery wrote:

 > Languages evolve too; Haskell has several antecedents suitable to
 > bootstrapping it, admittedly with varying levels of pain:  LML,
 > Miranda, if you really wanted to you could do it in Scheme or SML
 > (and even Prolog, but keep the Excedrin bottle handy).

 > And as already noted, Hugs is written in C.  Again, headache-inducing,
 > but remember that any Turing-equivalent language can be used to
 > implement any other if you're willing to do the work.  Expressiveness
 > certainly makes it easier, but nothing (other than sanity...) stops
 > you from writing a Haskell compiler in, say, COBOL.


Brent Yorgey wrote:

 > *I* would stop you.  Friends don't let friends write in COBOL.


That last made me physically laugh out loud!

Post a reply to this message

Orchid XP v7 nous apporta ses lumieres en ce 2007/11/11 17:06:
> Brandon S. Allbery wrote:
> 

> Brent Yorgey wrote:
> 
>  > *I* would stop you.  Friends don't let friends write in COBOL.
> 
> 
> That last made me physically laugh out loud!

COBOL, maybe the only computer language where the internal representation for 
numbers is a formated string!
6 May 1960 needed all the space for the longest month name.
06/05/1960 needed 10 bytes to store, but 06/05/60 needed "only" 8: enter the Y2K 
bug...
$000,000,730.75 needed 15 bytes.
It would have been so much simpler to store all numbers and dates as binary, 
with input/output formating filters...
The peoples who created that must have been crazy! At the time, RAM and storage 
where at a premium, and you waste precious memory to store EVERYTHING as 
strings... Not to mention that doing arithmetics on strings is prety slow.

The problem comes from the fact that the developing team was headed by a team of 
administrators, acountants and actuaries, not programers nor anybody with any 
computer knowlege.

-- 
Alain
-------------------------------------------------

Did you know that Al Capone's business card said he was a used furniture dealer.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> It would have been so much simpler to store all numbers and dates as binary, 
> with input/output formating filters...
> The peoples who created that must have been crazy! At the time, RAM and storage 
> where at a premium, and you waste precious memory to store EVERYTHING as 
> strings... Not to mention that doing arithmetics on strings is prety slow.

  You don't understand. They were actually visionaries. Ahead of their time.
They correctly envisioned the current trend in programming, where memory
usage and speed are a non-issue. Why make a program fast when computers
are getting faster?

-- 
                                                          - Warp

Post a reply to this message

Alain wrote:
> COBOL, maybe the only computer language where the internal 
> representation for numbers is a formated string!

Well, only if you told it to. You had binary numbers, bcd numbers, 
packed bcd numbers, and "display" numbers, which is what you're talking 
about.

Actually, the first mainframe I used had an optional "scientific unit" 
(aka "floating point processor") and an optional "business unit" (aka 
string-processing processor). The latter had instructions like block 
move, BCD math, and (get this) an instruction that took a packed BCD 
number pointed to by one register and a COBOL display formatting string 
pointed to by the other register and formatted the number into the space 
pointed to by a third register, all in one instruction, with floating $, 
leading zero suppression, putting () around negative values, and everything.

> It would have been so much simpler to store all numbers and dates as 
> binary, with input/output formating filters...

Usually that's what happened. Where people did calculations with the 
numbers, they used COMP or DECIMAL numbers. Where they printed them, 
they used DISPLAY numbers.

 > The peoples who created that must have been crazy! At the time, RAM and
> storage where at a premium, and you waste precious memory to store 
> EVERYTHING as strings... Not to mention that doing arithmetics on 
> strings is prety slow.

You never actually programmed anything in COBOL, did you?
-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Warp escribió:
> Alain <ele### [at] netscapenet> wrote:
>> It would have been so much simpler to store all numbers and dates as binary, 
>> with input/output formating filters...
>> The peoples who created that must have been crazy! At the time, RAM and storage 
>> where at a premium, and you waste precious memory to store EVERYTHING as 
>> strings... Not to mention that doing arithmetics on strings is prety slow.
> 
>   You don't understand. They were actually visionaries. Ahead of their time.
> They correctly envisioned the current trend in programming, where memory
> usage and speed are a non-issue. Why make a program fast when computers
> are getting faster?
> 

Ugh... lol

Post a reply to this message

Darren New wrote:
> Well, only if you told it to. You had binary numbers, bcd numbers, 
> packed bcd numbers, and "display" numbers, which is what you're talking 
> about.

http://www.cs.niu.edu/~abyrnes/csci465/notes/465num.htm
For example.


-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New nous apporta ses lumieres en ce 2007/11/12 23:45:
> Alain wrote:
>> COBOL, maybe the only computer language where the internal 
>> representation for numbers is a formated string!
> 
> Well, only if you told it to. You had binary numbers, bcd numbers, 
> packed bcd numbers, and "display" numbers, which is what you're talking 
> about.
> 
> Actually, the first mainframe I used had an optional "scientific unit" 
> (aka "floating point processor") and an optional "business unit" (aka 
> string-processing processor). The latter had instructions like block 
> move, BCD math, and (get this) an instruction that took a packed BCD 
> number pointed to by one register and a COBOL display formatting string 
> pointed to by the other register and formatted the number into the space 
> pointed to by a third register, all in one instruction, with floating $, 
> leading zero suppression, putting () around negative values, and 
> everything.
> 
>> It would have been so much simpler to store all numbers and dates as 
>> binary, with input/output formating filters...
> 
> Usually that's what happened. Where people did calculations with the 
> numbers, they used COMP or DECIMAL numbers. Where they printed them, 
> they used DISPLAY numbers.
> 
>  > The peoples who created that must have been crazy! At the time, RAM and
>> storage where at a premium, and you waste precious memory to store 
>> EVERYTHING as strings... Not to mention that doing arithmetics on 
>> strings is prety slow.
> 
> You never actually programmed anything in COBOL, did you?
I did! I folowed some COBOL course, well enough to learn to HATE that thing.

-- 
Alain
-------------------------------------------------
Depression is merely anger without enthusiasm.

Post a reply to this message

Darren New wrote:
> Darren New wrote:
>> Well, only if you told it to. You had binary numbers, bcd numbers, 
>> packed bcd numbers, and "display" numbers, which is what you're 
>> talking about.
> 
> http://www.cs.niu.edu/~abyrnes/csci465/notes/465num.htm
> For example.
> 
> 

Yep.  IIRC, the S/36 defaulted to DISPLAY, and the S/38 defaulted to 
COMP--the only difference was whether or not you *had* to use the USAGE 
clause.  I also seem to recall that the S/36 (but not, I think, the 
S/38) also had a PIC 1 type for getting at the individual bits...

OK, I'm boring myself now.  ;)

--Sherry Shaw


-- 
#macro T(E,N)sphere{x,.4rotate z*E*60translate y*N pigment{wrinkles scale
.3}finish{ambient 1}}#end#local I=0;#while(I<5)T(I,1)T(1-I,-1)#local I=I+
1;#end camera{location-5*z}plane{z,37 pigment{granite color_map{[.7rgb 0]
[1rgb 1]}}finish{ambient 2}}//                                   TenMoons

Post a reply to this message