Status of Cardinal (was Re: Proposal to create a new mailing list)

ruby-talk
41

M. Edward (Ed) Borasky wrote:

Wilson Bilkovich wrote:

Also, given that
by far the largest target platform is x86, and it has a tiny number of
gprs, you're going to be doing a lot of shuffling anyway. Why not let
a compiler handle that for you, since they spend all day, every day,
working on making it good at that task?

Actually, though, if you have a look at Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X, you'll see that not only is the *compiler* working hard to do that, so are those bazillions of transistors in the chip! Just because an 8088 only had half a dozen registers, none of which was truly general purpose, and needed an 8087 to do floating point computing, doesn't mean a Tulsa can't have hundreds or thousands of threads' worth of copies of the 8087 and 8088. :slight_smile:

So why not have a Ruby inner interpreter that exploits the massive parallelism, concurrency and caching that's on the chip? In short, why should Sun, Microsoft and the open source community build the Ruby interpreters? Intel and AMD build their own compilers and math libraries, or contract them out -- why don't they build Ruby (and Perl and Python and PHP) interpreters too?

There's not a heck of a lot I can do about AMD, but I *am* in Intel's back yard. :slight_smile:

Did I just propose that Ruby *keep* green threads and not move to using the OS threads? :slight_smile:

···

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

42

Francis Cianfrocca wrote:

'Multicore architectures: many people will probably disagree vehemently with
this, but I think that taking advantage of the new architectures will best
be achieved by breaking computations up into multiple processes. I think the
style that is broadly represented by Erlang will be the most effective
approach, so a new "paradigm shift" (sorry) in programming is coming.
(That's why I've worked so hard on event-driven programming support for
Ruby.) But teaching programmers to be better at multithreading, etc. will be
fruitless because this approach is really difficult now, and will be far
more difficult on highly parallel or multicore hardware. That's my two cents
on the subject, and it's worth every penny ;-).

On the contrary -- I'll agree vehemently on some of this and disagree less strenuously on the rest.

Vehement agreement: Erlang-style lightweight processes are a *proven* way to solve large complex problems on large collections of hardware. However, Erlang does some other things that seem to stick in the craw of a lot of folks here -- like a functional programming style and compile-time type checking. :slight_smile:

Disagreement, but perhaps more a lack of acceptance of reality: I think today's programmers are up to the task of highly parallel programming, because there are many decades of theory and practical experience in it already. I posted a rant about this already today, so I'm not going to belabor the point. I'll just fall back on Arthur C. Clarke's Law: When a distinguished but elderly scientist says something is possible, he is usually proven right. :slight_smile:

···

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

43

Well it might be a challange to be more -Ofun than them and I believe
Smalltalkers have a lot of fun too.
Robert

···

On 1/3/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

Robert Dober wrote:
> On 1/3/07, Martin DeMello <martindemello@gmail.com> wrote:
>>
>> <snip>
>>
>> O'Reilly Media - Technology and Business Training is indicative.
>
> What a great link!!!!!
> Thx a lot for sharing.
> <snip>
Yeah ... fun is definitely a compelling business reason for moving from
subversion to Darcs. So -- is there any chance that Perl 6 will become a
dialect of Haskell rather than a rewrite of Perl?

And who has more fun -- Ruby programmers or Haskell programmers?

--

M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

--
"The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. Don't be misled by the enormous flow of money into bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas."

- Alan Kay

44

Yeah ... fun is definitely a compelling business reason for moving from
subversion to Darcs.

No, but it's a compelling reason to spend your limited free time
hacking on Pugs rather than any project that might be competing for
your attention. Toss in the productivity boost Haskell gives you and
the future looks pretty bright for Pugs in terms of not drying up and
withering away.

So -- is there any chance that Perl 6 will become a
dialect of Haskell rather than a rewrite of Perl?

It's passing Perl 6 tests, so I'd say no :slight_smile: On the other hand, Haskell
might just about be flexible enough to let it be both (not sure).

And who has more fun -- Ruby programmers or Haskell programmers?

I enjoyed both, but the last time I looked at Haskell, Ruby was
definitely more in tune with the posixverse, and I didn't have any
real itch that Haskell scratched. Were I a perler I'd be very tempted
by pugs.

martin

···

On 1/3/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

45

In Rubinius, fun is an object, just like stack frames and CPUs.

···

On 1/3/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

