Tar -> BSD -> Unix wars -> SCO vs IBM -> Trade secret -> Trade dress -> 
Honeywell -> Burroughs Corporation

-> Stack machine -> Accumulator machine -> Register machine -> Counter 
machine -> Pointer machine -> Random access machine -> Random access 
stored program machine

-> FORTRAN
    -> Arithmetic IF
    -> Front panel
    -> Modula-2 -> Oberon -> F

-> ALGOL
    -> P-code machine -> UCSD Pascal -> Ada
    -> Lisp machine
    -> Whetstone

-> COBOL

Like, TOTALLY RETRO, man!

I'm really loving this quote:

"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (Dijkstra)

Seeing the 8-line Hello World implementation, I'm tending to agree...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Tar -> BSD -> Unix wars -> SCO vs IBM -> Trade secret -> Trade dress ->
> Honeywell -> Burroughs Corporation
>
> -> Stack machine -> Accumulator machine -> Register machine -> Counter
> machine -> Pointer machine -> Random access machine -> Random access
> stored program machine
>
> -> FORTRAN
>     -> Arithmetic IF
>     -> Front panel
>     -> Modula-2 -> Oberon -> F
>
> -> ALGOL
>     -> P-code machine -> UCSD Pascal -> Ada
>     -> Lisp machine
>     -> Whetstone
>
> -> COBOL
>
> Like, TOTALLY RETRO, man!
>
> I'm really loving this quote:
>
> "The use of COBOL cripples the mind; its teaching should, therefore, be
> regarded as a criminal offense." (Dijkstra)
>
> Seeing the 8-line Hello World implementation, I'm tending to agree...
>
> --
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*

There are days that I tend to agree with that too.  Though I am not a COBOL
programmer, I am tech support for a medium size mainframe operating system, and
have to deal with a programming staff of COBOL programmers.  When a select few
of them have problems, and its always the same select few, I have to help them
debug their programs.  Though we have some very sharp people working here, there
are some I don't know how they find their way to work every morning.

As an aside, have you ever looked at PL/I.  My second programming job was at a
PL/I shop.  It has some nice features, but also some strange idiosyncrasies.
As the wikipedia entry on PL/I points out, there are no reserved keywords in
the language, thus you can have variable names like IF, THEN or ELSE etc. Sot
the following statement is perfectly valid:

IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;

This can lead to some very difficult debugging.

Isaac

Post a reply to this message

>> "The use of COBOL cripples the mind; its teaching should, therefore, be
>> regarded as a criminal offense." (Dijkstra)
>>
>> Seeing the 8-line Hello World implementation, I'm tending to agree...
> 
> There are days that I tend to agree with that too.  Though I am not a COBOL
> programmer, I am tech support for a medium size mainframe operating system, and
> have to deal with a programming staff of COBOL programmers.  When a select few
> of them have problems, and its always the same select few, I have to help them
> debug their programs.  Though we have some very sharp people working here, there
> are some I don't know how they find their way to work every morning.

I went to uni with a bunch of people who were taught COBOL rather than 
Pascal at college. (Apparently due to the Y2K marketin- uh, concerns.) I 
don't know much about COBOL myself. All I heard is "if you miss out one 
dot, the compiler will report an error message 800 lines later".

(I don't know whether that's true or not, but any programming language 
where beginners might realistically write an 800 line program worries me!)

> So the following statement is perfectly valid:
> 
> IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;
> 
> This can lead to some very difficult debugging.

That's fairly tame compered to the lambda calculus. (Then again... no 
sane human being writes programs using the lambda calculus!)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Clarence1898 wrote:

> 
> IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;
> 

Anyone who writes a program construct like that deserves to be shot ...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> "The use of COBOL cripples the mind; its teaching should, therefore, be
> >> regarded as a criminal offense." (Dijkstra)
> >>
> >> Seeing the 8-line Hello World implementation, I'm tending to agree...
> >
> > There are days that I tend to agree with that too.  Though I am not a COBOL
> > programmer, I am tech support for a medium size mainframe operating system, and
> > have to deal with a programming staff of COBOL programmers.  When a select few
> > of them have problems, and its always the same select few, I have to help them
> > debug their programs.  Though we have some very sharp people working here, there
> > are some I don't know how they find their way to work every morning.
>
> I went to uni with a bunch of people who were taught COBOL rather than
> Pascal at college. (Apparently due to the Y2K marketin- uh, concerns.) I
> don't know much about COBOL myself. All I heard is "if you miss out one
> dot, the compiler will report an error message 800 lines later".
>
> (I don't know whether that's true or not, but any programming language
> where beginners might realistically write an 800 line program worries me!)
>
> > So the following statement is perfectly valid:
> >
> > IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;
> >
> > This can lead to some very difficult debugging.
>
> That's fairly tame compered to the lambda calculus. (Then again... no
> sane human being writes programs using the lambda calculus!)
>
> --
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*

