Building a Startup - Defending .NET

I did know that, and these things heavily factor into why I default to C# for most projects these days! .NET 4 is awesome.

C# is an excellent language. It has all these great things, yet doesn't feel polluted or bloated at all. I absolutely love lambdas, closures, and generics. They help write concise and clear code. Generic support in C# and F# and the CLR itself is brilliant.

Writing event-driven, asynchronous IO code in .NET code is a breeze. It seems like the current programming trend around these parts is focused on "iterating fast" and having async IO. C# gives me both of these things, with the bonus of having the compiler catch most of my errors.

I disagree with the general notion that duck-typed languages are more empowering or let you iterate faster than strongly typed languages.

If you think that a language that is lazy (or worse, unspecific) about types lets you write code faster, I think that you have some fundamental problems with how you approach development.

The whole dynamic languages = faster code production is an unsettling school of thought, in my opinion.

And? Unless you're trying to sell them something, who gives a rats-ass what they think? :-)

Try going to something that's a bit more unixy and it's just the opposite: you can feel people judging you when you pull out your MBP. Pull out an iPad and you may be asked to leave :)

I have gone to equivalent places/events with my Acer laptop, without anyone judging me. (It is running Ubuntu, mind).

Maybe this is less about .net/other languages and more about what makes development so terrible in large corporations. But keep in mind most .net developers, of which I am one, are products or large corporate development .

However, if you already know how to do something well in one particular stack, then you should just stick with that if the objective is to ship.

The operative word is of course that you know you can do it well in that stack. If you start thinking "there has to be a better way" then you should seriously look into alternative stacks or whether you are using your current one correctly.

Your quote is apt, but it cuts both ways. Using the same old tool indefinitely, even when newer tools can do the job better and much faster, might be foolish. On the other hand, learning to do the same task over and over again using different tools, each only a modest improvement on the last, might also be foolish.

In the case of your C+CGI example, I would agree that it makes sense to prefer any of the more modern "scripting" languages, which typically have both good library support for networking protocols and much more powerful integrated string handling than C.

On the other hand, there is little offered by any mainstream language ecosystem today that can't be achieved at least reasonably proficiently using tools from the .Net world as well (ignoring the obvious limitation of having to run on a .Net platform).

I think the danger with this decision is that we tend to get a "grass is always greener across the street" mentality. I have yet to find a programming language that has no serious warts.

Certainly different languages have different warts, and thus suit different jobs better. However, just because we haven't used a language enough to appreciate its warts, that does not mean we will not discover them to our cost at exactly the wrong moment in our new project.

Moreover, with newer or more recently popularised languages, there is sometimes a tendency for the community to bury its head in the sand. Some defenders might claim that we "just don't understand" if we identify a serious shortcoming. Sometimes the individual or group that defines/specifies a language will have a blind spot and make seemingly arbitrary decisions that we don't agree with. In contrast, with longer-established languages, the shortcomings tend to be well-known and acknowledged, and the emphasis in the community is often on sharing the most effective workarounds or alternative techniques.

Obviously these generalisations aren't necessarily universal. We find helpful people in otherwise intransigent communities and awkward people in otherwise helpful communities. Still, I have seen the pattern repeat over the years for many different languages as they evolve from the Newer And Better Thing to a mainstream tool and ultimately to an older tool that is superceded by the next newer and better thing.

When I'm choosing the tools for a project, I usually favour the middle of that spectrum over either extreme. Out-of-date and underpowered is bad, but tried-and-tested is good. YMMV.

Force yourself to start writing other things with the language you want to use TODAY. I would start writing utility stuff in something else until you're comfortable with it.

It's also a little funny to see Python and Ruby described as more powerful that Java! I guess powerful is a mutable word, but personally I'd consider them less powerful but faster to develop in (for a dev at the same skill level in both languages).

For a minimum viable product, you need to do the minimal amount of work, whatever that turns out to be for the startup you are building.

Is it something like DropBox? In that case, you need to write at least part of your product as a Win32 Shell Extension, and regardless of how well you know Java, it is MORE work doing that in Java than in C++