Robert Dober wrote:
> On 1/3/07, Martin DeMello <martindemello@gmail.com> wrote:
>>
>> <snip>
>>
>> O'Reilly Media - Technology and Business Training is indicative.
>
> What a great link!!!!!
> Thx a lot for sharing.
> <snip>
Yeah ... fun is definitely a compelling business reason for moving from
subversion to Darcs. So -- is there any chance that Perl 6 will become a
dialect of Haskell rather than a rewrite of Perl?

And who has more fun -- Ruby programmers or Haskell programmers?

46

At this year's C4 conference [1], Steve Dekorte gave a presentation [2] on programming using the Actor Model [3]. It was fascinating to me since I had never been exposed to anything like it before. His IO language [4] is rather pretty too.

It would be wonderful to wrap something like this up in ruby so it was a first-class citizen in the language.

cr

[1] http://c4.rentzsch.com/0/ AND C4 (conference) - Wikipedia
[2] http://www.iolanguage.com/docs/talks/2006-10-C4/Actors.pdf
[3] Actor model - Wikipedia
[4] http://iolanguage.com/about/

···

On Dec 31, 2006, at 4:54 PM, M. Edward (Ed) Borasky wrote:

Francis Cianfrocca wrote:

'Multicore architectures: many people will probably disagree vehemently with
this, but I think that taking advantage of the new architectures will best
be achieved by breaking computations up into multiple processes. I think the
style that is broadly represented by Erlang will be the most effective
approach, so a new "paradigm shift" (sorry) in programming is coming.
(That's why I've worked so hard on event-driven programming support for
Ruby.) But teaching programmers to be better at multithreading, etc. will be
fruitless because this approach is really difficult now, and will be far
more difficult on highly parallel or multicore hardware. That's my two cents
on the subject, and it's worth every penny ;-).

On the contrary -- I'll agree vehemently on some of this and disagree less strenuously on the rest.

Vehement agreement: Erlang-style lightweight processes are a *proven* way to solve large complex problems on large collections of hardware. However, Erlang does some other things that seem to stick in the craw of a lot of folks here -- like a functional programming style and compile-time type checking. :slight_smile:

Disagreement, but perhaps more a lack of acceptance of reality: I think today's programmers are up to the task of highly parallel programming, because there are many decades of theory and practical experience in it already. I posted a rant about this already today, so I'm not going to belabor the point. I'll just fall back on Arthur C. Clarke's Law: When a distinguished but elderly scientist says something is possible, he is usually proven right. :slight_smile:

47

Vehement agreement: Erlang-style lightweight processes are a *proven*
way to solve large complex problems on large collections of hardware.
However, Erlang does some other things that seem to stick in the craw of
a lot of folks here -- like a functional programming style and
compile-time type checking. :slight_smile:

I'm glad you agree, Ed. I'd add a couple of minor clarifications. First,
I've been involved with Posix threads since before they were Posix threads,
and to me "lightweight process" refers to what is sometimes called a kernel
thread. I assume you're using the term to mean full-weight (userland)
processes that interact with each other in more advanced ways than are
common today. Second, I was careful not to endorse the Erlang language
itself, but rather the broad approach (processes collaborating through
low-bandwidth but very flexible channels) that characterizes Erlang.

Disagreement, but perhaps more a lack of acceptance of reality: I think

today's programmers are up to the task of highly parallel programming,
because there are many decades of theory and practical experience in it
already. I posted a rant about this already today, so I'm not going to
belabor the point. I'll just fall back on Arthur C. Clarke's Law: When a
distinguished but elderly scientist says something is possible, he is
usually proven right. :slight_smile:

There are a lot of strands to this argument, but to avoid a lot of offtopic
controversy, I'll just call out that my concern is not with highly parallel
programming. My problem is with *multithreaded* programming, which I don't
believe is the right way to take advantage of machine parallelism because it
introduces a concurrency into programs that usually isn't germane to the
business problem. I'm not interested in fighting over this, however, except
to say that if I'm right, I'll be shipping a lot more valuable software in
unit time than someone else will. I'm inclined to answer that question
empirically, and then revisit the theoretical issue.

···

On 12/31/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

48

This reply is largely off-topic, but I can't stand mis-information.
Erlang, just like ruby is dynamically typed. Its type checks happen at
runtime not compile time. Admittedly this is surprising for a functional
language, but there it is.

···

On Mon, Jan 01, 2007 at 07:54:08AM +0900, M. Edward (Ed) Borasky wrote:

However, Erlang does some other things that seem to stick in the craw of
a lot of folks here -- like a functional programming style and
compile-time type checking. :slight_smile:

49

M. Edward (Ed) Borasky wrote:

