the perens in lisp dilects is there for a reson... macros.

[M. Edward (Ed) Borasky]

You seem to confuse the language Common Lisp with the mathematical
concept Lisp. Lisp is seven operators and a one-page denotional
semantic definition. That's about as small and core as it gets.

Yes ... I wish I could remember who made that distinction and when. In
any event, I'm guessing it was in the days of Lisp 1.5, which is
certainly a core language. IIRC Lisp 1.5 had some primitive string
handling, and some implementations even did floating point. But this was
well before Common Lisp 1, Common Lisp 2 or the ANS standard.

As I noted in an earlier post, I'm now off looking for the Ruby "core
language".

 

[dblack]

Hi --

Thanks!! In February of 1993, I was just starting on the project that has
consumed most of my "paid programming" time since then. It started out as
Korn shell augmented with "gawk" for the more complicated pieces, then got
migrated to Perl 4 as soon as I discovered Perl 4. It picked up the R
component about 2000, but it's still mostly Perl 4. The Java 1.1 program was
done in 1997.

So, going back to another thread, it looks like the "core language" of Ruby
is the object model and the Perl features. Is there by any chance a place
where I could get the Ruby 1.0 source? That might be *very* interesting.

ftp://ftp.ruby-lang.org/pub/ruby/1.0. Nothing before 1.0, as far as I
can find.


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
http://www.manning.com/black => book, Ruby for Rails
http://www.rubycentral.org => Ruby Central, Inc.

 

[Kristof Bastiaensen]

You seem to confuse the language Common Lisp with the mathematical
concept Lisp. Lisp is seven operators and a one-page denotional semantic
definition. That's about as small and core as it gets.

No, I don't. The post I replied to was mentioning practical programming
languages, not mathematical concepts. Lisp can mean the family of
languages, to which Common Lisp, Emacs Lisp, and scheme belong, and the
programming language Common Lisp. But since he was mentioning scheme as a
different language, I concluded that he meant the last. But I should have
clarified that it my post though.

Regards,
Kristof

 

[Kristof Bastiaensen]

No. It looks more like trolling in an incoherent way, than a discussion with
meaningful information about lisp.

Apparently some people do care. If you don't, then why reading the
thread?

Whatever you opinions about any programming language are, Ruby is
implemented in C at the moment, so C at least has *that* going for it!

Exactly! It is quite useful to know C, for example to write bindings to
existing libraries, or to rewrite the parts of your program that are slow
in C.

Regards,
Kristof

 

[Chad Perrin]

There's a discussion related to this going on over at Lambda the
Ultimate that you might enjoy:
http://lambda-the-ultimate.org/node/1646

While I know a fair bit about Lisp dialects such as CLisp and Scheme, I
don't actually know the languages per se. As such, I find it difficult
to be certain I'm not missing something. Judging by what I do know,
though, it seems likely to me that the way UCBLogo handles the
parentheses "problem" is pretty damned optimal: you don't need
parentheses because expressions have default lengths (which default can
be circumvented by adding the parentheses back in).

I'm not about to go joining a Lisp mailing list to make that statement
without knowing more about "proper" Lisps, however. Of course.

 

[Chad Perrin]

Hmmm... I had rather thought that functional-style languages were more
common for writing language interpreters/compilers in. Aren't Lisp guys
always on about using Lisp to write another language more specific to
the problem domain, and working from there?

Err . . . not exactly. It's more like in Lisp you create a
domain-specific "jargon" that allows you to abstract the problem further
according to the needs of the moment -- like using a particularly long
lever to gain the ability to move larger things with less "heavy
lifting" power provided by you, the programmer.

As one uses a higher-level programming language rather than moving bits
around one at a time with a pair of tweezers when one wants to (for
instance) edit some text, so one uses Lisp to create domain-specific
syntaxes for further abstracting things so that not even the extra work
of using that "higher-level" programming language is necessary. At
least, that's my understanding: it's not about literally writing a
compiler for a language, then writing programs in that language.

I could be wrong, though.

 

[Daniel Martin]

No. It looks more like trolling in an incoherent way, than a discussion with
meaningful information about lisp.

Looking up other posts by (e-mail address removed) on google groups is
informative. It *looks* like the poster is continuing some
pre-existing conversation, but he's not. However, I'm not sure that
this is trolling in the sense of "the poster is consciously trying to
arouse an emotional response", unless the entire persona of
(e-mail address removed) is one long extended troll.

