http://www.aaronstannard.com/post/2010/07/03/NET-Culture-Shock-Why-NET-Adoption-Lags-Among-Startups.aspx

C

Charles said:

The author makes some valid and important points. However, it is clear that he is unaware of the BizSpark program (not that this nullifies his concern and perspective...). See some of the start-ups who have taken the bet on .NET here: http://channel9.msdn.com/tags/BizSpark and here: http://www.microsoft.com/bizspark/

 

C

The link in the last section of that story is to the BizSpark page, so he is aware of it.

1. Fashion and lack of awareness of .NET's benefits - php is more ubiquitous and probably always will be, ruby is more trendy. Don't underestimate the effect of programming fashion in startup culture. Some people would rather waste their time writing server-side code with immature tech like Node.JS than use something tried and tested like .NET or Java.

2. Fear of costs - People know they can always get Linux servers for next to nothing. I tend to think that if you're businesses sucess depends on eliminating the cost of a few Windows Server licences, then you've got a crappy business plan, but not everyone thinks like that.

rhm said:

There's two issues aren't there?

 

1. Fashion and lack of awareness of .NET's benefits - php is more ubiquitous and probably always will be, ruby is more trendy. Don't underestimate the effect of programming fashion in startup culture. Some people would rather waste their time writing server-side code with immature tech like Node.JS than use something tried and tested like .NET or Java.

 

2. Fear of costs - People know they can always get Linux servers for next to nothing. I tend to think that if you're businesses sucess depends on eliminating the cost of a few Windows Server licences, then you've got a crappy business plan, but not everyone thinks like that.

I think a third point that goes beyond cost is simplicity.  Startups don't necessarily start with expert developers.  Lots are straight out of college.  I am biased though since I work on this WebMatrix stuff. 

rhm said:

There's two issues aren't there?

 

1. Fashion and lack of awareness of .NET's benefits - php is more ubiquitous and probably always will be, ruby is more trendy. Don't underestimate the effect of programming fashion in startup culture. Some people would rather waste their time writing server-side code with immature tech like Node.JS than use something tried and tested like .NET or Java.

 

2. Fear of costs - People know they can always get Linux servers for next to nothing. I tend to think that if you're businesses sucess depends on eliminating the cost of a few Windows Server licences, then you've got a crappy business plan, but not everyone thinks like that.

I think .NET isn't used because people assume that you have to buy Visual Studio to use it. There is still the misunderstanding that the express versions can't be used in production, and that you can't develop in .NET without Visual Studio.

Another big reason is that colleges don't teach it. Most professors I've met are open-source proponents, so the kids are taught C++ or Java due to their cross-platform support.

Speaking as a former unix developer, I originally switched to .net when it was released in order to spend less time debugging heap corruption and other low-level C++ problems. I thought .net would steadily increase in efficiency and simplicity, for example by providing an equivalent to the STL. At this point .net doesn't have many advantages, except operating system market share.

Frank Hileman said:

The increasing complexity of the .net framework and .net development tools steadily increases the barrier to market entry for software developers. Other disincentives: a lack of platform portability, a neglected JIT optimizer, quick obsolescence of knowledge as new libraries are continuously churned out. C++ and Java JIT optimizers should not be faster than .net, and the .net framework doesn't need to be such a monster.

 

Speaking as a former unix developer, I originally switched to .net when it was released in order to spend less time debugging heap corruption and other low-level C++ problems. I thought .net would steadily increase in efficiency and simplicity, for example by providing an equivalent to the STL. At this point .net doesn't have many advantages, except operating system market share.

There are some libraries where one just has to marvel. It is as if one is standing before a grandiose piece of architechture, full of patterns and symmetries. The .NET collections library probably isn't one of those libraries. The best type has to be IEnumerable, the "workhorse of .NET" and the premier Linq enabler, besides IQueryable.

My own naïve view is that programming Linq to Objects is like treating memory like a database. It is such an important use-case with so far-reaching implications that it should be heavily optimized by the compiler, even if it has to be treated like a special-case. Linq queries are superbly composable and are extremely easy to reason about and glue together.

One can have several regrets in retrospect about .NET but in actual fact, many regrets simply have to do with how Moore's law is realized now vs how it was realized in the past. It also has to do with a realization of how purity and a declarative style can help improve software correctness.

Microsoft clearly has some massive internal efforts underway. The Phoenix Framework, the Bartok research compiler, the various research languages at MSR, The Singularity and Helios projects as well as the newer incubation project being lead by Joe Duffy, also heavy on language research. But when following CS it's hard to ignore how many advances are continuously being made and how it would be nice to apply those advances. When do you decide you are far enough along? CS is still a young science and we are still doomed to reinvent the wheel over and over again, in ever more clever ways.

Frank Hileman said:

The increasing complexity of the .net framework and .net development tools steadily increases the barrier to market entry for software developers. Other disincentives: a lack of platform portability, a neglected JIT optimizer, quick obsolescence of knowledge as new libraries are continuously churned out. C++ and Java JIT optimizers should not be faster than .net, and the .net framework doesn't need to be such a monster.

 

Speaking as a former unix developer, I originally switched to .net when it was released in order to spend less time debugging heap corruption and other low-level C++ problems. I thought .net would steadily increase in efficiency and simplicity, for example by providing an equivalent to the STL. At this point .net doesn't have many advantages, except operating system market share.

What neglected JIT optimizer, which C++ JIT optimizer?

Ion Todirel said:

Frank Hileman said:

*snip*

What neglected JIT optimizer, which C++ JIT optimizer?

Frank, of course, means native C++ performance and Java JIT performance compared to CLR JIT performance. I don't know how Java Hotspot stacks up against CLR these days.

exoteric said:

Ion Todirel said:

*snip*

Frank, of course, means native C++ performance and Java JIT performance compared to CLR JIT performance. I don't know how Java Hotspot stacks up against CLR these days.

Correct. I am not sure how java hotspot stacks up these days either, but I know the CLR JIT stagnated for many years. Simple things we have had in C++ for decades, such as temporary object elimination, were never added, except recently for structs in some cases. Here is the latest I could find discussing it: http://blogs.sun.com/jrose/entry/bravo_for_the_dynamic_runtime 

In regards to a "good" library versus a "bad" one: ease of learning is the most important aspect, inversely proportional to size and complexity.

Regarding IEnumerable: "Abstraction and Specification in Program Development," by Liskov and Guttag, published in 1980, discussed implementing iterators in Clu. IEnumerable is the CLR equivalent of iterators. It is nice to see these ideas make their way into common high level languages, but it is hardly a new concept.

Frank Hileman said:

exoteric said:

*snip*

Correct. I am not sure how java hotspot stacks up these days either, but I know the CLR JIT stagnated for many years. Simple things we have had in C++ for decades, such as temporary object elimination, were never added, except recently for structs in some cases. Here is the latest I could find discussing it: http://blogs.sun.com/jrose/entry/bravo_for_the_dynamic_runtime 

 

In regards to a "good" library versus a "bad" one: ease of learning is the most important aspect, inversely proportional to size and complexity.

 

Regarding IEnumerable: "Abstraction and Specification in Program Development," by Liskov and Guttag, published in 1980, discussed implementing iterators in Clu. IEnumerable is the CLR equivalent of iterators. It is nice to see these ideas make their way into common high level languages, but it is hardly a new concept.

IEnumerable is specific kind of iterator, a forward iterator. Forward iterators have linear complexity for searching. Hence why Linq to Objects has linear complexity.

Charles said:

The author makes some valid and important points. However, it is clear that he is unaware of the BizSpark program (not that this nullifies his concern and perspective...). See some of the start-ups who have taken the bet on .NET here: http://channel9.msdn.com/tags/BizSpark and here: http://www.microsoft.com/bizspark/

 

C

About the BizSpark program,  my startup got rejected multiple times because we do some consulting work to finance our product development.

Even though we can certify that the BizSpark software wouldn't be used for consulting work (ie clients provide it), they just don't care.

That's just silly.

Charles

Bass said:

Frank Hileman said:

*snip*

IEnumerable is specific kind of iterator, a forward iterator. Forward iterators have linear complexity for searching. Hence why Linq to Objects has linear complexity.

Some Linq to Objects operators do check for whether an IEnumerable happens to also be an IList, giving random-access. 

cverdon said:

Charles said:

*snip*

About the BizSpark program,  my startup got rejected multiple times because we do some consulting work to finance our product development.

Even though we can certify that the BizSpark software wouldn't be used for consulting work (ie clients provide it), they just don't care.

 

That's just silly.

Charles

Interesting. I'll ask about this. I'm meeting with the BizSpark people tomorrow morning.

C

cverdon said:

Charles said:

*snip*

About the BizSpark program,  my startup got rejected multiple times because we do some consulting work to finance our product development.

Even though we can certify that the BizSpark software wouldn't be used for consulting work (ie clients provide it), they just don't care.

 

That's just silly.

Charles

Hi Charles,

I manage the BizSpark program in the US and I am sorry that you've had this experience.  While BizSpark is specifically for the development of a specific product, and not for use for consulting services, if you're working on a specific product and you fit the requirements of being a) private company, b) under 3 years old, c) making under $1million USD per year, then you certainly qualify.  Can you email me at jacob.mullins@microsoft.com and we can get it all squared away?  Sorry for the inconvenience, look forward to solving this with you soon.

Best,

Jacob Mullins

Partner Development Manager, Microsoft BizSpark

@jacob