Since I am unfamiliar with lambda calculus, not being taught in the FORTRAN
class I took at college, I looked it up on wikipedia.  After a few paragraphs,
my eyes glazed over and could no longer focus.  At least I now understand where
the lambda function in Python came from.   As far as COBOL is concerned, we
typically assign new programmers to maintaining existing programs, some of
which are over 15000 lines long.  I have heard that programs that size are not
that unusual in the COBOL world.

Isaac

Post a reply to this message

>> IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;
> 
> Anyone who writes a program construct like that deserves to be shot ...

...unless it's for an obfuscated coding competition, in which case they 
probably deserve a medal...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>> IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;

>> That's fairly tame compered to the lambda calculus.

> Since I am unfamiliar with lambda calculus, not being taught in the FORTRAN
> class I took at college, I looked it up on wikipedia.  After a few paragraphs,
> my eyes glazed over and could no longer focus.

What do you mean?

   λn· n (λj· (λx· (λy· y))) (λx· (λy· x))

It means "n == 0". What's so hard about that? ;-)

> At least I now understand where
> the lambda function in Python came from.

Yeah, probably.

> As far as COBOL is concerned, we
> typically assign new programmers to maintaining existing programs, some of
> which are over 15000 lines long.  I have heard that programs that size are not
> that unusual in the COBOL world.

I hope I never have to touch COBOL!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> don't know much about COBOL myself. All I heard is "if you miss out one 
> dot, the compiler will report an error message 800 lines later".

Well, I can tell you that if you spell it "IDNETIFICATION DIVISION" on 
the first line, you'll get 700 error messages on a 300-line program. ;-)

COBOL wasn't bad for its time. It's wordy because everything is line 
oriented, and it was supposed to be easy for non-programmers to read, 
and a 32K machine with 4 meg of disk space and milisecond cycle times 
was a high-end mainframe.

There's no dynamic layout or allocation of memory. operating systems 
weren't nearly as uniform as they are today.

(COBOL has evolved, of course, but I'm talking in the 60's versions.)

> (I don't know whether that's true or not, but any programming language 
> where beginners might realistically write an 800 line program worries me!)

It was, IIRC, some 350 lines to write a program to look through the 
employee file and calculate and print how many days each employee had 
been employed, in descending order. COBOL was pretty darn verbose.

A great deal of that was boilerplate, of course, identifying the 
program, naming the files it used and the layouts of their records, etc 
etc etc. The actual body of the code was probably 100 lines.

-- 
Darren New / San Diego, CA, USA (PST)
  Ever notice how people in a zombie movie never already know how to
  kill zombies? Ask 100 random people in America how to kill someone
  who has reanimated from the dead in a secret viral weapons lab,
  and how many do you think already know you need a head-shot?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> COBOL wasn't bad for its time. It's wordy because everything is line 
> oriented, and it was supposed to be easy for non-programmers to read, 
> and a 32K machine with 4 meg of disk space and milisecond cycle times 
> was a high-end mainframe.

  I always got the impression that COBOL was the "BASIC" of the 70's,
while all real programmers used Fortran. (Heck, even nowadays some old
gurus state that real programmers use Fortran.)

-- 
                                                          - Warp

Post a reply to this message

On Thu, 07 Aug 2008 13:02:33 -0400, Warp wrote:

>   I always got the impression that COBOL was the "BASIC" of the 70's,

Try the 60's. ;-)

Jim

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > don't know much about COBOL myself. All I heard is "if you miss out one
> > dot, the compiler will report an error message 800 lines later".
>
> Well, I can tell you that if you spell it "IDNETIFICATION DIVISION" on
> the first line, you'll get 700 error messages on a 300-line program. ;-)
>
> COBOL wasn't bad for its time. It's wordy because everything is line
> oriented, and it was supposed to be easy for non-programmers to read,
> and a 32K machine with 4 meg of disk space and milisecond cycle times
> was a high-end mainframe.
>
> There's no dynamic layout or allocation of memory. operating systems
> weren't nearly as uniform as they are today.
>
> (COBOL has evolved, of course, but I'm talking in the 60's versions.)
>
> > (I don't know whether that's true or not, but any programming language
> > where beginners might realistically write an 800 line program worries me!)
>
> It was, IIRC, some 350 lines to write a program to look through the
> employee file and calculate and print how many days each employee had
> been employed, in descending order. COBOL was pretty darn verbose.
>
> A great deal of that was boilerplate, of course, identifying the
> program, naming the files it used and the layouts of their records, etc
> etc etc. The actual body of the code was probably 100 lines.
>
> --
> Darren New / San Diego, CA, USA (PST)
>   Ever notice how people in a zombie movie never already know how to
>   kill zombies? Ask 100 random people in America how to kill someone
>   who has reanimated from the dead in a secret viral weapons lab,
>   and how many do you think already know you need a head-shot?

Cobol has evolved quite a bit.  In its latest incarnation it has built in
support for CICS, XML, Websphere, DB2. It can even talk to Java.  That has to
at least double the number of error messages.

