Getting the word to conventional programmers
Cameron Laird
<URL: http://www.devsource.com/article2/0,1759,1778141,00.asp >.
Christopher Nelson
Rob .
"In five years I expect that dynamic languages ... [will] overtake
Java and C++ as the dominant implementation languages in most areas."
- Guido van Rossum
"One problem shared by all scripting languages is the lack of a good
IDE environment." - Dave Thomas
I believe the potential growth of Ruby usage is tied to the
availability of more sophisticated editors - we need something like
Intellij IDEA for Ruby. The Ruby Editor Plugin I'm developing for
jEdit will provide some of the features available in Intellij like:
auto indent and insert end (done)
file structure popup (done)
next error (done)
previous error (done)
next method
previous method
go to class
find usage
find declaration
extract variable
complete code
quick rdoc
I'm happy to try porting some of this work to FreeRide at a later
date, but because of past experience I'm more productive in jEdit for
now.
Rob
sig...@gmail.com
Robert
sig...@gmail.com
Cameron Laird wrote:
> *DevSource* profiles "The State of the Scripting Universe" in
> <URL: http://www.devsource.com/article2/0,1759,1778141,00.asp >.
It would have been nice to put in a blurb for some of the cool stuff
planned for 8.5. That way people could see that things are *happening*
in the Tcl world and Tcl is moving forward language wise.
That doesn't take away from the article though. It was just a thought.
Robert
Joe Van Dyk
I'm a vim diehard, but it would be nice to have something like ctags
or similar for Ruby. It would be great to hit a key and see a list of
the available functions and their arguments. One of the problem(s)
probably would be that every class in Ruby has a ton of available
functions, as they all inherit from a base class.
Pete Elmore
> or similar for Ruby.
Ctags (ctags.sf.net) has supported every language I've thrown at it.
Cameron Laird
<sig...@gmail.com> wrote:
.
.
.
>It would have been nice to put in a blurb for some of the cool stuff
>planned for 8.5. That way people could see that things are *happening*
>in the Tcl world and Tcl is moving forward language wise.
>
>That doesn't take away from the article though. It was just a thought.
.
.
Robert, though "just a thought", I want to say a few words in response:
you're wrong. Or, you're ambiguous: I think you're saying, "To appro-
priately infect readers with the enthusiasm for Tcl that you (and I)
think they deserve to have, it is necessary to anticipate the objection
that Tcl is 'dormant' and convince them otherwise."
Here's the problem: a magazine needs to be written for its readers,
rather than its authors or any other actors (from a business stand-
point, content ultimately is designed to serve advertisers, but that
rather dreary reality is a distraction we'll ignore for now). Lynn's
job was to profile the languages. To keep her scope manageable, she
did not address the cultures of the different languages. As I under-
stand her thoughts, she doesn't try to help the languages, but rather
help the readers.
It feels as though I'm hitting this tack of a point with a too-heavy
sledgehammer. I sure don't want to offend you, Robert; I *do* want
to take the opportunity to distinguish the different motivations afoot
here. While I think you already understand this, I'll make it explicit:
Lynn deserves our encouragement for her openness to ideas like use of
scripting languages, not our censure for failing to go far enough.
sig...@gmail.com
The size of you hammer was okay with me. It takes a lot to offend me
and having delt with people from this group I know that most of the
stuff is constructive in nature anyway. : )
I did take the opportunity to submit the overall article to OSNews with
an extra link to the Tcl article.
Robert
Glenn Parker
> *DevSource* profiles "The State of the Scripting Universe" in
> <URL: http://www.devsource.com/article2/0,1759,1778141,00.asp >.
It was NOT the most interesting or useful interview I've ever read.
Maybe it was the format: four simulatneous interviews handling totally
softball questions. Or maybe it was the repetition that resulted from
the lack of interaction between the participants. Or maybe it was the
inevitable boosterism from the interviewees. If you're looking for
believable and meaningful criticism (what would you change, etc.),
you'll have to go to people that are not completely vested in the world
of dynamic languages.
My favorite bit was Guido's comment: "If the same effort were poured
into speeding up Python as Sun devoted to Java, Python would be better
than Java in every respect." Guido has some serious cajones, even if he
is right, which he probably is in this case. The same assertion could
be made about Ruby, but in any case the assumption is that the really
smart folks don't work on free software. Do you really buy that?
The rest of the interview was mostly whining about how people just don't
understand how really great dynamic languages are. We get the setup for
this in the first sentence: "Scripting languages have long been regarded
by the programming world as poor country cousins, somehow inferior to
the 'real' programming languages." I must say, this premise is pure
100% baloney. The programming world already knows all about scripting
languages and they tend to use them where they make sense.
The claim that corporate PR trumps better language design is equally
suspsect. Perl does not suffer even though it doesn't have Sun's PR
department behind it. New dynamic languages are simply enduring the
inevitable growing pains. If they solve problems in a radically better
way, they will find a home.
Just my curmudgeonly opionion.
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
Sam Roberts
> I'm a vim diehard, but it would be nice to have something like ctags
> or similar for Ruby. It would be great to hit a key and see a list of
> the available functions and their arguments. One of the problem(s)
> probably would be that every class in Ruby has a ton of available
> functions, as they all inherit from a base class.
I've never seen a version of tags that searches inheritance trees for
methods..
Quoting pe...@petta-tech.com, on Thu, Mar 24, 2005 at 06:56:30AM +0900:
> >I'm a vim diehard, but it would be nice to have something like ctags
> >or similar for Ruby.
> I'm using ctags and ruby. Maybe it's your version of ctags? Exuberant
> Ctags (ctags.sf.net) has supported every language I've thrown at it.
Yeah, but its support for ruby is really weak. Lots of language
constructs it doesn't support.
Biggest thing that hurs me is that it doesn't do qualified tags. jumping
to the tag for "to_s" isn't going to get you anwhere in ruby that you
want to go.
If either of you are interested, I've hacked rdoc to generate tags for
methods so that
module Foo
module Bar::None
class Joe
def to_s
end
end
end
end
will create a tag for
to_s
Joe.to_s
None.to_s
Bar.None.to_s
Foo.Bar.None.to_s
among other things, this allows you to semi-navigate class hierarchies,
you can type:
Bar.None<TAB>
and see a list of all the next matches, all the tags in None.
Its a quick hack, and has some problems. I mean to go back to it, I know
more about tags now, I think I could do better. I want tags for
constants, for example (exctags doesn't do that either).
I'm not trashing the work of whoever did exctags. Parsing ruby is hard,
and to get tags of the same quality of C++/Java/C you can look at what
they had to do... and shudder. Its close to a full parser! Thats why I
used rdoc, its a pretty good ruby parser, though a bit slow.
Mail me off list if you want the rdoc diffs.
Cheers,
Sam
Csaba Henk
> Cameron Laird wrote:
>> *DevSource* profiles "The State of the Scripting Universe" in
>> <URL: http://www.devsource.com/article2/0,1759,1778141,00.asp >.
>
> It was NOT the most interesting or useful interview I've ever read.
Yeah, mostly they were just whining and advocating, business as usual.
> My favorite bit was Guido's comment: "If the same effort were poured
> into speeding up Python as Sun devoted to Java, Python would be better
> than Java in every respect." Guido has some serious cajones, even if he
> is right, which he probably is in this case. The same assertion could
> be made about Ruby, but in any case the assumption is that the really
> smart folks don't work on free software. Do you really buy that?
There was one interesting bit, committed by Pall, the PHP guy:
DevSource: If there were one core thing you could change about scripting
languages, what would it be?
Pall: Even though popular scripting languages such as Python, Perl, Tcl,
PHP, Javascript are all very high-level languages, they are all based on
an text based idiom. [...] Representing code as abstract syntax trees
and not streams of characters is central to huge advances in programmer
efficiency and simplicity.
Csaba
Glenn Parker
>
> There was one interesting bit, committed by Pall, the PHP guy:
>
> DevSource: If there were one core thing you could change about scripting
> languages, what would it be?
>
> Pall: Even though popular scripting languages such as Python, Perl, Tcl,
> PHP, Javascript are all very high-level languages, they are all based on
> an text based idiom. [...] Representing code as abstract syntax trees
> and not streams of characters is central to huge advances in programmer
> efficiency and simplicity.
I chuckled when I read that. The secret to "huge advances" is, wait for
it... LISP! Only we'll have to drop that antiquated textual
representation stuff for something (?) better. Too much PHP must rot an
important area of the brain, the same way candy affects your teeth. :)
Christian Neukirchen
And the bitter irony in above statement is that PHP is the only
language of these that requires the *code as a string* to create a
lambda. :-)
> Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
Csaba Henk
:)
Recently I got quite fond of Io, http://www.iolanguage.com.
Io supports all the lispy stuff and even more (no difference between
object and binding; function, closure, method, lambda, macro-like
parsetree tweakers are all the same; and not *almost* everything is
message sending to an object, like in Ruby or Smalltalk, but
*everything*, perdiod). And it has a much more friendly syntax than than
of Lisp. Slightly more verbose than Ruby, but still an agile language.
Ruby:
[dog, cat, cow].each { |a| a.squeak }
[dog, cat, cow].each_with_index { |a,i| a.say "I'm the #{i}-th animal" }
Io:
list(dog,cat,cow) foreach(i,a,a squeak)
list(dog,cat,cow) foreach(i,a,
a say("I'm the " .. (i asString) .. "-th animal")
)
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.
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.
Csaba
Csaba Henk
> And the bitter irony in above statement is that PHP is the only
> language of these that requires the *code as a string* to create a
> lambda. :-)
Well, you can't really feel the value of something until you suffer from
the lack of it :)
Csaba
Christian Neukirchen
> On 2005-03-25, Glenn Parker <glenn....@comcast.net> wrote:
>> Csaba Henk wrote:
>>> Pall: Even though popular scripting languages such as Python, Perl, Tcl,
>>> PHP, Javascript are all very high-level languages, they are all based on
>>> an text based idiom. [...] Representing code as abstract syntax trees
>>> and not streams of characters is central to huge advances in programmer
>>> efficiency and simplicity.
>>
>> I chuckled when I read that. The secret to "huge advances" is, wait for
>> it... LISP! Only we'll have to drop that antiquated textual
>> representation stuff for something (?) better. Too much PHP must rot an
>> important area of the brain, the same way candy affects your teeth. :)
>
> :)
>
> Recently I got quite fond of Io, http://www.iolanguage.com.
>
> Io supports all the lispy stuff and even more (no difference between
> object and binding; function, closure, method, lambda, macro-like
> parsetree tweakers are all the same; and not *almost* everything is
> message sending to an object, like in Ruby or Smalltalk, but
> *everything*, perdiod). And it has a much more friendly syntax than than
> of Lisp. Slightly more verbose than Ruby, but still an agile language.
(Please note that I'm biased due to my Lisp knowledge.) I actually
think Io's syntax is horrible compared to Lisp. :-) I like the small
size, the prototyped object system and some other nifty features
(transparent futures etc.) of IO, but the syntax is so "bare", it's
really annoying. Heck, I think even JavaScript would be more
convenient. ;-)
> Ruby:
>
> [dog, cat, cow].each { |a| a.squeak }
> [dog, cat, cow].each_with_index { |a,i| a.say "I'm the #{i}-th animal" }
>
> Io:
>
> list(dog,cat,cow) foreach(i,a,a squeak)
> list(dog,cat,cow) foreach(i,a,
> a say("I'm the " .. (i asString) .. "-th animal")
> )
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 :-)
(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? 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. :-))
> Csaba
Mathieu Bouchard
On Sat, 26 Mar 2005, Glenn Parker wrote:
> Too much PHP must rot an important area of the brain, the same way
> candy affects your teeth. :)
Which reminds me...
"It is practically impossible to teach good programming to students that
have had a prior exposure to BASIC; as potential programmers they are
mentally mutilated beyond hope of regeneration." -- Dijkstra
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence." -- Dijkstra
"APL is a mistake, carried through to perfection. It is the language of
the future for the programming techniques of the past: it creates a new
generation of coding bums." -- Dijkstra
"GOTO statement considered harmful"
-- Source: title to a letter in CACM 11, 3 (March, 1968)
"Object-oriented programming is an exceptionally bad idea which could only
have originated in California." -- Dijkstra
_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Phlip
> Which reminds me...
>
> "It is practically impossible to teach good programming to students that
> have had a prior exposure to BASIC; as potential programmers they are
> mentally mutilated beyond hope of regeneration." -- Dijkstra
>
> "The use of COBOL cripples the mind; its teaching should, therefore, be
> regarded as a criminal offence." -- Dijkstra
>
> "APL is a mistake, carried through to perfection. It is the language of
> the future for the programming techniques of the past: it creates a new
> generation of coding bums." -- Dijkstra
>
> "GOTO statement considered harmful"
> -- Source: title to a letter in CACM 11, 3 (March, 1968)
Uh, that title was by an editor... Apocryphally...
> "Object-oriented programming is an exceptionally bad idea which could only
> have originated in California." -- Dijkstra
Hey, suck my Dijk.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Christian Neukirchen
> On Sat, 26 Mar 2005, Glenn Parker wrote:
>
>> Too much PHP must rot an important area of the brain, the same way
>> candy affects your teeth. :)
>
> Which reminds me...
>
> "It is practically impossible to teach good programming to students that
> have had a prior exposure to BASIC; as potential programmers they are
> mentally mutilated beyond hope of regeneration." -- Dijkstra
>
> "The use of COBOL cripples the mind; its teaching should, therefore, be
> regarded as a criminal offence." -- Dijkstra
>
> "APL is a mistake, carried through to perfection. It is the language of
> the future for the programming techniques of the past: it creates a new
> generation of coding bums." -- Dijkstra
>
> "GOTO statement considered harmful"
> -- Source: title to a letter in CACM 11, 3 (March, 1968)
>
> "Object-oriented programming is an exceptionally bad idea which could only
> have originated in California." -- Dijkstra
And I still think the best thing about Dijkstra is his
handwriting. :-)
> Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Robert Klemme
"Christian Neukirchen" <chneuk...@gmail.com> schrieb im Newsbeitrag
news:m2br96v...@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 :-)
> (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... :-)
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
Christian Neukirchen
>> 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... :-)
You know that CL is the world's first OO language to achieve ANSI
standardization? :-) 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.
Mathieu Bouchard
On Sun, 27 Mar 2005, Phlip wrote:
> Mathieu Bouchard wrote:
> > Which reminds me...
> > -- 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.
_____________________________________________________________________
Robert Klemme
> "Robert Klemme" <bob....@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
http://www.gigamonkeys.com/book/macros-standard-control-constructs.html and
http://www.gigamonkeys.com/book/macros-defining-your-own.html
>> 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... :-)
>
> You know that CL is the world's first OO language to achieve ANSI
> standardization? :-)
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...)
:-)
>> 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.
Thanks for the pointer!
Kind regards
robert
Christian Neukirchen
> "Christian Neukirchen" <chneuk...@gmail.com> schrieb im Newsbeitrag
> news:m2wtrut...@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. :-) 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}. :-) 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
> http://www.gigamonkeys.com/book/macros-standard-control-constructs.html
> and http://www.gigamonkeys.com/book/macros-defining-your-own.html
Good start, yes.
> Kind regards
> robert