Cliff Wells wrote: > On Thu, 2006-08-24 at 04:04 +0000, Tim Roberts wrote: > > Cliff Wells <[EMAIL PROTECTED]> wrote: > > > > > >But there are interesting things in Ruby (and Ruby 2 should take care of > > >lots of warts Ruby 1.8 has) that Python could learn from. All-in-all, > > >Ruby is mostly as good as Python in most ways and better than Python in > > >a couple key ways.
The big difference between Ruby and Python is the lifecycle phase that the languages/systems are in: Ruby arguably has room for a lot of basic improvements in the architecture of the virtual machine and presumably has a list of "must add" features that cover gaping holes with respect to certain audiences [1], whereas Python has been around for ages and has covered most of the critical gaps in the feature list (although we can always suggest things which bother our own part of the community). Whereas the Ruby people merely have to agree on how critical their missing features are and to move in one widely agreed direction, the Python people face a tougher choice as to what should be done next; strategies include a tidying-up exercise to make the language more coherent, a complete reimplementation, deep modifications to the runtime, the introduction of radical new semantics. The fewer obvious issues that a language has, the less energy there is in the community to deal with those issues thoroughly, I think. I guess the Perl community chose a bold new direction in line with the observation that a big vision can inspire much more in people than lots of incremental changes to an existing vision, but the energy required to follow through on such a vision can be immense. In addition to all this, a large existing community is more likely to want larger benefits for smaller levels of disruption because of the amount of existing code. Thus, the available energy for change is less in a mature project than in a growing project because people have to constantly monitor the breakage in their existing investments in the language. > > ...but you can't READ Ruby code. > > Yeah, that's one of the big reasons I haven't seriously considered > trying it. It's expressive, got interesting features... and appears > unreadable to me. I'm usually pretty good at deciphering most > languages, even if I haven't used them before, but Ruby is one of the > exceptions. My feeling is that I'd rather learn more about Lisp or Scheme than Ruby - the benefits are greater and for me Lisp and Scheme increasingly have the edge on readability. Perhaps I'm just not "tuned in" to Smalltalk-style syntaxes. > This brings us back around to the web framework debates. For many > people Ruby "fits" their brains and for others Python does. I think > frameworks are similar. I tried Django and while I thought it was a > great product, it simply didn't "fit" how I think about that problem > domain. I thought that the most interesting thing about Django was the URL mapping strategy it employs, although you have to be fond of regular expressions to really appreciate it, I think. The template and persistence mechanisms used have the principal advantage of just being there in the same package when compared with other solutions, and I don't think they'd have many fans if they were just some random projects available from the Python Package Index. > TurboGears on the other hand did, and really, it helped clarify > a few things I had vague notions about. I think we'll do better not > trying to shoehorn people into one or the other. The goal is to provide appropriate solutions for particular problem cases, especially common cases like database-backed Web sites, rather than choosing something which only does a particular flavour of database-backed site and then claiming that it's a silver bullet. I've written a number of Web applications for my own use, and many such applications either don't use a relational database or use it in a way that is completely orthogonal to some relatively simple object-relational scheme. Some of these applications are admittedly simple, but having to create various tables in relational databases as an offering to some framework deity is pure unnecessary overhead that should suggest, at least to the more objective among us, that any solution requiring such baggage is perhaps not always the most optimal. Paul [1] http://headius.blogspot.com/2006/06/unicode-in-ruby-unicode-in-jruby.html -- http://mail.python.org/mailman/listinfo/python-list