Isaac

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Darren New <dne### [at] sanrrcom> wrote:
> > COBOL wasn't bad for its time. It's wordy because everything is line
> > oriented, and it was supposed to be easy for non-programmers to read,
> > and a 32K machine with 4 meg of disk space and milisecond cycle times
> > was a high-end mainframe.
>
>   I always got the impression that COBOL was the "BASIC" of the 70's,
> while all real programmers used Fortran. (Heck, even nowadays some old
> gurus state that real programmers use Fortran.)
>
> --
>                                                           - Warp

COBOL was a little more than BASIC, but it was "THE" business programming
language.  For most large businesses today, it still is the primary programming
language for their mainstream applications (ie. order processing, inventory,
billing, etc.), at least in the USA.  Since I'm not in the scientific or
engineering field, I don't know how much Fortran is still being used.  Most
COBOL programmers looked down their noses at the nerdy little techie Fortran
programmers, while as you said, Fortran programmers never considered COBOL
programmers as real programmers. Since Fortran was my first language, I never
have cared much for COBOL, but unfortunatly I have to deal with it most every
day.

Isaac

Post a reply to this message

Warp wrote:
>   I always got the impression that COBOL was the "BASIC" of the 70's,

Vice versa. BASIC was the COBOL of the 70's. They were both pretty much 
the same programming model, tho. Flat code space, flat data space, 
everything preallocated, etc.

> while all real programmers used Fortran. (Heck, even nowadays some old
> gurus state that real programmers use Fortran.)

Depends what you were programming. People doing databases and business 
math (i.e., decimal, reports, etc) didn't use FORTRAN. People doing 
physics simulations didn't use COBOL.

-- 
Darren New / San Diego, CA, USA (PST)
  Ever notice how people in a zombie movie never already know how to
  kill zombies? Ask 100 random people in America how to kill someone
  who has reanimated from the dead in a secret viral weapons lab,
  and how many do you think already know you need a head-shot?

Post a reply to this message

Clarence1898 wrote:

> Since I am unfamiliar with lambda calculus, not being taught in the FORTRAN
> class I took at college, I looked it up on wikipedia.  After a few paragraphs,
> my eyes glazed over and could no longer focus.

In seriousness now...

A Turing machine (as you may or may not know) is a "computer" simplified 
down to the barest essentials. It turns out, the simpler a machine 
becomes, the harder it becomes to program it.

[Strictly, a *universal* Turing machine is a simplified programmable 
computer, if you want to nitpick.]

Similarly, the Lambda calculus is sort of the simplest possible 
programming language. And again, it turns out the simpler the language 
is, the harder it is to program anything with it!

The Lambda calculus is a programming language with 1 datatype and 1 
operator. And it's Turing-complete. That's a pretty impressive result!

The only datatype is "function", and the only operator is "function 
call". You pass each function an argument (which must be a function, 
since there aren't any other datatypes), and it returns a result (which, 
again, has got to be another function).

It's like binary. Binary isn't "complicated" - actually it's extremely 
simple. The confusing thing is that you need *a lot* of binary digits to 
actually "say" anything. And 0010010101100100110111010111010110 makes 
you go dizzy after a while.

Similarly, the Lambda calculus isn't "complicated", it's just that the 
whole "function takes a function and yields a function" seems a little 
confusing initially.

Many people speak of the "enriched lambda calculus", which is lambda 
calculus with more datatypes and operators so it's not *quite* so insane 
to use. The enriched lambda calculus really is quite simple. For example,

   λx· 3*x + 5

is a lambda function. It does roughly the same thing is

   function NONAME(x)
   {
     return 3*x + 5;
   }

in JavaScript. The difference - obviously - is that lambda functions 
don't have names.

The freaky part about the "pure" lambda calculus is that you use 
functions to represent things that aren't functions. For example, you 
say that any 2-argument function that throws away the first argument and 
returns the second one represents "true", and any 2-argument function 
that throws away the second argument and returns the first represents 
"false".

You can represent numbers as functions, and then write a function that 
takes two of these functions-that-represent-numbers and constructs a 
function that represents the number you get when you add these two 
numbers together.

...which is a really confusing way of waying you can perform 
mathematical addition in the pure lambda calculus. Instead of taking two 
numbers, converting them to binary and putting them through some digital 
circuitry, you take two numbers and convert them to functions, and 
convert the resulting function back into a number. Same deal, just more 
perplexing.



Now if you REALLY WANT TO MAKE YOUR HEAD FRIGGIN HURT... Try the SKI 
combinator calculus.

The lambda calculus says: If you can construct a function with any 
possible shape, then you can represent any kind of data and perform any 
algorithm on that data.

The SKI combinator calculus says: You can construct any shape of 
function from just 3 functions, named "S", "K" and "I".

For example, the "true" function becomes K, and the "false" function 
becomes KI. The "2" function is S(S(KS)K)I, and so forth.

