Ruby Is Scary

 

Why is Ruby on Rails all the rage at the moment, and why do a lot of .NET people seem so defensive? 

Undoubtedly, there is a buzz in development right now, things are changing rapidly, possibly more rapidly than they have for a good number of years. New languages are sprouting up all over it seems, with PHP and Python gaining massive popularity, F#, Erlang and Haskell suddenly being talked about as mainstream, Javascript evolving beyond that thing that makes "onClick" work in your browser, and Ruby (and especially Rails) becoming "flavour of the month" for web development. Ruby is even starting to invade the .NET mainstream space with evolutions like Rake, Cuke4Nuke and Nu muddying the divide that there once was. We even have IronRuby to make Ruby run on .NET

And yet, many .NET people seem defensive, as though their safe world was being invaded by a parasite.

I find this quite odd. As a developer who has been around for far too long, I have seen more than my fair share of languages and platforms come and go, none of them was perfect, and I would venture to say none of the ones we have now are either.

It would appear that a large proportion of the uncertainty is in the C# development 'community', though that may be as I don't really frequent circles that use VB.NET (and I'm fairly sure they are still busy being defensive about C# and probably haven't noticed that's *so* last year :) Somehow the introduction of new ideas is rocking the C# type safe world.

Some people seem to be concerned about Ruby itself, some seem to have concerns about the lack of a statically typed safety net, and some seem to think that "the Enterprise" needs something more professional than toys like Ruby and Rails.

To The Static Typing Stalwarts

Yes, it's nice to have that compile time checking that static typing gives you, it gives us all a warm sense of fuzziness knowing that the compiler told us that this code would run just fine when we dropped it onto our web server.

Yes, we appreciate the great benefits that this has for things like Intellisense and for easily discoverable APIs, and even for automated documentation.

And yet, none of these things seem to bother the Ruby (and PHP/Python/Javascript) crowd too much. Why is that?

I would suggest that the static typing benefits a language like C# brings are illusory to a large degree. 

The compiler isn't telling us that this code will run correctly at all, it's actually just telling us that the CLR won't throw our code out before the application even starts up - but correctness is so much more important than that. The safety net static typing provides us with is just one part of the equation, and possibly the least important part - we really should be enforcing correctness upon our code.

Correctness is verified by good automated testing, and static typed languages start to come back and bite us here - we trade that compile time security blanket for a much harder experience testing our code. Sure, tools like NUnit, xUnit, Rhino Mocks, Moq, SpecFlow, StorEvil et al ease away our pain, but still our application code is littered with constructs that are pretty much there to support SOLID (or SOLID is required due to the constraints of type safe OO languages), and they become most obvious when we start testing in languages like C# (I am *so* over Interfaces, IoC, Covariance, Contravariance and Generics !

The testing experience in Ruby is a world apart from in C# and .NET, it is just easy and simple ... so simple in fact that it is almost harder to not write automated tests in Ruby - and that's how it should be. In C# testing is often convoluted, complex, fragile and just plain hard work - I can't think of the last time a C# developer described automated testing as fun ... and yet, in Ruby, it just seems like FUN!

And yes, Ruby without automated testing leaves you open to all kinds of runtime errors that C# just wouldn't - so in Ruby, you just make sure you test, and not only test your code will run, but also test it will run *correctly* - there is no safety net, but the trade off is you are ensuring correctness of code, not just compilation of it.

Intellisense, sure it's nice, but as RubyMine and even Visual Studio (under Javascript) demonstrate, you can do some form of Intellisense in dynamic languages, you just can't always be certain what may or may not be available - but this is getting better. And honestly, is discovering which method you are meant to call though typing "." all that great an idea anyway? Shouldn't you as a competent developer know *in advance* what you wanted to call, rather than guessing it as you type?

To The Enterprise 

Sure, Ruby doesn't have the track record that C# has, nor does it have the exposure, or market reach, or backing of a company like Microsoft.

But, is that what is really important?

