Slashdot Mirror

Like the Tyranny of Email article, Getting Things Done When You're Only a Grunt also suggests that there's a significant productivity boost to be gained from shutting off your email client.

Human Task Switches Considered Harmful and Where do These People Get Their (Unoriginal) Ideas? have more on this topic.

Joel's archives have quite a number of interesting articles.

• Slashdot... Hardly a surprise here..
• Freshnews.. I really like this news aggregator site, from there, I usually scan OReilly, Kuro5hin, Ars and a few other sites they feature for interesting articles and visit if the title seems interesting..
• Use Perl.. Top 10 journals, mostly
• Google news.. This replaced visits to BBC, CNN and a few others
• Freshmeat.. and a few other shareware sites from time to time
• Joel on Software.. and a few more blogs, like Scripting
• Trillian, Phoenix, Apache and a few more software sites for possible updates...
• Webmail accounts

Of course, some people who specialize in scripting DO know the lower levels too, and thus the law doesn't apply to them, but many people whose jobs rely around scripting activities would be stuck if their abstractions leaked...

There are quite a few people who dont agree with you on the "The Mac OS X UI is a joy to use because of the underlying consistency, not because of the overlay of lickable buttons."

These people compare OS X to the clear usability winner of all time, OS 9. And in that light OS X is worse. There are lots of inconsistencies, mostly smallish. For example, the keyboard shortcut for the Preferences... command varies between applications. In Mail.app it'ss [cmd-alt-;] but in Safari it's [cmd-,] and TextEdit has no keyboard shortcut at all. But these are minor problems and are probably visible only to old-timer Mac users.

However, Apple has brought over many of the good things from OS 9 -- getting started from a solid basis, so to speak -- and they are improving OS X in the right direction all the time.

Compare this to the MS Windows user interface, which tends to change without any clear goal or even direction. Case in point: Windows XP, which is basically Windows NT 5.1 with skins and a rearranged Start menu. They say that Microsoft spends hundreds of millions on usability research but it must be an urban legend because we haven't ever seen any results.

One of the problems with KDE is that every developer goes in the direction he personally happens to prefer. It's completely OK that one of the best-known skin designers defends skinning as a concept -- fair enough, more choices for everyone, good for you, etc etc. But skinning does not increase usability and it's wrong to say that it does. Skinning decreases usability and user efficiency, mostly because the user doesn't learn UI elements by heart. In Mac OS 9, every on-screen control in the user interface is completely predictable. After a while, the UI becomes natural; you don't ever have to stop and think about controls on the screen. This leaves valuable brain cycles for other things, like whatever you're actually working on right now.

