Re: My feeling
> but seriously though, i agree with you
> that changing . to _
> and -> to . was pointless
The string glue is now called ~, not _.
-> to . makes sense in many ways. Dot is easier to type (it's only a third of the key presses), and is nicer when used without a LHS. Besides that, -> is now a neat new operator that you will learn to appreciate. It creates a closure with named parameters, and is not just syntactic sugar for loops.
The underscore is a great tool for telling apart people who read some early documents and couldn't get over the initial shock and people who are really interested in the new language.
> % print <>;
> Wow, fewer lines of code... it must be
> better. And this way is so much more
No, I didn't write the Perl examples to show that you can do more in less lines with Perl.
I did write them to show to the readers of this article/forum that there is in fact more than one way to do it, and that Perl is a nice alternative to Ruby, especially when it comes to things like this. A single line that is a basic "cat" implementation, but that has no explicit literal "open" or "argv", or "readline" in it shows that Perl has built-in shortcuts for those simple tasks, so you can focus on the important parts of your program. The examples that I gave were to compare the two languages - the comparison itself and the conclusions drawn from it are up to the reader. One of the possible conclusions is that Ruby's syntax is more BASIC-like, and thus clearer and free of excessive punctiation. This may or may not be a good thing, it depends on the reader.
> Yep, that attitude is why I switched
> from Perl to Ruby. ;-)
You pick your programming language by the attitute of some programmers that happen to use it? Maybe that's an option if you code for aesthetic purposes, or if you feel you need to be part of a larger community to be a good coder, but I like to base my choice of language on personal experience, not the attitude of others.
> Seriously, though, you're completely
> missing the point of the article.
I am beginning to think I did. I thought the article was going to be about scalability, and would point out some nifty Ruby features. Until I clicked the link. I was disappointed - there was no in-depth discussion of scalable code, or the swell object orientation that Ruby offers. There was only a very basic file reading tutorial that does nothing more than skimming the surface. If you're going to write an article about a specific language, at least use something that is specific to it.
The article in question has nothing to do with scalability, and has little to do with Ruby. The only real connection between Ruby and this article is that Ruby happens to be the language that the author chose to write the examples in. Almost any language could have been used. And when it's about clean, punctuationless syntax, I would prefer Visual Basic.
> The idea was not to show the best solution
> to the problem, but rather how Ruby
> supports some different approaches.
So it's a programming language with loops, functions, libraries and object orientation. I'm terribly sorry if my expectations are too high, but those are simple features that I expect to be in every modern programming language. Those are not at all specific to Ruby, as even a crappy language like PHP has them. Since when does TIMTOWTDI (There Is More Than One Way To Do It) have anything to do with scalability? A scalable solution only points out the Best Way To Do It, because re-coding something to use a Better Way is a sign of bad scalability. Scaling has to do with expanding and refactoring, not with multiple approaches of the same problem.
> The scalability the author was talking about
> stems from being able to attack a
> problem using different methodologies -
> procedural, OO, functional... Perhaps
> the author could have demonstrated this
> more clearly using some different
> The fact that Perl, Python,
> LISP, etc also support some of the same
> things is irrelevant - the author wasn't
> making any assertion that they don't. No
> need to try to start a language war.
I provided some examples of how Perl "attacks" this "problem". It was not my intention to start a language war, that's just how some readers interpret my reply.
> Do you think you
> can write a better article? Then by all
> means please do so. I would love to read
> it - and I mean that sincerely.
> Freshmeat needs more good articles.
No, I can not write a better article, but I didn't choose to do write one. The author of this article did choose to write something, and when you do so, you can expect some comments, both positive and negative. If negative comments were not welcomed, there should be a warning about that.
Freshmeat needs more _good_ articles, yes. That's why I think this particular article is deplorable, as in my opinion, the article is not "good".
> On the other hand, if you're not going to
> contribute something, don't make
> bullshit jabs like this at those who do.
So you think that a reply, complete re-write and negative comments are not a contribution of some sort? I think it does contribute, and so does your reply. Just like in usenet, there's no need to start new threads to be meaningful to the community, and there's no need to act all friendly if you don't mean it. Fortunately, Freshmeat provides a way to comment on articles, and I decided to do so. "Contribute" and "write an article" are not the same, the latter does imply the first though.
> It serves no purpose other than to make
> you look like a jerk.
If that's how you see me, I can probably not alter that image. Hopefully some people understand that comparison of languages is the only way to come to a good decision. Non-coders who want to learn a language will have to pick one to start with, and a good way is to see equivalent code in multiple languages.