F.Y.I Not sure if you guys have read this article, I am going to re-post it here. http://glyphobet.net/blog/essay/228
on 08.04.2008 04:54
on 08.04.2008 05:10
2008/4/7 Song Ma <songmash@gmail.com>:
> http://glyphobet.net/blog/essay/228
The piece can be summarized in two brief quotations:
First, near the beginning:
I promise we'll be as objective as humanly possible
then, about 500 pages later:
TMTOWDI is bad
In other words, I'll be objective, so long as objective means judging
things according to my own lack of imagination.
on 08.04.2008 05:17
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Song Ma wrote: | F.Y.I | | Not sure if you guys have read this article, I am going to re-post it here. | | http://glyphobet.net/blog/essay/228 | "It's not ready, because it isn't Python". That sums the article up in a sentence. I could say the same in reverse about Python, or any other language. Two major fallacies: 1) The issues the article touches on are already known, and partially addressed in libraries (Regexen with Oniguruma (sp?)) and/or different implementations (speed in JRuby, for example, where you could farm out to Java's Strings or regexen). 2) (And this breaks the whole premise of the article:) The basis for the comparison is humbug. Porting libraries and applications isn't a valid test of languages, since the original implementation shapes preconceptions. If Ruby and particularly Rails weren't ready, it wouldn't see adoption by major players. - -- Phillip Gawlowski Twitter: twitter.com/cynicalryan Rule of Open-Source Programming #4: If you don't work on your project, chances are that no one will. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkf646IACgkQbtAgaoJTgL8PwwCglpbFBS9fqm+/6q8WTGdeliC7 0IAAn3YcFu1ATbfo4C58mbuyccgGLlEb =Xush -----END PGP SIGNATURE-----
on 08.04.2008 05:18
Well he seems to hold everything to the standard of Python, so of course anything that follows the TMTOWDI approach rather than Ivory Tower Driven Development (ITDD) is going to be bad. --Jeremy 2008/4/7 Avdi Grimm <avdi@avdi.org>: > then, about 500 pages later: > -- http://jeremymcanally.com/ http://entp.com Read my books: Ruby in Practice (http://manning.com/mcanally/) My free Ruby e-book (http://humblelittlerubybook.com/) Or, my blogs: http://mrneighborly.com http://rubyinpractice.com
on 08.04.2008 05:22
Interesting. But what I am thinking about is not the attitude of the author, but the points he was trying to make. The deep review and discussion will benefit the language insights. 2008/4/8, Avdi Grimm <avdi@avdi.org>:
on 08.04.2008 05:29
Song Ma wrote: > F.Y.I > > Not sure if you guys have read this article, I am going to re-post it here. > > http://glyphobet.net/blog/essay/228 > > Warning: only read if you feel like being really irritated to gain maybe a tiny bit of insight, probably on things you already know. At least, that's my opinion on this article. -Justin
on 08.04.2008 05:46
Damn! Our whole coding business has been built on a language and framework that's just not ready yet?? <sigh> LOL! <tongue out of cheek> That's just silly. I don't understand why he'd write something like that, but honestly it doesn't really matter. If he wants to not use Rails and Ruby, then so be it. I use it, and I've used it for years, we've done numerous apps (over 10), some of our them Enterprise-level, and it works a treat. I looked at Python, but writing it is a pain in the neck. It just sucks (for me). This is my preference. Julian. Learn Ruby on Rails! Check out the FREE VIDS (for a limited time) VIDEO #3 out NOW! http://sensei.zenunit.com/
on 08.04.2008 05:47
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Song Ma wrote: | Interesting. But what I am thinking about is not the attitude of the author, | but the points he was trying to make. The deep review and discussion will | benefit the language insights. Two years ago, it might have. But not anymore. And it is not about attitude. It's credibility. And the first two paragraphs of the article blew *that*. - -- Phillip Gawlowski Twitter: twitter.com/cynicalryan Never buy what you do not want because it is cheap; it will be dear to you. ~ -- Thomas Jefferson (1743-1826) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkf66msACgkQbtAgaoJTgL/U2wCgkHjcu+D9JU7o5BQxSHVW4Y55 14AAnRUDvsB6d1XnyEUPz0guIMBxxmR6 =JGAj -----END PGP SIGNATURE-----
on 08.04.2008 05:55
The points he was trying to make are incredibly biased. Ruby works like people do. That's why I like it. That's why it's faster to program in. If people aren't open to programming in a more natural way, Ruby will just "get in the way". So, it's not for them. All of the "downsides" are worth this. It's pragmatic. Julian. Learn Ruby on Rails! Check out the FREE VIDS (for a limited time) VIDEO #3 out NOW! http://sensei.zenunit.com/
on 08.04.2008 06:00
2008/4/7 Song Ma <songmash@gmail.com>: > Interesting. But what I am thinking about is not the attitude of the author, > but the points he was trying to make. The deep review and discussion will > benefit the language insights. There's no deep review here. It's a shallow review written in a shallow way. The author is completely and wholly incorrect that: "The options for Ruby 1.8 users are to install 1.9 or the third-party Oniguruma package... In general, it's a bad sign when a third-party reimplements a large chunk of functionality in an existing piece of software." This represents pure ignorance. Yes, Ruby 1.8 users must install Oniguruma for the features that Oniguruma provides. But it's not a "third-party" product as such; it *is* the Ruby 1.9 regexp engine. This fact has been known and stated for at least three years, and Oniguruma is made available as an option for people who need the additional features. (Free clue: not many. Those who do need it really need it. Most people don't.) The author is similarly wholly ignorant of Ruby 1.9 and Ruby 2.0 discussions and assumes that "lack of English documentation" is the same as "lack of documentation." The author is a fool for believing the claim that Ruby 2 has been in development longer than Perl 6. Perl 6 was ramping up as I switched to Ruby in 2002 and Ruby 1.8 was released a bit after that (I got my Ruby 1.8 Pickaxe at the 2005 RubyConf in San Diego). Matz has been talking about the next generation of Ruby (Ruby 2.0) for a while, but that's no different than the discussions and experiments surrounding Py3k. Worst of all, the author treats both the Alioth shootout and the Zed Shaw rant as things worthy of positive attention, when both are, well, worthless. The Alioth shootout has been known to be worthless for years yet periodically some idiot treats it as serious. Zed's rant was a *rant*. It too had things that are known to be false, things that are probably libellous, and things that were simply taken out of context. All in all, the authors pretend to be objective when they are anything but. They've drunk the Guido-ade and as the resulting article shows had no interest in showing Ruby in a positive light. Most of the things that they've mentioned are *differences* from Python (neither positive nor negative) or have little importance to most applications. (Yes, Virginia. Most people don't need full-on Unicode munging in their code. It's necessary when you do need it, but most people don't need it.) This article deserves to be buried with great prejudice. -austin
on 08.04.2008 06:06
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Austin Ziegler wrote: | (Yes, Virginia. Most people don't need full-on Unicode munging in | their code. It's necessary when you do need it, but most people don't | need it.) http://www.joelonsoftware.com/articles/Unicode.html I need it. Most of Europe needs it. Not to mention Arabia, Japan, and everybody else not speaking English. - -- Phillip Gawlowski Twitter: twitter.com/cynicalryan ~ "Endorsing products is the American way of expressing individuality." - -Calvin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkf67xsACgkQbtAgaoJTgL8EsQCfS8P7nsE9JFbcHpwzbbpPQGvq 7LIAnRMf/jqxjnTHbun779NQuhBQ0mKm =9M0o -----END PGP SIGNATURE-----
on 08.04.2008 06:07
I'm pretty sure this was simply a bullet point review on a client's list of requirements for a project's RFP/spec. "We want you to use Ruby/Rails because we've heard you get things done faster. If you want this project, you need to use Ruby or tell us why you won't use it." "We don't know how to use Ruby, so let me give you a list of stupid reasons we aren't using it. It has nothing to do with the fact that we don't have any clue how to use it. Nope. The biggest killer for us is all of these minor things, especially having to remember THREE WHOLE WAYS to print text to the screen. Whew! Ruby isn't ready." I think your assessment is basically spot on of its bias. --Jeremy 2008/4/8 Austin Ziegler <halostatue@gmail.com>: > Oniguruma package... In general, it's a bad sign when a third-party > > Worst of all, the author treats both the Alioth shootout and the Zed > things that they've mentioned are *differences* from Python (neither > * austin@halostatue.ca * http://www.halostatue.ca/feed/ > * austin@zieglers.ca > > -- http://jeremymcanally.com/ http://entp.com Read my books: Ruby in Practice (http://manning.com/mcanally/) My free Ruby e-book (http://humblelittlerubybook.com/) Or, my blogs: http://mrneighborly.com http://rubyinpractice.com
on 08.04.2008 06:31
Austin Ziegler wrote: > There's no deep review here. It's a shallow review written in a > shallow way. Indeed. Just one shallow point that showed up when I scrolled about 2/3 down and read a couple of paragraphs from the essay: > What is the difference between the length and size methods on > String, Array, and Hash? There is none. Hashes have update and > merge methods. What's the difference? None. > > These are particularly atrocious synonyms, because the English > words they are based on aren't synonymous. What if you have a > class representing a geometric object, and you want length and > size to return different measurements? Sure, so on your geometric class you define length and size to be different. It happens that they are the same for strings (and why not). They don't have to be the same for other things.
on 08.04.2008 12:51
On Apr 8, 5:05am, Phillip Gawlowski <cmdjackr...@googlemail.com> wrote: > > I need it. Most of Europe needs it. Not to mention Arabia, Japan, and > everybody else not speaking English. > Bullshit. I've done localization for Chinese sites in Ruby without ever having to think about unicode issues. SOME things require you to take care. Such as not making stupid assumptions about the length of strings in bytes vs. characters. But most of the time people can do a lot of string mangling with UTF-8 without ever needing to think about it. ALL my work involve international character sets in one way or the other, because I refuse to not deal with i18n. NONE of my work involves "full- on unicode munging". It involves a tiny subset of support at most. That applies to most people, and most of what they'll ever need is trivial to implement. Reading/writing UTF-8 is easy. Splitting UTF8 into characters, or converting it to 32 bit codepoints is easy (surprise, surprise, #pack and #unpack supports it). Once you have it in 32 bit, the length calculation problems go away, and slicing and splicing strings without thinking about it becomes easy. That's almost everything _most_ people ever need in order to work with Unicode. If there was such a burning need, most people would use ICU bindings for Ruby (do they exist? I've never even bothered to look, but if they don't they'd be trivial to write if I ever need them) Vidar
on 08.04.2008 13:24
[Unicode]
> I need it.
I keep on reading people that need Unicode, and in your case it may very
well be true and for many others as well.
But personally I never had a need to use Unicode and it may be true for
many others as well.
======================================================
But about the blogger in question - it is easy to see he is an avid
python user.
Personally I have no big objection to python as a language (much less
than against perl or php), I think projects using python instead of perl
do a big improvement in general for various reasons, and I think anyone
choosing python can as well choose ruby.
But the blogger seems to make extremely BAD points:
Point 1
"The language and its implementation are incomplete and immature."
"A project loses time when it must implement missing or incomplete
functionality."
This is a statement. He does not give points to illustrate this
statement.
I can only laugh about unbased statements. What functionality is
missing?
Should viewers try to understand how you think?
Point 2
"The language is inconsistent and needlessly complex. Inconsistency and
complexity confuses people and confusion breeds bugs."
It is true that ruby as a whole is a _complex_ language. So is haskell.
"Complexity" alone is nothing inherently bad. If you want an euphemism
for "complexity", you could use "powerful". And if we use the word
powerful the
language suddenly no longer appears "bad". But it is true - ruby is
complex. There is a lot to learn and know for a newcomer to ruby
(normally, but ruby is A LOT easier than haskell)
When i went from php (yes, laugh...) to ruby there was a lot to learn.
There is still a lot to learn but the situation has changed. I have
since then entirely got rid of all my php (which means yes, all my web
stuff is powered by ruby).
For several reasons, ruby is a much better language than php. And ruby
is more suited to outside-www tasks than php ever will.
Ruby as a language is not inconsistent though.
As said I partially agree about the complexity stuff as in "a lot to
learn and know", but this does not really matter for a given project.
For example I do spend more time aggressively thinking if I really need
to use something in a ruby program or not.
@@class_vars I really never need, global vars I do sometimes use but
they arent needed that much. Metamagic is sometimes fun but I dont think
there are that many use cases for it. (I am just in love of objects
which seem to solve pretty everything ...)
Point 3
"The documentation is incomplete. Incomplete documentation breeds bugs
as you might misuse a feature."
That documentation could be improved in ruby - agreed. I am in total
favour of this, and I hope people do not recommend _only_ ri as
"solution". Often the ri was equivalent to "RTFM". This is what php for
a long time had better solved than ruby due to webpages _about_ php and
the php-homepage docu (the situation has changed in the recent years for
ruby due to some websites and efforts improving online docu of ruby, so
I am not complaining here really)
That "incomplete docu breeds bugs" is total and utter bullshit.
Last but not least, I think everyone that visits the blog knows what
"Comments are closed." means:
He is only interested in presenting his (IMHO incorrect) view to the
visitor.
A blog that disallows comments yet makes many unfound and incorrect
statements is just wasting time of the visitor.
on 08.04.2008 13:40
Marc Heiler, 08.04.2008 13:24: > [Unicode] >> I need it. > > I keep on reading people that need Unicode, and in your case it may very > well be true and for many others as well. > That's precisely the ignorant attitude that caused the issues we currently have with differen character sets. I'm pretty sure that if computer systems had been emerged from a non-english speaking country at the beginning we wouldn't need to still fight character set issues (there are still too many applications that even have problems with 8bit character sets) There are definitely more users in the world who *need* Unicode than users who don't need it and therefor don't care. You can not even get away with a 8bit character set for a european wide application, let alone a world-wide application. I'm a newbie with Ruby and until I read this discussion I simply assumed it would fully support Unicode "out of the box" especially given the fact that is originates from Japan. I'm actually very confused (not to say shocked) that there *is* a discussion if Ruby needs (or supports?) Unicode. Unicode (and a relevant encoding such as UTF8) should be the *standard* for all (new) programming languages and not an exception. Thomas
on 08.04.2008 13:55
Why is everyone getting so worked up? It's a critique. Biased it may be, but that in itself does not make it worthless. In fact, it can be very constructive b/c it uncovers "attack points" with the language. With each point we can ask ourselves objectively is this a misconception or a fair point? In either case we have an opportunity, to address misconceptions in our Ruby evangelizing blogs and to work to improve Ruby where a point has merit. Bias can work both ways. But I think the Ruby community can rise above it, and Ruby will be all the better for it. T.
on 08.04.2008 14:51
From: "Thomas Kellerer" <YQDHXVLMUBXG@spammotel.com> > > That's precisely the ignorant attitude that caused the issues we currently have with > differen character sets. "Let me tell you something about You that YOU don't know. . . ." <grin> > I'm a newbie with Ruby and until I read this discussion I simply assumed it would fully > support Unicode "out of the box" especially given the fact that is originates from Japan. > I'm actually very confused (not to say shocked) that there *is* a discussion if Ruby > needs (or supports?) Unicode. My understanding was that in Japan, character encodings such as EUC-JP or Shift_JIS were widely preferred over Unicode. > Unicode (and a relevant encoding such as UTF8) should be the *standard* for all (new) > programming languages and not an exception. Apparently not, as One Character Encoding to Rule Them All is not considered satisfactory to many people. Here's a long thread on the subject from the archives: http://tinyurl.com/ge2kp Anyway, ruby 1.8 *does* have usable UTF-8 support "out of the box." (See also post #9 in that thread by Matz talking about 1.8.) Ruby 1.9 has much broader support for handling multiple character encodings. Regards, Bill
on 08.04.2008 15:08
On 8 Apr 2008, at 03:53, Song Ma wrote: > F.Y.I > > Not sure if you guys have read this article, I am going to re-post > it here. > > http://glyphobet.net/blog/essay/228 If an article of similar tone were published comparing French and English we would all see it for the daft nonsense it is. Python and Ruby fill a certain niche and present different ways of handling problems in that niche. I much prefer Ruby to Python, and I have friends who much prefer Python to Ruby. Arguing over which is the better language is pointless. Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net ---- raise ArgumentError unless @reality.responds_to? :reason
on 08.04.2008 15:17
Bill Kelly, 08.04.2008 14:51: >> Unicode (and a relevant encoding such as UTF8) should be the *standard* for all (new) >> programming languages and not an exception. > > Apparently not, as One Character Encoding to Rule Them All is not considered > satisfactory to many people. But Unicode/UTF8 would at least satisfy a *lot* more people than plain ASCII or 8bit encodings (such as ISO-8859-x) > Here's a long thread on the subject from the archives: http://tinyurl.com/ge2kp > > Anyway, ruby 1.8 *does* have usable UTF-8 support "out of the box." (See also > post #9 in that thread by Matz talking about 1.8.) Ah! Good to know that. > Ruby 1.9 has much broader support for handling multiple character encodings. Is there any release plan for 1.9? Thomas
on 08.04.2008 15:19
Err, to point a fact: Ruby itself does not support Unicode, in the way that Intel quad core processors aren't really quad core. Those are true statements, but they are misleading. Ruby can mimic enough Unicode to get by in the areas where you need it. Otherwise the original Japanese author probably wouldn't have been able to use it quite as much, and then it wouldn't have caught on in Japan, and wouldn't have moved over to the US and Europe. Heck, the fact that you can type this into vi and the two output lines are the same should be enough to convince anyone. #!/usr/bin/ruby #an example shamelessly pulled from a ruby mailing list question a="\xD7\x90" b="א" puts a puts b Probably the fact that ruby's lack of Unicode support still lets you do this is why there hasn't been more of a push for full blown Unicode. --Kyle
on 08.04.2008 15:26
Bill Kelly, 08.04.2008 14:51: > Anyway, ruby 1.8 *does* have usable UTF-8 support "out of the box." (See also > post #9 in that thread by Matz talking about 1.8.) Hmm. After reading the thread, I simply tried: puts "öäü".length and it returns 6 if the source file is saved with UTF8, which is plain wrong. (it returns 3 if saved in ISO-8859-1 encoding). String#size returns the same values. In case your mail reader does not display the string correctly - it's: öäü Thomas
on 08.04.2008 15:35
2008/4/7 Song Ma <songmash@gmail.com>: > F.Y.I > > Not sure if you guys have read this article, I am going to re-post it here. > > http://glyphobet.net/blog/essay/228 The only good point in that whole mess is that the current state of docs for Ruby is poor, and could use a lot of love. - Rob http://robsanheim.com http://thinkrelevance.com
on 08.04.2008 16:21
> TMTOWDI is bad > > In other words, I'll be objective, so long as objective means judging > things according to my own lack of imagination. > Ok, don't kill me for this, and I do disagree with most of the article (I personally found Ruby more coherent and therefore simple, and I see many things are improving (speed, regexp, etc...) so I am happy with that). However I did sympathise with the author's comment on having too many ways to do the same thing. They pretty much mirror my feelings: that you either learn them all (in which case you lost in simplicity) or you'll have a very hard time reading other people's code. I admit though that it makes _writing_ code easier. I know however that the Ruby community is strongly in favour of this "feature", so I was wondering why. Diego
on 08.04.2008 16:34
Rob Sanheim wrote: > 2008/4/7 Song Ma <songmash@gmail.com>: >> F.Y.I >> >> Not sure if you guys have read this article, I am going to re-post it here. >> >> http://glyphobet.net/blog/essay/228 > > The only good point in that whole mess is that the current state of > docs for Ruby is poor, and could use a lot of love. Well ... I guess that depends on which docs you are talking about. There's plenty of documentation on Rails, three of the major GUIs -- Shoes, FXRuby and QtRuby -- have books in "print" on them, there are two major Ruby "cookbooks", the documentation on Ruport and RSpec is excellent, etc. A week or so ago when the Ruby Mendicant was considering working on the docs, I expressed the opinion that the documentation is the responsibility of the creator -- someone shouldn't have to do it for them. Now if the creator is a better coder than tech writer, perhaps the project can take on someone. But my experience has been that it's very rare for someone to be an excellent coder and a poor tech writer. I read the essay and all of the posts about it here so far, and my own personal opinion is: 1. Everything he said has been said before -- it's basically a rehash of old criticisms. 2. My main concern is not with the documentation. My main concern is that both the syntax and semantics of the language seem to be more fluid than "pragmatic" considerations would dictate. I more or less grew up with FORTRAN, although I missed FORTRAN I. So I'll use its evolution as an example. Ten years into its evolution, an ANSI committee was formed to standardize the language. Users and vendors sat around a huge table and thrashed out what would break the least code, what was easy to implement, what kinds of programs people wanted to write in the language that they couldn't, etc. The result was FORTRAN 66. 11 years later there was FORTRAN 77, etc. Now FORTRAN is 50 years old, there's a FORTRAN 95 standard, and the language is still in use (I think -- I haven't written any since 1990). Ruby is a tad older than ten years, and I think maybe it's time for some standardization on the syntax and semantics. I think there are enough "killer apps" now that we know what we can't take out of Ruby without breaking Rails, RSpec, Ruport, etc. And from MRI, KRI, jRuby and Rubinius, I think we know what's easy to implement and what isn't. But what I have no clues about is what programs people want to write in Ruby that they can't write now.
on 08.04.2008 16:37
On 08/04/2008, Thomas Kellerer <YQDHXVLMUBXG@spammotel.com> wrote: > > and it returns 6 if the source file is saved with UTF8, which is plain > wrong. (it returns 3 if saved in ISO-8859-1 encoding). > String#size returns the same values. > > In case your mail reader does not display the string correctly - it's: > öäü > It's completely correct. length in 1.8 means number_of_bytes. You can get 3 by using regexps in utf-8 or a special extension which is mentioned in many threads on Unicode as well. Thanks Michal
on 08.04.2008 16:38
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | However I did sympathise with the author's comment on having too many | ways to do the same thing. They pretty much mirror my feelings: that | you either learn them all (in which case you lost in simplicity) or | you'll have a very hard time reading other people's code. I admit | though that it makes _writing_ code easier. | | I know however that the Ruby community is strongly in favour of this | "feature", so I was wondering why. Learning Ruby as my first language, I can emphasize with this issue. But: The TMTOWDI approach helps with productivity. A lot. I switch between the different idioms and methods as the situation requires. Sometimes it is more natural to use #match, sometimes it is more natural to use #scan, depending on the situation. The only problem I've had is the less than optimal documentation for Ruby, so it is rather difficult to find what a method does or, sometimes, where it comes from. And lets face it: Most code in the world is write-only: It's written once, and becomes instant legacy code. How often is code completely revisited, and has to be re-factored in an amount of time that makes it impossible to wrap one's head around it again? Not much, and it doesn't happen often (mostly in languages that are used in the enterprise, where refactoring tools are available, and IDEs are more useful than with Ruby at the moment). Besides, it helps with problem solving, I've noticed, the more Ruby I pick up. It's a matter of using the right tool for the right job within the language itself. However, I've not yet formalized my IT knowledge, so take it with a grain of salt. My view is an opinion. Treat it as such. - -- Phillip Gawlowski Twitter: twitter.com/cynicalryan Write first in an easy-to-understand pseudo-language; then translate into whatever language you have to use. ~ - The Elements of Programming Style (Kernighan & Plaugher) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkf7guQACgkQbtAgaoJTgL93AACgmigzprUIZJD87pcNyae5IO+7 W6AAn02u5jVsqJ3+2rYNB9xN5hOG88lX =FPEN -----END PGP SIGNATURE-----
on 08.04.2008 16:46
On Tue, 2008-04-08 at 23:20 +0900, Diego Virasoro wrote: > However I did sympathise with the author's comment on having too many > ways to do the same thing. They pretty much mirror my feelings: that > you either learn them all (in which case you lost in simplicity) or > you'll have a very hard time reading other people's code. I admit > though that it makes _writing_ code easier. > I know however that the Ruby community is strongly in favour of this > "feature", so I was wondering why. You answered your own question here. It makes writing code a joy. And, unlike, say, Perl (or even more extremely, K), Ruby isn't quite a write-only programming language. (If you use all the idiot Perlisms you can make it that way, but almost nobody uses those thankfully!) Ruby is by no means a perfect language. But as a former Pythonista (I started with Python at v1.3), Ruby, despite its warts (and this includes the UNICODE issue, the lousy performance, the bad threading model and the whole host of other things people have ranted about for ages now) remains my first and favourite language I reach for when I'm starting a project. As things move along in the project I reach for other languages to supplement or replace it (recently Erlang has grabbed my imagination for certain key application elements), but Ruby's my first choice and is usually in the final product in some form or another.
on 08.04.2008 16:54
On Tue, Apr 8, 2008 at 3:15 PM, Thomas Kellerer <YQDHXVLMUBXG@spammotel.com> wrote: > But Unicode/UTF8 would at least satisfy a *lot* more people than plain > ASCII or 8bit encodings (such as ISO-8859-x) Would it? It comes with a very significant hit in the speed of Regex processing, at least with the current implementation. Enough to, for many applications, negate the speed benefit everything that has been optimized from 1.8 to 1.9. This has been shown with speed reports on this mailing list previously I'll note that I work in a non-US character set, and in my experience, UTF support in a programming language has only been in the way. So far, what has been useful to me has always been to have strings be lists of bytes. I do not doubt that there are usecases where the support is useful; it is just that so far I haven't come across them, or the support that has been there has been unobtrusive enough that I haven't noticed that it was useful (but I don't think so - all data I have fit nicely in ISO-Latin-1, because all I work with comes from western Europe or is in english.) Note that this sounds like I am against transparent UTF-8 support - that's not necessarily so. I just want to make sure that people are (many) usecases where the support isn't just neutral, it is actually a drawback (loss of speed, extra complexity, not knowing that the result of string.length actually means you can put string in a field of length length), so the upsides had better be worthwhile. Eivind.
on 08.04.2008 17:03
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Edward (Ed) Borasky wrote: | Well ... I guess that depends on which docs you are talking about. | There's plenty of documentation on Rails, three of the major GUIs -- | Shoes, FXRuby and QtRuby -- have books in "print" on them, there are two | major Ruby "cookbooks", the documentation on Ruport and RSpec is | excellent, etc. I shouldn't have to buy a book (like the PickAxe), to get decent documentation. A book should be one option, among many, to get to the documentation. I'll elaborate on that in the next paragraph. | A week or so ago when the Ruby Mendicant was considering working on the | docs, I expressed the opinion that the documentation is the | responsibility of the creator -- someone shouldn't have to do it for | them. Now if the creator is a better coder than tech writer, perhaps the | project can take on someone. But my experience has been that it's very | rare for someone to be an excellent coder and a poor tech writer. While I agree, that the project is responsible for its own documentation ~ (its rather obvious, is it not?), the tools we have in the Ruby community to create documentation are limited to RDoc, a rather hacky solution (Correct me if I'm wrong, but Dave Thomas said as much), intended as a stand-in until a more useful tool comes around. Sadly, as it is so common in the world, the temporary solution becomes the permanent solution, with all its short-comings (see a discussion on the mixup of Ruby Core and Ruby StdLib documentation on ruby-doc.org/core). And that is a big obstacle, making it unnecessarily difficult for newbies like me (I still am a newbie to Ruby, despite using it for more than a year, the language is just that complex in its simplicity, which is a major appeal for me, but that is a rant for another time). We, as a community, have to provide tools that make it easy and painless to generate documentation, and generate it in different formats. In my most humble opinion, we should take a look at Javadoc, and see what we can steal^H^H^H^H^H implement for Ruby. I fully recognize that Javadoc is great for Java, and less so for Ruby, but that doesn't mean it doesn't have useful ideas that make it a breeze to generate documentation. Anecdotal evidence: When building the gem for Gondor Library I was struggling in including the README and LICENSE files in RDoc. The files were included in my Rake task's FileList for gem generation, as well as standalone doc generation. However, the gem didn't include the files in ./, only ./lib, much unlike the RDoc task. I had to explicitly tell the gem, to include extra files. I lost more than an hour to that. The outdated RubyGems documentation didn't really help. Fortunately, I found other Rake tasks, and could eliminate the problem. But it shouldn't be this way, and I have the feeling it is a shortcoming of RDoc (maybe not, I haven't looked at RDoc itself, so my assessment of the reason maybe wrong, but my point still stands). Also, that RDoc generates frames for usage isn't the ideal solution, IMO, as it makes search difficult (via a browser's search, anyway). And AFAIK, RDoc cannot spit out PDFs, PostScript, or LaTeX, or something other than ri. And that makes it unnecessarily difficult to generate non-RDoc documentation without third party tools (and I don't really want to learn Yet Another Tool that is not directly related to increasing my productivity in writing Code (that's what I want to do, not write comments or documentation). | 2. My main concern is not with the documentation. My main concern is | that both the syntax and semantics of the language seem to be more fluid | than "pragmatic" considerations would dictate. I more or less grew up | with FORTRAN, although I missed FORTRAN I. So I'll use its evolution as | an example. | | Ten years into its evolution, an ANSI committee was formed to | standardize the language. Users and vendors sat around a huge table and | thrashed out what would break the least code, what was easy to | implement, what kinds of programs people wanted to write in the language | that they couldn't, etc. The result was FORTRAN 66. 11 years later there | was FORTRAN 77, etc. C and C++ went the other way, with the STDLIB growing steadily, and new features being added. Yet, C/C++ are more in use. However, both FORTRAN and C are anecdotal evidence. The scope of the languages is not really the same, and neither is Ruby's. | | I think there are enough "killer apps" now that we know what we can't | take out of Ruby without breaking Rails, RSpec, Ruport, etc. And from | MRI, KRI, jRuby and Rubinius, I think we know what's easy to implement | and what isn't. But what I have no clues about is what programs people | want to write in Ruby that they can't write now. For the power that Ruby gives me: I want to write everything in Ruby. It's good at pretty much everything I can throw at it, except number-crunching. But I can farm that out to C or Java, or maybe .NET once IronRuby is "production ready". Personally, I haven't reached the point where I feel that Ruby isn't up to the task at hand, or severely limited. That's anecdotal, though. I'm sure that people who have to do some heavy lifting and datamunging to do have a different opinion on that (but more related to Ruby's speed, than Ruby's syntax and expressiveness, or am I mistaken?). - -- Phillip Gawlowski Twitter: twitter.com/cynicalryan ~ - You know you've been hacking too long when... ...you dream that your SO and yourself are icons in a GUI and you can't get close to each other because the window manager demands minimum space between icons... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkf7iQIACgkQbtAgaoJTgL8aVgCgjWbCoZyKVMfxGJS0nMOwE9+P dfgAoJA1nYY99kKFqU68aNS9KO8ca+6G =Mf9d -----END PGP SIGNATURE-----
on 08.04.2008 17:23
> Now FORTRAN is 50 years old, there's a FORTRAN 95 standard, and the > language is still in use (I think -- I haven't written any since 1990). Most definitly. In my office we is it constantly. There's only one serious contender for number crunching here and it's C, but then C is much more of a pain to use, and you need to use the correct flags to get the kind of optimisations that Fortran gives you out of the box. Oh, and Fortran has now moved to Fortran 2003 standard (and they are working on 2008). It's a really nice language to write in... though it's not suitable for that many jobs. But this is totally OT, sorry. (it's just rare to find another person with a good opinion of Fortran ^_^) Diego
on 08.04.2008 17:38
On Apr 8, 2008, at 10:02 AM, Phillip Gawlowski wrote: > While I agree, that the project is responsible for its own > documentation > ~ (its rather obvious, is it not?), the tools we have in the Ruby > community to create documentation are limited to RDoc, a rather hacky > solution (Correct me if I'm wrong, but Dave Thomas said as much), > intended as a stand-in until a more useful tool comes around. I said it's a hacky _implementation_. I believe the concept is just fine. > of RDoc (maybe not, I haven't looked at RDoc itself, so my > assessment of > the reason maybe wrong, but my point still stands). Sounds like a configuration issue with the gem, to me. > Also, that RDoc generates frames for usage isn't the ideal solution, > IMO, as it makes search difficult (via a browser's search, anyway). The frames are just one option. Have you looked at api.rubyonrails.com? > And AFAIK, RDoc cannot spit out PDFs, PostScript, or LaTeX, or > something > other than ri. And that makes it unnecessarily difficult to generate > non-RDoc documentation without third party tools (and I don't really > want to learn Yet Another Tool that is not directly related to > increasing my productivity in writing Code (that's what I want to do, > not write comments or documentation). Actually, I have it generating all three, as well as plain text, chm, and our in-house PML markup. I'm not defending RDoc. But I think that if the situation is to improve, it should be through informed discussion. There are a couple of underlying issues. Firstly, much of the basic Ruby infrastructure is not well documented. Many standard libraries in the base distribution have minimal documentation, for example. Many gems are only minimally documented (for example, having just API-level documentation). Second, there's no good place to go to see documentation. I think we have the basis for a great set of documentation. What is needed now is for someone with vision to take the next step. It needn't be a big one. In the same way that the RubyGems initiative set down some simply packaging guidelines that we all follow, I think that someone could drive through the same for documentation. It needn't be more than a few conventions. For example, we are used to seeing README and INSTALL in the top-level of an application. Change Gems to include these by default. If it sees a HOWTO file, include that. If it sees GUIDE, do the same. These are just suggestions--someone needs to take ownership of this and flesh it out properly. We have the API documentation nut cracked. We need to do the same for the non-API documentation. And, if we set the conventions in place now, the tools will be able to use them to build a raft of different styles of documentation sites. I'm looking forward to it. Dave
on 08.04.2008 18:03
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Thomas wrote: | | On Apr 8, 2008, at 10:02 AM, Phillip Gawlowski wrote: |> While I agree, that the project is responsible for its own documentation |> ~ (its rather obvious, is it not?), the tools we have in the Ruby |> community to create documentation are limited to RDoc, a rather hacky |> solution (Correct me if I'm wrong, but Dave Thomas said as much), |> intended as a stand-in until a more useful tool comes around. | | I said it's a hacky _implementation_. I believe the concept is just fine. Err, yes. I like the idea of RDoc myself. I like it very much, almost to the level of fan boy. It is very easy to generate API docs. But that is the only thing it can do, it seems. | Sounds like a configuration issue with the gem, to me. Yes, it was. I had to tell the gem specifically to find these extra documents. My chip on my shoulder is, that this shouldn't be necessary, especially when the RDoc task in my Rakefile actually generates the documentation without declaring these documents explicitly. |> Also, that RDoc generates frames for usage isn't the ideal solution, |> IMO, as it makes search difficult (via a browser's search, anyway). | | The frames are just one option. Have you looked at api.rubyonrails.com? Which is still a frameset. The layout's different, but that's it. | Actually, I have it generating all three, as well as plain text, chm, | and our in-house PML markup. | | I'm not defending RDoc. But I think that if the situation is to improve, | it should be through informed discussion. Yes, of course. I'm not shouting to purge RDoc from the Rubyist's toolkit, not at all. However, it stopped progressing at some point, and no body has taken over to expand it. (However, I have found a github repository that seems to tackle the issue. And I'm waiting for the source code to take a look at it.) | There are a couple of underlying issues. Firstly, much of the basic Ruby | infrastructure is not well documented. Many standard libraries in the | base distribution have minimal documentation, for example. Many gems are | only minimally documented (for example, having just API-level | documentation). The hashing functions in the STDLIB have no documentation. Having looked at the STDLIB documentation for Ruby in the past, I'm looking at the web first, and spend my time tweaking search-engine queries, and find some sort of tutorial on how to use it. Which makes me sad. And since I'm not good at reading C, or other people's code just yet, I can't contribute with documentation patches, and *that* makes me an unhappy camper: Not being able to contribute in correcting issues I see, and help out a great community. :/ | Second, there's no good place to go to see documentation. Indeed. If there were, the Rails API wouldn't be on 5+ websites to look at. Similar for Ruby's documentation. That it isn't very searchable is another issue, IMO. (OTOH, neither is Javadoc from what I've seen. Well, there's no silver bullet, is there?). | I think we have the basis for a great set of documentation. What is | needed now is for someone with vision to take the next step. It needn't | be a big one. In the same way that the RubyGems initiative set down some | simply packaging guidelines that we all follow, I think that someone | could drive through the same for documentation. It needn't be more than | a few conventions. For example, we are used to seeing README and INSTALL | in the top-level of an application. Change Gems to include these by | default. If it sees a HOWTO file, include that. If it sees GUIDE, do the | same. These are just suggestions--someone needs to take ownership of | this and flesh it out properly. | | We have the API documentation nut cracked. We need to do the same for | the non-API documentation. And, if we set the conventions in place now, | the tools will be able to use them to build a raft of different styles | of documentation sites. To put my money where my mouth is, I'm willing to contribute to this effort in any way I can. Be it coding, writing documentation, or evangelizing it.. What I'd like to see, is something like RDoc, which grabs formatted files (In Textile, Markaby, RDoc's variant,..), and emits documentation, from files that are in some way specified (a .document extension, maybe. Something that is convention over configuration, to make the transition as easy as possible). I think I can hack up a simple tool that demonstrates what I mean (after all, there's RedCloth, and Rake's FileList to accomplish what I mean). Once I have that running, I'm perfectly happy to hand it to anyone who's more qualified than me to work on this tool. | I'm looking forward to it. So am I. As a personal note: I did not mean to criticize you or your work, Dave. In fact, if I could find my copy of the Pickaxe again, I'd drag it along to have you sign it. It was a great help to me in picking up Ruby, and a very valuable reference for the documentation. Thanks for the effort by you and all who contributed to it. :) And I'd go nuts without RDoc to generate API documentation. - -- Phillip Gawlowski Twitter: twitter.com/cynicalryan ~ - You know you've been hacking too long when... ...you "woke up" this morning and thought, "I'll checkpoint here, snooze a bit more and then revert to checkpoint." A while later you go up another consciousness notch and realize that you hadn't checkpointed successfully ~ - "Oh, of course. I didn't have the keyboard." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkf7lycACgkQbtAgaoJTgL8WjgCgkdQ+8JTKfPj3FoYllVffiVDs DgkAn28WmpugQ/yH+LyqCpVDcZH0XUnp =RXLi -----END PGP SIGNATURE-----
on 08.04.2008 18:04
I agree about the API docs. There has been talk recently about working on them, but there are some snags we need to get around (I don't know that you've been privvy to those conversations or not but if not you should be :)). As an aside, I'm working on re-implementing RDoc using ruby_parser. It's in very bad shape right now (transitioning from using RDoc's CodeObjects stuff to ruby_parser), but you can monitor my work at http://github.com/jeremymcanally/docr . The basic plan is to get the parser/normalization stuff in place and tested this week. Then I'll try to put a really lightweight bin script/library in front of it next week. Most of the same code should work in that part with minor modification. Sometime in there I'll be extracting the markup stuff from RDoc into its own gem/library so it's more separated from the mainline DocR stuff. I believe I along with others have plans to hack in some additions to the markup to give it some more powerful structures. Hopefully when this is in decent shape, it will be a well-tested, nicely implemented Ruby documentation tool. --Jeremy On Tue, Apr 8, 2008 at 11:37 AM, Dave Thomas <dave@pragprog.com> wrote: > I said it's a hacky _implementation_. I believe the concept is just fine. > > of RDoc (maybe not, I haven't looked at RDoc itself, so my assessment of > > > > minimally documented (for example, having just API-level documentation). > sees a HOWTO file, include that. If it sees GUIDE, do the same. These are > > > Dave > > -- http://jeremymcanally.com/ http://entp.com Read my books: Ruby in Practice (http://manning.com/mcanally/) My free Ruby e-book (http://humblelittlerubybook.com/) Or, my blogs: http://mrneighborly.com http://rubyinpractice.com
on 08.04.2008 18:11
On Apr 8, 2008, at 11:04 AM, Jeremy McAnally wrote: > As an aside, I'm working on re-implementing RDoc using ruby_parser. > It's in very bad shape right now (transitioning from using RDoc's > CodeObjects stuff to ruby_parser), but you can monitor my work at > http://github.com/jeremymcanally/docr . Could ripper be used for this? Given that 1.9 has it built in, it would reduce dependencies (on of the goals of RDoc was to have zero external dependencies, and that still seems like a good idea). > > Hopefully when this is in decent shape, it will be a well-tested, > nicely implemented Ruby documentation tool. Are you talking to Eric, who's currently working on RDoc for 1.9? Dave
on 08.04.2008 19:12
On Tue, Apr 8, 2008 at 12:05 AM, Phillip Gawlowski <cmdjackryan@googlemail.com> wrote: > Austin Ziegler wrote: > | (Yes, Virginia. Most people don't need full-on Unicode munging in > | their code. It's necessary when you do need it, but most people don't > | need it.) > http://www.joelonsoftware.com/articles/Unicode.html > > I need it. Most of Europe needs it. Not to mention Arabia, Japan, and > everybody else not speaking English. You didn't read what I said. I said "most people don't need full-on Unicode munging." This is true. There are some cases where it's absolutely necessary, but most people just need to know that they're not going to screw up things when they work with Unicode. You can write Unicode-safe applications without needing full Unicode string munging. Easily. Most Rails apps should probably be doing exactly that. And yes, I do know Unicode. Maybe not as well as Tim Bray, but well enough to know what's actually needed and what isn't. (I just wrote an app that deals with UTF-8 Unicode strings; I don't modify them at all, so I've got a Unicode-safe app in Ruby because I'm not mucking with things that I don't need to muck with.) Joel's article is oversimplistic on this, really. I stand by what I said: most people don't need Unicode munging. But when you need it, you *really* need it and Ruby can fall down flat for you, pre 1.9. (And yes, if you look above, that *is* what I said.) -austin
on 08.04.2008 19:19
On Tue, Apr 8, 2008 at 7:40 AM, Thomas Kellerer <YQDHXVLMUBXG@spammotel.com> wrote: > Marc Heiler, 08.04.2008 13:24: > > [Unicode] > > > I need it. > > I keep on reading people that need Unicode, and in your case it may very > > well be true and for many others as well. > That's precisely the ignorant attitude that caused the issues we currently > have with differen character sets. I'm pretty sure that if computer systems > had been emerged from a non-english speaking country at the beginning we > wouldn't need to still fight character set issues (there are still too many > applications that even have problems with 8bit character sets) Unfortunately Marc didn't keep *my* quote which has a lot more important context than was kept. I never argued that people don't need Unicode. I said that most people don't need Unicode munging of their text. Think operations on the strings rather than the existence of the strings themselves. > I'm a newbie with Ruby and until I read this discussion I simply assumed it > would fully support Unicode "out of the box" especially given the fact that > is originates from Japan. I'm actually very confused (not to say shocked) > that there *is* a discussion if Ruby needs (or supports?) Unicode. > Unicode (and a relevant encoding such as UTF8) should be the *standard* for > all (new) programming languages and not an exception. No, they shouldn't. Yes, Ruby needs Unicode support. But Unicode has a big problem: legacy data. There's more legacy textual data than there is Unicode textual data at this point. That will change, yes, but it isn't so now. Languages that assume that their strings are Unicode (and make it harder to deal with legacy data) are much harder to work with for legacy data. Also, look at the Han Unification discussions regarding Unicode and you'll see why the lack of Unicode support from Japan through early this decade isn't surprising. Unicode isn't very friendly to Asian texts, in terms of storage size. It's not a big deal now that we're dealing with massive hard drives and our textual data is a minuscule fraction of our overall data storage (audio, images, video). Ruby 1.8 has limited (too limited, but there's good historical reasons for this) support for Unicode; Ruby 1.9 has good support for Unicode and it's getting better. History is good to know. It would have prevented this blogger from being ignorant. -austin
on 08.04.2008 19:20
On Tue, Apr 8, 2008 at 7:54 AM, Trans <transfire@gmail.com> wrote:
> Why is everyone getting so worked up? It's a critique.
critique |krɪˈtiːk| noun
a detailed analysis and assessment of something, esp. a literary,
philosophical, or political theory.
verb ( -tiques |krɪˈtiks|, -tiqued |krɪˈtikt|, -tiquing |krɪˈtikɪŋ|) [
trans. ]
evaluate (a theory or practice) in a detailed and analytical way :
the authors critique the methods and practices used in the research.
The only thing detailed about the blog posting is the author's
ignorance. There's no analysis, just mindless bashing.
-austin
on 08.04.2008 19:25
On Tue, Apr 8, 2008 at 9:15 AM, Thomas Kellerer <YQDHXVLMUBXG@spammotel.com> wrote: > Bill Kelly, 08.04.2008 14:51: > > > Unicode (and a relevant encoding such as UTF8) should be the *standard* > > > for all (new) programming languages and not an exception. > > Apparently not, as One Character Encoding to Rule Them All is not > > considered satisfactory to many people. > But Unicode/UTF8 would at least satisfy a *lot* more people than plain > ASCII or 8bit encodings (such as ISO-8859-x) > > Here's a long thread on the subject from the archives: http://tinyurl.com/ge2kp Please read the thread that Bill pointed you to. It explains a lot more than you'd think there would be. (And yes, that's a thread that I was heavily involved in.) > > Ruby 1.9 has much broader support for handling multiple character > > encodings. > Is there any release plan for 1.9? When it's ready. 1.9.0 has already been released and there's ongoing patches to make it better. Follow ruby-core if you want more information about Ruby 1.9. Matz still recommends Ruby 1.8.x for production because there may be other incompatible changes with Ruby 1.9, but most of the breakers should be fixed. But it's running on a (newish) VM, so it's something to work with for exercising the language. I think that when 1.9.1 comes out, it'll be much closer to production quality. -austin
on 08.04.2008 19:30
On Tue, Apr 8, 2008 at 11:02 AM, Phillip Gawlowski <cmdjackryan@googlemail.com> wrote: > M. Edward (Ed) Borasky wrote: > | Well ... I guess that depends on which docs you are talking about. > | There's plenty of documentation on Rails, three of the major GUIs -- > | Shoes, FXRuby and QtRuby -- have books in "print" on them, there are two > | major Ruby "cookbooks", the documentation on Ruport and RSpec is > | excellent, etc. > > I shouldn't have to buy a book (like the PickAxe), to get decent > documentation. A book should be one option, among many, to get to the > documentation. I'll elaborate on that in the next paragraph. Used to be that was the ONLY way to get documentation. -austin
on 08.04.2008 19:36
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Austin Ziegler wrote: | On Tue, Apr 8, 2008 at 12:05 AM, Phillip Gawlowski | <cmdjackryan@googlemail.com> wrote: |> Austin Ziegler wrote: |> | (Yes, Virginia. Most people don't need full-on Unicode munging in |> | their code. It's necessary when you do need it, but most people don't |> | need it.) |> http://www.joelonsoftware.com/articles/Unicode.html |> |> I need it. Most of Europe needs it. Not to mention Arabia, Japan, and |> everybody else not speaking English. | | You didn't read what I said. I said "most people don't need full-on | Unicode munging." This is true. There are some cases where it's | absolutely necessary, but most people just need to know that they're | not going to screw up things when they work with Unicode. Without Unicode support, a string operation in a non-English alphabet will work as expected. Any language with more characters in the alphabet that English, needs full Unicode support. | | You can write Unicode-safe applications without needing full Unicode | string munging. Easily. Most Rails apps should probably be doing | exactly that. Without Unicode support, you can't be Unicode safe. That's a tautology. Also: Rails rolls its own Unicode support. - -- Phillip Gawlowski Twitter: twitter.com/cynicalryan ~ - You know you've been hacking too long when... ...you are looking at an ASCII core dump of your OS project which has many O's and &'s in it (among other things), and you shout: "I see the problem. Orcs are attacking my demons." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkf7rNMACgkQbtAgaoJTgL9VggCgpgHK+7+yLEitYjlG0+71Ahkw otAAn2/jKZS3RmAnMp0sLcyYVGQQzREI =CSoC -----END PGP SIGNATURE-----
on 08.04.2008 21:06
Someone has suggested that but I haven't looked at it. I haven't gotten far with the whole ruby_parser port (it's in place but didn't take long to write), so switching to something would be fine. I'll look into that tonight then, since I didn't know 1.9 had it built in. I spoke to Eric via mailing list who said he wanted to use ruby_parser for a new RDoc, but ripper seems like a more logical choice to me. --Jeremy On Tue, Apr 8, 2008 at 12:10 PM, Dave Thomas <dave@pragprog.com> wrote: > reduce dependencies (on of the goals of RDoc was to have zero external > > extracting the markup stuff from RDoc into its own gem/library so it's > > Dave