Programmers and software developers talk about being "in the flow" or "in the zone" . (See Joel Spolsky's article). On a Mac, you can stay in the flow for a longer time, because you're not interrupted by petty UI details. There was an interesting article on Slashdot a while ago -- go read it, it's cool! -- about the Mac OS 9 -based GoodEasy computing environment. Now only was it an extremely cool example of how you can ANTI-CONFIGURE your computing environment to remove all distractions, I also find it very refreshing that some people have the intelligence to create such an environment, and the guts to document it.

I have no doubt that OS X 10.3 or 10.4 will be an excellent work environment. It won't beat OS 9 in its heyday, but it will be good enough to beat everything else.

--Bud

Coding alone has never resulted in anything worthwhile. Actually thinking about the code you're about to write and writing a specification has.

Coding alone has never resulted in anything worthwhile. Actually thinking about the code you're about to write and writing a specification has.

Coding alone has never resulted in anything worthwhile. Actually thinking about the code you're about to write and writing a specification has.

Coding alone has never resulted in anything worthwhile. Actually thinking about the code you're about to write and writing a specification has.

Rich.

Joel Spolsky has an excellent article on this issue.

One of the problems with CS programs is that they were often born from mathematics departments. Mathemeticians prefer to work in abstractions and appreciate the "elegance" of a tightly defined recursive algorithm in a pithy language. The problem is that abstractions leak, and if you don't understand what is being abstracted away, you can't fix them. The mathemeticians would have programming taught in as high a level language as possible, but that kind of training leaves a new programmer with precious few intellectual tools for analyzing a core dump sent by a customer.

I think that CS curriculums should =start= in assembly language so that students can learn about the physical constraints of real machines and then move towards higher abstractions later in the curriculum as the importance of complex data structures and algorithms become more of a focus.

The trend to teaching intro CS courses in Java, or worse, VB, is disturbing.

Joel Spolsky says it best in his Law of Leaky Abstractions. In other words, no box is totally black.

I've worked on large systems where I've had a lot to do with many parts of the system, and not been able to hold the whole thing in my head all at the same time.

And as a someone that's had a lot to do with the building of these systems I have a better chance than most. New programmers would have no chance. We need black box systems to enable us to continue working.

The Real problem is that the black boxes we define don't have nice sharp edges, so when we put 2 boxes next to each other there are cracks. Cracks for the crackers to crawl through.
Joel Spolsky wrote about it and called it The Law of Leaky Abstractions

Not when peripheral vendors are building it into their hardware!

Jini was being hyped while it was still vaporware. Apple popped the cap on Rendevous just at the right time.

For more on this, read Joel's recent article.

Clear Channel is a dynamic distribution channel. What happens when they decide to start acting more like a label and less like a promotional wing of labels?

Swing (Sun's tech that lets you create GUIs the same xplat) stinks. But even Sun admits it, and (see the same link) they are doing something about it. Swing is no longer "a way for database apps to display debugging information in X11".

I'm still hoping for a Swing replacement from Sun that'll ship with its java virtual machines, but until then we have IBM's SWT which ties the widgets much more closely to native counterparts and Apple's attempts to merge Swing directly to native GUI widgets. We're nowhere close to Windows.Forms yet, but Swing's not so bad that you can't get the hang [notice I didn't say Swing] of things quickly.

The point being that you have options. Once you get the hang of Window Managers (doesn't take long) and creating some sort of Model for everything (from sorting tables to adding new values to lists), you can do complicated layouts that work xplat more quickly in the text editor of your choice than you could hack up a static UI (ie, that doesn't resize well) in the Visual Basic IDE -- which, as everyone knows, is really what makes VB GUIs "so easy".

(Aside: Even more importantly would be a standards-compliant parallel to what Microsoft's Web Forms does for IE... a quick, smart widget toolkit for the web. A "JWeb Forms" for JSP would do a lot to enable smart web-enabled UIs to Java web services.)

And there's nothing about Java that stops it from being a great client-side language short of Swing. Moore's Law and clever JIT VMs have pretty much done away with any show-stopping speed issues. Another hurdle is the fact that Java only compiles to bytecodes, making [even commercial] apps trivial to decompile, but if you look at VB 7 (aka, VB.NET) and C#, Java's most closely related competitors, they've got the same problems.

And sure, Java is more "Write once, test everywhere" than "... run everywhere", but you're not going to find an easier port from one platform to the next than Java. It commoditzes the user's operating system, and that's a great thing.

And heck, I'm using it. At least I'm putting my money where the keyboard is.

My point has always been "Monopolies are bad for competition."

Didn't you ever take Econ 1? Pure capitalism (i.e., competition) tends toward monopolies. In real-world competitions, there are never ties. Given enough time, one will always prevail over all others. Monopolies aren't inherently bad, but monopoly = power and power corrupts, so monopolists tend to make descisions that aren't in the best inteest of the populace. That's why we don't have pure capitalism--because we have a government that will step in if it feels it needs to. Remember, if men were angels, we wouldn't need government.

Monopolies tend to make companies lazy, which I think is your point, but then capitalism takes over--someone gets lazy, someone else innovates, the innovation usually involves efficiency so they can sell their product at a lower price, thus creating competition again. The problem comes when the monopolist uses his power to crush the new company, rather than competing fairly. Monopolies are bad for competition... but only for a little while. (State-sponsored monopolies, like the USPS or local utilities, are in the same boat--the gov't preventing true capitalism.)

For example, McDonalds is bigger than Burger King. If they wanted to (and were allowed to), McD's could put BK out of business in 6 months by selling everything on their menu for $0.05. That is what the government considers "unfair" and will step in to stop, which is why BK and McDs coexist, as they do. But if this were pure, unregulated, no-holds-barred, take-no-prisoners capitalism, Ronald would be wearing the King's crown. (Or, possibly, KFC, which was the biggest chain in the '70s.)

And anyone who says (you didn't, I'm just ranting now) that Apple is a monopoly is a) still bitter about Steve and OS 8 ending the clones or b) on crack. Yes, they have a monopoly on Macintoshes, the same way that Ford has a monopoly on Mustangs. Apple hardly has a monopoly on personal computers; certainly no more than Ford has a monopoly on cars.

And (I'm getting really way off here), take heart in knowing that monopolies don't last for forever. Examples:
IBM -> Microsoft
Iomega Bernoulli -> SyQuest -> Iomega Zip
Lotus 123 -> MS Excel
Fun story about that last one from a former MS emplyee and all-around pretty bright guy.

Applying antialiasing to screen fonts makes them harder to read. See
Joel on Software for the complete argument: http://www.joelonsoftware.com/printerFriendly/arti cles/fog0000000041.html

I'm sort of impressed to see people still plugging away at the Bayesian spam filter problem. It's admirable to see that kind of preserverance in programmers.

For those coming late to the story, Joel Sponsky demonstrated in his well known column recently that Bayesian filtering of spam is an intractible problem. Until we have quantum computers, we're stuck with black lists, which work pretty well anyway.

But keep plugging away guys. Who knows, maybe Joel's wrong.

According to his weblog, the article is about ten days old, that's all. As it seems to be with all these things (except Apple browsers, of course), they're all announced months before they're available, just to drum up some interest.

I'll confirm this one. I used to work for a small software consulting company, and we would sometimes get work from that was supposed to be done by a big consulting company but had been screwed up. Inevitably, this was exactly what had been done - the client had been impressed with the guys in the $5000 suits, but the people doing the coding had no understanding of the design and produced garbage. This obviously did not happen every time, but we were called in to clean up the mess more than once.

It all stems from the fact that consulting doesn't scale well, no matter what continent you live on.

When the distribution is expensive, then you filter the crap before the distribution. However, these filters always cost an unknown quantity more than their operating cost: they have false-positives in their crap-detectors and false-negatives in their goodsuff-detectors. I think its just a corollary of the 2nd Law of Thermodynamics (entropy), but The law of Leaky Abstractions (discussion) applies here also. In other words: Bayesian filters aren't much better than a bunch of publishers. Any publisher's experience of a work must be abstracted, and that abstraction is a function of that publisher's genetics and environment. It leaks at the "Beauty is in the eye of the beholder" point, and thus some crap will be suffered by the consumers, and some priceless work will be lost forever because it is mistaken for crap. A lot of other stuff in between can end up in the wrong pile as the publishers sort things out.

Publishers are weak, unreliable (even at their best) arbiters of quality, which is why we need a lot of them. Some might say, the more the better. In a world where all authors can be publishers, and some non-authors can be publishers, the number of publishers can exceed the number of works being published at one time. That doesn't solve the problem, but it DOES keep it from getting completely out of hand to the point where consumers' opinions (crap vs. not-crap) are insignificant. If publishing is cheap, then the hidden costs are the big cost factor!

Joel Spolsky comments on what starting again from scratch did for Netscape. Now I've never looked at the Mozilla code, so I can't comment on what state it's in, but I'd be thinking long and hard before choosing to start again from a completely clean slate.

I don't know if the FTP connection problems are part of a nefarious plan by Microsoft, but Joel Spolsky had to deal with this exact situation over a year ago as well.

What is really troubling is how the bug has been known for years now, and Microsoft has done absolutely nothing to resolve it.

Another Spolsky article points out the dangers of say, someone who knows Visual Basic, but doesn't know how to get around its limitations. Yes, you should know the language and the API's you are working with. But you should also know whats going on under the hood.

Why do specific languages seem to be more important to employers than CS concepts. Someone with a good background in CS should be able to work in a number of languages and be able to pick up new ones quickly.

Seems to me its more important to know algorithms, data structures, how to implement parsers, how to optimize databases(or knowing when its better to use a custom data structure rather than a database), etc.

I get really tired of hearing this one. Joel Spolsky wrote a bit on this. As you note yourself, "...in my experience knowing what to do with these languages far outweighs knowing the language itself." However, this doesn't usually consist of optimizing sorting algorithms, but more frequently understanding and knowing the details of vendor APIs (ISAPI, MAPI, SAPI, Win32, .NET, Java class libraries, STL, etc). This is something that is only learned through the pain of time spent using these tools. It's not just the language that is being looked at, but experience with the technologies involved.

-jerdenn

Joel is about 50% of the way to inventing Extreme Programming (or yet another Agile methodology) on his own.

Your tasks should be measured in hours, not days.... it forces you to design the damn feature.

Joel Spolsky on "Painless Software Schedules"

Yeah, it's a lot of hard work. Deal with it.

Joel Spolsky on "Painless Software Schedules"

Yeah, it's a lot of hard work. Deal with it.

I work with a guy who is 42 and has programmed with punch cards. He's a god. He has solutions for problems that he has had to face 10 times and really knows how to get through them.

The best reason for experience being so valuable with programming is The Law of Leaky Abstractions. Sure, most of us can learn the basics of a language pretty quickly, but to be really good with anything takes time.

The problem is, if the industry stays wildly unpredictable and shaky, there won't be any old timers around. It's funny, this seems to be the American way. Invent and exploit new thing with a huge labour pool and amazing capital markets, grow rapidly, slash and burn and then watch Asia and Europe build stable industries. BMW, Airbus anyone ?

Then again, if you're in biotech the US might be the place to be for the next 10 years.

Umm, methinks you mean Joel Spolsky. For the uninitiated, try http://www.joelonsoftware.com/

Just how difficult is it to port a Mac OS 9 app to Mac OS X's Carbon APIs? It's not that hard. Carbon apps are native Mac OS X apps and still binary compatible with Mac OS 9.

If Quark had not wasted YEARS rewriting Xpress from scratch (ala Mozilla), then Adobe InDesign would not have made the inroads it has (ala IE). Imagine a world a few years ago where designers had to choose between upgrading their huge library existing Quark files to a Quark XPress 5.1 Carbon app for Mac OS X or starting over with the incompatible, untested Adobe InDesign 1.0? Adobe wouldn't have had a chance..

Joel on Software: "Things You Should Never Do, Part I"

Mod Parent Up! The The Law of Leaky Abstractions is a must read.

This is just silly. If one wants people to use Linux, you've got to eliminate barriers keeping them from doing so. WineX is a solution (although it may not be perfect) for lowering one of the most important barriers: 'Can I still use that Windows app that I use so much when I switch'.
Read this interesting article by Joel Spolsky, about removing barriers for more info.

Furthermore, do you really think there are less people developing OSS because there's WineX. I don't think so, maybe fewer developers will try to rewrite a win application that works perfectly wih WineX, but they will develop something else instead (work enough if you ask me).

Stef

the parser can recover from malformed pairs

You mean die from malformed pairs, right? XML disallows any sort of "recovery". Parsers must abort on any kind of mistake like that.

The "benefit"- that error detection is easier- is a tiny one, and far outweighed by the greater difficulty in modifying XML in a traditional text editor. (Sure, an XML-aware editor could update the closing tag for you, but a smart editor would do its own checking anyway).

Another drawback is that XML parsers are more complex and slower than similar Lisp parsers. Of course the performance difference is tiny, but since people want to use XML with big databases and small devices, it still matters.

Having been at the software development game for about 20 years, I've been through the structured programming/data flow design/yourdon/OMT/UML methodologies at various levels of expertise, tools from vi/cc, borland turbo pascal/C on 8086, dec 10 and vax/vms fortran, visual C++, Jbuilder, etc. I haven't seen it all by any stretch, but I've seen enough to know that it hasn't all changed that much. In my time, we've just moved from designing libraries to looking for patterns, which has the side effect of resulting in somewhat useful code. Bottom line is the stupid little detail that was forgotten, or a missing key piece of info from the spec or customer causes endless havoc. If anything, the situation is worse because what we do has gotten more complex and the tools that we work with are essentially leaky abstractions (see Joel on Software) and if you didn't work at the low levels when your latest whizzy development environment doesn't produce code that works, you'll have a pretty difficult time figuring out the problem. Its still a black art, experience counts, and don't believe everything (anything?) the buzzword compliant managers or sales rep say.

The law of leaky abstractions (Joel on Software) seems to address at least one aspect of why this software nirvana has not been achieved.

--Shashank

I know everybody *hates* VB, and sneers at the people who use it (the more thoughtful amongst the slashcrowd sneer at people who use *only* VB, but whatever).

I have never, ever understood this. When I graduated from college, I was still twitching and gibbering from writing Motif apps for assignments. The real reason Unix people prefer command-line tools is that Motif apps are just not worth it to develop. ;)

Then I spent a little time writing Windows apps against the good ol' C api. That sucked too. Remember those massive switch statements in your event handler?

Then they came out with VB 1.0. It was jaw-droppingly awesome. Don't any of you remember, ALL YOU HAD TO DO WAS DRAW YOUR @#$(*&(@*#& WINDOWS AND THE APP WAS THERE. Double-click on a button, and open an editor to write its callback function.

And you know what, it's still true! Sure, if you're writing a device driver it's not going to help much. Sure, sure, obey Joel's law and call out to C where appropriate, but if you need a good solid UI for your program, why the heck not?

People complain about how any moron can slap together a crappy VB program that kind of works. Isn't that kind of the point? Wouldn't Linux, or *BSD, or (ahem) GEOS have benefitted hugely from VB or something like it?

I liked the article, but I followed the link to strings are hard and I wasn't so impressed with the guy. To quote"

As every compiler writer knows, lexing and parsing are the slowest part of compiling.

How about optimizing compilers? I find I get performance hits when I turn on optimizations in gcc when I specify -O3 as opposed to -O0. Somehow, I doubt it's a result of lexing or parsing.

It's a gross generalization and I strongly suspect that sort of thing permeates all his writings, given that he spouts off on XML in the aforementioned article as well.

Woz

The simplest thing that could possibly work (don't design more than you already need, and be ready to evolve it) is a tenet of XP. AbstractFactoryContainerXYZYourMom instead of a getter sounds like architecture astronaut-grade overgeneralized design in advance (or slavishly following design patterns instead of adapting them to your needs). Pair programming doesn't guarantee that what you were doing was XP.

DirectPlay - A high level networking API. DirectPlay is independent of the underlying protocol, and encapsulates high level networking concepts like meeting places and session management.

1) Whoever gets to the market first, and has more zealots is best (where best=more credibility, more freedom, more quality)

2) Linux should never approach companies, and capitalist markets, under the risk of losing freedom.

3) Linux distribution quality is measured largely by the ability to run in older hardware. Conversely, ability to adapt to new hardware features is irrelevant because no one measured it.

