"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.
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.
On Thu, 24 Mar 2005 01:18:49 +0900, Rob . <rob.02...@gmail.com> wrote: > In the article the following comments were made:
> "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.
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.
>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.
Cameron Laird wrote: > In article <1111613336.660577.241...@f14g2000cwb.googlegroups.com>, > <sigz...@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.
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.
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.
Quoting joevan...@gmail.com, on Thu, Mar 24, 2005 at 06:35:36AM +0900:
> 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 p...@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
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.
> 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.
> 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. :)
Glenn Parker <glenn.par...@comcast.net> writes: > Csaba Henk wrote: >> 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. > :)
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. :-)
>> 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. :)
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.
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 Henk <csaba@phony_for_avoiding_spam.org> writes: > On 2005-03-25, Glenn Parker <glenn.par...@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. :)
> 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. ;-)
> 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. :-))
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
> "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
Mathieu Bouchard <ma...@sympatico.ca> writes: > 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. :-)
> ;; 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.
"Robert Klemme" <bob.n...@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... :-)
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":
On Sun, 27 Mar 2005, Phlip wrote: > 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.
>>> 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 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":
"Robert Klemme" <bob.n...@gmx.net> writes: > "Christian Neukirchen" <chneukirc...@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. :-) 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).
|