I would bet that a large part of the appeal for statically typed languages  in the "Enterprise" is actually a need to deal with a much lower skilled developer base overall. Compile time safety means that your developers don't have to be top notch, the compiler can make up for their weaknesses (and in the case of C# and .NET, Visual Studio 'drag and drop' tooling is trying to make up for a lot of the rest)

Enterprises tend to see dollars and cents, not people and value. So anything that lets them hire cheaper developers to churn out more product must be good.

Again, I would argue this is a false economy. Sure that team of 30 developers may give you a warmer fuzzier feeling inside than a team of 4. And sure, the quantity of code those 30 can type out will probably be much more.

But this misses some real issues around productivity and value - a 'good' developer is 10x as productive as an 'average' developer, and more importantly, the 'average' developer will never be able to create the same quality level as the 'good' developer, even given a near infinite amount of time. No matter how much time a hobbyist painter spends with oil and canvas, he will never create a Leonardo. And as a Jackson Pollock will amply demonstrate, sometimes less is more.

So are you measuring bodies or productivity? Surely it is the end result that matters, not the comfort factor of people looking busy.

And, when you get a good developer, and let them have the freedom of a dynamic language, they can spend less time fighting compile time safety and language constructs that exist almost solely for that type safety, and more time concentrating on business logic and the end product.

In fact, the best argument for why Ruby is not suited to the Enterprise is ... the Enterprise probably already has a large investment in one platform and one core language (or maybe two), and the cost of retraining all those developers, support staff, renegotiating supplier contracts, etc etc is just disproportionately expensive. Lethargy is rife in the Enterprise, and monoliths take a long time to move - sure it's easier for startups to hop on new technologies and run with them, and often it's why they quickly challenge the status quo. This isn't really a technical issue, this is a political and management one.

Maybe Ruby and Rails will gain traction here, maybe not. Things like functional programming are certainly starting to grow roots in financial services, and things like Javascript are prevalent in web apps in the Enterprise so maybe dynamic programming in things like Ruby isn't so far off. It just takes one small faction to show how well they solved a particular problem with a new language or platform to plant that thought.

So Should We All Switch To Ruby Now?

Of course not, and maybe this is what the defensive people in .NET miss. The Ruby people aren't saying "you guys have it all wrong, convert now", they are just saying "hey, I found a really cool way of solving this problem".

Ruby is about choice, it's another tool in your arsenal. As are Javascript, PHP, Python, Erlang, F#, Java, Groovy, C++ and a host of others.

There is no "one right path", so let's all stop pretending there is. 

We don't need to be defensive about any one language or platform, unless we are so unsure of our abilities as developers that we cannot learn and adapt - and if that is the case, maybe a new career is a better idea?

As my recent presentation at DDDSydney said ... My Objective Today was to make you think ... "Maybe There Is A Better Way" - because it would just be depressing to think we are already doing things the best possible way.

 


Posted 07-31-2010 2:55 AM by Jak Charlton
Filed under: , ,

[Advertisement]

Comments

KevDog wrote re: Ruby Is Scary
on 07-30-2010 10:35 PM

--I would bet that a large part of the appeal for statically typed languages  in the "Enterprise" is actually a need to deal with a much lower skilled developer base overall.

I'm pretty sure this is the biggest piece of self-serving bullshit I have ever read in my life.

Horses wrote re: Ruby Is Scary
on 07-31-2010 2:36 AM

Rails is flavour of the month?  Is it 2006 again?

Not Webominator wrote re: Ruby Is Scary
on 07-31-2010 3:46 AM

"The compiler isn't telling us that this code will run correctly at all".

You are building castle on false statement. None expects from static typing that compiler will produce false statement.

Smart usage of compiler checks allows to reduce number of bugs.

Arguing with such nonsense statements, won't convince to Ruby (non static) language.

Dynamic languages have some nice things, but try better to describe them i some reasonble way.

Jak Charlton wrote re: Ruby Is Scary
on 07-31-2010 4:15 AM