Answering point by point:

1) You should be running a *BSD. It has been around since the late 70s. Its zealots are by far the most fanatic among the OSS crowd. Security and stability are unbeatable by Linux. Its harder to run. Harder than Debian, now that I come to think of it that way.

2) Some companies are likely to see linux as a strategic advantage. In fact, IBM, the main supporter behind Gentoo, is one of them. It'd be stupid to forfeit this help. See this article for some insight on IBM's (and others') motivations on OSS.

3) I totally refuse this "old hardware" vision. And it's not that you can't install older software on a Gentoo distribution. Just emerge older ebuilds. The fact that you *can* emerge recent software doesn't mean you *have to*. And to think you have to measure the gain in performance from i386 asm to P4 asm is unclassifiable.

Things You Should Never Do, Part I

Joel Spolsky wored with MS on the Excel team and points out that in user studies they did the ability of excel to record data in such a way was important in it's adoptance. Check out the chapter from his excellent book User Interface Design for programmers and search for excel.

so you're saying that if windows does it it is alright?

For a solid discussion of why design consistency (across programs, platforms, and systems) is key, check out Joel On Software's User Interface Design for Programmers. Here's the relevant part of the argument:

I've seen companies where management prides themselves on doing things deliberately differently from Microsoft. "Just because Microsoft does it, doesn't mean it's right," they brag, and then proceed to create a gratuitously different user interface from the one that people are used to. Before you start chanting the mantra that "just because Microsoft does it, doesn't mean it's right," please consider two things:

1. Even if it's not right, if Microsoft is doing it in a popular program like Word, Excel, Windows, or Internet Explorer, then millions of people are going to think that it's right, or at least, fairly standard, and they are going to assume that your program works the same way. Even if you think (as the Netscape 6.0 engineers clearly do) that Alt+Left is not a good shortcut key for "Back", there are literally millions of people out there who will try to use Alt+Left to go back, and if you refuse to do it on some general religious principle that Bill Gates is the evil smurf arch-nemesis Gargamel, then you are just gratuitously ruining your program so that you can feel smug and self-satisfied, and your users will not thank you for it.
2. And don't be so sure it's not right. Microsoft spends more money on usability testing than you do, they keep detailed statistics based on millions of tech support phone calls, and there's a darn good chance that they did it that way because more people can figure out how to use it that way.

it becomes apparent that the more accurate model is that of many kernels and many GUIs, a sort of "choose one from column A and one from column B" paradigm. the user gets to mix-and-match to suit his own tastes and needs, and that, to my mind, is REAL freedom.

That would be fine if the issue were choice. The issue is usability. For the common user. For Joe and Jane Average. The book I've been reading on UI says that you should respect your userbase and have little respect for them at the same time.

As a newbie programmer, and a long-time computer user/sysadmin, I try to pick up books that cover subjects like usability to keep from making mistakes with the stuff I write. I don't want to create the next app people love to hate (ie. MS Bob).

