Getting the word to conventional programmers

ruby-talk
21

"Christian Neukirchen" <chneukirchen@gmail.com> schrieb im Newsbeitrag news:m2br96vgn3.fsf@lilith.local...

Csaba Henk <csaba@phony_for_avoiding_spam.org> writes:

(snip)

Common Lisp:

(dolist (a (list dog cat cow))
(squeak a))

;; alternatively:
(mapc #'squeak (list dog cat cow))

;; AFAICS, there is no each_with_index, therefore we use LOOP.
;; Paul Graham would define a new macro :slight_smile:
(loop for a in (list dog cat cow)
     counting a into i
     do (say a (format nil "I'm the ~:R animal~%" i))) ; feat. english numbers

Note that in "foreach(i,a,a squeak)" there is no syntactic difference
between the index/value pair which are to be used as immediate values
and the "block argument", to say it in ruby lingo, which is to be
run in each iteration. This phenomenon becomes much more interesting
when you discover you can as well write methods like this.

This behavior can be done trivially with macros in Lisp.

So the point is that you can get "lisp powa" in a modern scripting
language as well without burying yourself under tons of parens and
whew-how-the-heck-should-I-name-this-one like function names.

I don't think there were *too* many parentheses in above code, were
there?

No.

Also, the method names were totally readable. (From MAPC, you
can at least guess that it maps a sequence. MAPC has the advantage of
not collecting the results. If you dont like the name of MAPC, you
are free to rename it as you like. Don't expect anyone to understand
that. :-))

Well, yes, but it's not only method names. It's the way you have to group things together plus the multitude of methods / ways to do certain things. And probably it's also the power of macros that make Lisp code difficult to comprehend for starters: a function call and a macro call look totally alike on the syntactical level yet they are so totally different (the most significant difference being the point in time when something is evaluated if my Lisp knowledge doesn't betray me). And then you have these different ways of quoting inside a macro...

I readily believe that Lisp is extraordinary productive - and I admire Lisp solutions once in a while. But I've never been exposed to it long enough to really embrace it. Maybe I've done too much procedural and object oriented development - or it's just that my brain is more suited to OO thinking, dunno... :slight_smile:

If someone out there knows a Common-Lisp-in-30-days-guaranteed-comprehension tutorial, let me know and I'll might give Lisp another try.

Thanks for listening and sorry for the noise

    robert

22

Mathieu Bouchard wrote:
> Which reminds me...
> "GOTO statement considered harmful"
> -- Source: title to a letter in CACM 11, 3 (March, 1968)
Uh, that title was by an editor... Apocryphally...

Not just any editor: it was Mr. PASCAL himself, Niklas Wirth. (or so I
read)

> "Object-oriented programming is an exceptionally bad idea which
could only > have originated in California." -- Dijkstra
Hey, suck my Dijk.

Note that Dijk is pronounced Dyke, and furthermore, that erotic literature
depicting sapphic women turning to the "good side" by being
straight-curious, is not a genre that survived the sixties.

···

On Sun, 27 Mar 2005, Phlip wrote:

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

23

"Robert Klemme" <bob.news@gmx.net> writes:

Also, the method names were totally readable. (From MAPC, you
can at least guess that it maps a sequence. MAPC has the advantage of
not collecting the results. If you dont like the name of MAPC, you
are free to rename it as you like. Don't expect anyone to understand
that. :-))

Well, yes, but it's not only method names. It's the way you have to
group things together plus the multitude of methods / ways to do
certain things.

TIMTOWTDI. Sorry, just couldn't resist. But the same is true for
Ruby too; for example, create a Hash from two Arrays that contain the
keys/values. I wonder how *you* would implement that. As soon as it
gets a bit more complex, Ruby provides lots of ways to solve things.
It's just that the very to often needed cases already have very
convenient solutions. That's what makes everyone think Ruby is so
easy and covenient. (And unfortunately, the part were Common Lisp
doesn't shine. I'm still looking for an really simple way to do
string.split...)

And probably it's also the power of macros that make Lisp code
difficult to comprehend for starters: a function call and a macro
call look totally alike on the syntactical level yet they are so
totally different (the most significant difference being the point
in time when something is evaluated if my Lisp knowledge doesn't
betray me).

Exactly. But, of course, this is what makes Lisp so powerful.

And then you have these different ways of quoting
inside a macro...

I'm not sure what you mean here, probably quasiquotation.
CL's `(foo bar ,baz quux) is to lists what Ruby's "foo bar #{baz} quux"
is to strings. I don't think that is very hard to grasp, but it's
true it's not that easy to write *good* macros. There are lots of
hidden traps. I can only recommend to everyone to read Paul Graham's
On Lisp on that topic. For advanced Lispers, though.

I readily believe that Lisp is extraordinary productive - and I admire
Lisp solutions once in a while. But I've never been exposed to it
long enough to really embrace it. Maybe I've done too much procedural
and object oriented development - or it's just that my brain is more
suited to OO thinking, dunno... :slight_smile:

You know that CL is the world's first OO language to achieve ANSI
standardization? :slight_smile: Still, there are worlds between CLOS and
Smalltalk-style message sending... I know that.

Also, often you don't even need to actively use Lisp to profit from
its ideas and techniques, knowing about them and their advantages and
disadvantages can make your life as programmer lots easier. (And more
painful if you need to use "lesser" languages...)

