Slashdot Mirror

Have you considered this in light of http://www.joelonsoftware.com/uibook/fog0000000249.html, especially chapter 7: "Users can't control the mouse very well" ?

Joel Spolsky likes it well enough to write about it.

As far as I know, he never developed anything, instead relying on others to do the work

And what exactly is the job of the CEO in contrast?

He didn't write code, but being a software geek, he could tell if his employees actually knew what they were doing.

Any DNS gurus care to explain why they wouldn't simply use UTF8?

Because they know full well that the vast majority of web developers don't really know what unicode is or how it works. Moreover the unicode spec is forever in flux and complete overkill for the international url problem. Lation only urls are a fly, we don't need a bazooka.

Frankly, the current Punycode based system is truly inspired, giving the best of both worlds. Newer browsers can display and use international urls seamlessly, but older systems need never know they exist. People get what they wanted and the entire system chugs on as before. This is exactly what was needed. A simple and effective system that sits on top of existing infrastructure.

If only IPv6 has been designed to be this transition friendly.

I don't think they actually suck. I think they are simply pressurized to produce results in the quickest time possible. I think part of the blame goes to the commissioning clients.

You just haven't worked in enough offices. Believe me, we have people working for our company, producing software, who couldn't code their way out of a wet paper bag. And they're not under any particular time pressure. (We also have a guy who does really good work, but he's so slooow... in that case, you're right, but from my experience that's the minority.)

And part of the blame goes to the "simple is best" mentality in some schools of thought. Simplicity is NOT elegance.

Possibly; but if you know that your shop has coders who won't understand the elegant code, you're better off writing simple code to accomplish the same task. Otherwise, they'll fuck up your elegant code and produce buggy, bloated results. Joel wrote an article about this recently: http://www.joelonsoftware.com/items/2009/09/23.html making that very point.

Personally, I don't think elegance should be the goal. Who cares if it's elegant? The finished product is the important part, not the code and the UI is what people judge. I'm sure a lot of products with extremely elegant code have godawful UIs.

Also, opinion is NOT fact.

Shocker!

Surprisingly, I see Cobian Backup, Avast! antivirus, and some other software being rather multi-user aware. Cobian v8 is open source, Avast! Home is freeware. These little attention to details impressed me a lot.

Being multi-user aware isn't "a little detail", it's an industry standard! If they weren't previously for the NT series, they should have been patched to be multi-user away for Windows 2000 Pro, which was mainstream.

That's not "impressive" that's just par for the course. That's like being "impressed" that it uses menus and buttons, or being "impressed" that it lets you switch which language the UI is in.

Then what do they rely on? Their IDE's ability to suggest methods and properties when they type?

That. Or Googling it. Or yelling, "hey Bob, what do you use to sort a list?" over the cubicle top. Or they keep an extensive collection of code snippets and they just copy and paste those in randomly until something works, or appears to work at first glance.

Joel Spolsky once said: Most programmers would love to do it even if they didn't get paid.
I wouldn't go that far but I really love what I do. Maybe I'm an idealist but if you're just in for the money, maybe you've got the wrong job? Apart from that I think it's unrelated to the whole glory issue. Glory in IT imho isn't non-existent but rare.

And yes I know IT is much more than programming, it's just an example.

It's a reaction to Yahoo Answers and Experts Exchange - with the difference that it doesn't suck.

http://www.joelonsoftware.com/items/2008/09/15.html ... is Joel's introduction to the site, which explains their motivation.

> I don't think this guy ever worked with any software engineer with any significant amount of experience

He designed Excel Basic, and did quite a lot of work on VBA, so you can't wipe his experience away. Also, I beleive that there are some experienced engineers at FogCreek

Anyway, the guy is an ass, and loves making outrageous statements. I guess it is because he have to rationalize about how could it be that, being as smart as he think he is, he ended-up with a nice looking web application written in the most evil kludge one could envision. Of course, his inner coherence is getting slowly shredded into pieces after that...

But remember, on numerous occasions Joel has stated how much he disagreed with the plan to rewrite mozilla from scratch. For example: http://www.joelonsoftware.com/articles/fog0000000069.html

Bloat isn't bad.

Version 5.0 of Microsoft's flagship spreadsheet program Excel came out in 1993. It was positively huge: it required a whole 15 megabytes of hard drive space. In those days we could still remember our first 20MB PC hard drives (around 1985) and so 15MB sure seemed like a lot... In 1993, given the cost of hard drives in those days, Microsoft Excel 5.0 took up about $36 worth of hard drive space. In 2000, given the cost of hard drives in 2000, Microsoft Excel 2000 takes up about $1.03 in hard drive space...

