We wanted closure, at least I knew I did. Was barely 20 and had my first serious application. Hundreds of MFC files, elaborate Win32 API integration, MS Office integration and a whole lotta crap. They fucked me over seriously bad, and I have already sunk in a year and a half of my time, skipping classes just to make it. Everytime I implemented a subsystem a new memo would come out on MSDN Magazine telling me to use a component bundled with Office for that, or tie my app into the latest IE release, or "just" use ActiveX.
I fucking wanted an answer. Instead, the fat guy they paid to talk to us said we could all get highly paying jobs if we only learned this new, new thing.
I left that mess for good. First to Perl, then Lisp. Never going back to the API carrots on a stick thing.
C'mon, people, give me a break - yes, there're lots of new frameworks coming from MS. Well, that's what I would expect the company to do in order to give their developers some other options to be more productive. It's not like MS' competition is sitting around and doing nothing - Google has their own not-invented-here syndrome, Ruby community produces new frameworks every other week, PHP community clones whatever Ruby community produces... Technology isn't frosen and is always a moving target, that's life, get over it.
1) Microsoft is both the tool vendor and the platform vendor. The Ruby community can go ape-shit forking each other on github, but at least the underlying OS remains constant.
2) Microsoft tools cannibalized each other. There is nothing laissez-faire about its offerings: the new kills the old and the entire company, developers, reference materials, publications, marketing, and retail are in lock step. You just couldn't depend on using a disavowed infrastructure without fear of your bookmarks going stale, immediately.
3) They had no reason to phase out products and tools, at least no sensible reason. It's often to harm a competitor. Not only that, but they have sometimes pushed changes for the same of ill-advised aesthetic reasons. You had to be a C++ programmer 1997 - 200 to see how MS can bully. The push to COM and machine generated stub code. The fucked up pre-compilers. The weird new syntax. You could do everything with vanilla C++, but they were trying hard to keep Borland and other compiler vendors at bay, so you had to kowtow and come along with them.
Alright, this is seriously giving me flashbacks and might trigger PTSD.
(2) - Please... Your old frameworks are still there. You are discouraged to use them, but they didn't go away. I seriously don't understand how this is a problem?
(3) - Again, technology is not frosen. Competitors are coming out with new shinier things - why Microsoft should stick to only what was there back 20 years ago? So they push their shiny stuff into the limelight. But given that old frameworks are still in place, it's not a problem.
"The push to COM and machine generated stub code." - I don't understand your grudge here. Why didn't you ask yourself: do _I_ really need to use COM? COM solves some particular problem - was it _your_ problem? Did ole-good Windows API and C++ classes just go away with the advent of COM? I for one am a C++/Win32|64 and .NET dev. Last few years I'm asking myself a question - do _I_ need to use WPF, just because it is there? My answer is no - I'm just ignoring it, as I ignore other shiny things that don't solve _my_ problem.
BTW, maybe this will sound like a blasphemy here, on HN, but Microsoft could teach a thing or two to the "platform vendors" out there. The pace of change and amount of inconsistency that is being introduced by everyone and their dog with web service "APIs" is astounding. Compared to that, MS' approach of keeping of old stuff while introducing new one is simply a god-send.
Then, you sold software based on polish and integration in UI look and feel. You have to choose your tools very carefully, because of the realities of software publishing and distribution. You don't know how long it takes from the moment you press the CD-ROM, to the moment it goes on the shelf, to when it's bought. If it looks and works OK today, a year from now it would be butt ugly. Only hardware vendors could get away with ugly software. Even anti-virus software is polished and themed to oblivion. But mine corporate software with strong Office integration, it has to look modern, for some modern in the unknown future.
Did ole-good Windows API and C++ classes just go away with the advent of COM?
They didn't. I occasionally write native win32 apps with Dev-C++. But I could not, today, embed all third party components, be they MS' or off-the-shelf, using only pure C++ and win32 API.
There are tiers of Win32 interfaces and libraries, in terms of quality and system integration. On one end you have the Win32 API, and on the other end the latest managed .NET newfangled things (I am ignoring native NT layer and the DDK.) However, in between you have this graveyard of APIs, from OLE to ActiveX to COM to what have you. Each has been pushed with merciless fervor by MS, at a time when they were the only game in town.
I am glad you like your stay on .NET though. Cheers! I myself java just rediscovered Java (the JVM, really) and this is where it's at. Sun couldn't sell for shit, but they knew how to make software.
You are completely pushing the philosophy of technology needs to remain the same and consistant through all of time. Not possible, ever. Technology HAS to evolve or we all sit at a standstill. If you don't want to learn new things and stay modern in technology, then you need to sign up for truck driving, not software development.
They (MS) didn't just sit around trying to find ways to piss you off by coming out with new technology. They released one, found a way to improve, and released that next. Quite blaming the vendors and put the blame squarely where it belongs, with people who refuse to learn and evolve with the technology.
I am not "complaining about now", I am complaining about 10 years ago. Specifically '98-00. Fireup Wikipedia and do a little MS history research.
I want my software to look fresh and fit in with the UI of the environment. I said was coding for the future, i.e. use the most cutting edge software today, so by the time we put the software on shelves, it doesn't look old.
My #1 issue with MS, really, is that they let the official API stagnate and forced us developers to use Office and IE components, in the hope of integrating them with Windows.
I would make sense of your writing if it wasn't so weirdly phrased.
I do that frequently, but you're the first to point it out :-)
With every new release of Windows, Office or IE, the UI got tweaked. Pretty quickly you couldn't even use vanilla C++ anymore to embed the bulk of widgets/controls from Office to do basic stuff like showing spreadsheets in your app. You had to use COM.
I was a sole developer hoping to differentiate myself from other shareware authors by being on MS's good graces. Good grief! I didn't get peace of mind until I dropped them.
What I send to see are two classes of MS developers:
1) Those who use the MS stack, but realize they're using tools that they build with and on.
2) Those who use the MS stack, but get stuck thinking that it is the only tool available, period.
The second group of developers sometimes gets an epiphany when they change to a non-MS stack, because its so clearly obvious in the non-MS world that there is no stack that is convincingly better than any other. Group two expresses their outrage at the MS stack. While group one is mystified that they ever thought the MS stack is the end all be all.
Here's a hint as to how to find them ahead of time. Go talk to the guy who does .NET development today and ask what his favorite third-party controls are. If he has none and says, "I only use MS out the box controls" then this person will eventually become part of second group.
I have been a programmer longer, mostly cracking games and writing x86 asm and DOS stuff with Turbo C; but I became a developer on Microsoft's platform and under their auspices.
After Microsoft, I went through a few years of insane productivity and deep, god-level hacking. I have chronicled those stories else on HN. Here is one:
After I found "success" elsewhere as a programmer. When I finally saw a product of mine being used, shipped, bought, deployed. When I started seeing bug-reports, requests for bulk prices, discounts, and yes, piracy. That's when I made peace with Microsoft and went back to using Windows. I am typing this on XP.
They're an OK company with an OK platform, just not when you're young and impressionable. Beware of the bastards and use portable, 3rd party libraries.
I am done with this thread ..
It took me 20 days to develop. Perl/Tk.
If memory service me right, and I really could be wrong .. I think I must have been the first one in the world to hack together a bridge between Perl and Office 2000, because I had a developer preview. ActivePerl .. now that was a delightful platform.
Perl empowered me. If it wasn't for Perl, I might have quit software altogether and became a philosophy major, or worse, a mathematician.
To boot, Perl natively supports modules written in C, and by way of DynaLoader.pm, a programmer can do fun things with exported symbols from object code. I wouldn't go as far as to call DynaLoader.pm a proper FFI, but it definitely gets the job done a lot of the time.
Phone rings "Hi, we upgraded our NT server and now your software is broken".
Many hours later "Oh MS changed the DB connection pooling to OFF"
Me: Hmm, this Personal Home Page things looks ok, I'll give that a try.
And as horrible as PHP is, it behaves itself.
Just yesterday there was a "goodbye python" article posted here, that blamed the fact that so many Linux installations have old installations of python, and so many things are broken when modules in the installation get updates.
Early on in my career I was given a codebase that adhered to every lesson in How To Write Unmaintainable Code. I can't thank fate enough.
Plus I had followed the advice in MSDN concerning connection pooling which was a registry setting for ODBC NOT part of the framework I was using (VBscript in ASP). Responsibilty for pooling was pushed into the framework.
The goodbye python article was about assumptions one could make about what would be available before one's code arrived. I bet php3 code still runs just fine.