If someone out there knows a
Common-Lisp-in-30-days-guaranteed-comprehension tutorial, let me
know and I'll might give Lisp another try.

I can only recommend everyone interested in Lisp to read Peter
Siebel's excellent book "Practical Common Lisp":

http://www.gigamonkeys.com/book/

Thanks for listening and sorry for the noise
    robert

You're welcome.

···

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

24

"Christian Neukirchen" <chneukirchen@gmail.com> schrieb im Newsbeitrag news:m2wtrute3t.fsf@lilith.local...

"Robert Klemme" <bob.news@gmx.net> writes:

Also, the method names were totally readable. (From MAPC, you
can at least guess that it maps a sequence. MAPC has the advantage of
not collecting the results. If you dont like the name of MAPC, you
are free to rename it as you like. Don't expect anyone to understand
that. :-))

Well, yes, but it's not only method names. It's the way you have to
group things together plus the multitude of methods / ways to do
certain things.

TIMTOWTDI. Sorry, just couldn't resist. But the same is true for
Ruby too;

Definitely!

for example, create a Hash from two Arrays that contain the
keys/values. I wonder how *you* would implement that. As soon as it
gets a bit more complex, Ruby provides lots of ways to solve things.
It's just that the very to often needed cases already have very
convenient solutions. That's what makes everyone think Ruby is so
easy and covenient. (And unfortunately, the part were Common Lisp
doesn't shine.

Yeah, maybe that's what makes the difference. The convenience mechanisms encapsulate complexity which is good if you start. You can then later delve into more detail. But if you just have a set of basic building blocks that you can combine in any way (Lego comes to mind...) it might be hard to find a good starting point.

I'm still looking for an really simple way to do
string.split...)

And probably it's also the power of macros that make Lisp code
difficult to comprehend for starters: a function call and a macro
call look totally alike on the syntactical level yet they are so
totally different (the most significant difference being the point
in time when something is evaluated if my Lisp knowledge doesn't
betray me).

Exactly. But, of course, this is what makes Lisp so powerful.

.... as I said. :-))

And then you have these different ways of quoting
inside a macro...

I'm not sure what you mean here, probably quasiquotation.

Yes, that was what I meant. (Of course I din't know the correct Lisp term...)

CL's `(foo bar ,baz quux) is to lists what Ruby's "foo bar #{baz} quux"
is to strings. I don't think that is very hard to grasp,

But it's easy to overlook as it's smaller (compare "`" with "#{}").

but it's
true it's not that easy to write *good* macros. There are lots of
hidden traps. I can only recommend to everyone to read Paul Graham's
On Lisp on that topic. For advanced Lispers, though.

I'll try Macros: Standard Control Constructs and Macros: Defining Your Own

I readily believe that Lisp is extraordinary productive - and I admire
Lisp solutions once in a while. But I've never been exposed to it
long enough to really embrace it. Maybe I've done too much procedural
and object oriented development - or it's just that my brain is more
suited to OO thinking, dunno... :slight_smile:

You know that CL is the world's first OO language to achieve ANSI
standardization? :slight_smile:

I didn't know that, thanks!

Still, there are worlds between CLOS and
Smalltalk-style message sending... I know that.

Also, often you don't even need to actively use Lisp to profit from
its ideas and techniques, knowing about them and their advantages and
disadvantages can make your life as programmer lots easier. (And more
painful if you need to use "lesser" languages...)

:slight_smile:

If someone out there knows a
Common-Lisp-in-30-days-guaranteed-comprehension tutorial, let me
know and I'll might give Lisp another try.

I can only recommend everyone interested in Lisp to read Peter
Siebel's excellent book "Practical Common Lisp":

Practical Common Lisp

Thanks for listening and sorry for the noise
    robert

You're welcome.

Thanks for the pointer!

Kind regards

    robert

25

"Robert Klemme" <bob.news@gmx.net> writes:

"Christian Neukirchen" <chneukirchen@gmail.com> schrieb im Newsbeitrag
news:m2wtrute3t.fsf@lilith.local...

for example, create a Hash from two Arrays that contain the
keys/values. I wonder how *you* would implement that. As soon as it
gets a bit more complex, Ruby provides lots of ways to solve things.
It's just that the very to often needed cases already have very
convenient solutions. That's what makes everyone think Ruby is so
easy and covenient. (And unfortunately, the part were Common Lisp
doesn't shine.

Yeah, maybe that's what makes the difference. The convenience
mechanisms encapsulate complexity which is good if you start. You can
then later delve into more detail. But if you just have a set of
basic building blocks that you can combine in any way (Lego comes to
mind...) it might be hard to find a good starting point.

But then, Lego is lots of fun to play with. :slight_smile: Much more than
Playmobil, for example. But it takes longer to get started, right.

CL's `(foo bar ,baz quux) is to lists what Ruby's "foo bar #{baz} quux"
is to strings. I don't think that is very hard to grasp,

But it's easy to overlook as it's smaller (compare "`" with "#{}").

You're free to define a new reader macro that makes `(,foo) look like
#{foo}. :slight_smile: Even if you overlook the `, when you see the , (or ,@) you
notice you have to be in a quasi-quotation (at least if the code is
valid).

I'll try
Macros: Standard Control Constructs
and Macros: Defining Your Own

Good start, yes.

···

Kind regards
    robert

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org