Francis Cianfrocca wrote:
> 'Multicore architectures: many people will probably disagree
> vehemently with
> this, but I think that taking advantage of the new architectures will
> best
> be achieved by breaking computations up into multiple processes. I
> think the
> style that is broadly represented by Erlang will be the most effective
> approach, so a new "paradigm shift" (sorry) in programming is coming.
> (That's why I've worked so hard on event-driven programming support for
> Ruby.) But teaching programmers to be better at multithreading, etc.
> will be
> fruitless because this approach is really difficult now, and will be far
> more difficult on highly parallel or multicore hardware. That's my two
> cents
> on the subject, and it's worth every penny ;-).
On the contrary -- I'll agree vehemently on some of this and disagree
less strenuously on the rest.

Vehement agreement: Erlang-style lightweight processes are a *proven*
way to solve large complex problems on large collections of hardware.
However, Erlang does some other things that seem to stick in the craw of
a lot of folks here -- like a functional programming style and
compile-time type checking. :slight_smile:

Why do you say Erlang does compile-time type checking?

···

Disagreement, but perhaps more a lack of acceptance of reality: I think
today's programmers are up to the task of highly parallel programming,
because there are many decades of theory and practical experience in it
already. I posted a rant about this already today, so I'm not going to
belabor the point. I'll just fall back on Arthur C. Clarke's Law: When a
distinguished but elderly scientist says something is possible, he is
usually proven right. :slight_smile:

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

50

Robert Dober wrote:

And who has more fun -- Ruby programmers or Haskell programmers?

Well it might be a challange to be more -Ofun than them and I believe
Smalltalkers have a lot of fun too.

Someone (Dave Thomas? Andy Hunt? DHH?) said that Ruby made programming fun *again*. So the obvious question is, "What languages were fun before there was Ruby?"

I've never written any Smalltalk, so I can't comment there, but I have to admit, as much as I enjoy programming in general, the two languages that have been the most fun over the years have been Lisp (1.5 actually -- I don't really enjoy Common Lisp all that much) and Forth.

The key to fun in that article, or at least one of them, seems to be the rapid feedback that one can get with some languages. Certainly a Lisp or Scheme REPL environment or Forth's equivalent, the "outer interpreter" and "colon compiler", give that kind of rapid feedback. And Ruby has irb, although there isn't really an "IDE" with irb at the core, at least none that I'm aware of. In Forth, we used to call this process DATK -- Design At The Keyboard.

···

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

51

Wilson Bilkovich wrote:

In Rubinius, fun is an object, just like stack frames and CPUs.

CPUs are objects in Rubinius? Do you have your own scheduler?

···

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

52

Francis Cianfrocca wrote:

Vehement agreement: Erlang-style lightweight processes are a *proven*
way to solve large complex problems on large collections of hardware.
However, Erlang does some other things that seem to stick in the craw of
a lot of folks here -- like a functional programming style and
compile-time type checking. :slight_smile:

I'm glad you agree, Ed. I'd add a couple of minor clarifications. First,
I've been involved with Posix threads since before they were Posix threads,
and to me "lightweight process" refers to what is sometimes called a kernel
thread. I assume you're using the term to mean full-weight (userland)
processes that interact with each other in more advanced ways than are
common today.

Well, actually, I meant "Erlang-style" to include the semantics and efficient implementation thereof specific to the way Erlang does it, rather than anything more "generic".

Second, I was careful not to endorse the Erlang language
itself, but rather the broad approach (processes collaborating through
low-bandwidth but very flexible channels) that characterizes Erlang.

You can be as careful as you wish. I, on the other hand, have no problem endorsing Erlang for a number of things I think it does right. :slight_smile: Neither, apparently, do the good folks at Amazon. :slight_smile:

There are a lot of strands to this argument, but to avoid a lot of offtopic
controversy, I'll just call out that my concern is not with highly parallel
programming. My problem is with *multithreaded* programming, which I don't
believe is the right way to take advantage of machine parallelism because it
introduces a concurrency into programs that usually isn't germane to the
business problem. I'm not interested in fighting over this, however, except
to say that if I'm right, I'll be shipping a lot more valuable software in
unit time than someone else will. I'm inclined to answer that question
empirically, and then revisit the theoretical issue.

Ah ... OK. In terms of business problems, I'm with you -- let's ship valuable software and let the theoreticians argue over whether Petri nets or the Pi-Calculus is the correct model. :slight_smile:

http://is.tm.tue.nl/research/patterns/download/bptrendsPiHype.pdf

Of course, since I know a lot more about Petri nets than I do about the Pi-calculus, that's going to color my approach.

···

On 12/31/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

53

The language has some great ideas to steal. Not all of them are
original to Io but some are implemented in really nice ways. One of my
favorites has been transparent futures. These are a little hard to
implement in Ruby w/o Object#become of some form. Proxies work well
but give a large performance hit and rare gotchas (Ruby takes quite a
few shortcuts that makes this break in odd places).

It would be awesome to see some of this implemented as first class
concurrency mechanisms. I had a good portion of Ruby's object model
mirrored in Io to experiment with the combination. The project was
dropped after I had difficulties with some of less defined areas,
parsing ruby code, and Io's general instablility (much better these
days, but still very visible).