The point that's run through this thread (and the others on this page) is that Linux is not ready for the average user's desktop. Not because you don't have enough choices, but because there are too many, none of them quite adequate.

I'm not trying to incite a riot, just to point out that people in general aren't ready to embrace Linux because there isn't an interface that's easy enough to set up and use for the common user.

It's not aimed at you (or rather, it is, in theory, but it's way overkill, and you'll spend more time doing meta-work than actually getting things accomplished.)

Instead, read some of the articles at Joel On Software, especially the Painless Software Schedules and Painless Functional Specifications He's somewhat arrogant, and he's a Windows developer (ex-Microsoft), but he's dead right on how to do basic functional specs and schedules. Once you've got something basic worked up, and have actually used it on a couple of projects, you can start looking at ways to improve.

It's not aimed at you (or rather, it is, in theory, but it's way overkill, and you'll spend more time doing meta-work than actually getting things accomplished.)

Instead, read some of the articles at Joel On Software, especially the Painless Software Schedules and Painless Functional Specifications He's somewhat arrogant, and he's a Windows developer (ex-Microsoft), but he's dead right on how to do basic functional specs and schedules. Once you've got something basic worked up, and have actually used it on a couple of projects, you can start looking at ways to improve.

I can't offer input here, but I can suggest you ask in forum for the Joel on Software software management discussion/article site. Good stuff there, good people.

How did this comment get to a 5? This person does not understand software development. If you need some more information on why we should not "replace the X windowing system alltogether", read this.

I'd check out material from Google, Amazon, The HCI Bibliography, NASA, the W3C, and Joel for starters.

While some may scoff, the ACM has an article on the Windows 95 interface, a little bit aged by now. Though many in this forum dislike Microsoft for its other faults (the constant crashes, draconian business practices, etc.), a big part of their current success comes from the fact that their user interface is simply easy to use. They do their homework when it comes to that.

My mom couldn't spell WWW when I set up my parent's computer for them a couple years ago. She complained that IE wouldn't go to the website after she typed in the address. It took me a while to realize that she wasn't pressing Enter when she finished typing the address in. That's why they have that little "Go" button next to the address box that I always get rid of right away.. Duh!

This is a noble quest, young hero. God speed.