@NotWebnominator

>>Smart usage of compiler checks allows to reduce number of bugs.

And testing won't?

@KevDog

Thanks :) I do try hard!

David Tchepak wrote re: Ruby Is Scary
on 07-31-2010 4:46 AM

@Not Webominator,

"The compiler isn't telling us that this code will run correctly at all".

I don't think this is a false statement. Compiler checks are useful for finding typos, syntax mistakes and type violations, but they don't tell you the code is doing what it expects. You need tests* for that.

And if you're going to be writing tests around everything anyway, how much help is the compiler really giving you? Your tests will pick up syntax and type errors just as well, but with the added benefit of checking the code does what you expect. In this case all the compiler is giving you is a whole lot of extra ceremony to go through.

Cheers,

David

* tests include exploratory tests, unit tests, acceptance tests etc.

mob wrote re: Ruby Is Scary
on 07-31-2010 10:25 AM

Xenophobia and FUD are rampant in this world, even when it comes to programming languages. :)

Rob Reynolds wrote re: Ruby Is Scary
on 07-31-2010 1:57 PM

"Ruby is about choice, it's another tool in your arsenal. As are Javascript, PHP, Python, Erlang, F#, Java, Groovy, C++ and a host of others."

This closely ties to what I've been saying for awhile now. Ruby is another tool. Just like C#. Use them where most appropriate.

This is a great post man, although I can't say I agree with every point. I think you are ruffling the feathers of the language religious types.  Nobody likes to be made uncomfortable IMO, and that causes people to lash out (no matter what the honest truth is).

Awesome!

DogKev wrote re: Ruby Is Scary
on 07-31-2010 2:21 PM

@KevDog - feel threatened much?

Dan Martin wrote re: Ruby Is Scary
on 08-01-2010 1:00 PM

That last section sums it up perfectly. Anyone who gets pissed off when the Ruby/C# topic comes up needs to take a deep breath, and then read that last section.

Not Webominator wrote re: Ruby Is Scary
on 08-01-2010 1:19 PM

"And testing won't?"

In both cases you have to write functionality.

In strong typed world like you mentioned those "tests" are "written" by compiler/language

:-)

In small teams (2-3 people) with up to medium projects dynamic languages can be OK.

In both cases compiler is used. Why not treat compiler as Your friend, as your first defence?!

Not Webominator wrote re: Ruby Is Scary
on 08-01-2010 1:26 PM

"David Tchepak":

I completly agree! Using test is must! I'm only saying that you can treat compler as your friend. It can be your first defence agaings those ugly bugs! In both cases you compiler code then run tests.

Fir example: if one person writes component that has some expectations an it is possible to code those expectations using kind of stron typed language elements - why not use it! You will write additional tests, but why not use compiler in a good way - your way :-)

I like dynamic languages to "DYNAMIC" part of your applications. Write code functionalityin stron typed, well tested way - almost bullet proof. Then allow to use dynamic languages to configure or finishe defining rest of application that changes more frequently (due to law changes, customer vision changes or their needs).

Why not?

I could not imagine write whole .NET in dynamic way and debug thousands stack traces because soem deep call has expectation on something that I've forgeot to type.

Not Webominator wrote re: Ruby Is Scary
on 08-01-2010 1:30 PM

Oh! I've forgot mention that in "Webelopment" solutions, dynamic languages are differnet story than in other pages. It is because of nature of mixing loosly typed page content and underlying data.

From compiler persoective (X)HTML is just text - compiler donesn't case about renderint and how it looks.

In context of ASP.NET written at the top of page, your statement can be justified. But please make additional statement about locality (to Webelopment) of your observations. That would be fair and event I will agree with You!

Remco Schoeman wrote re: Ruby Is Scary
on 08-01-2010 1:43 PM

"Compile time safety means that your developers don't have to be top notch, the compiler can make up for their weaknesses"

"...let (the smart programmers) have the freedom of a dynamic language, they can spend less time fighting compile time safety and language constructs that exist almost solely for that type safety, and more time concentrating on business logic and the end product."