There's lisp macro activity, which would be annoying on this list to
begin with, then there's poor lisp macro activity, which attempts to
wax on about how wonderful lisp macros are without providing more than
trivial examples (easily done with higher-level functions), then
there's incoherent advocacy, which is what we have here. (not merely
incoherent from the bizarre spelling and atrocious grammar, but also
incoherent at a structural level - he can't decide if he's defending
lisp as a wonderful language or as a sieve to separate the
uebermenschen from the rest of humanity)

Anyway. This is entirely much more time spent on this poster than I
meant to spend.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: the perens in lisp dilects is there for a reson... macros."
on Mon, 7 Aug 2006 03:04:47 +0900, (e-mail address removed) writes:

|Ruby's birthday is traditionally
|February 1994 (I can't remember the exact day),

It was 1993-02-24 for the record.

|and I seem to remember
|that that predates Java, but I'm not sure.

The first release date of the Java language white paper was somewhere
in 1994, so you might think Ruby predates Java, but in fact:

* the development of the Java language (formerly named Oak language)
started in 1991, if I remember correctly.
* the first public release of Ruby was December 1995.

As a conclusion, Java is slightly older than Ruby.

matz.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: the perens in lisp dilects is there for a reson... macros."
on Mon, 7 Aug 2006 07:41:37 +0900, (e-mail address removed) writes:

|> So, going back to another thread, it looks like the "core language" of Ruby
|> is the object model and the Perl features. Is there by any chance a place
|> where I could get the Ruby 1.0 source? That might be *very* interesting.
|
|ftp://ftp.ruby-lang.org/pub/ruby/1.0. Nothing before 1.0, as far as I
|can find.

I lost most of the old copies when I moved jobs (and due to disk
crash) ruby-0.49 was the oldest source package I have. It's way
before public release (0.95). I have just put it into

ftp://ftp.ruby-lang.org/pub/ruby/1.0/ruby-0.49.tar.gz

It's not guaranteed to run properly though.

matz.

 

[M. Edward (Ed) Borasky]

It's very interesting to compare the sample/ directories of 0.49 and
1.8.4. ;-)

I found the source for 1.0. Sadly, gcc 3.4.6 refuses to compile it --
complains about "varargs.h" not used any more.

 

[M. Edward (Ed) Borasky]

Hi,

In message "Re: the perens in lisp dilects is there for a reson... macros."
on Mon, 7 Aug 2006 07:41:37 +0900, (e-mail address removed) writes:

|> So, going back to another thread, it looks like the "core language" of Ruby
|> is the object model and the Perl features. Is there by any chance a place
|> where I could get the Ruby 1.0 source? That might be *very* interesting.
|
|ftp://ftp.ruby-lang.org/pub/ruby/1.0. Nothing before 1.0, as far as I
|can find.

I lost most of the old copies when I moved jobs (and due to disk
crash) ruby-0.49 was the oldest source package I have. It's way
before public release (0.95). I have just put it into

ftp://ftp.ruby-lang.org/pub/ruby/1.0/ruby-0.49.tar.gz

It's not guaranteed to run properly though.

matz.

What "recent" versions of GCC will compile it? 3.4.6 won't handle
"varargs.h" in the 1.0 source.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: the perens in lisp dilects is there for a reson... macros."

|What "recent" versions of GCC will compile it? 3.4.6 won't handle
|"varargs.h" in the 1.0 source.

As far as I know, 2.95.4 has <varargs.h>.

matz.

 

[Jeremy Tregunna]

Le 06-08-08 =E0 01:37, Francis Cianfrocca a =E9crit :

If one considers the appearance of the famous Dr. Dobbs article to =20
be the
"public release" of Java, it appeared in May 1995. Predates Ruby's =20
public
release but not by much.

Does it *really* matter which came first?

--
Jeremy Tregunna
(e-mail address removed)


"One serious obstacle to the adoption of good programming languages =20
is the notion that everything has to be sacrificed for speed. In =20
computer languages as in life, speed kills." -- Mike Vanier

 

[Charles Hoffman]

Err . . . not exactly. It's more like in Lisp you create a
domain-specific "jargon" that allows you to abstract the problem further
according to the needs of the moment -- like using a particularly long
lever to gain the ability to move larger things with less "heavy
lifting" power provided by you, the programmer.

As one uses a higher-level programming language rather than moving bits
around one at a time with a pair of tweezers when one wants to (for
instance) edit some text, so one uses Lisp to create domain-specific
syntaxes for further abstracting things so that not even the extra work
of using that "higher-level" programming language is necessary. At
least, that's my understanding: it's not about literally writing a
compiler for a language, then writing programs in that language.

