--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.

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

"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.

@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.

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

"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!

@KevDog - feel threatened much?

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.

"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?!

"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.

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!

"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.

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

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?  

"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.

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.

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

Ruby has too many.

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

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.

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

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.

article is seriously flawed

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.

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

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

"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.

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.

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.

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.

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.

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.  

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