And they have write more tests and runtime checks to ensure correct behavior themselves.

It's the law of conservation of  misery.

The work just pops up in other places.

YMMV as always, depending on what you're trying to do.

Jak Charlton wrote re: Ruby Is Scary
on 08-01-2010 5:24 PM

@Remco

>And they have write more tests and runtime checks to ensure correct behavior themselves.<

You have to write *exactly* the same number fo tests either way (if you are responsible) - and in fact, due to the way Ruby works, you will probably write less tests (as BDD/integration tests are so easy in Ruby you tend to use them over TDD often)

Ben Hyrman wrote re: Ruby Is Scary
on 08-02-2010 9:05 AM

Remco, are you saying that you don't write unit tests to assert that your logic is true? A compiler can't catch logic errors.

And, I think once you started playing with RoR a lot more, you'd find that you don't really miss type safety.

Aside: duck typing in Ruby: blade.nagaokaut.ac.jp/.../100511

Steve wrote re: Ruby Is Scary
on 08-02-2010 11:19 AM

I wrote something very similar on my blog this weekend actually, only to come across this today.

Your Enterprise section is pretty much spot on.  Working for a large company, you often have the "hey, you know you could probably replace those 50 onshore and 200 offshore developers with 10 really good ones" conversation with senior management about once a month, but they tend to laugh it off pie in the sky thinking.  I mean, if it was that easy, they'd have done it already, right?  

Alex Simkin wrote re: Ruby Is Scary
on 08-02-2010 11:48 AM

"because it would just be depressing to think we are already doing things the best possible way."

It is depressing to think otherwise, so the whole thing is just depressing.

Juergen Brendel wrote re: Ruby Is Scary
on 08-02-2010 1:54 PM

Replace "C#" and ".NET" with "Java" and the article remains correct. You can also replace "Ruby" with 'Python" (Jython is a Python interpreter written in Java and thus runs on the JVM).

