Live data from Hacker News

Why I Left the .NET Framework

blog.jonathanoliver.com

81–90 of 109 posts

Re: Why I Left the .NET Framework

#81
post #24

> Not having a debugger is actually a liberating experience because it forces you to code in a different way. Not having a debugger is like living in the stone age. Personally, the the ability to inspect application state at runtime is non-negotiable.

Fully agree. Some developers like to live in green phosphor vt100 days.

Funny you mention that, as the author of the blog post in question, I'm basically inside of a green-phosphor command line most of the time. I've got my cursor set to block and it doesn't blink.

Re: Why I Left the .NET Framework

#83

> Not having a debugger is actually a liberating experience because it forces you to code in a different way. Not having a debugger is like living in the stone age. Personally, the the ability to inspect application state at runtime is non-negotiable.

Coming from C#, when I originally started using a language that didn't have a debugger I thought I would miss it. But I found that I'm more deliberate about my code because the debugger isn't there for me to fall back on.

> I found that I'm more deliberate about my code

So your code never has bugs?

Any production piece of software is going to need debugged at some point. Sure, a step-through debugger like the one in VS isn't the only way to debug, but it sure as hell is one of the more intuitive ways.

Being able to expand objects and see their state etc. is extremely powerful and shouldn't be shrugged off as a nice-to-have.

Re: Why I Left the .NET Framework

#84

When I first got started in web development, my brother-in-law managed a large Microsoft shop and got me started with all the software I needed to get going for a huge project I managed to wrangle using .NET when it was at version 1.5(?). We worked on that for something like six months until, one day, all of a sudden everything was version 2.0(?) and it all fell apart! We quickly called my brother-in-law in and he co…

There wasn't a 1.5, so you're probably thinking 1.1 or 2.0. As far as I know it's been pretty good with backwards compatibility though. I used to do a lot of.net coding, and the only time I've seen compatibility issues upgrading was with beta versions (and even then, I only saw a small handful).

I don't remember the version numbers, and I had gotten it wrong once before when I posted about it, but compatibility was the issue now that you mentioned it. But I guess Microsoft told people that didn't happen and I must be a liar and hence all the downvotes.

Re: Why I Left the .NET Framework

#85

Earlier quoted context omitted.

I migrated a number of large services and desktop apps from .Net 1 to 2 and it required unremarkable effort. Some API differences that were well documented. The notion it required you to throw away all your code and change OS is simply absurd.

I completely agree, when I read that part it virtually invalidated everything else specious that was said, that is simply nonsense.

As the other poster said, it was a compatibility issue from what I recall but apparently Microsoft told everyone to forget that and thus it was so.

Re: Why I Left the .NET Framework

#86
post #39
post #24

Earlier quoted context omitted.

Fully agree. Some developers like to live in green phosphor vt100 days.

reliance on debuggers is a wierd strange concept. Debuggers are utterly incapable in multithreaded environments. Just write damn unit tests and simulations!

When was the last time that a unit test caught a race condition ? When was the last time a unit test caught a contract violation (one subsystem doesn't agree with another about the semantics of a piece of data) ? When was the last time a unit test caught the use of an O(n^large number) algorithm in a production system ?

Unit tests verify if the programmer's understanding of the code matches reality.

That's all. Not saying it's useless, but a) it's at best a start of proper testing, b) insisting on coverage is beyond useless.

What is needed is a test if the programmer's understanding of the problem is up to par. Since that's impossible, let's go with the programmer's understanding of the whole program : system and loadtests.

Unit tests, while useful for TDD for "fiddly" code, are useless to guarantee correctness of an application. System tests are better. Proper type system abstractions are best.

Re: Why I Left the .NET Framework

#87

When I first got started in web development, my brother-in-law managed a large Microsoft shop and got me started with all the software I needed to get going for a huge project I managed to wrangle using .NET when it was at version 1.5(?). We worked on that for something like six months until, one day, all of a sudden everything was version 2.0(?) and it all fell apart! We quickly called my brother-in-law in and he co…

There wasn't a 1.5, so you're probably thinking 1.1 or 2.0. As far as I know it's been pretty good with backwards compatibility though. I used to do a lot of.net coding, and the only time I've seen compatibility issues upgrading was with beta versions (and even then, I only saw a small handful).

One really big advantage I saw of running .NET was that the upgrade path from 1.0 -> 1.1 -> 2.0 -> 3.0/3.5 ->4.0, etc., was quite painless. Other than having to purchase a new copy of VS each upgrade, the tech side was really easy. This is unlike the Python 2.x to 3 migration which continues to hurt.

Re: Why I Left the .NET Framework

#88
post #61

Serious question: If you're building web products from scratch and can choose your environment why would you use .NET (other than "because I know it")? I've personally never used it because I'm opposed to closed-source single platform languages / frameworks and would like to understand the mindset of those who use it.

1. c# is a great language - LINQ and type inference make it as succint as python (or even more when I use extensions methods and generics!), static type system gives a lot of safety eliminating huge classes of bugs, decent performance compared to other succint languages like Python or ruby. Really hits the spot for me, and I would hate to go to a dynamically typed language now. 2. VS is a great IDE if you give it eno…

On AWS booting Windows can easily take 10-15 minutes. On the same type of EC2 instance, it takes 30 seconds. This makes auto scaling quickly very difficult because you have to scale up in anticipation of demand rather than as it occurs.

One other problem is that Windows by itself easily takes 1+ GB of RAM whereas Linux can easily run 64MB-128MB. So while Windows may only be 20% more expensive for similar hardware (which I don't object to either), I can run cheaper hardware and have more of it available to the application instead of the OS. Our metrics show the savings to be about 60% less expensive when counting hardware and licensing costs.

Re: Why I Left the .NET Framework

#89
post #58

It reads like his primary complaint is being forced to use "one true way", and the entire article and his decision are some sort of rebellion against this monstrous oppression, which he never describes in any kind of detail for us to understand what it is. I've been ising .NET for several years now, and the only complaint I can relate to is VS being a fat pig. Many of his complaints about not being able to use other…

vim is a breath of fresh air compared to VS, which you've mentioned is a resource hog.

A lot of the oppression comes from the mindset in various organizations that "we must use Microsoft" (because it's safe, because they provide support, etc. etc.) and thus looking outside is actively discouraged at an organizational level. While I can't say that Microsoft directly encourages this thinking, in the past they've certainly not discouraged it.

I would have loved to use async/await when they existed, but they didn't at the time. AND I needed it to run on Mono which didn't support those language capabilities yet. Things are improving dramatically, but I've moved on to greener pastures.

Re: Why I Left the .NET Framework

#90

> I consider .NET to be an ecosystem including all tools, projects, platforms, organizations, and groups of developers. Well, that explains the otherwise baffling statement "I left .Net because ... git is so much better than TFS" That is an opinion that I also hold, but isn't relevant. If the conclusion is that "but .Net comes with a mindset of using all and only the MS tools" then yeah, avoid narrow-minded people. A…

Yeah, I don't see this problem. Maybe I'm just an outlier, but when I was a .NET developer, I would use non-MS tools all the time. Git is better than TFS, just as nUnit is better than MSTest. TeamCity is better than TFS. Visual Studio with ReSharper is better than Visual Studio without. Good technologists will use a heterogeneous toolkit no matter what ecosystem they're working in.

The trouble is that "the ordained path" is MS tooling all the way. I suppose there's a lot of pressure on MS to provide a prescribed method and they're satisfying a market demand, but when I worked in .NET I had to make very deliberate choices about avoiding MS tooling and keeping it pinned back into a corner of my project. If left unchecked, it would try to dominate by default.
Post reply on HN