Live data from Hacker News

Why I Left the .NET Framework

blog.jonathanoliver.com

91–100 of 109 posts

Re: Why I Left the .NET Framework

#91
post #73

> Why do we develop this way? Why aren't we considering the behavior of the application more than how it's stored? All of my projects now utilize a JSON-based key/value store. What a self-centered statement. "MY projects don't need ACID or relational enforcement. Therefore, SQL is useless."

Yeah, I was particularly amused by OP's statement here.

As the original poster, I have found that relational databases have become our favorite hammer. The point of my post however is that things like the modern NoSQL movement did not originate in Redmond. Open source drove NoSQL to the forefront. If it were up to Oracle and Microsoft, we'd be using RDBMS forever.

Re: Why I Left the .NET Framework

#92
post #15
post #4

Some really good criticisms, but I do wonder how long ago this developer left .NET. .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…

I recently had to spend a lot of time with csproj files. They look and behave rather a lot like Ant/Maven. This is not a point in their favor. Ant/Maven was loved and then subsequently hated by a lot of java developers. XML is an extremely verbose syntax to have to deal with. But the real killer is one of lockin. Yes you can use msbuild to do things with them but the syntax is really designed not for a developer to r…

MSBuild files are actually far more powerful than what you just see from within Visual Studio! There is a bunch of cool stuff you can do with them (such as conditionals) that you do not have access to from within the VS IDE.

The .NET MicroFramework actually is an example of a project that uses MSBuild files for all sorts of crazy stuff, like supporting tons of different compilers (including GCC!).

Funny enough, it actually is possible to make VS support other compilers as well! (I've seen it done, honest!)

Editing them is no more painful than editing any other form of XML. (Err, not sure which way that is arguing!)

Re: Why I Left the .NET Framework

#93
post #60
post #4

Some really good criticisms, but I do wonder how long ago this developer left .NET. .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…

I'm from a Linux/FreeBSD background. I'm currently doing work on a Windows platform. > 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. Git in visual studio does not work well. I'm using the built-in stuff in VS2013. If you want to do anything except the standard stuff (add, commit, pull, push…

> And no, make files and .sln files are just not the same. They're both a part of the build system, but that's about it. I'm not even going to argue a point here, because it just fills me with rage to think about that god-forsaken fragile, XML setup that is .sln.

SLN files are not really part of the MSBuild system at all, nor are they XML. They seem to exist solely for the IDE's benefit!

Indeed I've used plenty of projects that use MSBuild but no SLN files.

Re: Why I Left the .NET Framework

#94
post #6
post #3

I 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…

> 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. 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…

Whatever. I work at Microsoft and use sysinternals tools all day and then come home and use my Unix box where all that shit is built in and composable via like 4 command line apps.

Re: Why I Left the .NET Framework

#95
post #93
post #60

Earlier quoted context omitted.

I'm from a Linux/FreeBSD background. I'm currently doing work on a Windows platform. > 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. Git in visual studio does not work well. I'm using the built-in stuff in VS2013. If you want to do anything except the standard stuff (add, commit, pull, push…

> And no, make files and .sln files are just not the same. They're both a part of the build system, but that's about it. I'm not even going to argue a point here, because it just fills me with rage to think about that god-forsaken fragile, XML setup that is .sln. SLN files are not really part of the MSBuild system at all, nor are they XML. They seem to exist solely for the IDE's benefit! Indeed I've used plenty of pr…

My mistake, I was confusing .vbproj/.csproj-files with .sln files.

Re: Why I Left the .NET Framework

#96
post #60

Earlier quoted context omitted.

I'm from a Linux/FreeBSD background. I'm currently doing work on a Windows platform. > 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. Git in visual studio does not work well. I'm using the built-in stuff in VS2013. If you want to do anything except the standard stuff (add, commit, pull, push…

Perhaps you know less about the build system than you think. SLN is NOT XML, it's some strange line-based format, that essentially lists projects. From there the whateverproj files are XML and valid MSBuild files. Git works fine in VS. Use Git Extensions.

> Git works fine in VS. Use Git Extensions. I don't know, but I think Git Extensions is superseded by the built-in Git support in VS2013. And it's very limiting if you want to do anything except the basic add, commit, pull, push stuff.

Re: Why I Left the .NET Framework

#97
Good article. A lot of the criticisms are ones that I often hit as well. I would probably dispute the asynchrony/performance one, though. C# async is very efficient -- a lot more efficient than many other eventing frameworks in many other languages. In addition, I don't really think that locks are specifically put ahead of lock-free things like InterlockedExchange when dealing with multithreaded code -- it's just that writing lock-free datastructures is so damn complicated (seriously, read the literature, it's really hard to get right), that for the everyday programmer a lock is the way to go. Moreover, there's not really a connection between async/eventing and locking; they're somewhat orthogonal. In large applications I would probably see a healthy dose of both. Async doesn't help with CPU-bound computation and threads aren't really the best way to deal with concurrent IO-bound computation.

Otherwise, I strongly agree with the points about Mono. Speaking personally, I would love if more of the .NET platform were extended for use on Linux, as I think the Windows CLR GC is still pretty far ahead of the Mono implementation.

Re: Why I Left the .NET Framework

#98

Earlier quoted context omitted.

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.

> The trouble is that "the ordained path" is MS tooling all the way

Every .Net shop that I've walked into, "the ordained path", speaking about the coding culture, was nUnit, TeamCity, Resharper, svn (later git) etc. Maybe you worked at the wrong places.

My anecdote doesn't trump your anecdote, but the reverse is also true.

Re: Why I Left the .NET Framework

#99

.Net developer here. I think VS is really awesome and a + for .Net . The support for Mono and cross platform has grown and Microsoft has shown interests by partnering with the team behind Mono.. IIS is getting decaprecated (= The OWIN project). LocalDB doesn't require you to create a new database and you really have a json file as database . You can just use it, it's called Biggy and it's on GitHub ( https://github.c…

> IIS is getting decaprecated (= The OWIN project)

Thats not even remotely true. How does Helios works then, which is also owin component?

Re: Why I Left the .NET Framework

#100
post #99

.Net developer here. I think VS is really awesome and a + for .Net . The support for Mono and cross platform has grown and Microsoft has shown interests by partnering with the team behind Mono.. IIS is getting decaprecated (= The OWIN project). LocalDB doesn't require you to create a new database and you really have a json file as database . You can just use it, it's called Biggy and it's on GitHub ( https://github.c…

> IIS is getting decaprecated (= The OWIN project) Thats not even remotely true. How does Helios works then, which is also owin component?

Perhaps decaprecated is a strong word, using IIS becomes optional thanks to OWIN would be better.

OWIN replaces the hosting part of IIS, so while you will always be able to run Asp.Net websites on IIS, IIS isn't a requirement anymore. (OWIN = Open Web Interface for .NET)

See the following link for a more thorough answer.

http://stackoverflow.com/questions/21308585/when-should-i-us...

Or http://www.dotnetcurry.com/showarticle.aspx?ID=915

Project Katana is a collection of projects for supporting OWIN (http://owin.org) with various Microsoft components. So yes, that obviously uses IIS. But IIS can be replaced by Apache or NGINX in the near future. Katana could be used as an example to implement the same thing for those webservers.

Post reply on HN