I could be wrong, though.

That makes sense to me, except that it doesn't seem all that different
from what you do with any language by writing functions and classes and
the like. You end up with all these concepts that you've defined in
code and given names to, and then work with those. So why do Lispies
make such a big deal over it?

--ch--

 

[M. Edward (Ed) Borasky]

That makes sense to me, except that it doesn't seem all that different
from what you do with any language by writing functions and classes and
the like. You end up with all these concepts that you've defined in
code and given names to, and then work with those. So why do Lispies
make such a big deal over it?

I did something similar a long time ago in macro assembler, which I
learned a long time before I learned Lisp. Interestingly enough, I dug
out my copy of Leo Brodie's "Thinking Forth" last night. That
programming style, and the term "factoring", are prominent in that work
(which by the way is available on line now as a PDF). I think it's
something all programmers of a certain level of maturity do regardless
of language.

I learned Lisp (1.5) in the early 1970s, and this style of programming
seemed to be tied to Lisp at the time, but I actually had used it
earlier. For some reason FORTRAN programmers, including myself when I
was one, don't usually use this style, perhaps because the original
FORTRAN didn't have structured concepts and forced the use of GO TO
statements.

Lisp is probably the third oldest programming language in use today,
after FORTRAN and COBOL. Since FORTRAN and COBOL programmers didn't tend
to program that way and Lisp programmers did, I suspect the Lispniks
make a big deal of it because they "invented" it and have been doing it
longer.

 

[M. Edward (Ed) Borasky]

Le 06-08-08 à 01:37, Francis Cianfrocca a écrit :


Does it *really* matter which came first?

Yes.

 

[dblack]

---2049402039-571243175-1155045609=:20280
Content-Type: MULTIPART/MIXED; BOUNDARY="-2049402039-571243175-1155045609=:20280"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---2049402039-571243175-1155045609=:20280
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

Le 06-08-08 =E0 01:37, Francis Cianfrocca a =E9crit :


Does it *really* matter which came first?

If you want to go out of your way not to learn about the history of
Ruby, just killfile Matz


David