In fact there are lots of great reasons for bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner. And that means you get more features, and features make your life better (when you use them) and don't usually hurt (when you don't). If your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible. Maybe, just maybe, if you tend to keep your hard drive full, that's one more Duran Duran MP3 you can download. But the loss to you of waiting an extra two months for the new version is perceptible, and the loss to the software company that has to give up two months of sales is even worse.

First you have to pick your preferred abstraction layer.

Eenie, meenie, miny... It really doesn't matter so much which abstraction layer you pick. You could pretty much take a list of features, look for a layer that has those features, and go -- particularly if you bias towards higher-level abstractions.

Then you have to work around the things it abstracts that you actually need to know about,

Rare.

In the original Law of Leaky Abstractions article, for example, Joel talked about things like having to iterate over each string several times -- once to find the length, then once again to copy it to a new, just-allocated string. And of course, that if you're concatenating strings all over the place, rather than using some sort of StringBuilder, this is happening a lot, and also leaving a lot of garbage to be collected, and tripping the allocator, and...

And how often does that particular problem affect the development of a desktop front-end, something that pretty much just needs to display some records in some forms, and store the updated version back in the database? Even on a five or ten year old desktop, the performance gains by using C++ versus a scripting language, or using StringBuilder versus straight concatenation, are pretty much irrelevant.

Click "parent" a few times to find this example:

That old clunky COBOL system might have been awkward to use and a bit long in the tooth, but it NEVER crashed, and its mistakes were minimal to say the least. This new Windows system crashes constantly (including crashing if you work too fast - yeah I literally have to do a "one one-thousand" count when switching between properties or the client will lock up), and it goofs up the data frequently enough that in another 5 years I think our data will be reduced to an unreliable mess.

In what way could that be caused by a "leaky abstraction"?

before you know it, you've got a dozen layers *all of which you need to understand their subtle quirks and interactions*.

12 layers seems like a bit much. I mean, most apps I write, I've got at most...

1. database
2. model (inside server-side app)
3. REST API
4. HTML view
5. CSS styling
6. Javascript client

So, about half that. What's more, these layers are mostly isolated from each other. The model sits completely between the REST API and the database. The CSS and JavaScript don't really need to know about each other at all -- the CSS only cares about the HTML itself, and the JavaScript cares about HTML and REST.

Subtle interactions? Sure, but it's not as though adding Javascript suddenly implies a huge and subtle interaction between the model and the database, or any change to the model at all.

The point isn't that the GUI is free -- I think I implied that, and I don't think I meant to.

The point is that, look at the stack I drew again. If you're having to change model code -- the heart of your application -- because of some GUI somewhere much farther down, you're Doing It Wrong. GUIs being "much more intricate" may lead to quirks, yes, but they should not lead to data corruption in any half-decent app.

Back in October 1998, Microsoft fixed a vulnerability in Internet Explorer 4 where a dotless IP address (represented as a single, unsigned 32-bit integer, which was legal in IPv4) would be treated as being on the local network rather than on the Internet at large. Basically, their programmers took a shortcut and assumed "no dots = local". (MS98-016)

This was re-introduced in IE 5 three years later and had to be fixed AGAIN. (MS01-051)

I've been waiting to see if they end up re-introducing this one, or if they learned their lesson well enough the last time.

As Joel Spolsky points out, this is exactly what happens when you rewrite software. The old software had lots of bug fixes. If your development shop made a particular mistake once, it's likely to do it again when you reimplement. It's unclear whether this was the case for IE 5 (no idea if that area of the code was rewritten), but it seems like this may have bitten Microsoft with the teardrop vulnerability.