...in other words, you write entire programs out of lots of S's, K's, 
I's and brackets!



IF YOU WANT TO TOTALLY BREAK YOUR MIND, you may try the Iota calculus.

SKI calculus says: You can make any function from just S, K and I.

Iota calculus says: You can make S, K and I from the X function.

In other words, the Iota calculus means you write whole programs that 
just consist of X's and brackets. That's all! Basically, the shape of 
the parse tree is the program! o_O

Somewhere I had a printout for the Iota calculus program to compute 2+2. 
Suffice it to say, it's 4 lines long, and looks something like

   X(X(XX)X(X)X(XXX)X(X)X(X(XX)))X(X(X))))X(X)...

So when I said that the lambda calculus is the "simplest" programming 
language, actually I lied. The Iota calculus is. If you write

   X(XX)

as

   *X*XX

instead (the "*" being a prefix application operator), then every Iota 
program becomes something like

  ****X*X**XX*X**X*XXX*X*XXX...

and you have a programming language that contains only two symbols - "X" 
and "*" - that is Turing-complete, and hence can express any possible 
algorithm.

The only real way to top that would be to convert the symbols to 1s and 
0s, encode the whole program as a binary integer, and then convert it to 
a unary integer. That way, your program would be a line of (several 
billion) 1s. But even I'm not *that* crazy!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:

> Iota calculus says: You can make S, K and I from the X function.
> 
> In other words, the Iota calculus means you write whole programs that 
> just consist of X's and brackets. That's all! Basically, the shape of 
> the parse tree is the program! o_O
> 
> Somewhere I had a printout for the Iota calculus program to compute 2+2. 
> Suffice it to say, it's 4 lines long, and looks something like
> 
>   X(X(XX)X(X)X(XXX)X(X)X(X(XX)))X(X(X))))X(X)...

I think this is the invention of a sick mind. My brain hurts.

Why would someone want to do this? (other than the obvious self-abuse?)

Post a reply to this message

>> In other words, the Iota calculus means you write whole programs that 
>> just consist of X's and brackets. That's all! Basically, the shape of 
>> the parse tree is the program! o_O

>>   X(X(XX)X(X)X(XXX)X(X)X(X(XX)))X(X(X))))X(X)...

> I think this is the invention of a sick mind. My brain hurts.
> 
> Why would someone want to do this? (other than the obvious self-abuse?)

To prove it can be done.

It's an interesting theoretical question: "How simple can a programming 
language be before it stops working?"

The answer - apparently - is "extremely simple".

As I said, as the language gets simpler, all the programs become more 
complex. Until, eventually, you arrive at the Iota calculus, the 
simplest programming language that can exist. And its programs are 
FREAKIN CRAZY!

I just wish there was some way to "run" these programs to prove that 
they do actually work, and it's not just line noise. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> [Strictly, a *universal* Turing machine is a simplified programmable 
> computer, if you want to nitpick.]

More completely, a Turing machine is a (very simple) machine with the 
program in ROM. A universal Turing machine is a Turing machine whose 
program (in ROM) is an interpreter for a program stored in the RAM. 
That's the sense in which it's "programmable".

The benefit is that if you can prove something is true of the universal 
turing machine, you can prove it's true of all turing machines, because 
the universal turing machine can be programmed to be like any other 
turing machine.

Mike Raiford wrote:
 > Why would someone want to do this? (other than the obvious self-abuse?)

Because it's math. If you can prove that X, with enough work, is 
equivalent to any Y, and then you prove some property of X holds, then 
you can prove that property holds for every Y.

If you can prove that (for example) you can't solve a problem with Iota 
calculus, and you can prove that Iota calculus can solve any problem a 
normal desktop computer can solve, then you can prove your desktop 
computer can't solve it.

By being very very simple, you make it easy to prove things about it 
that you'd never really want to *do* in actual real life.

-- 
Darren New / San Diego, CA, USA (PST)
  Ever notice how people in a zombie movie never already know how to
  kill zombies? Ask 100 random people in America how to kill someone
  who has reanimated from the dead in a secret viral weapons lab,
  and how many do you think already know you need a head-shot?

Post a reply to this message

Invisible wrote:
> is a lambda function. It does roughly the same thing is
> 
>    function NONAME(x)
>    {
>      return 3*x + 5;
>    }
> 
> in JavaScript. The difference - obviously - is that lambda functions
> don't have names.

JavaScript functions don't need names.

var value = (function (x) {
    return 3*x + 5;
})(42);

That actually works.

Post a reply to this message

Nicolas Alvarez wrote:

> JavaScript functions don't need names.
> 
> var value = (function (x) {
>     return 3*x + 5;
> })(42);
> 
> That actually works.