Is it the new GoogleDocs/ZohoOffice? In that case, about 90% of your work is in JavaScript or a language that compiles cleanly to JavaScript. This might be Java (by way of GWT), but probably isn't.

Is it a new "enterprise software system"? Java is probably a good choice, even if Java wasn't your strongest point.

And if it HAS to be java for some reason, there's Clojure, Jython, Mira, LinJ and a few others that let you switch slowly and incrementally, without having to decide or make a tradeoff.

Microsoft's programs exist because of the insane amount of features and support that have to go into their products for their enterprise customers. And its those features that really make us stick with Azure for now. Specifically, I'm talking about TableStorage, Queues and AppFabric's Distributed Cache Service. I've already had a small chat with the AppHarbor guys before. I'd definitely love to move if it made sense.

Don't get me wrong though. I definitely have my gripes with Azure too.

Most significantly, much of the Rails magic comes from Ruby. So when you say the two (WebForms and ASP.NET MVC) aren't alike, its like you are forgetting that they both use C#. The DLR is a small step, but it isn't in the same league. We can disagree that Ruby is such a significant productivity boost over C# - that's fine. But, if you think language is completely irrelevant, then imagine an MVC framework like ASP.NET MVC where you had to code your HttpModules, HttpHandlers, controllers, models and data access code in C. Concrete example? You don't do DI in a Rails app...yet it permeates through any WebForms/MVC app you write.

Then there's the tooling. WebForms and MVC share the same deployment and package management. Both are young and inferior to Cap and Gems (but they are young and they've done a good job with it so far). They are both hosted on IIS and essentially deployed/configured/managed the same. WebForms and MVC share the same IDE.

Then there's community. ASP.NET MVC and WebForms generally have access to the same libraries (nUnit, NHibernate, JSON.NET), the same resources, and the same community leaders (hey, I was one of them!)

So far, ASP.NET MVC and WebForms share: Language, Community, Tools, Libraries and deployment story. None of these are shared with Ruby.

Let's talk about code. Neither ASP.NET MVC nor WebForms have a cohesive model/data access story. Microsoft doesn't really provide an "M" with ASP.NET MVC. You can pick DataSets (oh wait, we don't like that anymore), or Linq2Sql (oh wait, we don't like that anymore), or Entity Framework (lolz) or NHibernate. Or, you can use Castle's ActiveRecord. None of these are very similar to Rail's ActiveRecord. So, when it comes to modeling and persisting your data, WebForms and MVC are exactly the same - which happens to be quite different than Rails.

WebForms and MVC share HttpHandlers and HttpModules/Global.asax. These are pretty nice (especially managed HttpHandlers in IIS 7). They also share the same built-in configuration management. But those are, yet again, something they share with each other, not with Rails.

Controllers? Ya, ASP.NET MVC shares more in common here with Rails than it does with WebForm's page model. And I agree this is pretty substantial..but even under the covers, things aren't all the similar. Email sending is very different (in Rails it builds on top of the controller core, which is why I include it here). Routing, model binding, validation...ASP.NET MVC and Rails are more similar than ASP.NET MVC and WebForms...but they still aren't that similar.

Views? ASP.NET MVC shares some stuff with Rails, but easily as much with WebForms. Asset management (or lack thereof), nested layouts...

Honestly, the only thing the two share in common is a controller with actions. And, when you look at typical ASP.NET MVC code, controllers/actions tend to do a lot more than than an equivalent Rails actions.

ASP.NET MVC shares more with Silverlight or WinForms development than it does with Rails.

EDIT: Somehow in all that I forgot to mention that WinForms and MVC share the same framework (.NET) and runtime (DLR/CLR). Neither of which is anything like what Rails runs on.

I find this part particularly hilarious:

"However, if you need to make a 1.7 oz burger, you simply can’t. There’s no button for it. The patties are pre-formed in the wrong size. They start out frozen so they can’t be smushed up and reformed, and the thawing machine is so tightly integrated with the cooking machine that there’s no way to intercept it between the two."

Pure silliness. Perfect example of an irrational language bias.