Talk:Ruby (programming language)
About the status paragraph
I don't want to call this section "criticism", or anything like that, but it seems important, given my experience with Ruby so far, to place a limit on the unbridled enthusiasm which so many website express for tools that are not quite (yet) ready for prime time. Many of the tools fulfill about 90% of what a developer might needs, but none seem to be 100% yet. A single set of tools that can install on any OS and provide support for Rails, GUI, and testing has not yet appeared. Granted, many tools can be forced to work on varioius platforms by near-heroic build efforts. When these tools become, for Ruby, what Netbeans or Eclipse is to Java, or Visual Studio is to C#, then Ruby can grow into the big time. So in case any Ruby lovers are tempted to completely remove that paragraph, which I deem in advance may upset some, please help me find a way to keep sanity about Ruby's current status, as well as hope for it's future. If you disagree, please bring evidence here (or to my talk page) first.Pat Palmer 11:28, 11 May 2008 (CDT)
- Ruby is designed in such a way as to not require the existence of NetBeans, Eclipse or Visual Studio-style IDEs. The Principle of Least Surprise is such that you don't need large IDEs to write Ruby. With a language like Java, one gets so wrapped up in OO implementation clutter (interfaces, abstraction, factories and so on) that you need an IDE to mask that complexity. In Ruby, this is not as important, in my humble opinion. Most Ruby users prefer TextMate, vi/Vim or Emacs over Eclipse, NetBeans or IntelliJ. This is a feature, not a bug. If your language is so complex you must use a large IDE, you lose flexibility. You become tied to that IDE, to whatever platforms run that IDE and so on. (The same is true for Python, Perl, PHP, C and many other languages.) –Tom Morris 11:19, 8 August 2009 (UTC)
My critique from Rationalwiki
Paul Wormer asked me to post this here as well as on RationalWiki:
In the thread we link to on (RationalWiki's) WIGO, Pat Palmer claims the closures section of the Ruby article is significantly better than the Wikipedia article.
But look at it:
- A full discussion of closures deserves an article of its own but cannot be avoided in any serious discussion of Ruby, which encourages their widespread use.
This is true, but it's also completely empty verbiage. Okay, you want a full discussion of closures, just link to an article on closures rather than saying that the topic deserves an article of its own. It is a wiki, gosh darn it, make the article.
- The definition and importance of closures has been widely debated with all the politeness for which the computer industry is known.
Why do I care if the debate around the use of closures has been contentious and impolite? I either am going to use closures because they satisfy my technical needs or I'm going to say "ooh, that's a bit too complicated and scary, I'll stay away".
- The learning curve for closures appears to be steep enough to cause some dissonance with the common claim that "Ruby makes programming easier".
Is there a source for that...?
The section doesn't actually provide an example of the syntax or use of a closure. It says this though:
- The often-cited example of closure use in Ruby is the .each procedure, which provides a more convenient way of iterating through collections than conventional looping. But sceptics counter that even Java now provides its own very simple syntax for iterating through collections (i.e., the "enhanced for loop").
If you don't know Ruby, saying there is a ".each procedure" (method, technically, but let's not quibble) but not showing how that works in practice doesn't really illustrate what makes .each different from a Java-style for loop. And saying that the benefits of a Ruby .each method have been matched in Java because of the enhanced for loop is a conflation of syntax and semantics. The semantics of closure-based iteration are different. The syntax isn't the interesting bit.
The point is that you need closures in order to have higher-order functions, in order to do chained array processing with things like map, filter (called 'select' in Ruby, much to my daily annoyance), and fold functions.
- Ruby advocates often struggle to illustrate the potential power of closures, which formerly were not required learning for a majority of programmers (to whom they were usually not available anyway).
That last clause is weird. Closures have always been available to programmers if said programmers choose to use languages that support closures.
Elsewhere in the Citizendium article:
- The power of Ruby's networking libraries, and its support for SOAP-based web services, equals or surpasses those in Java or C#.
That seems like a ridiculously bold claim to make without any sources.
- Like Visual Basic's default behavior, Ruby tries to infer the type of variables from the context, freeing the programmer (in many cases) from needing to declare the type explicitly upon first use. This is the opposite of what Java and C# do (they use so-called strong typing, which requires every variable's type to be known before the variable can be used).
There's some fuzzy thinking about type going on here: it is true that Java and C# use strong typing. It's not true that in C# you have declare the type before using a variable (since the introduction of the 'var' keyword in C# 3.0). Strong typing is not the same as static typing and static typing is not the same as required declarative type annotations. Ruby is strongly typed, and so is Java.
In Ruby, you never have to "declare the type explicitly upon first use", so it's not the case that you are freed "in many cases", which would sort of imply that there are some cases where you aren't freed from the requirement to explicitly declare types.
Like most people, the author of the Citizendium article isn't thinking very clearly about type systems and confuses static/dynamic with strong/weak with declarative/inferred type.
But I'm no expert. I'm just some guy who writes code. —Tom Morris (talk) 10:57, 14 June 2013 (UTC)
I hope that helps. —Tom Morris (talk) 17:34, 15 June 2013 (UTC)