Ooo... that's interesting.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
>>> In other words, the Iota calculus means you write whole programs that 
>>> just consist of X's and brackets. That's all! Basically, the shape of 
>>> the parse tree is the program! o_O
> 
>>>   X(X(XX)X(X)X(XXX)X(X)X(X(XX)))X(X(X))))X(X)...
> 
>> I think this is the invention of a sick mind. My brain hurts.
>>
>> Why would someone want to do this? (other than the obvious self-abuse?)
> 
> To prove it can be done.
> 
> It's an interesting theoretical question: "How simple can a programming 
> language be before it stops working?"
> 
> The answer - apparently - is "extremely simple".

Oh, so I was right. Self abuse ;)

I'll grant you, it is an interesting theoretical question ... But how 
exactly do you get a result from the above quoted statement, and what 
would that result look like?

Post a reply to this message

Mike Raiford wrote:

> I'll grant you, it is an interesting theoretical question ... But how 
> exactly do you get a result from the above quoted statement, and what 
> would that result look like?

That's exactly it. It's an interesting theoretical result. It has no 
"practical" value of any kind.



You *could* write a computer program that "runs" Iota calculus programs. 
(In fact, I did this a while back. Maybe I'll resurrect it just for fun. 
Or... self-harming?)

Interpretting the answer is tricky though. The Iota calculus is an 
untyped language, so if you don't know what type of value a program is 
supposed to produce, there's no way to know how to decode it. It's a bit 
like the way the bit sequence "1111" might mean "15" or "-1", depending 
on whether it's supposed to be signed or unsigned binary.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Clarence1898 wrote:
>
> > Since I am unfamiliar with lambda calculus, not being taught in the FORTRAN
> > class I took at college, I looked it up on wikipedia.  After a few paragraphs,
> > my eyes glazed over and could no longer focus.
>
> In seriousness now...
>
> A Turing machine (as you may or may not know) is a "computer" simplified
> down to the barest essentials. It turns out, the simpler a machine
> becomes, the harder it becomes to program it.
>
> [Strictly, a *universal* Turing machine is a simplified programmable
> computer, if you want to nitpick.]
>
> Similarly, the Lambda calculus is sort of the simplest possible
> programming language. And again, it turns out the simpler the language
> is, the harder it is to program anything with it!
>

Last night after work, I took another look at the lambda calculus article.  I
think I get the gist of it.  It is simple enough to be practically impossible
to write any useful program with it.

> Now if you REALLY WANT TO MAKE YOUR HEAD FRIGGIN HURT... Try the SKI
> combinator calculus.

I didn't even try to look this on up.

> IF YOU WANT TO TOTALLY BREAK YOUR MIND, you may try the Iota calculus.

Or this one.

The lambda calculus was somewhat interesting, but outside of some mathematicians
and computer scientists, I don't know how anyone could ever use it.  Now if you
could think of a way I could use it to get a few programmers off my back, I'll
take another look at it.

Isaac

Post a reply to this message

>> Similarly, the Lambda calculus is sort of the simplest possible
>> programming language. And again, it turns out the simpler the language
>> is, the harder it is to program anything with it!
> 
> Last night after work, I took another look at the lambda calculus article.  I
> think I get the gist of it.  It is simple enough to be practically impossible
> to write any useful program with it.

Affirmative. Even "2+2" is quite large in the Lambda calculus!

>> Now if you REALLY WANT TO MAKE YOUR HEAD FRIGGIN HURT... Try the SKI
>> combinator calculus.
> 
> I didn't even try to look this on up.
> 
>> IF YOU WANT TO TOTALLY BREAK YOUR MIND, you may try the Iota calculus.
> 
> Or this one.

I really can't say I blame you. ;-)

> The lambda calculus was somewhat interesting, but outside of some mathematicians
> and computer scientists, I don't know how anyone could ever use it.

Indeed yes. Nobody actually uses the lambda calculus itself. That would 
be insane. It's a theoretical rather than practical language. It's 
interesting because of what it tells us about the theory of computers 
and computation - and that is all.



However... Theoretically, you could claim that Haskell is the lambda 
calculus, with some new features added that make it easier to read and 
write, and more efficient to execute on a computer.

