Why I Left the .NET Framework
blog.jonathanoliver.com
Why I Left the .NET Framework
1–10 of 109 posts
Re: Why I Left the .NET Framework
#2That's so true! I always roll my eyes when I hear someone says "everything could be done under the MS dome with this and that... blah blah". Yeah, surely it will work, but that does not means there is no better, cheaper (free!) and more advanced solution in the Tech universe.
Re: Why I Left the .NET Framework
#3I think the authors view of Unix guys is a bit misplaced. I guess I could be a Unix guy -- I work with many different operating systems, programming languages, tools, etc. But in addition to all that, I also more recently have worked in Windows with C# and SQL server. One doesn't have to choose one side or the other -- you can choose the best tool for the task and have that include .NET if appropriate.
A lot of the "The Bad" is true of any platform; not specifically that list but in that every platform has pros and cons. If you choose Java, you'll have a different list. If you choose Ruby, you'll have another list. Depending on your task, you might be bitten pretty badly by whatever is on the bad list. Conversely, you might save a lot of time and headache from what is on a platform's Good list. And .NET is extremely efficient for some tasks.
It's actually really hard to know multiple operating systems, windows managers, desktop managers, file systems, package managers, etc. It's really a waste of brain space but a necessary evil. You can still only be an expert in a subset and muddle your way through the rest. Once you've learned a technology and everything about it then the next time you need to do a job you're likely to pick that technology even if it's not objectively the best choice for the task. So Java begets Java, Ruby begets Ruby and Windows begets Windows.
Re: Why I Left the .NET Framework
#4.NET is now heavily async based. WPF may have started it years ago, but async has been a keyword in the language for quite awhile! (I haven't used a proper lock in ages. Event queues are where it is at! Or pick your favorite paradigm, heck the framework comes with thread pools built in that it'll juggle for you!)
In regards to .csproj and .sln files, they serve the same purpose as make files. .csproj files (and .*proj files in general) are incredibly powerful, you do not even need to use Visual Studio with them. They interact with MSBuild to do some insanely extensible things.
That said, merging .sln files is horrible, the bloody file format has an element that is a count of project element nodes in that same solution file, if two people try to check in a new project to a solution at the same time, the project count field gets corrupted and life gets seriously un-fun. :( The SLN file has a number of other issues as well, ugh! But .csproj files are pretty nifty, no worse than any other makefile replacement.
As for Visual Studio, I run it just fine on my Ultrabook! Huge project, it works well. Not perfect, but good enough. VS2013 fixed some very blatent threading bugs that VS2012 had in its UI (oops!) and things are generally snappier now.
Oh and VS support for git has been around for awhile. :) TFS also has really good git support, it has been improving with every version and it is now at a really good place.
All in all though, some very good points of criticism! No programming language ecosystem is perfect! (Disclaimer: I m mostly use .NET for client apps, I haven't done server .NET stuff since 2.0!)
Re: Why I Left the .NET Framework
#5When I want to run small tasks I want a scripting language. I don't need a full blown type system, I'm importing from strings, what I need is a Nodejs ten liner, not having to build out a DAL just to run what in the Linux world is going to be a shell or python sys admin script.
Re: Why I Left the .NET Framework
#6I agree with the author on one point in particular: Choose the right technology for the task. The author doesn't state what his task is but he does drop a few hints that does indicate that .NET/Windows is the wrong technology for his task. I think the authors view of Unix guys is a bit misplaced. I guess I could be a Unix guy -- I work with many different operating systems, programming languages, tools, etc. But in a…
This is incredibly true! I'd argue that even on a given platform, that one only ends up knowing a portion of it!
Heck a part of it is just stuff learned through osmosis. If I'm on Windows I know I can use tools from Sysinternals[0], such as Process Monitor, to save myself hours of time. Put me on *nix and I do not know how to do equivalent system level traces. But I've met many highly experienced cross platform developers who also don't know about Process Monitor, oops!
These platforms have decades of history behind them, a specialist in just one will always know more than a specialist in multiple!
Re: Why I Left the .NET Framework
#7We quickly called my brother-in-law in and he couldn't figure what was going wrong either. After a few weeks, we had to throw in the towel and, on his suggestion, switched to Linux and then FreeBSD. Three months later, everything was humming along and we're still doing everything with FreeBSD.
Later, I don't recall the details, but there was some major change between versions that was what screwed us up. I know some Microsoft people will know what I'm talking in that .NET version 1.5 to 2.5 range but it hit us hard.
Re: Why I Left the .NET Framework
#8Strongly disagree. I've watched scores of Linux-only developers try to do things on windows machines, stumble over small things, and then proceed to blame windows instead of realizing they simply lack experience.
Re: Why I Left the .NET Framework
#9Re: Why I Left the .NET Framework
#10Not having a debugger is like living in the stone age. Personally, the the ability to inspect application state at runtime is non-negotiable.