Code tests should be done as take home exams. Reason is... any competent programmers these days know at least half a dozen of programming langauges (PHP, Python, Perl, Ruby, C, C++, Objective-C, Java, JavaScript, several different flavors of SQL, shell scripts, several different flavors of asm, etc.). BUT! Nobody would be juggling all those half-a-dozen languages (even a significant part of that language's features and libraries) last month. Result - if you code test someone on the spot, the guy who crammed for the interview (but usually incompetent) gets good results while the competent programmer at your interview would have forgotten the exact class/function names, or even syntax to use. So basically you, the interviewer, are shooting yourself in the foot.

Asking for the general direction in which the interviewee would use to solve the problem, however, is ok. Once you've got the general direction down, it's trivial to ask Google for the exact syntax and names. And after you've been working on a project for a few days you can get accustomed to those little things anyway. Someone who can't get the general direction down or comes up with overcomplicated designs (e.g. architectural astronauts - trying to scare me with buzzwords huh?) would be a real pain in the ass to work with.

Totally agree on the communications part. Being an introvert is no excuse for poor communication skills. Even if you're an excellent coder/architect/manager (how can anyone be manager without good communications skills?!), good communication skills saves time for everybody. You don't have to be able to talk/write perfect English - just get the damned idea across and have a good sense of other people's feelings.

Software companies do this too. You can usually get a student license (sometimes equivalent to regular one) for very low cost, sometimes free. While everyone else is required to pay higher prices. I mean, check out Windows. Most business users probably only require the stuff in the home edition. Except for being able to connect to a domain. Just for the privilege of connecting to a domain, you have to buy the professional (in XP), or business (in Vista) edition. That usually doubles the price. So, they know businesses have more money to spend, and that they will spend the money, so they charge them much more even if they only get minimally more out of it. Almost all software packages offer this in some level or another. Visual Studio Standard probably has 90% of the features needed by most developers, and costs about $250. The professional version has everything, and costs $550. Then there's the team suite edition, which costs a couple thousand dollars, and has everything including the kitchen sink, but you probably don't even need any of the extra stuff it includes. For more about this, read Camels and rubber duckies by Joel Spolsky.

Joel Spolsky agrees with you wholeheartedly on this:

Why am I so hardnosed about this? It's because it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it. In some situations it may be completely impossible to fire anyone. Bad employees demoralize the good employees. And they might be bad programmers but really nice people or maybe they really need this job, so you can't bear to fire them, or you can't fire them without pissing everybody off, or whatever. It's just a bad scene.

On the other hand, if you reject a good candidate, I mean, I guess in some existential sense an injustice has been done, but, hey, if they're so smart, don't worry, they'll get lots of good job offers. Don't be afraid that you're going to reject too many people and you won't be able to find anyone to hire. During the interview, it's not your problem. Of course, it's important to seek out good candidates. But once you're actually interviewing someone, pretend that you've got 900 more people lined up outside the door. Don't lower your standards no matter how hard it seems to find those great candidates.

(or read his spiel on interviewing yourself)

But at times, I might have no connection to the network, or I might have such a slow connection (either low bandwidth or high latency) that interacting becomes unbearable.

This brings up an important point concerning how 'cloud' (I really hate that word actually, it smacks of marketing attempting to 're-brand' what is basically a hosted networked service) computing services are pitched to potential clients. I agree with you that a 'desktop replacement' approach (aka the thin client) will NOT succeed for the reason(s) that you have mentioned (among others). There is really no need to replace all localized computing services with networked equivalents, especially when a decent desktop can be had for less than $500 upfront and netbooks for even less (a couple hundred dollars). Developers and other power users who demand more from their machines will obviously need more expensive gear, but they were the least likely to be satisfied with a 'desktop replacement' thin client anyway and besides; any manager who will pay $80,000+ USD/year for competent developers yet cheap out by giving them 'desktop replacement' thin clients (which waste seconds on every transaction) is an idiot. Joel Spolsky has written several articles addressing point (i.e. not getting the most out of developers because of poor management decisions).

All together, the evidence for magnetic monopoles "is now overwhelming", says Steve Bramwell, a materials scientist at University College London and author on one of the Science papers and one of the arXiv papers. ...

Even without directly seeing one, Bramwell says that he is certain that the monopoles are there. "I don't think anybody could question it after this flurry of papers," he says.

This mentality is a good example of what Joel Spolsky calls fire and motion. You just keep moving, keep publishing, keep innovating, and your opponent is so busy trying to catch up or deal with your earlier work that you gain huge momentum. Sometimes unstoppable momentum. People just can't deal with the information overload.

When the crystals are chilled to near absolute zero, they seem to fill with tiny single points of north and south. The points are less than a nanometre apart, and cannot be measured directly. Nevertheless, Morris and other physicists believe they are there.

For 30 years, physicists have believed that the universe is made up of tiny vibrating dimensional strings which only they are clever enough to understand. A fine idea, except it turns out not even they are clever enough after all. Nevertheless, they persist in this belief because the mathematics is beautiful. Likewise, many physicists persist in their belief in magnetic monopoles because the concept is beautiful, or some other such rubbish. Look! It even makes Maxwell's equations symmetric. So what? What's so important about having symmetric equations. Unsymmetrical ones are so much more interesting!

There's only one arbiter in physics, and science in general. It isn't a "flurry of papers". It isn't "beauty" or "symmetry" or "elegance" or "coolness". It isn't how many people agree with your viewpoint. It isn't how many journalists you can get to print words like "overwhealming evidence" in headlines. It isn't how much "supporting (online) material" you can find to back you.

The one, only, and final arbiter is the experiment. An honest to gods experiment. It finds things. It separates truth from fiction. You can try to twist the meaning of the result this way and that, throw back the grenade and carry on with your fire and motion, but in the end the results of all those experiments will finally weigh down your dishonesty and halt your advance.

There are no magnetic monopoles. You can try to separate north and south pole. You can even construct models of "magnetic charge" and dipoles if you like. But in the end, you can't get a north pole without having a corresponding south pole, very, very close by.

Modern science, and worst of all physics, is in a deplorable state. Cargo cult scientists,frauds, charlatans, fakes, and deluded true believers(Yes I'm serious about that last link) have saturated certainly the media circuit, but I fear many physics departments as well. Sensationalism and media attention are now as never before, deciding what the "consensus"* in science should be. It's disheartening to see the world lose its faith in the method of observation, hypothesis, experiment and above all skepticism that has served it so well for so many centuries.

P.S.
*Before the cranks jump in; No, I do not in fact, doubt the reality of anthropogenic climate change.

instead of forcing them to play silly mind games.

That's why I like Joel's approach.

Thanks for posting that link. Much better to read Joel's tips than this retarded "article".

instead of forcing them to play silly mind games.

That's why I like Joel's approach.

Ugh. Magic invisible gotos FTW!

Say what? The linked article proposes using return values (that will be ignored) instead of exceptions. If you wanted to discredit the use of try/catch, you need to find a better link.

(Or is the article supposed to be ironic? It looks genuine. If not, a big whoosh on me...)

From the linked article:

People have asked why I don't like programming with exceptions. In both Java and C++, my policy is:

• Never throw an exception of my own
• Always catch any possible exception that might be thrown by a library I'm using on the same line as it is thrown and deal with it immediately.

I have done code that way, before exceptions came into vogue. To do it right, you've got to have many many many error-checking if() statements after every call to any function that could fail. That could maybe be done as neatly as with exception-handling, if one was ever careful to maintain one's error-codes in a single numeric heirarchy, so as to allow 'families' of errors. The error-checking statements can then select for specific errors or for families of errors, like this: if (errorCode & ERROR_FAMILY_FILEIO).

But that is a lot of work, and the code won't be any cleaner than with exception-handling. In fact it will be uglier because you can no longer just call a bunch of functions in a row without checking returns, allowing a single exception-handler at the bottom to catch any errors it thinks it can handle.

Nor is the author correct in contending that 'throw' is somehow less visible or less handy or less maintainable than 'return'.

And he won't get the very very nice exception-handling support that some languages like C# offer.

But as below says, they make error handling an easier task as well as some oddly structured loops for which try/catch logic doesn't get you all the way

Ugh. Magic invisible gotos FTW!

The best choice for you depends on what you want.

From what you are saying, you are a lawyer who wants to get work done with a computer; you just want it to work. That argues for Mac OS X or Linux, IMHO.

If you buy a Windows laptop, it will come with all the drivers you need, pre-installed, and dialed in perfectly. It will also likely come with a whole bunch of useless junk helpfully pre-installed. It will also come with antivirus and antispyware software, and that is essential. So you can ignore the useless junk or strip it off, and make sure to keep your virus definitions updated. In Windows, everything you install has its own update manager, so from time to time Windows Update will need to run, the antivirus updater will need to run, Java (if you have it) has a really annoying updater... And Heaven help you if your machine does get some sort of malware that copies confidential data off your computer. And, it's getting harder to get old reliable XP; if you want to run Vista, you need a seriously powerful computer. (It is probably possible to turn off some background processes and strip out some cruft to make Vista better; and Windows 7 may be better; but for now, Vista can make a decent computer run slow.)

Note that the worst case scenario for Windows is a laptop being carried around and used in lots of different locations (coffee shops via WiFi, etc.) without a hardware firewall; that is the most likely way to get your computer infected with malware. Do you do this? If so, that argues against Windows.

With Mac OS X, you pay a bit more but everything Just Works. Fit and finish are mostly excellent. Lots of little things annoy me, so it hasn't seduced me away from Linux; for example, the fonts seem blurry to me, the Finder doesn't seem as friendly as the file manager I'm used to (Nautilus in GNOME), etc. But if you want a computer that Just Works, and especially if you don't have good tech support, this is a great way to go.

With Linux, once the computer is correctly set up and working, you can just use it and use it and it Just Works. It may be some effort to get it there. But my wife is very much a non-techie, and she is perfectly content with her Ubuntu desktop that I set up for her. It really does Just Work.

So, if you are interested in Linux, one way to go would be to buy a complete computer with Linux pre-installed and supported by some company. For example, if you want a laptop, you could buy one from Emperor Linux. (I haven't bought from them, but they have been around for years, so they must be doing something right.)

The thing I like about Linux is that it always keeps getting better. It can be a rocky process (PulseAudio has had some serious growing pains, especially in my favorite distribution, Ubuntu) but overall it's working. Linux isn't getting slower as it improves; it stays the same or gets better, overall. (A modern distribution should run anywhere XP will run, and probably faster.)

So, get Linux if you like the way it looks and works (I find the GNOME desktop to be quite soothing and efficient and I love the virtual desktops feature). If you are a busy non-techie, get a turnkey pre-configured system, even if you need to pay more.

Get Mac OS X if you like the way it looks and works. It's not that much more expensive and it Just Works.

Get Windows if you don't mind having to do a lot of administration work (updating virus definitions, running virus scans, etc.). You are definitely swimming with the currents if you adopt the most popular OS available; you can get help and support anywhere. (But you are more likely to need that help and support, IMHO. I have friends and family who come to me with computer problems, and I don't much enjoy cleaning malware off an infected Windows computer, but I've had to do it plenty.)

Hope this helps.

steveha

... when Joel Spolsky wrote "Human Task Switches Considered Harmful".

Just because you wouldn't use the product doesn't mean that it doesn't exist.

It's not that I won't use it. There's almost little to no information on it with no demo or purchasing information.

You can call it Crapware all you like, but if they were making money off it, then that's all that matters.

How do you know they're making money from it? Or do you mean the vast sums of money they're about to be awarded because of their patent abuse?

If you were a developper on some widget for a program, you'd patented the methods and technology, and were making your livelihood off it, you'd be screaming bloody murder.

I wouldn't be stupid enough to pour effort into something Microsoft could replicate in a day. When you're a bottom feeder the more success just means the bigger likelihood you'll be out of business. The fact that they didn't see this coming (and this is of course assuming they're legit) brings no sympathy.

The damages are a little excessive, but this is a company that's been put out of business by a developper with significantly more resources available to them deciding to ignore its patents.

$40 million is a little excessive? Do you honestly believe this company is capable of selling even 1% of that much within it's life time? and you've completely ignored that fact that this Canadian company is filing suit in Texas.

Just face facts, unless some new ones come out, it's a patent troll.

There is an interesting article here which holds up pointers and recursion as two things in programming that a lot of people never really understand.

I also keep hearing tales of hardware no longer working because the driver model changed yet again.

For the second time in Windows 20+ year history, for security reasons. How long is the average binary driver interface in Linux stable, again? On the order of days?

I also keep hearing astroturfers tell me that applications that break after an 'upgrade' to the newest Windows are the fault of the application writers for not sticking to MS' rules.

It's true. If you don't follow the published APIs, and decide to get 'clever' with some hidden ones, you should expect it could break at any time. If you do this, and you're not large enough for Microsoft to test against, you're SOL, but it's your own damn fault.

And yet, you guys keep reassuring me that Microsoft bends over backwards to maintain compatibility. Welcome to Microsoft Newspeak, now even more doubleplusgood.

Because even if you bend over backwards to maintain compatibility, you don't always get to keep it. Compare with Mac's numerous significant breaks of compatibility, or Linux refusal to have a stable Binary API. It's only newspeak if you don't have any understanding of the issue whatsoever.

For a software position, try to see how well the company scores on the Joel Test:

1. 
        
2. Do you use source control?
3. Can you make a build in one step?
4. Do you make daily builds?
5. Do you have a bug database?
6. Do you fix bugs before writing new code?
7. Do you have an up-to-date schedule?
8. Do you have a spec?
9. Do programmers have quiet working conditions?
10. Do you use the best tools money can buy?
11. Do you have testers?
12. Do new candidates write code during their interview?
13. Do you do hallway usability testing?

Also see http://www.joelonsoftware.com/articles/fog0000000043.html ;D

If it is a programming type position, I would likely ask then the check list of questions offered by the Joel Test and make sure they have really good reasons for any negative responses. Also, based upon my own experiences, I would add one more question to that list, "What is the background of the person that will be my supervisor?" For a position that involves you writing a lot of code, having someone that is not familiar with the process as your supervisor is definitely a negative.

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

read and understand; please

I have read that previously and do understand it. I am also familiar with the concept of technical debt and its logical extreme, and tend to suspect that code with net positive value would be less likely to become abandoned. I also suspect that abandoned code actually will lose value over time, due to interfaces with or assumptions about the external world going stale.

read and understand; please

Word definitely should be on its way out. Not because we don't print everything out (digital distribution is MORE of a reason for everyone using the same program), but because the free alternatives do everything just as well (or better, they are much more lightweight)

I don't really understand the complaints about bloat. I will just block quote(since Slashdotters don't like to click on links) from this article here http://www.joelonsoftware.com/articles/fog0000000020.html

Strategy Letter IV: Bloatware and the 80/20 Myth
by Joel Spolsky
Friday, March 23, 2001

Version 5.0 of Microsoft's flagship spreadsheet program Excel came out in 1993. It was positively huge: it required a whole 15 megabytes of hard drive space. In those days we could still remember our first 20MB PC hard drives (around 1985) and so 15MB sure seemed like a lot.

By the time Excel 2000 came out, it required a whopping 146MB ... almost a tenfold increase! Dang those sloppy Microsoft programmers, right?

Wrong.

I'll bet you think I'm going to write one of those boring articles you see all over the net bemoaning "bloatware". Whine whine whine, this stuff is so bloated, oh woe is me, edlin and vi are so much better than Word and Emacs because they are svelte, etc.

Ha ha! I tricked you! I'm not going to write that article again, because it's not true.

In 1993, given the cost of hard drives in those days, Microsoft Excel 5.0 took up about $36 worth of hard drive space.

In 2000, given the cost of hard drives in 2000, Microsoft Excel 2000 takes up about $1.03 in hard drive space.

(These figures are adjusted for inflation and based on hard drive price data from here.)

In real terms, it's almost like Excel is actually getting smaller!

What is bloatware, exactly? The Jargon File snidely defines it as "software that provides minimal functionality while requiring a disproportionate amount of diskspace and memory. Especially used for application and OS upgrades. This term is very common in the Windows/NT world. So is its cause."

I guess those guys just hate Windows. I haven't run out of memory in more than a decade, ever since virtual memory appeared in Windows 386 (1989). And hard drive space is down to $0.0071 per megabyte and still plummeting like a sheep learning to fly by jumping out of a tree.

Maybe Linus Ã...kerlund can explain it. On his web page, he writes, "The big disadvantage of using these bloated programs is that you have to load this very large program, even if you just want to accomplish one tiny little thing. It eats up all your memory... you're not using your system in an efficient way. You make the system seem more inefficient than it really is, and this is totally unnecessary."

Ohhh. It eats up all your memory. I see. Actually, well, no, it doesn't. Ever since Windows 1.0, in 1987, the operating system only loads pages as they are used. If you have a 15MB executable and you only use code that spans 2MB worth of pages, you will only ever load 2MB from disk to RAM. In fact if you have a modern version of Windows, the OS will automatically rearrange those pages on the hard drive so that they're consecutive, which makes the program start even faster next time.

And I don't think anyone will deny that on today's overpowered, under-priced computers, loading a huge program is still faster than loading a small program was even 5 years ago. So what's the problem?

RA Downes gives us a clue. It looks like he spent hours dissecting a small Microsoft utility, apparently enraged that it was a whole megabyte in size. (That's 3.15 cents of hard drive space at the time he wrote the article). In his opinion, the program should have been around 95% smaller. The joke is that the utility he dissected is something called RegClean, which you've probably never heard of. This is a program that goes through your Windows re

Who's the fscking idiot who thought having \0 indicate end-of-string was a good idea?

Dennis Ritchie, actually. Have you won a Turing award lately?

Anyway, as to the substance, you'd prefer maybe we keep the length of a string in a byte character unsigned integer... (wait, is that big enough?) instead, then update it every time we change the length of the string at all? There's trade-offs for every design decision. This wasn't a stellar one, and brilliant people make mistakes, and fail to accurately predict the future. But really, I am highly skeptical that you have the standing to go throwing "fscking idiot" around at the way that things are implemented in what's essentially the closest thing a to a lingua franca in programming.

Well, the law that MS was prosecuted under is generally known as 'anti-trust regulation'. Google(or Bing?!) that if you if wish to see what I am talking about.

My other points still stand though.

Fast-forward about 10 years, and we get "Windows 7" - a 20GB "operating system" that requires a 128MB video card, with handwriting recognition, media center, Aero etc. etc. etc.

If you RTFA you will understand that the whole point of this Slashdot article that we are supposed to be commenting about is that 'Windows 7 runs well on netbooks'(even with aero enabled). In case you didn't know, netbooks contain the most smallest, cheapest and slowest hardware available for sale in the market, which are slower than mainstream desktops sold 3 years ago.

So, including 'handwriting recognition, media center, Aero etc. etc. etc. ' doesn't hurt the people who don't need them and immensely helps people who need them.

Now, before you continue slamming the 20gb OS(more like 10GB install size for the x64 version), you might want to read this --> http://www.joelonsoftware.com/articles/fog0000000020.html

Please, don't hold us the rest of us back just because you want to run the latest OS on your 486.

Also, destroying the competitive advantage of Exchange and Lotus Notes will have certain long-term strategic benefits.

And Sharepoint too.

Google's success (for it's applications at least) lies in reducing peoples dependence on non web applications. The more people are happy to use web apps for their everyday computing needs, the more Google stands to benefit as they have the scope to dominate the market for webapps.

Anything that provides alternatives or improvements over existing apps helps their overall goal, even if that particular app isn't profitable by itself. In terms of Googles overall revenue, releasing these little projects isn't expensive.

Another possible goal: MS (and to a lesser extent Yahoo) are probably the only companies that can threaten their search ads gravy train. If Google can hurt their competitors other revenue streams by commoditising and/or open sourcing them - then their competitors have less resources to attack Googles search ad business.

If Google can make their competitors have to respond to these developments and play catch up, then that helps. Joels old article "Fire and Motion" talked about that as a MS strategy in the early .NET days - but Vista seems to have hurt their momentum over the last few years, and now Google seems to be using it against MS now.

Java's strong/weak point is its memory management. You'll never have to deal with/learn garbage collection or pointers.

And that means that Java can't be used to discriminate between great programmers and mediocre programmers.

I wouldn't recommend Assembly. Most of the "under the hood" things are not the job of the programmer anymore. That's why we have compilers.

If I could choose now, I'd learn Python first, for basic algorithmic programming, followed by C, to get a grip on what's really happening at runtime. After that, you're not dependent on language anymore.

Why do I think C is important, you ask? Read on.

KDE4 has already become far too bloated and unresponsive for my liking and it looks like GNOME will be next, maybe XFCE after that but other minimalist window managers will be created to fill the niche left behind by those who fell victim to the awful disease that is feature creep.

http://www.joelonsoftware.com/articles/fog0000000020.html

If you want a desktop that does nothing then that's fine by the rest of us.

What about them?
I pointed out that even the owners of Netscape, AOL, wanted something better.. if you didnt know, Netscape 6 and 7 were both based on the Mozilla suite.

It all begins with Netscape fucking up and doing a full 100% rewrite, putting them almost a decade behind.

I didnt rewrite history. I stated the pertinent stuff. You are trying to rewrite history if you are claiming that Mozilla had a good competitive browser before FireFox 1.5. Are you claiming that?

Mozilla didnt have a good competitive browser before that because they started from the position of having recently made the single worst strategic mistake that any software company can make.

This first-hand article gives a bit of insight into how Bill Gates ran Microsoft. Certainly doesn't give the impression that Gates was stupid.

http://www.joelonsoftware.com/items/2006/06/16.html

http://www.joelonsoftware.com/articles/fog0000000020.html

Read this:

http://www.joelonsoftware.com/articles/APIWar.html

Specifically, scroll down to the section "Enter the Web". After reading that, you should understand that it's not about keeping Internet Explorer dominant. It's about holding back the progress of the web.

Another source (in print):

http://www.amazon.com/Barbarians-Bill-Gates-Jennifer-Edstrom/dp/0805057544

I noticed that someone tagged this article with "bloat".

Ignoring the fact that this is not the proper way to tag an article, they really should read Joel Spolsky's excellent article "Strategy Letter IV: Bloatware and the 80/20 Myth".

To quote (emphasis mine):

A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Unfortunately, it's never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release "lite" word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the "word count" feature which they need because most journalists have precise word count requirements, and it's not there, because it's in the "80% that nobody uses," and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can't use this damn thing 'cause it won't count my words.

What you consider to be bloat, many other people consider to be essential functionality.

Excel versus Lotus

I guess a GPS unit is a bit like code generation tools (zomg a backwards car analogy! :P ) in that it's a good tool for experts, but it can hinder the development of expert skills by beginners.

Yup. The law of leaky abstractions. In order to use the higher level tool efficiently, you must be proficient in the lower level foundations.

"The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)" is also a very good -- but very much shorter -- introduction to Unicode.

http://www.joelonsoftware.com/articles/Unicode.html

I frequently send this to people that I need to work with who don't "get" it.

Totally wrong. One of the most important rules in software is: "be liberal in what you accept, and strict in what you output." XHTML does that first part COMPLETELY WRONG.

Far from being "one of the most important rules in software", Postel's law has been all but debunked, at least in this context.

the basic power of the web-- the fact that everybody can (and should) participate in it. You long for a world where, if I put my STRONG tag and my EM tag in the wrong order, a completely trivial error, the browser should show absolutely nothing. Even though it's obvious to everybody what I *meant*, since a computer thinks like a computer and rejects it like a retard.

Maybe *he* does, but many of us don't, and that's not the only reason to advocate XHTML.

As long as HTML is liberal, and we expect people to write it, then browsers all have to have their own intuition at this level. That means anybody writing something that will end up on the web has to know about the whole stack down to the level of the HTML rendering. That seems horribly low-level.

I want XHTML to be rock-solid, with no room for question or interpretation. If it's too hard to write, we can build useful abstractions on it -- like everybody does (Markdown, Wikimedia, etc.) anyway.

I want it to be like those other low-level standards that leave no room for interpretation, like UTF-8. UTF-8 has been a phenomenal success, in part (I believe) because UTF-8 parsers don't have to deal with guessing. Nobody's asking for "well, what if I find four consecutive bytes that start with 10..." in the spec, or in a decoder. If it doesn't look right, the decoder just aborts. (It's largely backwards-compatible with ASCII, so you can sometimes read part of the page if it's wrong, but it's obvious that it's really broken, and you need to fix it.)

HTML should be the same way, and XHTML showed a way to do that. If it's too low-level, you have your tools convert to it. You could even write an HTML4-to-XHTML converter. But the "guess what the user meant" intuition belongs in tools, not in the core specs.

Another big problem is that with all the intuition required in a browser, it makes it virtually impossible for new rendering engines to appear. The web would never get off the ground with the crap we've got out there today. I there to be more than 3 rendering engines in the world, and I want the specs to be simple enough that that's possible to achieve. If you want to talk about "important rules in software" and "the basic power of the web", then we should make implementing a rendering engine that meets the specs *possible*. Right now, no browser will ever come close, and the specs are already 10x more complex than will ever get implemented, but adding "guess what the user meant!" crap just sucks the life out of any progress that these rendering engines have to do. IE8 punted and included IE7-mode -- that's how bad it's getting.

It may be an strategic choice from MS. Preventing people from use other filesystems will lock you to Windows. In the other hand, releasing a development kit to users for free (as in beer) would help them increase the user base, and thus selling more Windows copies. A better explanation here: http://www.joelonsoftware.com/articles/StrategyLetterV.html

This is basically just a gigantic band aid, and is unlikely to be successful. Most of what needs doing is to fill in glaring gaps of functionality in software that is now ten years old or more. Much of what people will put in there will already have bugs in an upstream Bugzilla somewhere - years old with no resolution other than WONTFIX. I fail to see how that will change.

I really hate that term 'usability' that a lot of people never define and expect to be the answer to their troubles. It gets thrown around by many in the open source desktop world mainly as a response to mask the internal troubles in the software that they're using and if someone starts talking about 'usability' and 'Mac OS' as benchmarks then maybe people will think 'Hey, they're going to be as cool as Macs!' and that they're doing something about the issues and it will all go away. Usability is about far more than making some sad Mac clone. It's about developers, developers, developers, developers - creating the useful applications and functionality that people want, making it easy for developers to create it and getting that functionality to users. Windows has that. Mac OS has that (albeit with a few speed bumps), and can run the open source software most open source developers use, so it's what you're going to see most of them use.

The Linux desktop is not the answer. It doesn't have to be that way but it's going to take a distributor to really grab hold of the situation, make sensible software choices on behalf of developers and users and identify just what system it is they're putting together. Given that we have desktops in the open source world that have limited functionality in the name of 'simplicity' (read JoelSpolsky on 80/20 method of software development - http://www.joelonsoftware.com/articles/fog0000000020.html) and we have brain damage such as PulseAudio that distributors readily lap up without any thought then I really cannot see who's going to do it. 'Just Works' is so far away it's just stopped being funny.