"The
I'm struggling to understand what you mean by this, it doesn't really make any kind of sense. Are we talking about upgrading code, or upgrading the CLR?
You tell me...
3.5 code is forwards compatible, the breaking changes are minimal and insanely rare edge cases).
untrue.
...3.5 runs on the 2.0 runtime, and 4.0 had it's own new runtime.
Thanks for proving my points. That's exactly right, and exactly what was a horrible nightmare to deal with. Those few, edge case incompatibilities were what hit me each time. And, the 3.5->4.0 wasn't as minor as you make out. Even the 4.0->4.5 isn't 100% smooth, nor would it be, given the shenanigans MS did there.
The
Java generics mostly are syntactic sugar. They allow for less boilerplate code, but if you don't understand what's happening under the covers, it makes no difference. Spring is the devils path to hell. Try debugging a Spring initiate's code sometime. The exorcist will have nothing on your head spinning. ORMs are pretty much all sucky bad. RDBMs just don't mesh with ORMs, as they're orthogonal. Any idea you have that they're not is mistaken or because you're at the LCD point.
Regarding uptime, I code with Java, Xcode, and Android Studio currently, and my uptime is measure in months. I also use git. (who would use svn? It's irrevocably broken by design unless it's 1 user per source tree) What you're describing is a nightmare trifecta of bad tools, bad process, and bad developers. Any 1 of the three will be an unpleasant experience, but all three? You have my sympathies.
While I normally don't respond to deeply biased trolling morons (most ACs), you've made some incredibly bad assertions. While I won't disagree with the desktop workload statement as almost any normal desktop workstation workload can be handled by a phone these days, the extra capability in the desktop merely increases the available headspace and has 0 effect on the tasks at hand. MS systems (desktop or otherwise) running MS SQL are inherently worse at anything SQL. Well, at least if you want to scale for business purposes. They may be on par for a single SQL query, or a personal DB, and perhaps even a little better in the last case as a replacement for Excel. In this case I speak from multiple personal experiences. MS SQL is wholly unsuitable as a DB for anything requiring load.
Heck, you're aware of course that windows has horrible context shifting costs? That alone dooms it in high performance high concurrency scenarios of the types running in servers? You can start reading here. It's really fascinating how MS worked so hard at cutting corners to create something that ran single threaded semi well at the cost of running the types of loads servers run really badly that it should come as no shock at all that *nix servers, which made the opposite architectural decision, run server type loads far more efficiently than windows ever will.
AD is a laughable POS. In fact, it is so terrible, I can barely even describe it. I recall when AD came out, and Exchange was hamstrung to that turd. Something that used to take 5 minutes wound up taking 6 hours. The only difference? AD. It hasn't gotten better.
SCCM (formerly SMS) sucks rocks too, it just sucks a little less than most other GUI packages out there. That's not an endorsement. You can put as much lipstick as you like on that turd, it won't change the stink. The best system I ever saw in this space was a variation of *nix long ago. Anywhere you went, the desktop, as it was, was there. In fact, this was far enough back that "desktop" wasn't even part of the lexicon. It was merely known as your home directory. But no matter what machine you were on, it was like you were "home". SGI's GUI version was also pretty darn decent, at least where I was at the time. Too bad it cost an arm and a leg even in today's dollars. The mid-level graphics card alone was $25K.
People still develop for windows? Why? (yeah, I better duck, my karma is taking a beating today:)
Windows destkop and servers are still being deployed in the millions,
Windows servers in the millions, there's a reason for that. Last time I had real numbers to compare 2 large scale equivalent systems: UNIX: <100 servers, Windows: about 2400 servers. Same basic workload, different codebases and languages (Java / COBOL for *nix, C/C++ MS SQL for Windows). Oh, and the windows system was much less capable.
Seriously though, Windows servers are in decline, and have been for a while. They're a screaming security risk, perform poorly - *nix of any reasonably modern flavor smokes windows on the same hardware, unless, of course, you're attempting to run a windows program under an emulator or API framework under *nix.
I am certain both you and benjymouse, if you are LINQ proponents, don't have a clue how to write high performance data access layers. I have had to undo that wonderful ORM/LINQ crap clueless morons like both of you (assumed by your comments) created because "it is awesome". Awesomely bad. LINQ straight-jackets you, as does every ORM library out there. It's just like a drug dealer, that first hit is free... That doesn't mean that you shouldn't use them as they have their place. But overall, be aware of their short-comings and make sure to wrap the access layer such that it can be wholesale replaced if need be.
"Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." -- Virginia Woolf, "Mrs. Dalloway"