The biggest problem that Java has, and it's a problem it has always had, is that Java programs take too long to start. This is directly because of this dependency problem. I say: strip it down to layers. Define a core set of classes, no more than 20 or so of them, that must always be there. Add new functions on top of those in small increments. Basic classes must not depend on more advanced ones.
That's strange. All my Java programs, nearly all of them large Swing programs, start up in less than one second. Without any OS caching.
What on earth are your programs doing that makes them so slow to start? Are you still using Java 1.4 or something?
I've seen a lot of pages describing this vulnerability, but I'm still not clear on what APIs are involved. You are one of many who have said it's probably in native code, which makes sense, since the Java runtime won't permit a buffer overflow in Java bytecode. Can anyone confirm if this means the vulnerability lies in Applet.getImage, Toolkit.getImage, Toolkit.createImage, and certain ImageIcon constructors, while the loading of images through ImageIO is unaffected?
If it was Child porn then we beat you up while the cops are on the way (really happened, cops didn't arrest our guy, but told him to hope the CP guy didn't realize he could press charges).
Wow, awesome. Vigilante justice. You must be so proud.
Believe it or not, "truth and justice for all" does not mean "justice for all, except the people we're pretty sure don't deserve it." The whole point of the American system is that a fair legal system is far more qualified to punish people than you and your thug buddies. You are no better than a villager with a pitchfork going after Frankenstein's monster.
I'm not saying you should have done nothing at all. Holding or stalling him until the police arrived would have been appropriate. Or at least getting his license plate.
We had one issue where the girl looked a little young, so we gave the guy a chance to have her, with ID come in and she could pick up the photos. She showed up, and the ID was good (honestly didn't look fake), thing is, her hair was noticeably shorter in the pics and she had turned 18 only a week? before. we let her have the photos, for lack of proof that she was underage, but it made my stomach churn.
Made your stomach churn? What the hell?
If it was a picture of a guy with a seven-year-old, I would agree. But a girl who might have been a week less than eighteen?
There is nothing sick or wrong about having sex with a 17-year-old girl; it just happens to be illegal in a lot of places. If you happen to be gay, that's fine. If it made your stomach churn for any other reason, there is something wrong with you.
So conveniently close to a holiday, too. A large number of people are on vacation, and both vacationers and everyone else will be too busy playing with booze and fireworks to give this much consideration.
Re:This is my single biggest push to free software
on
Vista is Watching You
·
· Score: 1
I had a similar experience. Someone asked me to find out why their dial-up connection was so slow. (Broadband is near-impossible to get in most rural parts of the US, but that's a whole other Slashdot article.)
I immediately assumed malware. In fact, it was XP trying to get and install WGA. (I should do the math sometime to determine how long that would take over a modem, on a phone line so noisy it cannot do better than 26400 baud.)
Oh, and yes, the horrid HP camera driver was trying to transfer something as well. Not only is there no way to stop the HP driver's resident software from doing that, there is no option to stop it from running! At least Java, Quicktime, and Acrobat Reader have options to stop their sitting in the system tray.
When I tell them that Vista will do the same thing in spades, I expect they'll seriously look into getting a Mac for their next computer. (I use Linux but I don't think it would be right for them.) If word of Vista's behavior spreads sufficiently, Vista's sales among people with limited bandwidth should take quite a hit.
First, who cares? The whole point of using properties is to make something that's conceptually a field but works a little differently under the hood, or (more commonly) simply to prevent a field from changing or limit the values the field can hold. Unless you screwed up when writing your setter/getter methods, the distinction between field and property should be unimportant to anyone using your class.
I care. I don't like surprises. Surprises and hidden behavior make for difficult debugging.
Second, if you're using a decent IDE, like the one most C# programmers use, then it'll tell you whether Adapter is a field or a property.
I don't know a graceful way to say this: stuff your IDE. All IDEs are memory hungry, bloated, and have frustratingly tedious editors. I don't expect the whole world to use vi(m), but I do and I am very very efficient with it. I cannot be nearly as efficient with an IDE. I know some IDEs have vi-like plugin editors but I find them pale imitations. And did I mention the memory usage?
Finally, since public fields are frowned upon (as in most other languages), you can just assume that Adapter is a property, and you'll be right 9 times out of 10. Ask any experienced C# programmer how often they aren't sure whether a certain identifier is a field or a property: it simply isn't an issue in real life.
Read: eventually you just learn to decipher the code and know that it is not what the syntax suggests it is. Sure, that's a useful skill, but it's not helpful, it doesn't enhance productivity, and it's not innovative. Oh, and it saves a paltry number of keystrokes at best. Not enough to justify the increased crypticness.
Good rule for language design: K.I.S.S. so programmers can concentrate on their work instead of the syntactic candy.
BTW: Referring back to the String example, there's another problem. The interfaces don't come anywhere close to covering the members of String. It's not hard to solve this problem... just create the new interface(s) and declare that String implements it/them. By not creating standard covering interfaces you're not only encouraging, you're more or less demanding a lot of concrete instances of String, when what you really mean is something String-like in some way.
You don't know as much as you think you know, especially about Strings. To begin with, I suggest you do some Google searches for the phrase "Premature optimization is the root of all evil." Now then...
Don't concatenate, use StringBuffer-s.
You don't seem to be aware that the following two lines are either identical, or so close to identical in their execution that you will never be able to discern the difference with any debugger or benchmark:
System.out.println("The product of " + a + " and " + b + " is " + (a * b)); System.out.println(new StringBuffer("The product of ").append(a).append(" and ").append(b).append(" is ").append(a * b));
It is true that in Java 1.0, StringBuffer was always the better way to concatenate. But that was over ten years ago. Modern Java programmers know you don't use StringBuffer unless you're doing frequent concatenations (such as inside a loop). And professional programmers know that readability and maintainability are way more important than saving a few cycles in some logging statement.
Don't use buffer.append("a" + "b") - kinda defeats the purpose:) .
Wrong. Concatenation of constants results in a single constant at compile time. In other words, the following lines will compile into byte-for-byte identical bytecode:
System.out.println("Today" + ' ' + "is" + " December " + 13); System.out.println("Today is December 13");
Feel free to try it for yourself if you don't believe me.
Which you can't, because like half of java.lang, Integer is final, which means no other classes may extend it. Because, of course, no one would EVER want to add new attributes to Strings. (Like, say, font information, color info, minor things like that.)
First of all, String and the primitive wrapper classes are used by most of the core classes like ClassLoader and Class. If they could be overridden, it would be a gigantic security hole. Also, many crucial mechanisms rely on those classes' immutability, so allowing for the possibility of a mutable subclass would introduce considerable instability.
Second of all, people all too frequently seem to want to use inheritance for every task. Inheritance is not a toy. It's a String and some other data, not a new kind of String or a String with specialized behavior. Subclass when you must, not whenever you can. As someone else pointed out, you're far better off using a class (such as java.text.AttributedString) that aggregates a String and your other attributes of interest.
If it can't lay out everything at its preferred size, it completely ignores preferred sizes and lays everything out based on their minimum sizes. This sounds logical, but means that layouts suddenly 'jump' when resized below the preferred size, and can look very strange at small sizes. Instead, it should scale components down smoothly from their preferred to minimum size, taking both into account.
It does very stupid things if it can't even give everything its minimum size (e.g. giving some components negative size in order to give others positive size). It should be much more intelligent about this.
I agree wholeheartedly. The problem can be ameliorated by setting components' minimum sizes to their preferred sizes (especially JTextFields), but it's still a pretty brain-dead "throw your hands up in the air" behavior.
Its alignment options should include one for text baseline as well as for component top and bottom.
You have never developed an application that needs to be internationalized, obviously.
Different cultures and different languages need items positioned differently. Some languages are read left to right, others right to left, others top to bottom. Some phrases are much longer in some languages than others. All this makes impossible to have an universal layout.
And yet, nearly all Java layouts seem to do exactly that. If you don't believe it, arrange some components into a GridBagLayout with at least two columns and look at the results. Then add a call to applyComponentOrientation( ComponentOrientation.RIGHT_TO_LEFT ) on the window (after all components have been added to it), recompile and look at the results again.
I haven't used Java in awhile, but I remember coming up with Shakespearean-esque curses to describe what I thought of GridLayout and their buddies.
I'm guessing you really mean GridBagLayout, since GridLayout is a different and very very simple layout.
I realize GridBagLayout is hard to learn, but over the years I've learned that you cannot avoid it.
Sun has triedthreetimes
to make a "simple" replacement for GridBagLayout. Each attempt utterly fails as a replacement (but each is useful for some other rare types of layout needs).
I've tried to make my own "simplified" version of GridBagLayout too. In fact, I suspect nearly every intermediate Java GUI programmer tries this at some point; it's almost a rite of passage. And it's always a failure. The reason is that UI layout simply is that complicated, and there's no way around it. If you think it's simpler, then you probably aren't aware of all the issues involved.
A UI builder won't make it any simpler. It will just make it easier for you to ignore the issues. The usual result of such "freedom" is that the resulting UI looks acceptable, but doesn't have acceptable behavior. For instance, to pick a simple case, a scrolling list doesn't resize when the window containing it resizes.
Maybe I'd like my application to have a menu bar which can be navigated with the keyboard.
Maybe I'd like drag-and-drop of files or images or custom data.
Maybe I don't care for the cardinal UI sin of having scrolling areas inside other scrolling areas.
Maybe I want a context menu.
Maybe I want something HTML doesn't provide, like a table with selectable rows.
Maybe I don't want to worry about disabling the "Back" button.
Maybe I don't want to worry about a user double-clicking a form submit button.
If UI libraries were motor vehicles, HTML would be a skateboard. It's absurdly primitive, because, well, it was never meant to be a UI framework. It's for documents.
There's a reason "Web 2.0" is a laughingstock among those of us who care about UI design.
Of course if you've ever owned a hamster, you know the domesticated ones seem to sleep all the bloody time...
All mammals sleep all day if confined to a cage with nothing to do; it's called boredom. Even hamsters need mental stimulation. An exercise wheel only goes so far.
Try changing the terrain (new tubes, houses, etc.) every day. They won't sleep nearly as much.
Of course, hamsters are nocturnal, so they probably do a lot more sleeping in the day than at night.
Spolsky is pretty insightful on this one, but I don't think I like what he's implying here:
Being able to do mentally difficult things like context switching makes our product better. This Is Why Programmers Get The Big Bucks.
For sure, you sometimes need to incur the penalty of "context switching" when customer needs (or any important situation) requires it. But I read that part as suggesting that any programmer who's paid well should expect to be yanked around on a regular basis, putting out one fire after another, instead of being allowed to devote the attention to his/her primary job necessary to do it well.
And I'm more than a little worried that managers will perceive Joel's article as an endorsement of such yanking.
The "New formats mean pricey hardware" paragraph is ignoring history. New tech always starts out expensive and then comes down in price. I mean, come on, the first VHS VCRs were well over a thousand dollars.
I wonder if Microsoft would be better off if they disregarded at least the incorrect coding by outside developers. I guess the baggage you mentioned has had its share of delaying Vista.
Yes, they would.
While it's true that the level of backward compatibility Windows achieves is a truly impressive feat, it is also a painful solution for a tragic situation of Microsoft's own creation.
Microsoft's own plethora of undocumented but useful APIs has caused programmers everywhere to rely on things that were never actually reliable. Microsoft could have told those people that they are engaging in risky behavior and they have no right to complain if a later version of Windows breaks the program. In fact, I have some old MS-DOS books which document the INT 21h assembly calls with that very language: if you don't follow certain rules, we don't guarantee that your program will work.
It is like a Java program using classes in the "sun.*" packages. You can use the "hey, it works, so why not use it" excuse, but you have no business complaining if the same classes are different or missing in a different Java version. You were warned. And if you submit a bug about it, Sun will glibly tell you, "You were told not to use those."
We sue for-profit companies who produce products which are known to be harmful to us, even after being told for three decades that what they produce is harmful, yet still continued to buy and use the product, and win.
Tobacco companies have known since the fifties of this addictive nature, but I don't recall seeing it mentioned on the packaging of any tobacco product, ever.
Even when told how dangerous it is, virtually no smoker has the ability to quit once they've started, regardless of their desire to do so. Of all the smokers you've known, how many would have started if they'd known it was that addictive? A lot of people willingly submit to brief danger (like unintentionally inhaling gasoline fumes) but would think differently if they knew one moment of contact would force them into a lifelong spiral of increasing exposure to the same danger.
Of course craptastic Web 2.0 pages don't work on mobile devices. They use JavaScript like it's the high fructose corn syrup of the development world.
I can't get too mad at the article, though, because clearly 99% of the world's web authors are clueless about writing compliant, gracefully-degrading pages. If they made sure every page was at least minimally functional in lynx, mobile devices would easily be good enough.
Maybe some sort of "Mobile Device Compatible" certifications body would help. It doesn't even have to be a binary condition; they can be "compliant with level one mobile usage," "compliant with level two mobile usage," and so on.
H-P was so enamored of the software that it routinely used ReadNotify's array of email spying features to test prospective H-P employees, according to Adler's testimony.
Now that is disturbing. And informative; it's enough reason for me to refrain from considering employment with HP.
... Verizon's $18 billion decision to run fiber all the way into consumers' homes might be a costly one...
I'm sorry, when did this news come out? Oh, wait, I see; that must refer to Verizon's decision to accept $18 billion for the promise of rolling out fiber to the home.
I am confident that nothing Verizon has done has cost them $18 billion. I doubt if there's a single county in the Verizon empire in which more than a thousand homes have FIOS as an option.
I cannot see the word "Gizmondo" without being reminded of this awesome commentary on it from a year ago, back when its goofy pricing plan was announced. (The fifth item is a bit eerie in its prescience.)
I frequently hear that "Microsoft pays attention to the user." There is a lot of evidence, including this article, to support it. Microsoft products are constantly trying to give the users what they want.
The problem is, Microsoft has always tried to appease users instead of trying to help them.
The difference is expertise. Users know what they need to do, but they're mostly not software engineers or UI designers, so they aren't able to say exactly how their needs should be met. Even if they have some idea of what they want, they're very unlikely to be informed of the implications of what they're asking for.
A good UI designer has that expertise. He knows how to meet the user's needs. He doesn't just do whatever the user wants; he examines their complaint, realizes what the real need is, and programs an intelligent, usable solution. Then that solution is rigorously tested to ensure it is actually better than the situation it was aiming to solve.
Microsoft doesn't have this expertise. For all their supposedly brilliant minds, I see no evidence of their recognizing any principles of good software design. Instead, they just appease users by doing exactly what the user tells them to do, regardless of the consequences. Even if the addition makes things worse. They don't help the user; they pander to the user.
The user says, "There are too many items in these menus." Microsoft responds with "personalized menus." They addressed the complaint but they didn't help the situation at all. The real solution would be to better organize the menus. Any programmer can look at the menus of, say, Word, and intuit a better arrangement.
The user says, "There are too many icons in my system tray." Microsoft responds with a button that collapses the tray. This is a band-aid solution, which doesn't address the real problem: too many programs staying resident for no reason. The real solution would have been implementing a software certification program (they already have one for drivers, supposedly) that frowns on or utterly fails software which employs undesirable practices like cluttering up the system tray.
The user says, "There are too many things in the Programs menu." Microsoft responds by telling vendors to install programs under submenus which bear the vendor name. It's a horrendous solution. It's the last way anyone would choose to organize anything. No one organizes their books by publisher. Hardly anyone remembers the publisher of most of their books. And indeed, few people remember the publisher of their software.
The user says, "It takes too long to log in." Microsoft responds by showing the desktop before it is "ready"; you can move the mouse, and you can bring up some menus, but they will be forcibly unposted in a few seconds, and attempts to start applications are no faster than they would be if you waited for all the startup items to finish.
The user says, "Windows isn't intuitive, I should be able to know right away how to do things." Microsoft responds with Bob.
There are dozens more examples. The point is that I see Microsoft listening to users, but it is as if Microsoft has no experience with designing usable software, even after all these years. It could well be a case of management paralysis. I don't know the cause, but the symptoms are pretty consistent.
Excuse me, but in the past few years that I've seen, Windows has evolved significantly.
Normally I consider it poor form to counter-argue by demanding examples, since virtually no one has the time to hunt down supporting documents unless they're professional researchers.
But I'm going to do it anyway, because I can't come up with any feature of Windows 2000 or XP that supports your statement. What evolution are you describing?
Yes, 2000 is more stable than NT and XP is more stable than 2000. (XP's flaws overshadow that stability, in my opinion, but that's beside the point.) But evolution? How is XP not a slightly modified and colorized version of 2000? The colors aren't even an improvement; the layout of the "improved" Start menu is an unreadable mess.
And guess what? Usability is hard. Designing good interfaces is hard.
I agree. It is hard, and 99% of software developers clearly don't give a damn.
But we are talking about the company with more resources, and supposedly brighter developers, than any other company in the world. And after all of Microsoft's experience with desktops, shouldn't they have some skill at doing hard things like designing good, usable interfaces? Or are hard things out of Microsoft's reach?
It's a fine line, between security and usability - anything that's convenient isn't always the best thing because someone could take advantage of that convenience.
It's certainly not an even balance between the two. Some security mechanisms may require a slightly degraded user interface, but we're talking about all the terrible user interfaces that currently exist in Windows, and I doubt they are the way they are due to security considerations.
Slashdot Mirror
That's strange. All my Java programs, nearly all of them large Swing programs, start up in less than one second. Without any OS caching.
What on earth are your programs doing that makes them so slow to start? Are you still using Java 1.4 or something?
I've seen a lot of pages describing this vulnerability, but I'm still not clear on what APIs are involved. You are one of many who have said it's probably in native code, which makes sense, since the Java runtime won't permit a buffer overflow in Java bytecode. Can anyone confirm if this means the vulnerability lies in Applet.getImage, Toolkit.getImage, Toolkit.createImage, and certain ImageIcon constructors, while the loading of images through ImageIO is unaffected?
Wow, awesome. Vigilante justice. You must be so proud.
Believe it or not, "truth and justice for all" does not mean "justice for all, except the people we're pretty sure don't deserve it." The whole point of the American system is that a fair legal system is far more qualified to punish people than you and your thug buddies. You are no better than a villager with a pitchfork going after Frankenstein's monster.
I'm not saying you should have done nothing at all. Holding or stalling him until the police arrived would have been appropriate. Or at least getting his license plate.
Made your stomach churn? What the hell?
If it was a picture of a guy with a seven-year-old, I would agree. But a girl who might have been a week less than eighteen?
There is nothing sick or wrong about having sex with a 17-year-old girl; it just happens to be illegal in a lot of places. If you happen to be gay, that's fine. If it made your stomach churn for any other reason, there is something wrong with you.
So conveniently close to a holiday, too. A large number of people are on vacation, and both vacationers and everyone else will be too busy playing with booze and fireworks to give this much consideration.
I had a similar experience. Someone asked me to find out why their dial-up connection was so slow. (Broadband is near-impossible to get in most rural parts of the US, but that's a whole other Slashdot article.)
I immediately assumed malware. In fact, it was XP trying to get and install WGA. (I should do the math sometime to determine how long that would take over a modem, on a phone line so noisy it cannot do better than 26400 baud.)
Oh, and yes, the horrid HP camera driver was trying to transfer something as well. Not only is there no way to stop the HP driver's resident software from doing that, there is no option to stop it from running! At least Java, Quicktime, and Acrobat Reader have options to stop their sitting in the system tray.
When I tell them that Vista will do the same thing in spades, I expect they'll seriously look into getting a Mac for their next computer. (I use Linux but I don't think it would be right for them.) If word of Vista's behavior spreads sufficiently, Vista's sales among people with limited bandwidth should take quite a hit.
I care. I don't like surprises. Surprises and hidden behavior make for difficult debugging.
I don't know a graceful way to say this: stuff your IDE. All IDEs are memory hungry, bloated, and have frustratingly tedious editors. I don't expect the whole world to use vi(m), but I do and I am very very efficient with it. I cannot be nearly as efficient with an IDE. I know some IDEs have vi-like plugin editors but I find them pale imitations. And did I mention the memory usage?
Read: eventually you just learn to decipher the code and know that it is not what the syntax suggests it is. Sure, that's a useful skill, but it's not helpful, it doesn't enhance productivity, and it's not innovative. Oh, and it saves a paltry number of keystrokes at best. Not enough to justify the increased crypticness.
Good rule for language design: K.I.S.S. so programmers can concentrate on their work instead of the syntactic candy.
You mean like CharSequence?
You don't know as much as you think you know, especially about Strings. To begin with, I suggest you do some Google searches for the phrase "Premature optimization is the root of all evil." Now then...
You don't seem to be aware that the following two lines are either identical, or so close to identical in their execution that you will never be able to discern the difference with any debugger or benchmark:
System.out.println("The product of " + a + " and " + b + " is " + (a * b));
System.out.println(new StringBuffer("The product of ").append(a).append(" and ").append(b).append(" is ").append(a * b));
Details are here.
It is true that in Java 1.0, StringBuffer was always the better way to concatenate. But that was over ten years ago. Modern Java programmers know you don't use StringBuffer unless you're doing frequent concatenations (such as inside a loop). And professional programmers know that readability and maintainability are way more important than saving a few cycles in some logging statement.
Wrong. Concatenation of constants results in a single constant at compile time. In other words, the following lines will compile into byte-for-byte identical bytecode:
System.out.println("Today" + ' ' + "is" + " December " + 13);
System.out.println("Today is December 13");
Feel free to try it for yourself if you don't believe me.
First of all, String and the primitive wrapper classes are used by most of the core classes like ClassLoader and Class. If they could be overridden, it would be a gigantic security hole. Also, many crucial mechanisms rely on those classes' immutability, so allowing for the possibility of a mutable subclass would introduce considerable instability.
Second of all, people all too frequently seem to want to use inheritance for every task. Inheritance is not a toy. It's a String and some other data, not a new kind of String or a String with specialized behavior. Subclass when you must, not whenever you can. As someone else pointed out, you're far better off using a class (such as java.text.AttributedString) that aggregates a String and your other attributes of interest.
I agree wholeheartedly. The problem can be ameliorated by setting components' minimum sizes to their preferred sizes (especially JTextFields), but it's still a pretty brain-dead "throw your hands up in the air" behavior.
Yes, that one was overdue. It's now in 1.6.
And yet, nearly all Java layouts seem to do exactly that. If you don't believe it, arrange some components into a GridBagLayout with at least two columns and look at the results. Then add a call to applyComponentOrientation( ComponentOrientation.RIGHT_TO_LEFT ) on the window (after all components have been added to it), recompile and look at the results again.
I'm guessing you really mean GridBagLayout, since GridLayout is a different and very very simple layout.
I realize GridBagLayout is hard to learn, but over the years I've learned that you cannot avoid it.
Sun has tried three times to make a "simple" replacement for GridBagLayout. Each attempt utterly fails as a replacement (but each is useful for some other rare types of layout needs).
I've tried to make my own "simplified" version of GridBagLayout too. In fact, I suspect nearly every intermediate Java GUI programmer tries this at some point; it's almost a rite of passage. And it's always a failure. The reason is that UI layout simply is that complicated, and there's no way around it. If you think it's simpler, then you probably aren't aware of all the issues involved.
A UI builder won't make it any simpler. It will just make it easier for you to ignore the issues. The usual result of such "freedom" is that the resulting UI looks acceptable, but doesn't have acceptable behavior. For instance, to pick a simple case, a scrolling list doesn't resize when the window containing it resizes.
Maybe I'd like my application to have a menu bar which can be navigated with the keyboard.
Maybe I'd like drag-and-drop of files or images or custom data.
Maybe I don't care for the cardinal UI sin of having scrolling areas inside other scrolling areas.
Maybe I want a context menu.
Maybe I want something HTML doesn't provide, like a table with selectable rows.
Maybe I don't want to worry about disabling the "Back" button.
Maybe I don't want to worry about a user double-clicking a form submit button.
If UI libraries were motor vehicles, HTML would be a skateboard. It's absurdly primitive, because, well, it was never meant to be a UI framework. It's for documents.
There's a reason "Web 2.0" is a laughingstock among those of us who care about UI design.
All mammals sleep all day if confined to a cage with nothing to do; it's called boredom. Even hamsters need mental stimulation. An exercise wheel only goes so far.
Try changing the terrain (new tubes, houses, etc.) every day. They won't sleep nearly as much.
Of course, hamsters are nocturnal, so they probably do a lot more sleeping in the day than at night.
For sure, you sometimes need to incur the penalty of "context switching" when customer needs (or any important situation) requires it. But I read that part as suggesting that any programmer who's paid well should expect to be yanked around on a regular basis, putting out one fire after another, instead of being allowed to devote the attention to his/her primary job necessary to do it well.
And I'm more than a little worried that managers will perceive Joel's article as an endorsement of such yanking.
The "New formats mean pricey hardware" paragraph is ignoring history. New tech always starts out expensive and then comes down in price. I mean, come on, the first VHS VCRs were well over a thousand dollars.
Yes, they would.
While it's true that the level of backward compatibility Windows achieves is a truly impressive feat, it is also a painful solution for a tragic situation of Microsoft's own creation.
Microsoft's own plethora of undocumented but useful APIs has caused programmers everywhere to rely on things that were never actually reliable. Microsoft could have told those people that they are engaging in risky behavior and they have no right to complain if a later version of Windows breaks the program. In fact, I have some old MS-DOS books which document the INT 21h assembly calls with that very language: if you don't follow certain rules, we don't guarantee that your program will work.
It is like a Java program using classes in the "sun.*" packages. You can use the "hey, it works, so why not use it" excuse, but you have no business complaining if the same classes are different or missing in a different Java version. You were warned. And if you submit a bug about it, Sun will glibly tell you, "You were told not to use those."
And for how many of those decades were we told that nicotine is as physically addictive as heroin?
Tobacco companies have known since the fifties of this addictive nature, but I don't recall seeing it mentioned on the packaging of any tobacco product, ever.
Even when told how dangerous it is, virtually no smoker has the ability to quit once they've started, regardless of their desire to do so. Of all the smokers you've known, how many would have started if they'd known it was that addictive? A lot of people willingly submit to brief danger (like unintentionally inhaling gasoline fumes) but would think differently if they knew one moment of contact would force them into a lifelong spiral of increasing exposure to the same danger.
Yeah, just new levels.
Except for the pain elemental. And the arachnotron. And the mancubus. And the revenant. And the arch-vile.
And the super shotgun.
The additions are a masterpiece orchestration of game balance. I guess Kurt Kalata never actually played it.
Of course craptastic Web 2.0 pages don't work on mobile devices. They use JavaScript like it's the high fructose corn syrup of the development world.
I can't get too mad at the article, though, because clearly 99% of the world's web authors are clueless about writing compliant, gracefully-degrading pages. If they made sure every page was at least minimally functional in lynx, mobile devices would easily be good enough.
Maybe some sort of "Mobile Device Compatible" certifications body would help. It doesn't even have to be a binary condition; they can be "compliant with level one mobile usage," "compliant with level two mobile usage," and so on.
Now that is disturbing. And informative; it's enough reason for me to refrain from considering employment with HP.
I'm sorry, when did this news come out? Oh, wait, I see; that must refer to Verizon's decision to accept $18 billion for the promise of rolling out fiber to the home.
I am confident that nothing Verizon has done has cost them $18 billion. I doubt if there's a single county in the Verizon empire in which more than a thousand homes have FIOS as an option.
I cannot see the word "Gizmondo" without being reminded of this awesome commentary on it from a year ago, back when its goofy pricing plan was announced. (The fifth item is a bit eerie in its prescience.)
I frequently hear that "Microsoft pays attention to the user." There is a lot of evidence, including this article, to support it. Microsoft products are constantly trying to give the users what they want.
The problem is, Microsoft has always tried to appease users instead of trying to help them.
The difference is expertise. Users know what they need to do, but they're mostly not software engineers or UI designers, so they aren't able to say exactly how their needs should be met. Even if they have some idea of what they want, they're very unlikely to be informed of the implications of what they're asking for.
A good UI designer has that expertise. He knows how to meet the user's needs. He doesn't just do whatever the user wants; he examines their complaint, realizes what the real need is, and programs an intelligent, usable solution. Then that solution is rigorously tested to ensure it is actually better than the situation it was aiming to solve.
Microsoft doesn't have this expertise. For all their supposedly brilliant minds, I see no evidence of their recognizing any principles of good software design. Instead, they just appease users by doing exactly what the user tells them to do, regardless of the consequences. Even if the addition makes things worse. They don't help the user; they pander to the user.
The user says, "There are too many items in these menus." Microsoft responds with "personalized menus." They addressed the complaint but they didn't help the situation at all. The real solution would be to better organize the menus. Any programmer can look at the menus of, say, Word, and intuit a better arrangement.
The user says, "There are too many icons in my system tray." Microsoft responds with a button that collapses the tray. This is a band-aid solution, which doesn't address the real problem: too many programs staying resident for no reason. The real solution would have been implementing a software certification program (they already have one for drivers, supposedly) that frowns on or utterly fails software which employs undesirable practices like cluttering up the system tray.
The user says, "There are too many things in the Programs menu." Microsoft responds by telling vendors to install programs under submenus which bear the vendor name. It's a horrendous solution. It's the last way anyone would choose to organize anything. No one organizes their books by publisher. Hardly anyone remembers the publisher of most of their books. And indeed, few people remember the publisher of their software.
The user says, "It takes too long to log in." Microsoft responds by showing the desktop before it is "ready"; you can move the mouse, and you can bring up some menus, but they will be forcibly unposted in a few seconds, and attempts to start applications are no faster than they would be if you waited for all the startup items to finish.
The user says, "Windows isn't intuitive, I should be able to know right away how to do things." Microsoft responds with Bob.
There are dozens more examples. The point is that I see Microsoft listening to users, but it is as if Microsoft has no experience with designing usable software, even after all these years. It could well be a case of management paralysis. I don't know the cause, but the symptoms are pretty consistent.
Normally I consider it poor form to counter-argue by demanding examples, since virtually no one has the time to hunt down supporting documents unless they're professional researchers.
But I'm going to do it anyway, because I can't come up with any feature of Windows 2000 or XP that supports your statement. What evolution are you describing?
Yes, 2000 is more stable than NT and XP is more stable than 2000. (XP's flaws overshadow that stability, in my opinion, but that's beside the point.) But evolution? How is XP not a slightly modified and colorized version of 2000? The colors aren't even an improvement; the layout of the "improved" Start menu is an unreadable mess.
I agree. It is hard, and 99% of software developers clearly don't give a damn.
But we are talking about the company with more resources, and supposedly brighter developers, than any other company in the world. And after all of Microsoft's experience with desktops, shouldn't they have some skill at doing hard things like designing good, usable interfaces? Or are hard things out of Microsoft's reach?
It's certainly not an even balance between the two. Some security mechanisms may require a slightly degraded user interface, but we're talking about all the terrible user interfaces that currently exist in Windows, and I doubt they are the way they are due to security considerations.