| igualmente :]. co-founder of a very-recently Google & Atlas Venture backed startup (so not an investment deterrent; no issues on the engineering deep-dive during diligence, and received kudos on our architecture and some clever stuff we developed). love .NET and the MSFT support & team over at azure... been on it since beta circa 09'. I'm also an avid python numpy & matlab programmer, even submit patches to and support a few open source python libraries (ps: flask is my favorite web framework). in this discourse (and that of the original article and its comments) of the original article) I've encountered a tremendous amount of opinion/perspective that contrast my own/teams, and the experiences we've had - so I'm sharing my thoughts below. I may not address each questions but it's at least a stream of consciousness evoked by the topic. (btw: I came from an all-java shop (oracle) by way of a company they acquired in '07.) our language is C#, target framework 4.0. - misc: C# is semantically equivalent to Java, virtually the same for the core libraries; syntax and the nuance of the latter aside it's easy to embrace engineers from the opposing worlds within each others framework.
- diamonds in the rough: there is a treasure-trove of very smart previously inaccessible engineers toiling away in corporate waste-land, skilled in C#, and ineligible (by syntax/familiarity guidelines) for lots of startup reqs. example: we have a brilliant mathematician on our team that's been coding in C# since its release, working for investment banks where C# was the internal language of choice. as always, it's really about the person, not the language (look at what php's done to push the envelope with PHP... mysql...). - .NET in terms of limited capability: we've written some pretty heavy non-linear optimization frameworks, stuff that while easy to prototype in python, we've found much more maintainable in C# due to the VS IDE, static typing, and the effectiveness & patterns they beget. also the efficiency inherent in some of the data structures to their static nature has been noticeably performant. (btw, latest CLR has truly dynamic types, and an independent fully dynamic runtime DLR.) - prototyping: django's beautiful admin framework aside, .NET MVC 2 via C# and Django via Python yield very similar efforts for prototyping. MVC has a struts-like template for pushing admin stuff up quickly. - cool/weird stuff: we've built (and had one of the best software engineering companies attest to) an incredibly innovative multi-dimensional-map for 'moving' throughout a highly constrained NP solution space during non-linear optimization. C# and Java do not support generic generics (think maps of N # of maps with X type). we have code-generate this, and their super efficient. it's something you could just bang away on at python or in lisp to prototype quickly, but you would need careful optimize and code to get performant, and also maintainable and provable (mathematically) across a multitude of types inherited for varying different sources throughout a framework. object-oriented languages w/static typing afford you this. yes it could have been done in open source C++, C or Java, but we did do it in .NET. It's one of the fun and weird things we've worked on. inspiration is/should not be limited by a language, regardless if it's correlated, it's not causal. please see auto vector regression by one of this years nobel laureate in economics or this: http://www.venganza.org/about/open-letter/ - for quick intuition as to why. :] - liquidity/exit event, and the choice: we didn't choose .NET due to a likelihood of acquisition, or not choose it in fear of it preventing one (I mean this as in every sense except that in which .NET made our business look more compelling; hone our competitive advantage, etc.) I agree for a framework company (solely depending upon the level of the framework) this could be critical, but for most companies where at least one level of abstraction (framework included) obviates development platform dependency from a decision to use the service, it's negligible. we chose it because of how pervasive windows and its embedded and compact environments were in some of the disparate systems we're integrating with. it made life easier. it's worth stating that, whilst I stand by my first sentence, a couple of our most likely acquirers do have predominantly microsoft stacks, or are c++ based and could assimilate our development ethos quickly. - cost of tech: we're bizspark'd which made this venture possible, I agree, without that .NET would not have been feasible decision. we would have went java or python (especially given the fantastic client-side deployments dropbox was doing w/it at the time). we would not have chosen MONO - at the time ASP.NET via Mono scaled poorly and MVC didn't exist for it (digression: absolutely no way in hell anyone should build on the old asp.net forms paradigm or hold it against .NET now that MVC is an option: even excluding the IoC weirdness and its terrible pattern, I still cringe when I see .aspx extension on a site. that said MONO for our integration platform would have been perfectly fine. - long term cost (post 3 years): azure is not expensive, like all platforms (I have EC2 and app-engine experience) if you optimize for it, you can make it cost-effective. more importantly, if you're not earning $ or in some cases raise/preserve capital after 3 years (or until you hit $1.5m in rev per the bizspark restrictions) what kind of business are running? - source control: TFS (team foundation server) is fantastic, from its testing framework, bug repository, and with some hacking its workflow systems it's a tool I've found as powerful (but easier to configure) than clear case, the systems we used at oracle, and myriad other variants I've worked with over the years. it's not source safe :]. - complexity: we've had to lift up the hood quite a bit to accomplish what we wanted. "the ability to patch and pull in req's for changes to FOSS software" is but one way to customize. .NET offers many, down to the many ways you can override/overload/extend even the most isolated libraries with the latest syntax sugar, to getting your hands a little dirty in MSIL. while not the FOSS way, it's possible. whether or not it's ideal is a matter of perception - e.g. when you work in (and accept) a proprietary environment. - developer vs. engineer culture: semantics here. probably the b&b of this article, I think culture, pervasiveness (not independent of the former), and founding team/CTO experience, and biz strategy sum up to the decision as to why people do or do not use .NET. I find it difficult to place a coefficient on each of those terms but it's empirically manifest that more often than not they weigh against the choice to use .NET. strategy includes cost, only recently (~3 yrs) obviated by bizspark. it's also the market stuff I mentioned. FOSS has existed for years as an alternative - this is why it's pervaded (among other reasons). I have no data on founder XP, but I've met very few others that have experience working in .NET languages, I think this is a big contributor to start culture & personality types and where most .NET developers dwell - that's why I labeled that intersection 'diamonds in the rough'. last statement should show how those terms are not mutually exclusive. - language/tech zealots: agreed, they're everywhere. even people I respect tremendously just have this natural predilection toward their preferred tech and its advantages. my .2e-1 observation: have you seen the wonderful and cross-platform [android, ios, win phone] natively compiled .NET tech miguel's team @ xamarin have been working on? I suspect the # of corp clients that are leveraging that tech and the exposure to consumers the app-serving end-devices have will inspire those corp developers to create their own apps eventually... could bring a lot of .NET favoring newcomers (and different demographic) into the startup scene - neither a bad thing. |