Brian.

···

On 12/31/06, cremes.devlist@mac.com <cremes.devlist@mac.com> wrote:

On Dec 31, 2006, at 4:54 PM, M. Edward (Ed) Borasky wrote:

> Francis Cianfrocca wrote:
>> 'Multicore architectures: many people will probably disagree
>> vehemently with
>> this, but I think that taking advantage of the new architectures
>> will best
>> be achieved by breaking computations up into multiple processes. I
>> think the
>> style that is broadly represented by Erlang will be the most
>> effective
>> approach, so a new "paradigm shift" (sorry) in programming is coming.
>> (That's why I've worked so hard on event-driven programming
>> support for
>> Ruby.) But teaching programmers to be better at multithreading,
>> etc. will be
>> fruitless because this approach is really difficult now, and will
>> be far
>> more difficult on highly parallel or multicore hardware. That's my
>> two cents
>> on the subject, and it's worth every penny ;-).
> On the contrary -- I'll agree vehemently on some of this and
> disagree less strenuously on the rest.
>
> Vehement agreement: Erlang-style lightweight processes are a
> *proven* way to solve large complex problems on large collections
> of hardware. However, Erlang does some other things that seem to
> stick in the craw of a lot of folks here -- like a functional
> programming style and compile-time type checking. :slight_smile:
>
> Disagreement, but perhaps more a lack of acceptance of reality: I
> think today's programmers are up to the task of highly parallel
> programming, because there are many decades of theory and practical
> experience in it already. I posted a rant about this already today,
> so I'm not going to belabor the point. I'll just fall back on
> Arthur C. Clarke's Law: When a distinguished but elderly scientist
> says something is possible, he is usually proven right. :slight_smile:

At this year's C4 conference [1], Steve Dekorte gave a presentation
[2] on programming using the Actor Model [3]. It was fascinating to
me since I had never been exposed to anything like it before. His IO
language [4] is rather pretty too.

It would be wonderful to wrap something like this up in ruby so it
was a first-class citizen in the language.

54

Logan Capaldo wrote:

···

On Mon, Jan 01, 2007 at 07:54:08AM +0900, M. Edward (Ed) Borasky wrote:
  

However, Erlang does some other things that seem to stick in the craw of a lot of folks here -- like a functional programming style and compile-time type checking. :slight_smile:
    

This reply is largely off-topic, but I can't stand mis-information.
Erlang, just like ruby is dynamically typed. Its type checks happen at
runtime not compile time. Admittedly this is surprising for a functional
language, but there it is.

I wasn't aware of that -- since there is a compiler, and some rather fancy language-based QA analysis tools, I assumed there was some kind of "compile-time type checking".

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

55

Yeah. We are planning to have M:N green->native thread mapping, so we
need to do some scheduling.

···

On 1/3/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

Wilson Bilkovich wrote:
> In Rubinius, fun is an object, just like stack frames and CPUs.
CPUs are objects in Rubinius? Do you have your own scheduler?

56

To me, one major component of 'fun' is how well the 'grain' of the
language supports clean, abstract programming and problem solving in
the domain at hand. Ruby is a lot of fun, for example, because its
blocks make control structure abstraction not only easy, but the
*natural* way to solve a problem, because it speaks unix very well
indeed, and because it is sufficiently multiparadigm that you almost
never need to fight the language to do what you want to do.

Lisp and Haskell are both almost as much fun as ruby, but a major win
for the latter is that it is the first (sufficiently powerful)
language where I've never had to wonder whether I'm using the language
wrong or simply approaching the problem wrong (I've had experiences in
both CL and Haskell where I was actually making a mistake in my
formulation of the problem, but my first instinct was nevertheless to
blame my grasp of the language. Doubtless that will go away as I get
more comfortable in said languages, but with ruby I was comfortable
from day one).

martin

···

On 1/3/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

