Live data from Hacker News

Why I Left the .NET Framework

blog.jonathanoliver.com

51–60 of 109 posts

Re: Why I Left the .NET Framework

#51

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

I used to always use the VS debugger when I used C# in school (my research lab used C#). Now, I use Python and C for work, and I never use a step debugger. For some reason I just don't miss it, and using print statements is just fine.

This is especially true in multithreaded code. I do a lot of Qt programming, and everything tends to be executed in an auxiliary thread.

I will say that I like step debuggers that come along with a REPL. This is probably the one and only thing I like about Matlab.

Lastly, I program in Haskell for fun (enough at least to write a small unit conversion library [1]). Because of laziness, I find the step debugger impossible to use. I definitely rely on print statements in Haskell.

[1] https://hackage.haskell.org/package/quantities

Re: Why I Left the .NET Framework

#52
post #47
post #28

Earlier quoted context omitted.

FYI, next version will have a JSON-based project file (whether this is better or not is left as an exercise to the reader).

Not really. When your build files are designed to be serialized IDE state no matter what the format you have limited your build system to what your IDE creators decided to express. This is not always what you need and that mismatch will only get more and more out of sync the longer your project lasts.

The current state is that the project files are MSBuild projects and Visual Studio itself supports only a subset of functionality (but leaves advanced things more or less alone). So the build system itself is quite a bit more capable of just what Visual Studio supports within the files and in many cases you can mix that quite freely.

Re: Why I Left the .NET Framework

#53

Earlier quoted context omitted.

You can try Clojure - it is both CLR and JVM. Lisps seem to never die completely :). Definitely not mainstream though.

Thanks. I know this is something I can do right now but a few things I wanted to look at was node.js and Angular. I'm definitely in need of catching up on some new techniques, I've been so engrossed in doing paid work that I've not had time to pick up a book and get back to the fun bit of programming

That would be a good experience!

You probably know this, but just a couple of generic facts up front:

Node.js is basically a http://en.wikipedia.org/wiki/Reactor_pattern implementation with some package management on top (similar to NuGet) plus a bit of healthy hype (solves all problems!). Microsoft is going to add this option as well it seems: http://blogs.msdn.com/b/webdev/archive/2014/02/18/introducin...

Angular is basically an MVVM implementation for JS, where most things are observable by default plus all the benefits and disadvantages of dynamic weak typing and lack of OOP. Directives are a new concept I guess, scope inheritance is another concept to watch out for (don't forget to install the Chrome extension for scope inspection - Batarang; .NET Demon + Chrome LiveReload is a nice thing to try as well when going WebAPI on server side). It is probably the best MVVM JS framework so far, so a good thing to know. Microsoft guys are using it too sometimes it seems (check the sources): http://status.modern.ie.

Re: Why I Left the .NET Framework

#54
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…

A million times this ^.

So much of the criticism I keep on hearing on... anything programming-related comes from people that have experience of basically ONE platform, which they tried to use for everything -- and obviously failed at times. Changing platform does solve some issues but creates new ones.

In time, once people experience a few platforms and they become able to distinguish when it is appropriate to use each tool, the true advantages and shortcomings of each.

Unfortunately many are stuck working in "one-trick shops", monocultures, and end up being inexperienced in the grander landscape of possibilities and completely loose the plot.

Re: Why I Left the .NET Framework

#55
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.

Re: Why I Left the .NET Framework

#56

I wonder how long did the author was using .NET since "bad" points were very weak. Also, it seems that author isn't really interested in what's happening and what MS already done to improve .NET. Like integrating Git with MS, async, open-sourcing C# source code, moving away from IIS to OWIN, K runtime, SqlDb as file. And also, if you don't like that Visual Studio is heavy you are free to use Vim with custom run param…

"Windows devs are typically only good at Windows and get lost very quickly outside of their comfort zones"

this is actually an oxymoron. Assuming we are talking about a one-trick pony, yeah, I can see how that is possible, but it's clearly a straw-man argument.

The problem is the mindset that all .NET developers are .NET developers only. This is completely false -- all good developers I know are comfortable on a number of platforms.

Re: Why I Left the .NET Framework

#57

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.

From reading all the previous threads, the answer seems to be Visual Studio.

Me, I use it because I know it, and because it works for me. I see no reason to jump ship.

Re: Why I Left the .NET Framework

#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 databases, lack of non-locking paradigm (async/await, parallel LINQ), are simply ignorant. And then he talks about windows devs being close-minded...

Re: Why I Left the .NET Framework

#59
I think there is migration away from .NET underway, as Windows loses market share to other OSes. Desktop apps are becoming more rare. Web apps are being written in open-source platforms. A lot of the companies still using .NET are large fortune 500 ones, maintaining existing systems. Remember Cobol? I'm almost at the point where I consider .NET legacy. Perhaps, not yet, but maybe in 5 years. Does this mean the well is dry for .NET developers? Not at all. Large companies will pay small fortunes to find people to maintain their legacy systems. Either way, I think it's important for developers to become proficient in multiple programming languages.

Re: Why I Left the .NET Framework

#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 without fancy options), it's horrible. There's no UI support for anything, and no CLI. I find myself resorting to msysgit a lot, and it has it's own problems. And the other devs laugh at me for it ("You're running bash, on Windows? Huehuehue"), only to experience the same problems as I do.

The .NET "async" model is not good for I/O bound problems, which is what I work on. Want I/O multiplexing? Well, you can have IOCP, but most people end up with one thread per connection anyway because I/O multiplexing is not an option in most parts of the library eco-system. Want to make an HTTP request? Have it done in a worker thread, because your HTTP library is blocking. I know things are changing, and I know there's other ways to go about this, but the author's claim that the concurrency model offered by .NET is inferior to others is a very valid one. I've done work in Java previously and it's basically the same problem. I've also experienced problems with lock contention, corner-case deadlocks, &c. Now these are problems related to the codebase, not the language itself, but threads as a concurrency primitive tends to cause programmers to make mistakes more often than other concurrency models in my experience.

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.

Post reply on HN