We wrote RESTx (http://restx.org) - a very quick way to create RESTful web services - in Python/Jython: Component authors can chose to write their components in Python or Java to (a) allow them to use the language that best fits the problem and to (b) cater to developers of different skill levels.

steven wrote re: Ruby Is Scary
on 08-02-2010 10:05 PM

my problem isnt with the lack of type control, it's with the language itself.

it is far too confusing and has too many special characters.

Jak Charlton wrote re: Ruby Is Scary
on 08-02-2010 10:35 PM

@steven

C# or Ruby has too many special characters?

(I would say C# noise and ceremony swamps the language, but you may think the reverse)

steven wrote re: Ruby Is Scary
on 08-03-2010 1:46 AM

@Jak Charlton

Ruby has too many.

But then again, I come from a Java background (which ofcourse has it's own share of problems)

davi wrote re: Ruby Is Scary
on 08-03-2010 2:53 AM

I think this situation is the same as with databases.

A lot of new DB came out in the recent years which tries to beat SQL. Sure, SQL is not perfect, and it is quite old now, but millions of people used and tried to optimalize it. Enterprise world won't change to mongoDB in these days for example. Maybe they will. But even if mongoDB clearly works better to a single case, it doesn't matter.

And that's the case with C/C++/C#/Java/...'s OO world IMO.

And that mentioned "good" developer will solve the case under static typing languages as well with ease.

JduP wrote re: Ruby Is Scary
on 08-03-2010 2:55 AM

All i have to say is: "Be water, friend."

Joe wrote re: Ruby Is Scary
on 08-03-2010 11:19 AM

While I understand and somewhat agree with some of your points you made here, I have to say the it is kind of missing a point.

All this talk about the compiler is honestly just bs.  All languages mentioned go through some form of compiler and that compiler will stop the execution of said script/program when it's syntactical checks have failed.  Responsible programmers will write appropriate unit tests for their programs despite the language used.  

Saying strong-typed languages breed less-than-good programmers is just a fallacy.  There are probably just as large of a percentage of bad Ruby, PHP and Python programmers out there as there is C#, C++, C, etc programmers out there.  Strong typed is just a constraint of the language that your using.  It is one more thing that particular language's compiler will automatically catch in it's checks.  Using said language doesn't make you a bad programmer.

The big statement I will agree with you on is "There is no "one right path", so let's all stop pretending there is." on forward.  Use the best tool for the job instead of using a hammer for everything.

I quite often switch between C# and PHP with the occasional Python and Perl scripts thrown in for good measure.  They all have a use, use them where they fit best.

jj wrote re: Ruby Is Scary
on 08-03-2010 1:08 PM

article is seriously flawed

Streamcap wrote re: Ruby Is Scary
on 08-03-2010 2:46 PM

Being a bad developer is one thing, being new in a long-running project is another.

Let's say that you are included in an ongoing project that has years of code in the repository - as I have been.

The hard part is not the language but the old code - there is absolutely no way to grasp all the different classes, methods, properties, interfaces and all other constructs in a timely manner. And no, you do NOT have the time to sit and study the code in order to learn all the different   methods - that is not being productive in the eyes of the customer, and they  ultimately decide what to pay for.

Having that "." to filter out what you can actually call is a lifeline until you can get your head around the system enough to "get it". Ideally, you should be "getting it" using documentation, but let's be honest: How much of the code in the world is documented?

Not so much.

All in all, Ruby is one of those languages that are "cool to begin with", but coming into a Ruby project half-way is a nightmare. And let's be honest, most of the code we work with is written by someone else.

Joe Ryan wrote re: Ruby Is Scary
on 08-03-2010 5:20 PM

Isn't it interesting that all the money spent on drop down boxes (Intellisense) and all the garbage in that ultimately gets in the way developing in a language like C# has become the very thing developers are running from. A language like Ruby allows developers a level of interaction with their computer that no statically typed language has ever achieved. Even taking into account all the so-called productivity increases an IDE heavy environment like Visual Studio was built to give developers like being close to the logic or the program and understanding the code starts to slip away. You would think using a lower level language in general would achieve giving the developer I feeling of control and understanding but it turns out the expressiveness of the language is what gives a developer the feeling that he is now communicating with his tools and the machine at large. As if the computer is saying "Oh, thats's what you meant". If this makes any sense to anyone.

Thanks

Jeff wrote re: Ruby Is Scary
on 08-03-2010 7:58 PM

I think I read this in 2004...is this a repost?

Jak Charlton wrote re: Ruby Is Scary
on 08-03-2010 9:21 PM

@Jeff

LOL it often feels that way!

Mohammed wrote re: Ruby Is Scary
on 08-04-2010 2:25 AM

"Compile time safety means that your developers don't have to be top notch, the compiler can make up for their weaknesses"

I quit reading at the above statement.

Mike Borozdin wrote re: Ruby Is Scary
on 08-04-2010 7:36 AM

Sorry, but calling developers bad because they are using statically typed languages is a non-sense. Moreover, Ruby isn't only about dynamic-typing, there are many languages also applied to the Web that are dynamic, like PHP and Python.

Adam wrote re: Ruby Is Scary
on 08-04-2010 9:38 AM

Saying that the appeal of Ruby in the enterprise is the ability to hire lower quality developers is a major punt.  

Not being a Ruby developer I honestly don't know the answer to these questions, but:

1 does Ruby have some mechanism for installing and managing client-server applications which is as easy to work as ClickOnce?

2 is there some sort of workflow utility as easy to use as WF, or am I going to have to write that myself, using all the time I save not having to "fight" the compiler

3 is there an ORM which is as robust as NHibernate / EF4, or are we assuming all my data-access requirements will be simple enough to handle with Active Record.

joelycat wrote re: Ruby Is Scary
on 08-04-2010 1:44 PM

me thinks thou dost protest too much. Perhaps you should do a little introspection about your obvious defensivness about being a Ruby developer. Lashing out at those of us that actually understand the theory behind OOP and strong typing, and why it's valuable, won't help anyone.

cyberman wrote re: Ruby Is Scary
on 08-04-2010 3:01 PM

I develop gaming tools for online offering such as Evony, I work predominantly in c# + Silverlight to achieve this.

I have coded in type-safe and non-type-safe languages.

I feel I have to add that the accesiblity of .Net style tools is helpful to the layman and beginner but on the reverse having to gain an understanding of type-safe-ness and what that means in term of testing can be a millstone.

It would be fair to say that the best answer here is "Horses for courses". Is C# better? Is Ruby the best.

No. Neither, they are two different hammers sometimes for the same nail. I don't see where the debate is getting heated?

My two cents.

Jak Charlton wrote re: Ruby Is Scary
on 08-04-2010 4:26 PM

@adam

1) Ruby on Rails deployment blows things like ClickOnce to pieces, it's an XCopy - or even just a Git check in - Ruby for a desktop app, you would have to be nuts to do it

2) WF really sucks fairly badly, yeah, write your own, I would over WF in .NET most of the time too ( a quick Google will give you Ruby options like http://ruote.rubyforge.org/ but I haven't used or evaluated - looks pretty cool though)

3) Simple enough for ActiveRecord? Woah donkey :) Yes, there are 'ORMs' (http://datamapper.org/why for example), but the AR in Ruby/Rails is far beyond what you may imagine AR to be - hence why in Ruby it also supports NoSQl just fine too

@joelycat

A quick check would have revealed I'm a C# programmer 80%+ of the time, with things like Javascript filling most of the rest - Ruby is a niche thing for me

And yes I understand OOP and static typing very well - firstly I know they have no relation to one another, and secondly, you do know that Ruby is (if anything) far more grounded in OOP than  C# don't you? For example, everything is an object - even strings, ints, and constants

@cyberman

Good point, should have mentioned games programmers, where both have lived alongside for a long time

@Mike

I didn't say they were bad, I said it lets companies think they can lower the bar - but in constraining all developers with static typing, you make it a lot harder for the good ones to excel

Adam wrote re: Ruby Is Scary
on 08-04-2010 10:28 PM

Well I think you're being a bit tough on WF, but still, point taken.

You mentioned Javascript.  I recently wrote a rich internet app essentially all in Javascript/jQuery (and EXT!!), with some plain old asmx services behind it.  I've got to say, it was much much much more fun writing that un-typed js code than C#.  Which begs the question of why I've (and a lot of C# developers) always had an aversion to Ruby.  I think it might just be the nature of the language.  Ruby, IMO is incredibly ugly and counter intuitive (at first).  Javascript, Java, C, C++, C# all kinda sorta look the same - even VB, unsavory as it may be, is certainly understandable.  

Meh, food for thought.  

Adam wrote re: Ruby Is Scary
on 08-04-2010 10:34 PM

One last thought - IMO whatever advantages Ruby had over C# are virtually nil (excuse the pun!) given C#'s new dynamic typing.  Check out this question from SO and tell me that's not the absolute best of both worlds - strong-typing combined with dynamic typing (when needed).  When the compiler gets in the way (legitimately, don't be stupid with dynamic), just eliminate it!

stackoverflow.com/.../using-createsourcequery-in-ctp4-code-first

Jak Charlton wrote re: Ruby Is Scary
on 08-04-2010 11:24 PM

@Adam

If Ruby is ugly at first, it's probably just familiarity - I'm still not 'comfortable' with it - but in most cases its a lot easier to follow and understand (IMO)

Just go play with Ruby for 30 minutes, or watch a couple of introductory screencasts to understand why 'dynamic' is nothing like Ruby, and gives none of the advantages

dynamic makes com easier, solves some nasty 'I can't cast this to one of these' type problems (we use it on current project deep in our reflection stuff - we could have just used reflection anyway under 3.5 for 1 more line of code) - but ultimately is nothing like duck typing

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)