You'll also find that many (most?) compilers for functional languages 
take the code you wrote and translate it into some 
extended-lambda-language of some kind, perform a few dozen optimisation 
passes, and then finally translate that to some sort of graph reduction 
engine. (At least, for lazy languages it's usually graph reduction - for 
strict language it'll probably be something more imperative.)

Even here, the lambda calculus is interesting: Without getting into long 
debates about complicated features like type checking or dynamic binding 
or scope rules, the lambda calculus lets us talk about possible 
execution orders - strict vs lazy and so on - and investigate their 
consequences. Investigating such design choices in a hyper-simple 
langauge makes everything much easier.

So the lambda calculus is where we explore the theories that our real 
tools are built on.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Even "2+2" is quite large in the Lambda calculus!

  Real programmers know that "2 2 +" is the only true notation.

  No need for complicated operator precedence rules nor any pesky
parentheses. For example "(1 + 2) * (3 + 4)" can be written as
"1 2 + 3 4 + *" and it's completely unambiguous.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Real programmers know that "2 2 +" is the only true notation.
> 
>   No need for complicated operator precedence rules nor any pesky
> parentheses. For example "(1 + 2) * (3 + 4)" can be written as
> "1 2 + 3 4 + *" and it's completely unambiguous.

Up to being able to distinguish "1 2" from "12". ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Even "2+2" is quite large in the Lambda calculus!
> 
>   Real programmers know that "2 2 +" is the only true notation.
> 
>   No need for complicated operator precedence rules nor any pesky
> parentheses. For example "(1 + 2) * (3 + 4)" can be written as
> "1 2 + 3 4 + *" and it's completely unambiguous.
> 

Mmm, RPN... My dad has an HP calculator that uses that. Once you get 
used to it it's quite nice.

Post a reply to this message

Mike Raiford wrote:

> Mmm, RPN... My dad has an HP calculator that uses that. Once you get 
> used to it it's quite nice.

It's a simple and clean solution to the age-old problem of trying to do 
a calculation on a pocket calculator and needing to write down values 
and later type them back in again. Just use a stack, silly!

(I've never tried this extensively, but I would suggest that it probably 
requires a little forethought before you start the calculation...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> (I've never tried this extensively, but I would suggest that it probably 
> requires a little forethought before you start the calculation...)

Not too much. If you have the equation written down, the rule is that 
you type in the numbers in the order they appear, and you type in the 
operators as soon as you've gotten all the arguments for that operator.

Now, if it's not written down, it can take some head-twisting, but IME 
not any more than using infix. Certainly easier than using infix without 
parentheses built into the calcualtor.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

>> (I've never tried this extensively, but I would suggest that it 
>> probably requires a little forethought before you start the 
>> calculation...)
> 
> Not too much. If you have the equation written down...

I was thinking more if you're just casually throwing numbers around, and 
you suddenly realise that you'd like to use the number on the top of the 
stack as the *denominator*, not the numerator, or something like that. 
If you know before hand exactly what computation you want to perform 
then yes it's quite easy.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> you suddenly realise that you'd like to use the number on the top of the 
> stack as the *denominator*, not the numerator, or something like that. 

I think there's a button for *that* case, actually.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

>> you suddenly realise that you'd like to use the number on the top of 
>> the stack as the *denominator*, not the numerator, or something like 
>> that. 
> 
> I think there's a button for *that* case, actually.

Division and subtraction are the obvious ones. (Oh, and exponent if 
there's a button for that.)

Thinking about it, a button to swap the top two operands ought to fix 
most problems you might have.

I also anticipate that being able to somehow "inspect" the stack might 
come in handy if you can't remember what you put on there already...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Thinking about it, a button to swap the top two operands ought to fix 
> most problems you might have.

That's kind of what I was referring to, yes.

> I also anticipate that being able to somehow "inspect" the stack might 
> come in handy if you can't remember what you put on there already...

Yes. I expect such a thing might have been around on some of the 
calculators I remember seeing.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Fri, 15 Aug 2008 08:58:35 +0100, Invisible wrote:
> Nicolas Alvarez wrote:
>
>> JavaScript functions don't need names.
>> 
>> var value = (function (x) {
>>     return 3*x + 5;
>> })(42);
>> 
>> That actually works.
>
> Ooo... that's interesting.

Python:

  value = (lambda(x): 3*x+5)(42)

Lua:

  value = (function(x) return 3*x+5 end)(42)

Ruby (1):

  def test
    yield 42
  end
  value = test { |x| 3*x+5 }

Ruby (2):

  value = lambda { |x| 3*x+5 } .call(42)

C++0x:
  
  int main()
  {
    int value = <>(int x) (3*x+5) (42);
  }

  (I would have tested this, but the build instructions
   at http://parasol.tamu.edu/groups/pttlgroup/lambda/
   don't work for me, tried to computers...)

i386 assembly (ok, this is cheating):
  mov eax, 42
  call over
  lea eax, [eax*2+eax+5]
  ret
over:
  pop eax
  call eax
  mov [value], eax

-- 
Joel Yliluoma - http://iki.fi/bisqwit/

Post a reply to this message

Joel Yliluoma wrote:

> Python:
> 
>   value = (lambda(x): 3*x+5)(42)
> 
> Lua:
> 
>   value = (function(x) return 3*x+5 end)(42)
> 
> Ruby (1):
> 
>   def test
>     yield 42
>   end
>   value = test { |x| 3*x+5 }
> 
> Ruby (2):
> 
>   value = lambda { |x| 3*x+5 } .call(42)
> 
> C++0x:
>   
>   int main()
>   {
>     int value = <>(int x) (3*x+5) (42);
>   }
> 
> i386 assembly (ok, this is cheating):
>   mov eax, 42
>   call over
>   lea eax, [eax*2+eax+5]
>   ret
> over:
>   pop eax
>   call eax
>   mov [value], eax

Haskell [is that cheating??]

   value = (\x -> 3*x + 5) 42

Lambda calculus:

   \i ->
   (\n -> \m -> \f -> \x -> n f (m f x))
   (
     (\n -> \m -> \f -> \x -> n (m f) x)
     (\f -> \x -> f (f (f x)))
     i
   )
   (\f -> \x -> f (f (f (f (f x)))))

[I can't be bothered to write "42" in the lambda calculus. Suffice it to 
say it contains 42 copies of the letter "f".]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Joel Yliluoma wrote:
> C++0x:
>   
>   int main()
>   {
>     int value = <>(int x) (3*x+5) (42);
>   }

I thought it was [], not <>.

But I don't have any C++0x compiler...

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Joel Yliluoma wrote:
> > C++0x:
> >   
> >   int main()
> >   {
> >     int value = <>(int x) (3*x+5) (42);
> >   }

> I thought it was [], not <>.

  I suppose the exact syntax has still not been written to stone. The
current wikipedia article on the subject uses your syntax:

http://en.wikipedia.org/wiki/C%2B%2B0x#Lambda_functions_and_expressions

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I suppose the exact syntax has still not been written to stone. The
> current wikipedia article on the subject uses your syntax:
> 
> http://en.wikipedia.org/wiki/C%2B%2B0x#Lambda_functions_and_expressions
> 

It's not a feature I'm likely to use much, anyway. I'm more interested in
the range-based for loop (yes, I know it's pure syntax sugar), and template
concepts.

Currently:
for (std::vector<int>::iterator i = myList.begin(); i != myList.end(); ++i)

With the new type determination feature:
for (auto i = myList.begin(); i != myList.end(); ++i)

With the range-based for loop:
for (int &x : myList)

<3

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> It's not a feature I'm likely to use much, anyway.

  Lambda function will make it much easier to use STL algorithms which take
a user-defined functor (such as for example for_each(), find_if(),
transform(), etc.) which will make them much more desirable. They will
also make it easier to quickly create data containers with more exotic
comparison functions than less_than or greater_than.

> I'm more interested in
> the range-based for loop (yes, I know it's pure syntax sugar), and template
> concepts.

  Personally I'm drooling over rvalue references, which will allow for much
more efficient move semantics.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Personally I'm drooling over rvalue references, which will allow for much
> more efficient move semantics.

My understanding is that informally, this lets you match a template or 
overload where one or more of the arguments is, essentially, guaranteed 
to not be aliased.  Is this a reasonable summary?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Tue, 02 Sep 2008 21:13:43 +0200, Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
>>   Personally I'm drooling over rvalue references, which will allow for  
>> much more efficient move semantics.
>
> My understanding is that informally, this lets you match a template or  
> overload where one or more of the arguments is, essentially, guaranteed  
> to not be aliased.  Is this a reasonable summary?


Not really, at least not the way I understand it.

R-value references are basically just a way to bind temporaries to  
non-const references. Specifically, they facilitate move constructors  
which are much like copy constructors except that they may destructively  
alter the source of the "copy".


-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> Specifically, they facilitate move constructors 
> which are much like copy constructors except that they may destructively 
> alter the source of the "copy".

One of my problems with learning C++ is the number of places where, 
instead of saying "This is what this feature does", people say "this is 
how you use this feature."  (Not unlike Perl, where there are all these 
defaults that nobody uses because they're too complex to remember. :-)

What is a "move constructor"? When would you be "moving" some value? If 
you destructively alter something with aliases, aren't you in trouble? 
Isn't that what the whole "ownership" concept is supposed to prevent?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Tue, 02 Sep 2008 22:22:46 +0200, Darren New <dne### [at] sanrrcom> wrote:
> One of my problems with learning C++ is the number of places where,  
> instead of saying "This is what this feature does", people say "this is  
> how you use this feature."

Perhaps because the rules are sometimes so complex that few really know  
exactly what a particular feature does under all conditions. It is much  
easier to say "if you do it like this, it works" than to list all the many  
cases where it does something slightly or vastly different.



> What is a "move constructor"? When would you be "moving" some value?

"Moving" a value is useful when you know that the source value will be  
discarded anyway right after the copy is performed, e.g. if it is the  
return value of a function. Many objects that are expensive to copy can be  
"moved" much more efficiently.

Also, some types of objects are inherently non-copyable -- because they  
hold/represent some unique resource -- but they could still be "movable".



> If you destructively alter something with aliases, aren't you in trouble?

Hence the need to distinguish temporaries from regular const objects. Note  
that non-temporaries can also be bound to r-value references, but not  
implicitly.



> Isn't that what the whole "ownership" concept is supposed to prevent?

A move constructor would transfer ownership of whatever the source object  
is holding. Look to 'std::auto_ptr' for something resembling an example.




A more verbose summary can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html


-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> On Tue, 02 Sep 2008 22:22:46 +0200, Darren New <dne### [at] sanrrcom> wrote:
>> One of my problems with learning C++ is the number of places where, 
>> instead of saying "This is what this feature does", people say "this 
>> is how you use this feature."
> 
> Perhaps because the rules are sometimes so complex that few really know 
> exactly what a particular feature does under all conditions. It is much 
> easier to say "if you do it like this, it works" than to list all the 
> many cases where it does something slightly or vastly different.

Yeah, basically.  "We don't actually know what the semantics are. We 
just all know the idioms for using the feature."

>> What is a "move constructor"? When would you be "moving" some value?
> 
> "Moving" a value is useful when you know that the source value will be 
> discarded anyway right after the copy is performed, e.g. if it is the 
> return value of a function. Many objects that are expensive to copy can 
> be "moved" much more efficiently.

But the rvalue thing doesn't move a value. What does the rvalue thing 
actually *do* that's different from anything else?  Isn't it that it 
points to a temporary with a guarantee of no aliases?

> Note that non-temporaries can also be bound to r-value references, but 
> not implicitly.

Well, yes, because C++ lets you break anything. That's not the point, 
tho. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Tue, 02 Sep 2008 23:16:45 +0200, Darren New <dne### [at] sanrrcom> wrote:
> But the rvalue thing doesn't move a value. What does the rvalue thing  
> actually *do* that's different from anything else?

It lets you distinguish objects whose values will soon be discarded anyway  
 from objects whose values may not be tampered with.



> Isn't it that it points to a temporary with a guarantee of no aliases?

Aliasing is not the issue. Expected lifetime is.



>> Note that non-temporaries can also be bound to r-value references, but  
>> not implicitly.
>
> Well, yes, because C++ lets you break anything. That's not the point,  
> tho. :-)

It is useful when you need to shuffle values around, but you do not want  
to pay the price of copying them.



-- 
FE

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> What is a "move constructor"? When would you be "moving" some value? If 
> you destructively alter something with aliases, aren't you in trouble? 
> Isn't that what the whole "ownership" concept is supposed to prevent?

  I explained this to you some time ago.

  Suppose you have two 1000x1000 matrices, A and B, and you do this:

Matrix C = A + B;

  The result of operator+ is a nameless temporary which will be destroyed
after the ';'. What that line is doing is initializing C with the value of
that temporary (before it's destroyed).

  What move semantics allow is for the constructor of C to grab the huge
1000x1000 array from the temporary, ie. move it to itself, rather than
copying it (the constructor of C does this by eg. copying the array pointer
from the temporary and assigning null to the pointer in the temporary). When
it has moved the array to itself, the nameless temporary has only a null
pointer, which the destructor of the Matrix class will delete, but deleting
a null pointer is a no-op. Thus nothing is destroyed (except the nameless
temporary Matrix object).

  It's safe for C to do that because it knows that the parameter is a
temporary, nothing points to it, and it's the sole owner of its array.
Nothing will get broken if C just moves the array from the temporary to
itself.

  In the current C++ doing such a move constructor is impossible: There's
no way of knowing if the parameter is a temporary or not.

  What the new C++ standard will add is a way creating a function (eg. a
constructor) which is called when a temporary is given to it as parameter.
This is achieved with the so-called rvalue references. A function taking
an rvalue reference knows that the parameter is a temporary, and thus it's
completely safe to modify it, allowing move semantics to be implemented.

  Move semantics have many useful purposes. For example they make it much
easier to safely return a dynamically allocated object as the return value
of a function, without having to go through the trouble of implementing
reference counting. (The new standard will actually include a one-owner
smart pointer which has move semantics, similar to the current auto_ptr,
but much safer.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I explained this to you some time ago.

Yes. I wanted to rephrase it so I was sure I understood.

>   It's safe for C to do that because it knows that the parameter is a
> temporary, nothing points to it, and it's the sole owner of its array.

Yes, that's kind of what I was asking.

I see where I went wrong. When I said "guaranteed not to be aliased", I 
was implicitly implying (in my head rather than out loud) the 
"temporary" part, and that confused people trying to help me. I should 
have said "a temporary guaranteed not to be aliased."

I mean, the important part is that it isn't and will never be accessed 
by something else later, so it's OK to corrupt it; that temporaries are 
the obvious place where the compiler can tell this is the case is 
secondary, yes?

Sorry for seeming dense.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On 7 Aug 2008 13:04:00 -0400, Jim Henderson wrote:
> On Thu, 07 Aug 2008 13:02:33 -0400, Warp wrote:
>
>>   I always got the impression that COBOL was the "BASIC" of the 70's,
>
> Try the 60's. ;-)

And Lisp was the Haskell of 60-70s?
It was developed in 1958. Wow, that seems awfully early
for a language with such high level concepts.
And they say, any new high level language concepts devised
in today's modern languages are merely imitations of
what Lisp has had already for ages.

-- 
Joel Yliluoma - http://iki.fi/bisqwit/

Post a reply to this message