F.Y.I
Not sure if you guys have read this article, I am going to re-post it here.
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.
Song Ma wrote:
F.Y.I
Not sure if you guys have read this article, I am going to re-post it
here.
"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.
Song Ma wrote:
F.Y.I
Not sure if you guys have read this article, I am going to re-post it here.
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
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, at 12:53 PM, Song Ma wrote:
F.Y.I
Not sure if you guys have read this article, I am going to re-post it here.
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.
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
···
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.
----
raise ArgumentError unless @reality.responds_to? :reason
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
···
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.
I have read most of the comments in this forum. Most of them are
helpful while some key points in the blog were not touched.
This is an example:
"In another incident in the same article, the original Rails author
admits that the original Rails code required about four hundred
restarts a day, or six to seven restarts per thread per day. Four
hundred restarts a day means four-hundred chances for a database
transaction to fail...."
The question is: Is the statement true?
Why should I concern this? Because my next project will be a
webgame(for thoese who don't know webgame, please visit www.travian.com).
I'm considering use Ruby on rails to develop this web app. For such
application, beging stable is extremedly important or the player will
leave with anger when data was lost, data being inconsistency or
something like that.
If the statement is true, then should I turn from rails to Pylons?
···
On Apr 8, 10:53 am, Song Ma <songm...@gmail.com> wrote:
[Note: parts of this message were removed to make it a legal post.]
F.Y.I
Not sure if you guys have read this article, I am going to re-post it here.
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>:
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.--
Avdi
--
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
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>:
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.--
Avdi
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
Rob Sanheim wrote:
F.Y.I
Not sure if you guys have read this article, I am going to re-post it here.
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.
···
2008/4/7 Song Ma <songmash@gmail.com>:
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 Tue, Apr 8, 2008 at 7:54 AM, Trans <transfire@gmail.com> wrote:
Why is everyone getting so worked up? It's a critique.
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * http://www.halostatue.ca/feed/
* austin@zieglers.ca
That, and that it'd be useful to have a backtrace that shows the lines
of code in question. Should be implementable as a postprocessor.
martin
···
2008/4/8 Rob Sanheim <rsanheim@gmail.com>:
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.
I have read most of the comments in this forum. Most of them are
helpful while some key points in the blog were not touched.
This is an example:
"In another incident in the same article, the original Rails author
admits"
Chris,
I understand you here. But what others should also understand - namely a
very few Python hackers, or other people that take a habit to jump
bandwagons - is that there is the language Ruby, and the framework Ruby
on Rails. I have nothing against RoR, but I have something against
people that put all things in the same bag. (I recommend people to read
more objective blogs like the one that talks about python and ruby
filling the same niche in a software ecosystem)
I guess anyone could rant for hours how horrible "language x" with
"framework y" is and I am sure if this is hyped again and again in a
blogosphere, some "language x" people would feel unhappy. (Not to excuse
the RoR folks, who hyped RoR a lot too.)
I am rather tired to see blog posts where the two (Ruby, and Ruby on
Rails) are intertwined and confused. Sure, one needs Ruby to use RoR,
but some people write as if the two are the same.
The "coolest" people are those that write "Ruby and Rails" - but they
clearly mean "Ruby on Rails", not Ruby and RoR ... makes you wonder if
they cant even get the name right.... I mean the homepage alone should
give one a clear hint about the name -> www.rubyonrails.org but may they
never visited. Anyway...
Now to your other point [about speed]:
If the statement is true, then should I turn from rails to Pylons?
You see, if people only use app solutions and ditch languages happily in
favour for app x or app y (which is a perfectly fine attitude IMHO),
then I would be in agreement that switching makes sense if you find
specific drawbacks in an app. You can even read a comment about DHH
praising php (for its ability for www usage), though this is of course
not my opinion, because I think php needs to go away... 
But lets be honest - often you just trade in one disadvantage with
another if you switch frameworks. And sometimes you trade in more
disadvantages.
RoR is also not the only web framework for Ruby.
(And Pylons not the only one for Python.)
I dont think anyone can recommend _YOU_ here to switch to a totally
different language if your use scenario already depicts a way to a
framework _outside_ of ruby. Because after all you will be writing
either python, or ruby code, right? So I dont think its fair to
recommend a framework in ANOTHER language - I mean, I would recommend
people to use ruby over python. Ok let's put it bluntly...
Go use Ramaze. http://ramaze.net/
But even more importantly, decide if ruby as a language is for you, or
whether you want to pick up python. Then these questions can more
readily be addressed - besides I believe python and ruby are still
filling a very similar use scenario/ecosystem. The common enemy should
be PHP and its www dominance
···
--
Posted via http://www.ruby-forum.com/.
Chris Guo wrote:
I have read most of the comments in this forum. Most of them are
helpful while some key points in the blog were not touched.
This is an example:
"In another incident in the same article, the original Rails author
admits that the original Rails code required about four hundred
restarts a day, or six to seven restarts per thread per day. Four
hundred restarts a day means four-hundred chances for a database
transaction to fail...."
The question is: Is the statement true?
Why should I concern this? Because my next project will be a
webgame(for thoese who don't know webgame, please visit www.travian.com).
I'm considering use Ruby on rails to develop this web app. For such
application, beging stable is extremedly important or the player will
leave with anger when data was lost, data being inconsistency or
something like that.
So, instead of examining solutions and deployment of applications
yourself, to see if they fit your need, you instead rely on what amounts
to hearsay to make your decisions?
"It must be true, I read on the internet"?
If you are that concerned, shouldn't you instead go and see for
yourself? (And yes, load-testing is difficult, if you want to simulate a
heavy load, I fully recognize that).
And AFAIK, Passenger, JRuby, and Mongrel pretty much solved the
stability issues. That may not be true for your situation, though.
- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
~ Life is full of surprises but never when you need one.
-- Calvin
"In another incident in the same article, the original Rails author
admits that the original Rails code required about four hundred
restarts a day, or six to seven restarts per thread per day. Four
hundred restarts a day means four-hundred chances for a database
transaction to fail...."
The question is: Is the statement true?
True, but there is some important contextual information that is missing.
Why should I concern this? Because my next project will be a
webgame(for thoese who don't know webgame, please visit www.travian.com).
I'm considering use Ruby on rails to develop this web app. For such
application, beging stable is extremedly important or the player will
leave with anger when data was lost, data being inconsistency or
something like that.
If the statement is true, then should I turn from rails to Pylons?
The information about the original Rails, running the original BaseCamp, requiring 400 restarts per day lacks a great deal of context, and context is important.
First, regarding the actual issue of the restarts, it is very important to note that this was the _original_ Rails (which was changing very frequently -- go back and check the logs for release announcements from back then; they were often only a few days apart), which was running on fastcgi.
Additionally, one thing that I have never seen mentioned is just what those 400 restarts a day really were. Since the code was running on fastcgi, were they just restarts originating in mod_fastcgi's management of external processes? If so, there's nothing really incriminating there.
Also, bear in mind that fastcgi is not the prefered way of deploying Rails apps these days, and in fact isn't even common. This information about restarts just isn't particularly relevant to today's Rails.
I know that Rails gets intermixed with Ruby in many people's minds these days, but consider, too, that Rails != Ruby. There are several good, capable ways of doing web app development using Ruby today that don't involve Rails at all, and which have different sets of strengths and shortcomings than Rails. If you are concerned, maybe you should be looking at some of the alternatives?
Kirk Haines
···
On Thu, 10 Apr 2008, Chris Guo wrote:
"In another incident in the same article, the original Rails author
admits that the original Rails code required about four hundred
restarts a day, or six to seven restarts per thread per day. Four
hundred restarts a day means four-hundred chances for a database
transaction to fail...."
The question is: Is the statement true?
The answer to that is both "yes" and "no". I didn't address it in any
of my comments because it was part of the section dealing with
"criticisms" provided in Zed's rant. They're completely out of context
and DHH *did* clarify the context in his own blog, IIRC. IMO, anyone
who relies on Zed's ghetto rant for their context is not worth
listening to. (Zed's ghetto rant is marginally worth reading on its
own, but it's not a suitable basis for others to base their arguments
on.)
Why should I concern this? Because my next project will be a
webgame(for thoese who don't know webgame, please visit www.travian.com).
I'm considering use Ruby on rails to develop this web app. For such
application, beging stable is extremedly important or the player will
leave with anger when data was lost, data being inconsistency or
something like that.
That won't happen.
If the statement is true, then should I turn from rails to Pylons?
Nope.
-austin
···
On Thu, Apr 10, 2008 at 1:25 AM, Chris Guo <guoxianghao@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * http://www.halostatue.ca/feed/
* austin@zieglers.ca
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)