--=20
http://www.rubypowerandlight.com =3D> Ruby/Rails training & consultancy
----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com =3D> D[avid ]A[. ]B[lack's][ Web]log
http://www.manning.com/black =3D> book, Ruby for Rails
http://www.rubycentral.org =3D> Ruby Central, Inc.
---2049402039-571243175-1155045609=:20280--
---2049402039-571243175-1155045609=:20280--

 

[Francis Cianfrocca]

I learned Lisp (1.5) in the early 1970s, and this style of programming
seemed to be tied to Lisp at the time, but I actually had used it
earlier. For some reason FORTRAN programmers, including myself when I
was one, don't usually use this style, perhaps because the original
FORTRAN didn't have structured concepts and forced the use of GO TO
statements.

I've always been fascinated by one specific aspect of functional
languages: in theory, it's possible to use tools to prove programs
correct. What a productivity win that would be. At different times, I
used professional programmers who worked for me as guinea pigs to see
just how they would take to the functional style, and the results were
dismal.

Even though the Church and Turing models of computation are unified
(and were unified long before digital computers existed), there still
seems to be something intuitively attractive to many programmers about
stuffing values into little boxes and being able to go get the values
out of the boxes later. I'm not sure if this is fundamental, or a
side-effect of the fact that our practical computing machines are all
Turing machines and most programmers learn something about "memory"
and "secondary storage" early in their training. This explains why
pure functional programming is stylistically so challenging in
practice, whether or not you believe it's challenging in theory.

But one of the more insightful things I've heard recently is this:
Turing-completeness works against productivity and makes programs less
tool-able. And this is a direct consequence of its power, which
necessarily gives you Godel-undecidability in the general case.

The Lispish style (conceptualizing programs as artifacts in a
domain-specific language), which Ruby does extremely well in an
imperative-language context, can be said to have the following virtue:
it allows you to work with your problem domain using a language that
is not Turing-complete. (Let that sink in for a moment.) That means
that your programs are easier to reason about, easier to debug, and
eventually, easier to tool. What you lose in expressive power is
trivial because your standard for language power is related to your
problem domain, not to Turing-completeness in general. What you gain
in productivity is potentially immense.

 

[M. Edward (Ed) Borasky]

I've always been fascinated by one specific aspect of functional
languages: in theory, it's possible to use tools to prove programs
correct. What a productivity win that would be. At different times, I
used professional programmers who worked for me as guinea pigs to see
just how they would take to the functional style, and the results were
dismal.

You are bringing back memories and dreams I had in graduate school.
Nobody where I went to school knew anything about this, but it was all
in the library. I still have most of the books I bought on the subject,
which date back to the mid-1970s for the most part.

I learned the Von Neumann style first -- it's hard not to when your
first programming class is taught on ILLIAC I. But I learned the
functional style and prefer it.

But one of the more insightful things I've heard recently is this:
Turing-completeness works against productivity and makes programs less
tool-able. And this is a direct consequence of its power, which
necessarily gives you Godel-undecidability in the general case.

More memories and dreams. Maybe that's why regular expressions are so
popular -- because they're equivalent to the lowest common denominator,
a finite state machine, about which you can pretty much prove and
discover everything.

The Lispish style (conceptualizing programs as artifacts in a
domain-specific language), which Ruby does extremely well in an
imperative-language context, can be said to have the following virtue:
it allows you to work with your problem domain using a language that
is not Turing-complete. (Let that sink in for a moment.) That means
that your programs are easier to reason about, easier to debug, and
eventually, easier to tool. What you lose in expressive power is
trivial because your standard for language power is related to your
problem domain, not to Turing-completeness in general. What you gain
in productivity is potentially immense.

Well ... there are two reasons to write a Domain Specific Language:

1. As a way of organizing your own programming, and
2. As a tool to be used by *others* to perform a job.

For 1, I think any way of doing things that organizes your code for
yourself and your team/enterprise that works is in some sense the
"right" way, whether that be functional, object-oriented, or even
spaghetti code. But for 2, I'm not at all convinced by the DSLs I've
seen over the years, including those I've written myself. People in
general aren't programmers, and designing a programming language for
them may not in fact lead to increases in *their* productivity.

When I look at the main project I've been working on for the past ten
years, in my mind, at any rate, it is a domain-specific language. Most
of it is written in fairly small Perl scripts, with some graphics done
in R. In all, it's probably smaller in lines of code than Rails. I think
I could "prove things about its correctness". It badly needs a
rewrite/refactoring, given that big chunks of it were developed on a
system that only allowed 14-character file names. But it is in fact a
*small* application -- we aren't talking millions of lines of code or
anything like that. What's large is the *data*, which is typical of
"scientific" applications.

 

[Francis Cianfrocca]

Well ... there are two reasons to write a Domain Specific Language:

1. As a way of organizing your own programming, and
2. As a tool to be used by *others* to perform a job.

For 1, I think any way of doing things that organizes your code for
yourself and your team/enterprise that works is in some sense the
"right" way, whether that be functional, object-oriented, or even
spaghetti code. But for 2, I'm not at all convinced by the DSLs I've
seen over the years, including those I've written myself. People in
general aren't programmers, and designing a programming language for
them may not in fact lead to increases in *their* productivity.

I'm glad you enjoyed the trip down memory lane ;-). I gave up on
functional programming over a dozen years ago, for two reasons: first, I
learned the hard way that writing really good compilers for lambda-based
languages requires a huge amount of mathematical knowledge, and mine
doesn't go beyond partial diffeqs. Second, my experiments with ordinary
professional programmers proved that the proportion of them who are
mentally receptive to the functional style is too small to be
commercially valuable. I was completely taken with FP myself, but one
programmer does not a team make.

To your point about regexes: remember that they are level-0 languages,
whereas most programming languages (including useful DSLs) are level-1
languages (context-free grammars). AFAIK, a language that generates
expressions that can be reduced to NFAs can not be Turing-complete, but
correct me if I'm wrong on that.

A poorly-designed DSL is just as useless as any other tool that doesn't
reflect an appropriate modeling of the problem domain (not too powerful,
not too trivial, but just right). Still, I think it's pretty exciting
that Ruby makes DSLs easy and graceful, thus activating for imperative
programmers one of the most useful aspects of Lisp. (I'm sure that
statement will be hotly contested by Lisp partisans, but let them rant.)

With DSLs, I'm thinking about tools for programmers, not for
non-programmers. (Although there is a very interesting class of
highly-successful mini-languages for non-programmers, like MS Office
macros.) My point about "tooling" was in regard to automatic programs
that can reason about other programs. DSLs and other mini-languages are
far easier to write workbenches and IDEs for, which I think is really
interesting and potentially a huge productivity boost. And again, it's
the reduction from full Turing-completeness that may be the secret
sauce. I wish I could prove that, but I've already told you that I'm no
mathematician, so it's a hunch at best.