Jeremy D. Miller -- The Shade Tree Developer

I'd bet a lot of money that the paragraph you're quoting was Joel's clever way of saying "But what do I know..."

I think he was being sarcastic.  Think about the specs quoted there.

I just read a post by Joel Spolsky where he begins talking about different languages and platform stacks. ...

I've pretty much given up on Joel.  I don't understand why people consider him so authoritative.  He said some things about the merits swallowing exceptions (in an old post) that pretty much fly in the face of all my experience and what i've heard from other developers on best practices for exception handling.  He just doesn't sound in touch with the reality of developing code in the trenches.  Building your own proprietary language sounds pretty lame too.

Some perspectives on different programming languages....

Admittedly, I'm a Ruby Newbie, but it seems a lot of what I've seen from the Ruby proponents seems to be focused on Java. It seems Java programmers are frustrated with various inadequacies of their language/framework and are looking for a solution and WERE jumping on Python and are now jumping on Ruby.

There seems to be a buzz in the .NET world, but maybe no so much (of course, many .NET programmers are still using VB.NET, so an argument could be made that they don't have a clue about languages in the first place anyhow).

If Ruby is a better platform for Java, how does it relate to C#? C# has many of the better parts and some of the bad parts of C++/Java-style languages, but also has 'solved' or 'made easier' some of the other bad parts (more so than Java).

Does Ruby stack up as well against C# as it does to Java? Is there some killer feature that makes Ruby a must-have over C#? Continuations don't seem to be the killer feature, though everyone is quick to mention it. (How many people here use continuations enough to get their money out of it, raise your hands?)

Rails seems pretty cool. I've heard a lot of people dogging on ASP.NET but most people haven't touched 1% of what's in ASP.NET (they're still using <asp:TextBox and the built-in validators and post-backs and that crap -- i.e. the drag and drop designer crap in VS.NET that MS Marketing tells you is the greatest, but which doesn't work for any project which hopes to be successful, let alone testable and maintainble).

Is there anyone out there with some real deep, core ASP.NET experience who's also used Rails and can do a good pro/con comparison of the strengths and weaknesses of each?

- ActiveRecord in Rails is easier to use than NHibernate.  Maybe less powerful, but definitely easier

I think a better comparison would be to castle project's active record which sits on top nhibernate...

I read Joel's post a few minutes ago and was waiting for the "just kidding" part at the end.

"I've heard a lot of people dogging on ASP.NET but most people haven't touched 1% of what's in ASP.NET (they're still using <asp:TextBox and the built-in validators and post-backs and that crap -- i.e. the drag and drop designer crap in VS.NET that MS Marketing tells you is the greatest, but which doesn't work for any project which hopes to be successful, let alone testable and maintainble)."

Chad, you've piqued my interest. So you dont' use the built in controls or postback?  Did you go back to Request.Form["firstname"] type code and pass things back and forth the old fashoned way?

Jeremy, Amen on the added complexities of Web Forms.  There's lots of stuff i love about it, but also lots of stuff that drives me crazy and seems to make asp.net harder than it should be.

Fregas: I extend the built-in controls. The control lifecycle is actually the best part of ASP.NET and offers a lot of flexibility, but all the canned stuff for the drag-n-drop enterprise architects has to go and be replaced with serious stuff that's testable. We have a control framework built on the ASP.NET controls that make things like data binding, group-by's, repeaters, etc easy and testable and works well against a standard DDD aggregate repository-style architecture.

As far as postbacks, every web framework needs to post-back at some poine. With AJAX, that 'some time' is a lot less frequent, but that still happens. In that case, the post-back event handling in ASP.NET makes it easy, it's just that MS and VS.NET encourage you to use post-backs for everything (like onselectedindexchanged on a drop-down... terrible!) so you have to be judicious about the post-backs.  ATLAS makes AJAX simple and also makes client-side javascript easier. I've used prototype and script.aculo.us (sp?) before and they're good, ATLAS is better in some respects, and more complicated in others. Scriptaculous is also hard to use for AJAX since it's very Ruby-specific. The client-side-only stuff isn't terrible though.

I don't see what all the brouhaha is about. What they've done is simply create a domain specific language. Joel did a followup post describing his reasons for doing so, all of which seem perfectly valid to me. What's kind of amusing is that all of the RoR folks that are verbally beating Joel to a pulp over this don't seem to realize is that RoR is also a DSL. The only difference is that DHH et. al. now have to make RoR work in all kinds of applications and they have to provide support to hoards of demanding users. FogCreek on the other hand only has to make their DSL work for one specific task (orders of magnitude easier) and only need to provide support to themselves.

Jacob, if you knew Ruby you might see it from a different perspective. Writing a DSL in Ruby is far FAR removed from writing a compiler, using a lexer/parser, or anything of the sort. I can write a DSL in Ruby in just a few lines.

So they're not at all comparable.

Considering the popularity of RoR, and all the free work 37Signals is getting out of contributors, I'd also take issue with your framing the open-sourcing of Rails as a burden. I just don't see how any reasonable assesment of the business impact it's had on 37Signals could conclude that it's been anything but a tremendous avenue for profit and marketing kudos for the company.

Oh, and I think you're stretching with the support claims anyways. It's stated pretty clearly that the Core team doesn't implment features they don't want to... period. I'm not going to say there haven't been exceptions (render :component comes to mind), but by and large Rails Core development is definitely not driven by the "needs" of it's developer-users.

Calling Rails itself a DSL is definitely stretching it too. Many of the interfaces DSLs? Definitely, but under the covers there's a lot of code that really has little to do with the interfaces. Just like any Framework.

Oh, and Chad: method_missing and method overwriting. Beyond the blocks/closures, these two influence Ruby programming more than any other I think. When first learning Ruby I considered method overwriting a poor cousin to method overloading, but the truth is it's really the unsung hero of programming in Ruby IMO.

Hey, if you guys want to see a brand new top quality

data crunching programming language that is the best ,

check out :

www.my.opera.com/datahelper

My take on it...  at http://just-a-speck.blogspot.com/2006/09/wasabi-very-late-to-party.html