The key to fun in that article, or at least one of them, seems to be the
rapid feedback that one can get with some languages. Certainly a Lisp or
Scheme REPL environment or Forth's equivalent, the "outer interpreter"
and "colon compiler", give that kind of rapid feedback. And Ruby has
irb, although there isn't really an "IDE" with irb at the core, at least
none that I'm aware of. In Forth, we used to call this process DATK --
Design At The Keyboard.

57

Hi,

···

In message "Re: Fun languages (was Re: Status of Cardinal (was Re: Proposal to create a new mailing list))" on Thu, 4 Jan 2007 00:46:11 +0900, "M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

Someone (Dave Thomas? Andy Hunt? DHH?) said that Ruby made programming
fun *again*. So the obvious question is, "What languages were fun before
there was Ruby?"

BASIC was fun for me, when I was in junior high. The point is that as
I grow up, the problem domain I am in charge become far more complex
than BASIC can handle. That's why I need Ruby.

              matz.

58

Robert Dober wrote:
>> And who has more fun -- Ruby programmers or Haskell programmers?
>
> Well it might be a challange to be more -Ofun than them and I believe
> Smalltalkers have a lot of fun too.
Someone (Dave Thomas? Andy Hunt? DHH?) said that Ruby made programming
fun *again*. So the obvious question is, "What languages were fun before
there was Ruby?"

I've never written any Smalltalk, so I can't comment there, but I have
to admit, as much as I enjoy programming in general, the two languages
that have been the most fun over the years have been Lisp (1.5 actually
-- I don't really enjoy Common Lisp all that much) and Forth.

The key to fun in that article, or at least one of them, seems to be the
rapid feedback that one can get with some languages.

You got that right, again :wink:
Imagine where we have come from, feeding Pascal Programs into a card reader
and searching a printout the next day.
To changing a method in our Smalltalk GUI while the application is running
(and the concept was born *before* I fed punch cards into a Cyber mainframe
on university).

That is basically (pun intended) why I had lots of fun with Basic on the
Sharp1500 in the early 80s.
I could experiment with an iterative Quicksort implementing the stack of
local variables and return addresses myself. I thought in Pascal and
implemented in Basic that was about one of the most revealing programming
experiences I ever had. BTW after the Quicksort program was finished there
were 10 data cells left to be sorted LOL.

Ruby matches these feelings and I hope Smalltalk will too.

Certainly a Lisp or

Scheme REPL environment or Forth's equivalent, the "outer interpreter"
and "colon compiler", give that kind of rapid feedback. And Ruby has
irb, although there isn't really an "IDE" with irb at the core, at least
none that I'm aware of. In Forth, we used to call this process DATK --
Design At The Keyboard.

Exactly what I meant above.

···

On 1/3/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

--

M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

Cheers

Robert

--
"The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. Don't be misled by the enormous flow of money into bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas."

- Alan Kay

59

I love transparent futures! They also appear in Alice. Have you looked at
it? Too heavyweight for real programming (it's an ML derivative) but some
really sweet ideas.

···

On 12/31/06, Brian Mitchell <binary42@gmail.com> wrote:

The language has some great ideas to steal. Not all of them are
original to Io but some are implemented in really nice ways. One of my
favorites has been transparent futures. These are a little hard to
implement in Ruby w/o Object#become of some form. Proxies work well
but give a large performance hit and rare gotchas (Ruby takes quite a
few shortcuts that makes this break in odd places).

It would be awesome to see some of this implemented as first class
concurrency mechanisms. I had a good portion of Ruby's object model
mirrored in Io to experiment with the combination. The project was
dropped after I had difficulties with some of less defined areas,
parsing ruby code, and Io's general instablility (much better these
days, but still very visible).

Brian.

60

Yukihiro Matsumoto wrote:

Hi,

>Someone (Dave Thomas? Andy Hunt? DHH?) said that Ruby made programming >fun *again*. So the obvious question is, "What languages were fun before >there was Ruby?"

BASIC was fun for me, when I was in junior high. The point is that as
I grow up, the problem domain I am in charge become far more complex
than BASIC can handle. That's why I need Ruby.

              matz.

BASIC was *never* fun for me. I was in grad school when it came out, and by then I had extensive FORTRAN and macro assembler experience and was fooling around with Lisp 1.5. I simply can't imagine the people who bought Altairs and spent *hours* reading Microsoft BASIC into the 8K of RAM from an ASR 33. :slight_smile:

···

In message "Re: Fun languages (was Re: Status of Cardinal (was Re: Proposal to create a new mailing list))" > on Thu, 4 Jan 2007 00:46:11 +0900, "M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.