Hacker News new | past | comments | ask | show | jobs | submit login

It was Microsoft's answer to Java, with hindsight 20/20. I wanted to see their take on portable bytecode, JIT techniques, security, distributed computing, performance, etc. Nearly everybody there was burned by MS's short attention span when it comes to system libraries (OLE, COM, DCOM, DCOM+ for one, and the mess that is data-access libraries, OLE-DB,MDAC, ODBC, ADO, Jet, etc.)

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.




Part of the "Microsoft Tax" is that there is always a new new thing - when it comes to Microsoft selling products their biggest competitor is installed versions of their existing products not other vendors.


No, wait a sec. A good share of people is complaining about the lack of Microsoft's willingness to push the new shiny stuff - how much time did it take for them to come up with a MVC framework? - the other share of people is complaining that Microsoft pushes too much of a new stuff.

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.


Apples and oranges:

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.


(1) - I don't see the problem here. Somehow old DOS stuff still works in Windows 7. You need new features? They're coming with the newer OS, but your old features rarely go away. Contrast this with upgrades from PHP 3 to 4 or 5, stillborn Perl 6, great divide between Python 2 and 3.

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


I worked in a different era than yours. Today, you can pick and choose the microsoft stack you want to use, if any at all, because you have choice and they don't.

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.


Wait a minute... You are complaining that you are now forced to have updated looking and function software? Oh. The horror. That's a sure way to make your users mad. Sell them software today that looks like it was written 10 years ago... But wait, it was written 10 years ago.

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.


What? Did I not make myself clear or are you incapable of reading?

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.


"We wanted closure"; left the mess for Lisp. Indeed, the explicit use of closures is closely associated with Lisp.


I am sorry you have been downvotted, but that was indeed a deliberate word-mine, buried for your pleasure.

I do that frequently, but you're the first to point it out :-)


Did you HAVE to chase every new API as soon as they came out? Did MFC suddenly stop working? Did the Win32 API go away? Why couldn't you just keep going as you were until you really wanted to rewrite to new APIs?


Yes, if you want your corporate productivity app to be Office certified. The UI guidelines are pretty clear about how it should look and behave. First MS pushed the new CommonControls from IE on us, then there was an Office update, then XP came out with new UI elements, like rebars.

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.


And why is that mahmud? Because most developers, by a HUGE margin, wanted to this in VB. And in VB hosting COM controls in your app was super simple.

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.


That diagnosis about the second group fits me to a T. 100% correct you are, Sir.

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:

http://news.ycombinator.com/item?id=972423

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


Perl? You serious? Are you developing text-based system?


My first Perl application, after I put my Win3 app on hold, was a desktop GUI app for printing mailing labels. It had a builtin list building engine that scraped counties throughout Virginia and found information on new home buyers, and applications for building renovation.

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.


The only major failing of Perl is that its error handling facilities just flat out suck. Outside of that, it's a very modern language, albeit a little esoteric at times, and writing maintainable systems with it is possible with some discipline and common sense.

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.


Yep. That's why I bailed back in '99. You needed an MSDN subscription just so your apps could tread water.

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.


I don't see how this is any worse than trying to keep up with the latest version of some OSS library. Whether it's MS that's revving or open-source developers, changes happen, and if it's a breaking change in a shared library, sometimes you get hurt.

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.


Myopic viewpoints about code longevity tend to be driven by people that never worked on a project for more than 2 years. Few companies have business models that allow them to avoid the mess. It's not a problem for throw away projects or startups though.


The same PHP code has followed me round since 1999. From FreeBSD 4 to Linux to OpenBSD to FreeBSD 6 (but in a VM running on Linux).

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.


Distributing software always sucks, on every OS. It wasn't the language he had a problem with, it was the platform quirks.


I see what you're saying but upgrading an OSS library is usually undertaken by somebody that thinks beforehand "I wonder if upgrading this will have any implications" whereas clicking "Express" on update.windows.com is billed as pain free, just like all things point and click.

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.


You shouldn't be hitting 'express' on windows update on a live server just as you shouldn't be running 'update world' on a live linux server


Security updates and product updates are mixed on Windows (or were I don't know now). They called them "Option Packs" back then which sounds like it just brings another keg to the party not plans to re-arrange the furniture.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: