How Microsoft Dropped the Ball With Developers 814
cremou writes "As part of an Ars Technica series on how one developer migrated from Windows to OS X (and why), this second article concentrates on how Microsoft bungled the transition from XP to Vista. The author looks at some unfortunate decisions Microsoft made that have made Windows an unpleasant development platform. 'So Windows is just a disaster to write programs for. It's miserable. It's quite nice if you want to use the same techniques you learned 15 years ago and not bother to change how you do, well, anything, but for anyone else it's all pain... And it's not just third parties who suffer. It causes trouble for Microsoft, too. The code isn't just inconsistent and ugly on the outside; it's that way on the inside, too. There's a lot of software for Windows, a lot of business-critical software, that's not maintained any more. And that software is usually buggy. It passes bad parameters to API calls, uses memory that it has released, assumes that files live in particular hard-coded locations, all sorts of things that it shouldn't do.'"
Long Answer? (Score:3, Funny)
Short answer?
Windows!
Re:Long Answer? (Score:5, Funny)
I hate Windows. It robs me of my creative juices.
Because I am creative, you know... man?
So I "Switched".
Now, I code for OS X and every day is a beautiful rainbow for me.
Re: (Score:3, Insightful)
"Regular updates to the OS keep developers on the upgrade treadmill; they work to make their applications fit in with the latest and greatest release, leveraging whatever new bells and whistles it provides, further improving the software ecosystem."
As we see from the Windows and Mac OS (pre-X) ecosystems, this is completely false. Developers are loathe to change custom-written code that they know works in order to implement some kind of link to the OS; and in many cases they'll let old versions of their
Re:Long Answer? (Score:5, Funny)
Re: (Score:3, Funny)
Re:Long Answer? (Score:5, Interesting)
Because let's be honest, while I use linux all the time, and I contribute every now and then to a number of linux apps. But I don't kid myself that anything that can run on linux (whether kdevelop or eclipse, or *even* vim) is half as good as visual studio.
And it's still the only real dev platform for smartphones and pda's. I have a maemo device, which is nice. But developing for it is a bitch to say the very least.
Re:Long Answer? (Score:5, Informative)
No it's not. I've been using Xcode for several years and I still haven't figured out how to build a Windows application with it. Conversely, Visual Studio cannot be used to build a Macintosh application either. The two IDEs are used for different tasks so they can never be competitors.
Is Xcode as good for developing Mac applications as Visual Studio is for Windows applications. I think probably not. It has some superior features (NB the most recent version of VS I have used is 2005 so my knowledge may be out of date). It has some features I like better than VS but that''s probably because I prefer the Mac environment. It has some features that are worse than VS. The debugger is the worst of these IMHO.
On balance Visual Studio is a far better developer environment, but that counts for nothing if you are trying to write a Mac GUI application, in which case Xcode is the only game in town as far as I know.
Re:Long Answer? (Score:5, Interesting)
About the only thing I see VC++ having on Eclipse 3.3 for plain C++ development besides debugging is speed. Visual C++ is comparably fast, but Eclipse isn't slow in the "it takes a while to respond" sense, but rather in the "there is a 7 second splash screen when you start it" sense. I can live with that.
I was rather disappointed, really. I had thought that I had given up a great IDE (VC++) to go to a great OS (Linux) with a moderately decent IDE (Eclipse); in reality, looking back I have up a decent IDE to go to a great OS with a great IDE. A few years ago I loved Visual C++ 6, and I suppose I'm just sad to see its ancestor thwarted on my desktop so easily by a free program.
(Disclaimer: The statement above is merely my opinion. Your opinion may not match it.)
Re: (Score:3, Insightful)
I think the giveaway is when he says a screen shot is worth a thousand words, then his screen shot is of vista with the taskbar at the top, Im not saying nobody has the taskbar at the top but its just one of many signs that hes a fan of apple.
Im no programmer but the article seams short on facts & details and high on ms bashing & skimming.
Is the article right or is it just well presented trolling?
Re:Long Answer? (Score:5, Insightful)
Re:Long Answer? (Score:5, Funny)
Re:Long Answer? (Score:5, Funny)
Re:Long Answer? (Score:5, Funny)
Re:Long Answer? (Score:5, Funny)
Re:Long Answer? (Score:4, Interesting)
Unless you set Windows to do something other than shut down when you press the power button that is.
Re:Long Answer? (Score:5, Insightful)
The problem is they know a lot of people aren't happy with Windows but it runs all their programs. Once the scrap that backwards compatibility and build something solid, despite the fact it may be their best OS ever, it's on a level playing field with the rest which means people have to find an alternative to their old programs and they might just pick something that isn't Windows and MS isn't having that.
Re:Long Answer? (Score:5, Interesting)
Re:Long Answer? (Score:5, Informative)
IE's rendering engine can go in the legacy libraries for old apps, for example, while being a modular component that's fully removable in the new OS (thus keeping the EU competition comissioner happy)
That's the theory anyway. Whether MS manage to pull it off is another question.
Re:Long Answer? (Score:4, Funny)
Re:Long Answer? (Score:5, Interesting)
Well, sort-of. He concentrates way too much on the Win32 API, which not too many people are using directly. His big complaint about Windows Forms was threading, which doesn't seem like a big issue (you may have multiple threads once-in-a-while, but will you have more than one working with the UI?) -- otherwise he just kinda says it sucks without suggesting anything better (SWT might be a possible candidate. Swing is not.).
And the
Re:Long Answer? (Score:5, Informative)
And NeXTStep is a magical, shiny, new API compared to Win32, which is the biggest mess I've ever seen. Admittedly, I'm used to simpler systems like UNIX.
Re:Long Answer? (Score:5, Insightful)
Re:Long Answer? (Score:5, Insightful)
Re:Long Answer? (Score:5, Insightful)
Having to drop into Win32 to call some legacy thing that no-one should really be doing but which you have to do for backwards compatibility, that I could sort of understand. But having to drop into Win32 to call new features that have only just been added? Anyone saying "stop using Win32, just use
Re:Long Answer? (Score:5, Insightful)
Well, there is a good reason why it's not valid: because it makes .NET developers give a damn about HWNDs, message pumps, and the interactions between the two.
Off the top of my head we have, for example:
Win32isms are abundant.
Let's just recap the argument, shall we?
1) Claim: Win32 is clunky and horrible
2) Response: Write in .NET
3) Claim: .NET can't do everything Win32 can do, forcing me to use Win32
4) Response: "your arguments [...] make no sense to me"
Look, if the argument is going to be "Don't use Win32, use .NET" then .NET has to do all the things that Win32 can do. So which is it?
Either I should be using .NET--in which case MS's failure to add new Win32 features to .NET is a problem--or I should be using Win32--in which case "use .NET" is not a suitable response to cited flaws with Win32. You can't have it both ways, so which is it to be?
Re:Long Answer? (Score:5, Funny)
Re:Long Answer? (Score:5, Insightful)
I am in that third group of developers this article was supposedly written for. I absolutely abhor poorly written code, cheap workarounds, etc. And I make a living off
Re:Long Answer? (Score:5, Interesting)
Re:Long Answer? (Score:4, Funny)
I heartily encourage everyone else, especially all developers in low-income areas of the world, to Make the Switch ASAP. The less labor supply for these horrible, inconsistant Win32 APIs (really, it's like programming while your face is on fire), the better!
Re:Long Answer? (Score:5, Insightful)
Re:Long Answer? (Score:5, Interesting)
I agree. It sounds to me like this guy used .NET for a year or so around 2002 when it was brand new and then left and hasn't looked again for the last six (6) years. He is the first person that I have heard accuse .NET of being "too simplistic". The .NET class library (and Java class library as well) is the definition of everything and the kitchen sink. These are extremly powerful languages and libraries that are if anything too complex.
You seem to be confused between broad (.NET supports a lot of things, like sockets and cryptography and distributed transactions and GUIs and XML and oh my!) and powerful.
.NET does a lot of different things, but .NET doesn't have the greatest underlying abstractions. For example, to name a few:
Re:Long Answer? (Score:5, Interesting)
My own additions - from doing Sharepoint:
- Key classes (SPSite and SPWeb) that are IDisposable. That's not too much of a problem, except that the documentation is somewhat vague on how to handle them - calling some methods will e.g. initialize the RootWeb property of SPSite, which you have to dispose, despite never having called RootWeb yourself. And sometimes you have to take care _not_ to dispose, as you are handed a reference to a shared instance of an SPWeb or SPSite.
- Several nice components are sealed and/or internal - my current pet peeve is a webpart, which has its look and feel defined via XSLT-files (big poorly documented XSLT-files, that do a lot of scary things to dump a lot of ugly HTML), unfortunately these XSLT-files are used by several different webparts, and some of them have neither the ability to subclass the webpart to use another file, nor the option of configuring which file to use. The only way to change that look and feel is to change the standard files.
- Checking user permissions in some places requires you to call a boolean method and receive true for access (sounds good so far, right...) and an exception for access denied!
- Not only is the default rendering a load of IE specific crap, if you dig deep enough, you'll find hardcoded strings inside the core libraries that, to the best of my knowledge, are not valid HTML in any contemporary standard. And the only way to get rid of it is to capture the output stream and clean it up by hand, one string pattern at a time.
- And that reminds me of a
- And another Sharepoint gripe - why are all the interesting parts of my code inheriting stuff, that makes unit testing a real pain (I tried to mock my way through it once or twice, but the amount of code needed to test without invoking the database backend is beyond what I could justify even trying).
Re:Long Answer? (Score:4, Informative)
Except for to confuse me, why do ICollections have a Count, when arrays have a Length? What's the meaningful semantic distinction that I'm missing here? ICollections implement an IEnumerator interface and have an Enumerator object which counts the objects in a collection. Think of an enumerator as an odometer (like the one in your car). If the object implements ICollection, then it has an odometer, which you can get the count from. Arrays just have size.
Why do arrays have LongLength but with no corresponding LongCount for ICollections (3.5 adds LongCount as an extension method, but that gives it inconsistent (method) syntax, and of course it can never work because even if the collection were extended to support long lengths, an extension method can never exploit that fact, because the extension just works on IEnumerable which supports only an int Count)?
Again, difference between an attribute and a verb. LongLength is an attribute of an object, such as height or width. Whereas Count is like an odometer in your car. Your question is kind of like asking why can you travel tens of thousands of miles along the US highway, but my odometer in my car only goes up to 1000. Well, that's just the way the odometer was made. Length of trip is distance, whereas your odometer is a counter and is only a *measure* of distance. It's simply a distinction the language makes.
Why do arrays have LongLength, and not simply have Length be a long? It surely didn't take a whole lot of foresight to figure that one out, did it?
Chunking.
Where do I find reverse iteration/enumeration? Where do I find bidirectional iteration/enumeration?
Using the odometer analogy as above, the enumerator only goes forward; although you *can* reset it. If you want to do reverse iteration, copy your collection into a new collections backwards, and iterate over that new object. Alternatively, for most reverse or bidirectional iterations, you'll simply want to ditch the 'foreach' loops, and use a simple 'for' loop. Then you can start high and use decrement iterators to count down. I also like to use decrementor collections which get an object removed with each pass of the for loop.
Why is there no generalized mechanism for storing my position in a container?
You need to get the IEnumerator object from the ICollection, using the GetEnumerator method. It will have a Position field.
Why is there no SortedSet?
Probably implemented somewhere else.
Why are there no static type-inferencing factories for read-only collections or singleton collections? When you have generics, factory methods are good, because factory methods can infer. Don't make me type IList myReadOnlyList = new ReadOnlyCollection(myList); the double specification of the type is spurious.
You're splitting hairs here. It's a strongly typed language. It's meant to be explicit, not inferential. In other projects, besides yours, double specifying types is needed and a useful (if not critical) feature.
Why is it named ReadOnlyCollection when it is in fact a IList? Why is there no true ReadOnlyCollection (i.e. that is actually useful for collections)? Why is it na
Re:Long Answer? (Score:4, Interesting)
ICollections implement an IEnumerator interface and have an Enumerator object which counts the objects in a collection. Think of an enumerator as an odometer (like the one in your car). If the object implements ICollection, then it has an odometer, which you can get the count from. Arrays just have size.
Count is not a method; it is not asking "Count how many things are in this object". It is a property, and as such an intrinsic feature of the object (that behind the scenes it might have to do the verb thing is beside the point--it's semantically a property, even if it's actually a verb). And even if one were a verb--why should be it?
Again, difference between an attribute and a verb. LongLength is an attribute of an object, such as height or width. Whereas Count is like an odometer in your car. Your question is kind of like asking why can you travel tens of thousands of miles along the US highway, but my odometer in my car only goes up to 1000. Well, that's just the way the odometer was made. Length of trip is distance, whereas your odometer is a counter and is only a *measure* of distance. It's simply a distinction the language makes.
Again, though, the language doesn't make the distinction you are making. Count is a property, just like Length. If Count were a method I could sort of understand the difference (I don't really agree with it, it seems spurious, but I could sort of understand it). But it's not; it's a property.
Chunking. .NET gets used on both 32 and 64 bit platforms, and the performance penalty for splitting a 64 bit word into two is greater than using two 32 bit words. In the first case, you still have to use 64 bit words, but you pad the first 32 bits with zeros, and convert to 32 bit words. Requires an extra pass through the processor to calculate, whereas adding two 32 bit words into a 64 bit word is trivial. I'm not explaining this concept well, but if you look it up you'll find more info on the question you're asking. The design decision was based on current market saturation of 32 bit processors, and the LongLength was an added conversion for the 64bit programmers.
But LongLength means we won't have a clean transition, because it means people will have to fix up APIs to take longs where they currently take ints; making everyone pay the price for longs might be a short-term cost (though not a great one), but it'll be a long-term gain.
Using the odometer analogy as above, the enumerator only goes forward; although you *can* reset it. If you want to do reverse iteration, copy your collection into a new collections backwards, and iterate over that new object. Alternatively, for most reverse or bidirectional iterations, you'll simply want to ditch the 'foreach' loops, and use a simple 'for' loop. Then you can start high and use decrement iterators to count down. I also like to use decrementor collections which get an object removed with each pass of the for loop.
That really doesn't answer the question. In both Java and C++ I have iterating objects (java.util.ListIterator, C++ bidi/random iterators) that can go forwards and backwards. I use these quite regularly; why can .NET not provide the same?
You need to get the IEnumerator object from the ICollection, using the GetEnumerator method. It will have a Position field.
Neither here: http://msdn.microsoft.com/en-us/library/system.collections.ienumerator.aspx [microsoft.com] Nor here: http://msdn.microsoft.com/en-us/library/78dfe2yb.aspx [microsoft.com] So I'm not altogether sure what you mean.
Probably implemented somewhere else.
I don't understand what you mean.
You're splitting hairs here. It's a strongly typed language. It's meant to be explicit, not inferential. In other projects, besides yours, do
Re:Long Answer? (Score:5, Funny)
Windows is bad for developers.
Long answer?
Windows is bad for developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers!
(The lameness filter complains about my Ballmer joke -- it must be detecting residual Microsoft lameness.)
Re:Long Answer? (Score:5, Insightful)
Code first, design later. For example, I note with interest the amount of pain involved in trying to provide server protocol documentation for the EU. Some of the foot dragging is deliberate but some of it is that they don't have quality internal documentation.
There is a severe lack of direction and leadership at Microsoft. They are just not forward planning. As a result they are tearing themselves to pieces, doing the same work again and again.
With those arguements, any platform can suck (Score:5, Insightful)
Those are basically programming errors, not problems with the API. Don't get me wrong, I find Win32 to be a pain in the ass sometimes, but this article just reeks of flamebait.
Re:With those arguements, any platform can suck (Score:5, Insightful)
The problem is that many major legacy applications depend on undocumented behavior because they make sloppy use of the Windows API (e.g. by assuming that a particular function will not segfault when passed a bad argument). For those to keep working, newer revisions of the API implementation must have the same undocumented behavior, which causes a maintenance nightmare.
Re:With those arguements, any platform can suck (Score:5, Informative)
Re:With those arguements, any platform can suck (Score:5, Insightful)
While this has short term benefits, the long term imposes a hefty penalty, the same penalty MS (and some of its developers) is paying now.
Re:With those arguements, any platform can suck (Score:4, Insightful)
The term you look for is "enabler" (Score:4, Insightful)
The term you are looking for is "enabler" - Microsoft is an Enabler for other applications to engage in bad practices, for users to engage in bad security.
As you say it makes a lot of people happy now, but look what else it has given us - lots of decrepit systems, and hundreds of thousands of zombies that make our lives miserable in other ways.
Sometimes even a business can't just be about making people happy, it has to be about moving the market as a whole to dry land when they see the flood coming.
Just like the Spiderman quote tells us.
Re:With those arguements, any platform can suck (Score:5, Insightful)
I thought we discussed this when Apple did it? Undocumented APIs are there for the use of operating system developers and other people who feel the need to tickle the operating system at a low enough level to fool it into doing things that it was never intended to do for you. This is your prerogative; it's possible to sniff through the structure of the binaries to find new functions, and it's possible to debug functions to see what they're calling, so no one can really stop you anyway.
At the same time, being upset when they stop functioning correctly is the mark of a whiny idiot, because let's face it, they're undocumented. If you want that functionality exposed, by all means, cry to the OS vendor. Or, you know, you could support open source and/or free software and work with an environment in which you have all the source code and can at least make relatively responsible use of the undocumented functions, and if you are feeling froggy, even submit patches which express this functionality consistently with a documented API.
Seriously though, undocumented functions are par for the course. If the functions are never intended to be used by anything other than the operating system, and the functionality is expressed through the OS in some fashion (use of undocumented APIs in Win32 has often been done to work around a bug) then there's really no problem. The portions of the OS that need to be changed when the libraries change can be changed in such a situation (and hopefully will fail tests if someone doesn't think to do it beforehand.)
What part of "Undocumented" is hard to understand? (Score:5, Insightful)
So, you problem is that programmers make use of undocumented API calls. While "undocumented" does not always equal "unsupported", using them is just plain stupid. Whether it is Windows, Linux, MS-DOS, DR-DOS, OSux using the system in an undocumented/unsupported way is well, U N S U P P O R T E D. Don't blame the OS or the those that coded it, blame those that wrote against the API in an unsupported way.
RTFA turns out to be a effort in slogging through another of the author's attempts to explain why anyone on Windows is just benighted. He blames HIS short comings on the OS.
Re:What part of "Undocumented" is hard to understa (Score:5, Interesting)
(sarcasm off)
Windows has always been annoying to develop on; when you've got the lions share of the market, and the customers want "windows," that where most programmers are, annoying or not.
So maybe they "dropped the ball," I say they never had the ball to drop, and they don't give a crap because if you want to make money, you work on Windows.
Now... how is this different than last year, or the year before, or ten years ago?
Re:What part of "Undocumented" is hard to understa (Score:5, Funny)
I learned to live without money instead. It was less painfull.
Re: (Score:3, Funny)
Re:What part of "Undocumented" is hard to understa (Score:5, Insightful)
I think that's why Microsoft is afraid of breaking the old APIs. Once you have to go through the pain of porting to a new API why not just go cross platform?
Re:What part of "Undocumented" is hard to understa (Score:4, Interesting)
Re:With those arguements, any platform can suck (Score:5, Insightful)
I think you missed the point. For the sake of backwards compatibility, Microsoft supports applications which do all these things, and drags all the associated crap into future versions of Windows so they still run.
For that matter, so do hardware developers: back when I was writing drivers for Windows I had to deliberately put bugs in our code to support applications which only worked because of bugs in the Microsoft versions of the drivers and would crash if we didn't replicate those bugs ourselves. We also spent weeks working around abuse of the API by a certain big computer company that can't program PCs worth a damn (or even, apparently, read API documentation).
Re: (Score:3, Funny)
Re:With those arguements, any platform can suck (Score:5, Insightful)
Linux, in comparison, provides a fair amount of backwards compatibility, but doesn't have to overly worry because most software comes in source form and can be fixed when a kernel or library change breaks it. Windows doesn't have that option.
Right, so users are held hostage... (Score:3, Interesting)
DOS/Windows programming culture (Score:5, Informative)
The culture is all about writing code to get past deficiencies and shortcomings in DOS/Windows.
Windows programmers don't respect the rules... and if they do, they write what appears to be crappy software.
Re:DOS/Windows programming culture (Score:5, Interesting)
Re: (Score:3, Interesting)
Re:DOS/Windows programming culture (Score:5, Informative)
I was used to PDP-11s keep in mind.
The problem wasn't the 68000 wasn't ready, it was ready. There were just no support chips yet. Intel actually delivered a complete solution: CTC chips, PIC's, serial ports, dma controllers, i/o processors (that nobody but us used).
Motorola had a CPU and that's it. A vastly *superior* CPU, but the hardware guys wanted to build systems not wait for the rest of the stuff they needed. So we all held our noses and went x86. And bought Amigas as soon as they were out (I have serial #11. Still.)
This crap as all in one chip these days, but back then computers had several large black chips inside them.
Re:DOS/Windows programming culture (Score:5, Interesting)
According to the guys that created the IBM PC (Bill Lowe and Jack Sams), they did it this way because they thought they were running out of time in an important new market (PCs). The Apple II had been introduced in 1977 and was a runaway success. IBM noticed Apple IIs being used in the engineering departments of their clients.
IBM's top management met in August 1979 to discuss their "PC crisis." In another year, the PC industry might be too big for even IBM to take on. IBM chairman Frank Carey knew that it took "four years and three hundred people to do anything" at IBM. Bill Lowe, who would lead the IBM PC development team, claimed that his team could provide their product in a year. Carey gave Lowe two weeks to set up a proposal. Two weeks later, Carey bought it.
From the transcript:
Bill Lowe: Head, IBM IBM PC Development Team 1980: He kind of said well, what should we do, and I said well, we think we know what we would like to do if we were going to proceed with our own product and he said no, he said at IBM it would take four years and three hundred people to do anything, I mean it's just a fact of life. And I said no sir, we can provide with product in a year. And he abruptly ended the meeting, he said you're on Lowe, come back in two weeks and tell me what you need.
[Cringely narrating] An IBM product in a year! Ridiculous! Down in the basement Bill still has the plan. To save time, instead of building a computer from scratch, they would buy components off the shelf and assemble them -- what in IBM speak was called 'open architecture.' IBM never did this. Two weeks later Bill proposed his heresy to the Chairman.
Bill Lowe: And frankly this is it. The key decisions were to go with an open architecture, non IBM technology, non IBM software, non IBM sales and non IBM service. And we probably spent a full half of the presentation carrying the corporate management committee into this concept. Because this was a new concept for IBM at that point.
BIOS was only a small part of the picture (Score:5, Interesting)
You could call the BIOS interrupt function.
You could call the MSDOS Interrupt function.
You could detect the hardware and write directly to the hardware address.
Both the BIOS and DOS mechanisms were slow and broken and did not follow the conventions of any programming language. For example terminating strings with the $ symbol, FFS.
All commercial programs (and most hobbiest ones) wrote directly to hardware for speed.
DOS was not really an OS at all. It did very rudimentary memory management. About the only thing you'd really use DOS for was disk access and application launching, otherwise DOS applications were basically "bare metal" applications that managed just about everything (screen, keyboard, serial ports, mouse,...) internally.
Comment removed (Score:3, Funny)
how much MS bashing can you fit in? (Score:4, Funny)
and this has exactly what to do with MS? the coding habits of programmers has NOTHING to do with MS.
Re:how much MS bashing can you fit in? (Score:5, Interesting)
I have no idea what hes on about with the hard-pathed file references.
The problem is so many corporate coders back in the day (and still) would use whatever shortcuts they could within the api including "undocumented features" like the former two issues. If Microsoft were to fix these issues without compatibility for these "features", it would break tons of legacy applications. Therefore, ongoing developing must include these already-incorrectly-designed portions of the API as well as whatever they really want to be working on.
Just because a company does something poorly to begin with and people adapted to it, doesnt mean the company isnt to blame for the issues.
Course that doesnt make this article NOT a flaming pile of rhetoric, it just makes it slightly less than complete and utter bullshit.
Re: (Score:3, Interesting)
Re:how much MS bashing can you fit in? (Score:5, Informative)
This goes back even before Windows. I used to have some DOS programs that would only let you save a file to a floppy. Not just games, a poster-creating program had A:> built into the path for saving files, and there was no way to change it. Granted, even the most rabid Microsoft-basher can't blame that on them, but it's part of the way programs used to be written. It's the same type of mindset as caused game designers in the early DOS days to hardcode timing loops because, of course, the PC would always run at 4.77Mhz.
Re:how much MS bashing can you fit in? (Score:4, Interesting)
Then everyone started using the new shiny API's and it started getting a lot better.
He's complaining that the windows API's are still hauling along cruft and junk and nastiness from 15 years ago. It hurts MS's ability to improve them, it hurts developers ability to use them, because they have to wade through pages of deprecated functions to find the correct ones, or hit strange inconsistencies that have been hanging around for years. It's also just bad for the general consistency of the experience - see the comment about the system32 on Windows 64.
He knows that bad developers doing stupid things isn't Microsoft's fault. But how you react to bad developers is. It's a tough decision to make - do you slap the bad developers on the wrist and break things because *they* were doing something stupid, or do you keep letting them have their way until it's their decisions that rule the API and the platform?
As a dev who makes his living writing for .Net... (Score:5, Interesting)
I have access to all MS software as our MSDN and Gold Certified Partner plan administrator. I have tried Vista on a couple machines. Even on a brand new Dell dual core laptop with 2 gigs of ram, it was sluggish and still could not use the full aero interface. Yet I installed Ubuntu on a 4 year old 600m with 512MB ram and got a full interface with snappy performance.
I don't need aero to develop code. The features I was most interested in all got cut from Vista... most notably the filesystem upgrades. Now add frequent updates to the framework that require $1200 software packages to use to the fullest extent. Then add the insane cost of a legit SQL Server license on which to deploy it. Plus as a domain admin, I find the administration to be a drag. And I still don't trust them for a second on security. It all adds up to a monumental drag.
I am a frustrated
Re:As a dev who makes his living writing for .Net. (Score:5, Informative)
In 2004, when I joined a company that was well funded by venture capitalists, they required that I cost-justify the $2000 MSDN license cost. I argued that we were developing consumer applications and we needed the license.
In 2007, I can no longer justify $3500ish for MSDN. It just doesn't work anymore. They offer reduced versions of MSDN, each of which eliminates all the reasons why a person would subscribe to MSDN. They offer only 10 application installs for your $3500. They offer only a few OS installs. After you've installed a few, they stop letting you install more development copies and insist that you call them for more authorization. It just doesn't work anymore, and I'm sad because I really liked being able to develop code without artificial roadblocks in my path.
Re:As a dev who makes his living writing for .Net. (Score:4, Insightful)
Re:As a dev who makes his living writing for .Net. (Score:4, Informative)
Microsoft Certified Partners are entitled to a certain number of MSDN subscriptions and/or Visual Studio copies, depending on their partner level. Even as just a Registered Partner (anyone can get this simply by signing up for free), there's something called an Action Pack, I think, that includes enough licenses to get a small business running - server OS, SQL Server, etc. The Action Pack costs either $200 or $400, and I'm too lazy to verify that but here's the link if you're still interested:
http://partner.microsoft.com/ [microsoft.com]
Getting Certified Partner status isn't a big hurdle; get some customer references and prove certain technologies are within your scope and you're well on your way.
Same techniques 15 years ago? Not just Windows... (Score:5, Funny)
Apparently the author never heard of vi and gcc on Linux...
But Don't You Mean... (Score:3, Funny)
Re:But Don't You Mean... (Score:4, Funny)
But give them credit where credit is due... (Score:5, Interesting)
Re:But give them credit where credit is due... (Score:4, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
I used Eclipse for years (still do, when I'm on a Java project) and I generally hate it. I can't back that up with any kind of empirical reason for the dislike besides its resource-hogginess -- it's just designed in such a way that whatever feels like the intuitive way to do something to me is wrong. It's like I've stepped into a bizarro world where the knob marked 'H' in the shower makes cold water come out of the nozzle and the knob mar
"one developer" (Score:5, Interesting)
That pretty much says it all: "one developer"
The argument about old krufty code in Windows and the Win32 API has been around since.... the Win16 API! It didn't really seem to slow down Win32.
On the flip side is the argument that the need for backwards compatibility is holding back Windows - yet developers complain about the migration from XP to Vista?
All smells like we-will-find-anyway-to-condemn-Windows to me. Note: I do all of my development on LINUX, so I'm not a Windows booster. I think lots about Windows just stinks but there is an issue of credibility here.
If you want a clean new coherent API and you want to develop on Windows Microsoft has provided an option:
Re: (Score:3, Interesting)
Cult of Backward Compatibility (Score:5, Insightful)
Which would have been find if DOS (Win16, Win32, etc..) were a multi-platform, extensible OS to begin with -- but it wasn't. It was a quick hack that lives on and on.
I'm a developer that works primarily in Windows, with 15 years of heavy-hitting Unix programming experience behind me.
Re:Cult of Backward Compatibility (Score:5, Insightful)
Code written for Windows 95/NT (back in 1996) still works today on the Windows platform. 12 years later.
Try that with System 7 code on OS X.
Yes, this is part of why writing business-logic code sucks. You seldom get to just re-write anything to be really, truly good instead of something perennially built-upon and increasingly hacked-together. No one will pay for a change that doesn't deliver "business value". (And no, greater stability/performance is almost never enough, as that argument usually demands an associated headcount reduction) But at least the app still works and can continue to deliver. And since some will doubt, yes, I do maintain/enhance such code.
The market speaks - this sort of backwards compatibility is a conscious choice by MS, and it does sell their OS. Not concidentially, it also sells mainframes and *UX systems. And I'm convinced it's one of the big reasons Apple isn't bigger in the corporate world. Steve's demands for newer/better/faster totally supplanting the old are well known, and rightly feared.
Glory days are here (Score:5, Interesting)
When articles claim Microsoft dropped the ball I think it's more wishful thinking than anything, because Windows programmers are in their Enterprise glory days right now, no longer restricted to VB and half-assed object models. Not anymore. We now have full OO features and much much more, and Java is playing cathup feature-wise. It's nice for a change.
I don't care how messy Microsoft's underlying code is, as long as they've tested it and ensure it works enough for me to program against it. The Microsoft security updates help a lot too. They're very frequent which means there are a lot of security flaws but they take care of them quickly (I'm sure I will get numerous examples where they didn't take care of security quickly but if you're on Windows update you see them coming thought all the time).
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
Author is misleading at best.... (Score:4, Interesting)
No mention or acknowledgement of WPF/WCF or the new APIs that are and 'set' to replace Win32/Win64
Completely misleads users about API concepts and features of OS X compared to Windows, for example XAML/XPS concepts compared to Display Postscript is a massive difference in display technologies that are part of the new Windows API sets, that Carbon or Cocoa cannot provide to developers. (Go to Channel 10 and watch videos on why XAML/XPS was created and how it trumps every aspect of other display/print technologies. - Let alone how it is an integrated aspect of the video API system in Vista, making programming freaky simple for advanced features and new UI platforms like 3D.)
The author then jumps into UI consistency with dialog wording, and doesn't mention OS Xs lack of keyboard support, consistency of delete/backspace or 100 other things more important than dialog wording which is also NOT PART of Win32 inherently.
Author doesn't realize Microsoft and IBM wrote most of the GUI and UI guidelines that OS X even uses today.
Office 2007 is a new direction in GUI paradigms, and is WELL accepted in the business world. Not something to make fun of when OS X is still using old MENU (textual word lists) concepts. Menus were a hack to make features available in a GUI context, but are a draw back to non-graphical UIs. Vista and Office 2007 moving away from word lists (MENUS) is the right direction, too bad Apple isn't innovating on UI and just keeps throwing the same UI slop at users and telling them it is good. (And don't even mention multi-touch UI, go watch the freaking TED conferences Apple ripped the ideas off from several years ago, let alone the MS multi-touch work that also preceded the TED conference. MS Research has and is doing more with UI than any other think tank in the world.)
Author also totally ignores Adobe not providing any 64bit support for OS X because Apple dropped the ball on Carbon x64bit support that has been promised forever from Apple. In contrast 64bit development on Windows in both Win32/Win64 and
So for 'real developers' like Adobe (OS X) is a failure, and has failed paths. Which means if you want a 64bit version of Adobe products, you will have to move to Windows for the peformance and benefits. Oh, how brilliant Apple and OS X is...
This brings up the horrid Carbon/Cocoa platforms and migration paths, and even then not even touching on the development tool constrast between the two platforms.
I challenge Mr. Bright to a real debate on the topics covered, maybe he can try to justify some of his misleading and outrageous claims.
Re: (Score:3, Insightful)
Quite right. The last thing I want in my word processor is words.
Re: (Score:3, Interesting)
what is the problem with menus? ... unambiguous communication of options ...
Menu's have their purpose and their limitations. As apps get more functionality, the choice-lists get longer and longer, you get more nesting of menus, sub-menus, sub-sub-menus, until finding stuff becomes hard. Cases in point: Photoshop (and cousins), and MS Office (and cousins). Another side-effect: most feature requests MS gets for Office, are for things that already exist - users just don't know they're there.
The ribbon is not a new paradigm but it is a significant evolution. Menus do exist in Offic
Re: (Score:3, Informative)
Leopard's idea of 64bit is providing a 64bit version of Cocoa for applicaiton development. Like Tiger there are a few OS level 64bit pieces for addressing more RAM than 32bit, but the majority of the OS kernel itself is 32bit still. (Carbon was supposed to be mo
Re: (Score:3, Informative)
Leopard's idea of 64-bit is providing 64-bit versions of most frameworks and libraries for application development. The one big exception is Carbon, and, yes, that's a big exception, but it's not as if there's not much you can do in 64-bit mode (as was the case in Tiger).
Yes, a
Re:You have got to be insane or Fanboi! (Score:3, Informative)
Several... Should we start with things like Silverlight, or go into the whole WDDM model of Vista that uses XAML from the composer to printing? You are trying to confuse
Mac OS X's low level graphics APIs are called Quartz and OpenGL. Quartz is effectively Display PDF. Display Postscript sadly died in Apple's hands.
Ok, OpenGL is not Apple's any more than it is Microsoft's.
Display PDF is equivalent to GDI+ from
Re:Author is misleading at best.... (Score:4, Informative)
I completely agree that Microsoft and the
Generally it is an application framework that is rich, managed (apps easier to write and won't suck memory as it cleans itself up), and programming agnostic. So if you write in C, C#, Pascal, VB, Python, even ASP or PHP, you can write
It is kind of complex, so this is a very generic description, and hope it helps a bit.
Windows programming (Score:5, Insightful)
Because the software I wrote was also licensed for source code if the user wanted it, I picked Visual Basic as the platform to use. I wanted to use Visual C, but you could more easly find programmers that could get by in Visual Basic than VC. I should have picked VC rather than VB for a lot of reasons, the main one being that if you had experience in VC, you were at least likely not to be a total idiot. Not so with VB. I found that VB programmers were idiots at the approximate rate of 7:10, while VC programmers were likely to be idiots at an estimated 1:10 ratio... which isn't to say that all VB programmers were idiots, only that they were cheaper labor, and therefore less likely to have a solid background in programming logic.
That said, we'll focus only on my own development problems, just so we are dealing with only one (possible) idiot... me. I started out with VB 2.x. The upgrade to 3.x went fine, with very few problems. When 4.0 came out, I found I had to rewrite about 20% of my code. Sure, there were conversion programs, but they didn't quite fit in with exactly what I wanted the program to do. It'd get it about 90% right, but then I'd have to slog through the rest of the automated code to correct that last 10%. It was faster to discard that code and re-write it.
Then 5.x came out. Only about 50% of my code still worked. And again, the automated process to "ease" transisition left something to be desired. When Visual Studio 6.0 came out, it was a nightmare. only 20% of the code ported. At that point, I sent the 5.x code out to all the people that bought the program (with source or not), and told them that the code was now moribund, I would not be maintaining it, and that I was releaseing the source code to the public domain (5 floppies included). As I recall, that was about 1998-1999 or so.
As late as March 2008, I've been contacted about the code. Of course, it's morphed far past anything I'd written, and I could only help with the general business case logic involved, not the actual code. But having to deal once again with Microsoft development tools, one would have to offer me far, far more money than it would be worth. No, I'm done with Microsoft "development" games. I'm done with school yard bullies trying to take my lunch money. I'm done, PERIOD, with closed source, whenever I have a choice.
Re: (Score:3, Informative)
The appalling GUI inconsistency (Score:5, Insightful)
not sure they have a choice (Score:5, Insightful)
They could pull an Apple, and completely redo their windowing system. Apple benefited from using NeXT's system, which was well thought out, uses a language well suited to windowing systems (objective-c), and could be altered based on previous user experience.
However, in doing so they would lose all compatibility they current have. Keeping compatibility, even if it creates a developer's nightmare, is in the end what keeps them on top of the market.
That is not to say it's not impossible for them to do so. Apple did provide a virtual machine to run old OS9 software with the first releases of OS X. However, since both Mac and Linux machines also have the same options (currently running Parallels on my machine), it would still take the clear advantage M$ has in the market away.
It's not clear whether their bad API spells the eventual doom of the company. The more pragmatic developers will still value making products that more people can use over writing nice looking code. Additionally, wrapper libraries, such as WxWidgets or Qt can help hide much of the ugliness.
Take a look at Windows' past to understand, people (Score:4, Informative)
So far, so right. In theory.
In practice, though, let's look back into the world of Windows at its beginning. We're in the middle of the 90s, Win95 is fresh out the door and you're supposed to write for it... erh
So programmers faced the choice: Either write programs that cannot compete with programs written by MS (or companies that somehow got a hold of that information), or use calls where a few parameters are described as "set to NULL" or "unknown function".
MS has a history of releasing information about formats or calling parameters at trickling speed, at best. Anyone who ever wanted to get a hold on, say, the Office container format can vouch for that. It's not really a lot better for API documentation. Usually, you get it for a lot of money, if you are deemed "worthy" first of all.
Programmers don't let a company do that to them, though. They start figuring things out, reverse libraries and even existing program code to get the information they need. Of course, this results in the occasional mistake.
Jump into the present. The companies that created software back then don't exist anymore, blown up in the dot.com bubble. Their software, though, still exists. And companies now rely on this software. So MS has to maintain those "buggy" APIs, else companies running buggy software will refuse to upgrade.
Who is to blame? Basically, whoever decided that it's a smart idea to withhold the API documentation.
Qt (& GNOME) (Score:5, Informative)
If you are going to learn a new platform for a "modern" app or OS, then let it be one that allows you to target more than one platform. Seriously. Lets take a look at
- Everything in the library is new.
- You can only officially target one platform. (Mono not withstanding)
- You have to learn a new language to use it effectively.
Now look at Qt:
- New library
- Build onto same C++ compiler you've always used
- No messy COM, COM wrappers needed for introspection
- You can target any platform with a modern C++ compiler (VS6 and higher on win32, gcc on all platforms)
- Ground up C++, clean consistent API.
- Active development with binary compatibility within major releases.
- Python, ECMA scripting, (some C# support too!)
- Java version
- Meta-object compiler adds introspection. (no need to deal with COM)
- ActiveX interop in the commercial version (You can use Qt widgets in Winforms and vice-versa)
I don't know as much about GNOME, but it shares a lot with Qt, so should not be excluded.
About the only thing you miss out on is the automatic garbage collector. Qt emulates this to some degree by allowing every QObject to have a parent. Then the only thing missing is the ability to defragment memory in the heap. I've only heard about this being caused by lots of small memory allocations, but Qt block allocates so this isn't a problem. Also, many types are implicitly shared, meaning they are more like handles to the objects, meaning that 1) they can cross thread boundaries 2) they are references until they are modified.
All in all I see you only lose out on the memory defrag. But you don't need to learn C++/CLI or C#. (My opinion of C# is that if you're going to go that far, you might as well take the goals of the language to completion, in which case you end up with Python, oh yeah, there is a Python wrapper for Qt too)
I don't see it (Score:4, Insightful)
According to the article there are three types of developers: (I) the ones who bang Excel macros and Access databases together with VB (not very many), (II) in-house developers for large companies who program in whatever language is in demand (the vast majority), and (III) craftsmen-programmers who look for clean orthogonal programming tools and also program in their spare time (a few).
The article goes on to argue that Microsoft catered very well for categories (I) and (II), and not at all for category (III.)
Since I believe that the programmers who make stand-alone third-party applications mostly belong to category (II) I absolutely don't see how or why Microsoft supposedly "dropped the ball" for any developers except category (III). The article points to the messy API's of Win32 and the shadows that projects unto the .NET framework. Ok, fair enough, but who cares?
Not the end-users and not the managers. And they're the ones who determine where the money, and hence the bulk of the development effort goes. That means that what end-users actually see and care about, their _applications_ will continue to be in plentiful supply for MS-Windows.
Sorry, but the author will have to do a lot better to convince me that Microsoft shot itself in the foot as regards development effort. It's not the smartest thing that Microsoft could have done to alienate the craftsmen-programmers but I don't see how that puts a dent in their business.
Re:Yeah, yeah (Score:4, Funny)
What is this "ad" of which you speak? Your words are strange to us, visitor.
Re:use the same techniques you learned 15 years ag (Score:3, Insightful)
When it comes to using the extra power of modern hardware, it is easy to say "I want it to make everything 10 times faster". On the other hand, you could use that power to run a python interpreter, and
Re:MS should follow Apple? (Score:4, Insightful)
This is a false statement. Or at best misleading. Yes, Apple did finally ditch OS 9 after many years of offering backwards compatibility. Their succession of OSes, or OS X as some of us call it, are all backward compatible. Unless I'm mistaking your definition of backward compatible.
Apple's decision to make a break with their old OS was a good one, and I'm sure just about anyone would agree with that. I liken it to when the camera manufacturer Canon abandoned their old twist-lock lens mounts in favor of the electro-mechanical mount. That allowed them to develop the best autofocus lenses on the market and to finally overtake Nikon in a big way, whom they'd been playing second fiddle to since forever.