We already have -- and without great fanfare -- Lua, JavaScript, C# (MonoTouch), et al. This seems somehow different.
We already have -- and without great fanfare -- Lua, JavaScript, C# (MonoTouch), et al. This seems somehow different.
Douchebags are everywhere and it's sort of silly to paint an entire community with a broad brush. We're doing lots of good things, too, despite our own share of jerks.
Culture aside, simply technologically, Ruby has nothing significant to offer as compared to the many existing languages and technology stacks, especially those pushing forward language and runtime research. The only argument for Ruby here seems to be opening the market to developers unwilling to move beyond it.
- Despite the opinion clearly being unpopular here, I stand by it: the ruby community is toxic-at-best, and totally technogically uninteresting.
Individual Ruby developers may be very nice people, but that doesn't make the technology any more notable or novel, and doesn't change the general tenor of the Ruby community, which seems to be driven by larger than life personalities and a general lack of solid applied computer science.
But I also want to respond to the somewhat more interesting portions of your argument - is ruby "technically interesting", "notable", "novel", and/or lacking in "solid applied computer science", and to what extent do those things matter? I think it is technically interesting because you can do much with little, notable because it combines the elegant OO of Smalltalk and the weak functional programming of Lisp with an intuitive syntax reminiscent of though dissimilar to Python, not at all novel because it prefers to embrace good ideas from its predecessors, and quite thankfully lacking in leakage of hard computer science into mundane programs. It is wrong for many jobs, but right for many others, and for that it is interesting. It is one of a multitude of languages for which the same can be said.
2) Pure command-line interface that works with text files, that makes it work easily with any toolchain. Seems that GNU Smalltalk is the first version which only recently did not require an IDE.
3) All the basic and most useful objects are literals. Enumerators are stupid-easy to use.
4) Much lower learning curve than Smalltalk.
5) Adopts some useful Perlisms into the language mix.
6) A large focus on unit testing, and TDD. And they are very easy to use.
Programming is becoming a huge part of everyone's lives. Languages that ease the learning of CS and lower the barriers to entry are very welcome. And some of them also happen to be great business tools.
I don't think many here are arguing that Ruby is particularly interesting technology-wise. Amongst languages, well, it isn't particularly. But the baseless FUD about the "culture" or the "community" is unnecessary.
Its driven from the top, largely because most mature programmers that would provide a counter to community immaturity have no reason or need to use Ruby.
Things like "the [whatever] community is toxic-at-best" or "I don't relish the notion of [whatever] culture" are opinions that in Ruby's case are based on the behavior of a minority. It's like if people say all C developers are "fat bearded men." Quite a few are, but it's an unhelpful generalization.
If the Ruby community had a general atmosphere or a policy of encouraging sexist or unprofessional behavior, I'd let these remarks slide. But it doesn't. The articles and rants that make it to HN are usually the controversial parts because that's more likely to get votes on social voting sites like HN, alas.
And unsurprisingly, Linux is a terrible overall example of quality kernel development and design.
> If the Ruby community had a general atmosphere or a policy of encouraging sexist or unprofessional behavior, I'd let these remarks slide. But it doesn't.
Except that the only times I've ever had to deal with (or hear of, third-hand) a general atmosphere of sexist, unprofessional behavior in technology has been in relation to the startup community in general, and the Ruby community in particular.
You just described the majority of Ruby coders I've ever worked with. (mentally scrolls work history roster of Ruby devs...)
Yeah, in fact you've just described all of them.
I'm sorry your sampling of Ruby coders has been so poor, and I'm sure you could present examples to defend your prejudice. I know the stereotype you're talking about. I haven't worked with one of them, but I know they're out there.
Nevertheless, it seems to me you've become the thing you claim to despise: insular and closed off to experiences that would contradict your dogmas.
> Nevertheless, it seems to me you've become the thing you claim to despise: insular and closed off to experiences that would contradict your dogmas.
That would be the opposite of "polyglot". I can find value in Clojure's concurrency design, Python's scientific community, Scala's marriage of OO and functional, F#'s modernization of ML environments, C#'s language design, ObjC's UIKit/AppKit libraries, C's propensity for close-to-the-metal optimization without dropping to assembly, Haskell's lazy evaluation and functional purity, OCaml's mixture of pure functional with mutable state, Erlang's micro-thread actors, Java's virtual machine, Smalltalk's REPL-on-steroids, lua's JIT.
However, almost nothing from Ruby. The technology there is almost totally uninteresting -- it's just yet another imperative scripting language with a poorly designed runtime -- and the community, unlike Python's, doesn't make up for it. In fact, that Ruby community is one of the primary things that seems to give technologists a bad name outside the technology industry. When I hear tales of sexist conference behavior, inappropriate language in presentations, and outright bad wheel-reinventing technology, the tales are almost always tied to either Ruby, youthful startups, or both.
So -- no, I don't look forward to them joining the rest of us in the iOS space.
Again, I'm sorry your poor sampling seems to have traumatized you into an an irrational, confirmation-bias myopia, but my experience has been very different.
You like C#'s language design? Me too. I especially like its adoption of Ruby-ish idioms like lambdas and the LINQ collections DSL, and the C#-on-Rails framework goodness of ASP MVC.
"it's just yet another imperative scripting language with a poorly designed runtime"
Sweet Lord what an ignorant statement.
Here's the thing that Ruby does astonishingly well that none of those others you mentioned can do: metaprogramming. None of the languages can touch Ruby for its ability to consolidate expressive, DSL-like idioms that eliminate code duplication (and therefore bugs), increase communication and application logic clarity. This is where Ruby really eclipses everybody else, in its ability to create frameworks, DSLs and micro-solutions that drive interesting and expressive conventions that drastically reduces the time it takes to code and deliver a feature out the door.
This is why frameworks like Rails and Sinatra have been so successful with polyglot programmers like the ones I work with, and why new frameworks like Merb and Padrino keep popping up and offer new idioms and expressive possibilities. It's just a creative, open language to work with, that allows a creativity and level of surprising possibilities that have real business consequences. At the application level, where code conciseness and time-to-delivery are at a premium, Ruby simply shines.
You mention LINQ as somehow deriving from Ruby -- it doesn't, it derives from set theory, relational algebra, and some very careful consideration of how to model those in a typesafe environment. You fail to mention that LINQ is type-safe, which is an enormous advantage to its use compared to traditional approaches of modeling set theory / relational data problems, and has value for things well beyond databases or querying simple data structures, eg: http://msdn.microsoft.com/en-us/data/gg577609
You claim lambdas as Ruby-ish idioms, and yet totally ignore where "lambda" derives from: lambda calculus. This is not a Ruby-ism, and Ruby discards much of what is of value in lambda calculus: http://en.wikipedia.org/wiki/Lambda_calculus#Lambda_calculus...
Ruby is a "me too" on those fronts, and not a particularly novel one.
Of course. No one, especially not Matz, ever claimed Ruby was novel. Why should I care whether a language feature is new when I have features to ship? What you seem to be dogmatically, blindly ignoring is that Ruby's peculiar amalgamation of existing techniques, borrowed from (standing on the shoulders of) Smalltalk, Perl, Python, certain aspects of Lisp and others, created an expressiveness with those idioms that invited widespread adoption that Smalltalk and Lisp in all their glory only ever dreamed of. Innovation was the least of Ruby's concerns, and it's irrelevant to the conversation at hand.
Type-safety seems to be a big thing for you. This may seem to be an enormous advantage to you, and I wish you well. I personally think type safety is the most overrated language feature in CS history. In my crankier moments I'd say it's essentially a compile-time unit test and refactoring/code-browsing crutch for IDE-jockeys that don't test their code. In my less-cranky moments...I'll probably say the same thing. And that's after a decade and an half in Java and C#, not quite a decade in Ruby. To me, type safety imposes far more overhead than it's worth -- generics, abstract classes, interfaces, all irrelevant and basically built-in and implicit in dynamic environments like Ruby. But that's another digression. Suffice it to say, in my entire software career I've kept track of the sum total of bugs I've fixed related to passing the wrong type to a method, or receiving a wrong type from a method, and that number, to date, is (whirring, calculating sounds): 0. Total number of times I wished I had a refactoring shortcut for "extract interface", "rename method", "introduce parameter object" in a Ruby environment: 0.
I've not written a line of Scala or F#, so I can't speak to those, but the notion that C# could construct a DSL a fraction as concise and expressive as Ruby could is absurd. I like C# quite a bit, but let's not be ridiculous.
And I never claimed that LINQ or C# lambdas were derived from Ruby, just that they were Ruby-ish. Clearly someone in Redmond is watching Ruby and Rails. ASP MVC directly borrows Rails idioms, and many aspects of LINQ seem to have at least had Ruby in view, like 'Select', etc., even down to using hashrockets, although in a different manner. I certainly wouldn't be the first to point these parallels out:
http://nerdfortress.com/2008/06/12/c-30-encourages-rubyisms/
http://haacked.com/archive/2007/05/24/ruby-like-syntax-in-c-...
http://blog.troyd.net/PermaLink,guid,c4d8233b-77f4-4660-91a9...
http://rubysource.com/c-dynamic-features-helped-me-learn-rub...
This is the classic response. It's also ridiculous. It's not just a matter of "passing the wrong type", it's a matter of using the type system to express higher-level constraints that make it impossible to introduce bugs in a complex system -- bugs more fancy than "I passed a string when I should have passed an int".
Of course, passing a string when you should have passed an int happens with regularity, too, and claims otherwise are a lie, especially if you don't spend a ridiculous amount of time pretending to be a compiler by writing extensive unit tests that would be totally unnecessary if you had one.
> And I never claimed that LINQ or C# lambdas were derived from Ruby, just that they were Ruby-ish. Clearly someone in Redmond is watching Ruby and Rails.
What? I ... no. I point out a 1965 paper on lambdas and you claim MS R&D is watching Ruby? You're comparing LINQ -- which implements a coherent model of relational algebra and set theory -- to Rails?
Ruby didn't pioneer these things, didn't add anything novel to them, implemented inconsistent models of them, and can't take any credit for them.
It's classic because it's true.
"bugs more fancy..."
Fancy? Fancy?? (thumbs through Knuth and SICP looking for "fancy" bugs...looks for "fancy" anti-pattern...)
Nope, not there. Consistent with my own experience, rather than anecdotal FUD (Fanciness Uncertainty and Doubt), after years and years and thousands and thousands of lines of code in type-safe and dynamic environments, I've yet to encounter a significant issue that would have been caught by a type-safe system.
"...especially if you don't spend a ridiculous amount of time pretending to be a compiler by writing extensive unit tests that would be totally unnecessary if you had one."
Complete. Nonsense. I write the same unit tests in RSpec and TestUnit that I write in NUnit and JUnit, and far, far, FAR, fewer lines of code for the same coverage in Ruby. I do NOT write extra unit tests because -- holy crap! I don't have type-safety!
No, type coverage is a side-effect of a well-written unit test. No extra effort whatsoever is needed.
"I point out a 1965 paper on lambdas and you claim MS R&D is watching Ruby?"
This is starting to sound like a debate between a CS student who just got out of a Set Theory final and just figured out who CAR Hoare is, and someone who is just trying to ship features and make sure his company makes money. Yes, I have a decent handle on lambda calculus (thanks for the Wikipedia link) and I know the differences between Ruby's collections DSL and LINQ, having used both pretty extensively.
It doesn't matter. The notion that MS is not paying attention to the most influential application framework of the last 10 years is a ridiculous idea. The fact that Ruby didn't pioneer lambda calculus is...just as obvious as the fact that C# didn't pioneer VMs, GC, generics, etc., and can't take credit for those either, and just as much of a non-sequitur.
I'm afraid this might come down to a philosophical difference for you.
That's funny, because to me it seems you've taken a few of them at their word about what "the Ruby community" is like (or even the existence of a singular one in the first place).