Slashdot Mirror

...
Have you ever noticed that when animals are let out of cages, they don't always realize at first that the door's open? Often they have to be poked with a stick to get them out. Something similar happened with blogs. People could have been publishing online in 1995, and yet blogging has only really taken off in the last couple years. In 1995 we thought only professional writers were entitled to publish their ideas, and that anyone else who did was a crank. Now publishing online is becoming so popular that everyone wants to do it, even print journalists. But blogging has not taken off recently because of any technical innovation; it just took eight years for everyone to realize the cage was open.

I think most undergrads don't realize yet that the economic cage is open. A lot have been told by their parents that the route to success is to get a good job. This was true when their parents were in college, but it's less true now. The route to success is to build something valuable, and you don't have to be working for an existing company to do that. Indeed, you can often do it better if you're not.

When I talk to undergrads, what surprises me most about them is how conservative they are. Not politically, of course. I mean they don't seem to want to take risks. This is a mistake, because the younger you are, the more risk you can take. ...

Actually college is where the line ends. Superficially, going to work for a company may feel like just the next in a series of institutions, but underneath, everything is different. The end of school is the fulcrum of your life, the point where you go from net consumer to net producer.

The other big change is that now, you're steering. You can go anywhere you want. So it may be worth standing back and understanding what's going on, instead of just doing the default thing.

All through college, and probably long before that, most undergrads have been thinking about what employers want. But what really matters is what customers want, because they're the ones who give employers the money to pay you.

So instead of thinking about what employers want, you're probably better off thinking directly about what users want. To the extent there's any difference between the two, you can even use that to your advantage if you start a company of your own. For example, big companies like docile conformists. But this is merely an artifact of their bigness, not something customers need. ...

A Public Service Message

I'd like to conclude with a joint message from me and your parents. Don't drop out of college to start a startup. There's no rush. There will be plenty of time to start companies after you graduate. In fact, it may be just as well to go work for an existing company for a couple years after you graduate, to learn how companies work.

And yet, when I think about it, I can't imagine telling Bill Gates at 19 that he should wait till he graduated to start a company. He'd have told me to get lost. And could I have honestly claimed that he was harming his future-- that he was learning less by working at ground zero of the microcomputer revolution than he would have if he'd been taking classes back at Harvard? No, probably not.

And yes, while it is probably true that you'll learn some valuable things by going to work for an e

...
Have you ever noticed that when animals are let out of cages, they don't always realize at first that the door's open? Often they have to be poked with a stick to get them out. Something similar happened with blogs. People could have been publishing online in 1995, and yet blogging has only really taken off in the last couple years. In 1995 we thought only professional writers were entitled to publish their ideas, and that anyone else who did was a crank. Now publishing online is becoming so popular that everyone wants to do it, even print journalists. But blogging has not taken off recently because of any technical innovation; it just took eight years for everyone to realize the cage was open.

I think most undergrads don't realize yet that the economic cage is open. A lot have been told by their parents that the route to success is to get a good job. This was true when their parents were in college, but it's less true now. The route to success is to build something valuable, and you don't have to be working for an existing company to do that. Indeed, you can often do it better if you're not.

When I talk to undergrads, what surprises me most about them is how conservative they are. Not politically, of course. I mean they don't seem to want to take risks. This is a mistake, because the younger you are, the more risk you can take. ...

Actually college is where the line ends. Superficially, going to work for a company may feel like just the next in a series of institutions, but underneath, everything is different. The end of school is the fulcrum of your life, the point where you go from net consumer to net producer.

The other big change is that now, you're steering. You can go anywhere you want. So it may be worth standing back and understanding what's going on, instead of just doing the default thing.

All through college, and probably long before that, most undergrads have been thinking about what employers want. But what really matters is what customers want, because they're the ones who give employers the money to pay you.

So instead of thinking about what employers want, you're probably better off thinking directly about what users want. To the extent there's any difference between the two, you can even use that to your advantage if you start a company of your own. For example, big companies like docile conformists. But this is merely an artifact of their bigness, not something customers need. ...

A Public Service Message

I'd like to conclude with a joint message from me and your parents. Don't drop out of college to start a startup. There's no rush. There will be plenty of time to start companies after you graduate. In fact, it may be just as well to go work for an existing company for a couple years after you graduate, to learn how companies work.

And yet, when I think about it, I can't imagine telling Bill Gates at 19 that he should wait till he graduated to start a company. He'd have told me to get lost. And could I have honestly claimed that he was harming his future-- that he was learning less by working at ground zero of the microcomputer revolution than he would have if he'd been taking classes back at Harvard? No, probably not.

And yes, while it is probably true that you'll learn some valuable things by going to work for an e

Actually, if you the following article on complements (article), you'll see why ensuring "free" software exists is a good thing for his hardware business.

Not only are there usually no written specs but the code will also have undocumented obscure fixes for particular problems. If you don't know what the problem is you can't test for it. It may be that under special circumstances for a particular customer certain things need to be done so that for most customers ripping out the code to conform to some half baked spec you just thought of will work. This is so common in legacy code its almost a law. Joel had a bit to say on this in his essay on why you shouldn't re-write code (oh gees do I have to give a link ... ok for the google impaired here)

Its not so much a question of the data but more the way the actual data is structured. Databases impose a rigid structure on the data, or a leaky abstraction. If the data you have does not fit a rigid structure then the underlying asumptions of a database do not fit your needs well.

There are certain problems where this sort rigid structure works well, say a catalogue of car parts. But theres others where the rigid structure can prove to be more a pain than an advantage.

Take for example representing the medical records of a person. This has potential to be a very complicated structure. Indeed any structure imposed may well fall down at some point. There will be patients with rare conditions, who will have some specalised diagnostic tests. The database designer will not no aproir how to represent the results from these test. Fitting such data into the structure could be a maintance nightmare (maybe this is why so many of the big government IT systems have such a hard time). We could play a fun game here: you propose a data structure, I'll come up with with a counter example which will not fit.

I guess the problem is we are trying to represent the world here. Its known that there is no ontology (clasification system) which will serve all purposes. Theres philosophical problems about the nature of languare and how we can represent grammer and draw inferences. Yet what do databases offer us to represent textual data: a block of text! Fifty years of computers and they best method we've comeup with for representing a richly structured piece of writing like a wikipedia article is: a block of text. Ok, theres a bit of markup there but its all just stuffed together in a textblob. I might as well just dump it in a file for all the good a database does, indeed thats what yahoo does.

To my mind databases are broken beyond belief.

I'll simply note that per Joel Spolsky, it is easier to write code than to read code.

Thus we are doomed in software to revist anew the lessons others have painfully addressed and at length.

See: http://www.joelonsoftware.com/articles/VC.html
http://www.research.smu.edu.sg/faculty/edge/entrep _fin/papers/SER-VCandGrowth_WP_dec_2002.pdf
http://lrrc3.sas.upenn.edu/chinese/business/textbo ok/TransU4L2.htm

I'm surprised nobody recognized this as Fire and Motion yet.

Probably doesn't have much to do with PDF as the Mac's new display system, directly. Though this may come as a result of seeing how well PDF / Preview / Print->Save-as-PDF work on the Mac. Microsoft doesn't have anything that nice right now.

Remember how the Excel team's motto is "Find the dependencies -- and eliminate them"? This is just extending that to the whole system.

Microsoft doesn't have something like PDF. PDF (and maybe Postscript) is really the only PDF-like thing on Windows. The PDF standard, while open and free and all that nice stuff, is written by Adobe -- so if you were feeling paranoid, you might imagine that Adobe would put something in the next version of PDF without thinking of how hard it would be on Microsoft.

All (or nearly all, I would guess) of the other industry standards that Microsoft uses, they have people on. Look at HTML, CSS, Unicode, ...

Every standard Microsoft uses, they (a) wrote/control themselves (Word, ...), (b) forked/cloned to gain control over (.NET, ...), or (c) if they have no choice and have to use an international standard, they make sure to have people on the committee (Unicode, HTML, ...).

Microsoft is a very paranoid organization, and they want to be able to run a 100% Microsoft system. Adobe is standing in their way.

"There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It's harder to read code than to write it."

From Joel on Software
http://www.joelonsoftware.com/articles/fog00000000 69.html

Always comment.

For all you MS-apologists out there:

when was the last time you saw an ATM with an error that wasn't an Window error?

There is rarely such a thing as a bug-free release, and you don't necessarily want to fix every single bug before release. Here's a
good explanation on why not.

It can be, but this isn't UI. This is core library stuff.

(And there are people being paid to hack X. HP is paying guys to work on Xorg. I'm pretty sure other companies -- like Redhat -- do, too. So if you were trying to say that there's a salary requirement, I'd say we're doing just fine on that count, too.)

Mac OS X can do impressive things because they had (virtually) no backwards-compatibility requirements. Mac OS 9 apps run in a special environment, and can't take advantage of most of the new graphical features. When you're selling the hardware and the operating system and a lot of the software, you can change systems by executive fiat. That's a rare position to be in.

It has nothing to do with open-source. Microsoft has the same problem: look how much work they have to put in to ensure compatibility with everything from CP/M to Windows XP! (Their big selling point, from day 1, was being able to run CP/M software.)

In a sense, X11 is getting both the hot graphical features that Aqua has, and the backwards compatibility with millions of existing apps that Windows has. *No* operating system has the Mac interface (except Macs); if anything, this is a mark against not being a Mac, not a mark against open-source.

I could turn this around: Mac OS X uses many open-source technologies. Linux is completely open-source. Windows has a terrible user interface, and is completely proprietary, therefore, proprietary software leads to bad user interfaces. (Not true, of course, but no less true than your assertion.)

• '... This is the way Microsoft works: they have a product team for each product, and every year or two, that team ships a new version of their software. That's all. What we have here, ladies and gentlemen, is a pure marketing team that looked around at all the upcoming releases, decided they need a "theme" to make Microsoft look like Big Revolutionary Innovators, and ordering everyone to call their next thing ".NET". ...'
  [Microsoft Goes bonkers - JOS, July 22, 2000].

This reminds me of a JOS article, Microsoft Goes Bonkers by Joel. Do some substitution for .Net and no wonder your cynicism is piqued.

• '... This is the way Microsoft works: they have a product team for each product, and every year or two, that team ships a new version of their software. That's all. What we have here, ladies and gentlemen, is a pure marketing team that looked around at all the upcoming releases, decided they need a "theme" to make Microsoft look like Big Revolutionary Innovators, and ordering everyone to call their next thing ".NET". ...'
  [Microsoft Goes bonkers - JOS, July 22, 2000].

This reminds me of a JOS article, Microsoft Goes Bonkers by Joel. Do some substitution for .Net and no wonder your cynicism is piqued.

Joel on Software has another set of relevant articles. See "Painless Functional Specifications" and "Don't Let Architecture Astronauts Scare You."

Sample spec

"Here are some of the things I put in every spec.

A disclaimer. Pure self defense. If you put a paragraph saying something like "This spec is not complete", people won't come into your office to bite your head off. As time goes on, when the spec starts to be complete, you can change it to say "this spec is complete, to the best of my knowledge, but if I forgot something, please tell me." Which reminds me, every spec needs:

An author. One author. Some companies think that the spec should be written by a team. If you've ever tried group writing, you know that there is no worse torture. Leave the group writing to the management consulting firms with armies of newly minted Harvard-educated graduates who need to do a ton of busywork so that they can justify their huge fees. Your specs should be owned and written by one person. If you have a big product, split it up into areas and give each area to a different person to spec separately. Other companies think that it's egotistic or not "good teamwork" for a person to "take credit" for a spec by putting their name on it. Nonsense. People should take responsibility and ownership of the things that they specify. If something's wrong with the spec, there should be a designated spec owner, with their name printed right there on the spec, who is responsible for fixing it.

Scenarios. When you're designing a product, you need to have some real live scenarios in mind for how people are going to use it. Otherwise you end up designing a product that doesn't correspond to any real-world usage (like the Cue?Cat). Pick your product's audiences and imagine a fictitious, totally imaginary but totally stereotypical user from each audience who uses the product in a totally typical way. Chapter 9 of my UI design book (available online for free) talks about creating fictional users and scenarios. This is where you put them. The more vivid and realistic the scenario, the better a job you will do designing a product for your real or imagined users, which is why I tend to put in lots of made-up details.

Nongoals. When you're building a product with a team, everybody tends to have their favorite, real or imagined pet features that they just can't live without. If you do them all, it will take infinite time and cost too much money. You have to start culling features right away, and the best way to do this is with a "nongoals" section of the spec. Things we are just not going to do. A nongoal might be a feature you won't have ("no telepathic user interface!") or it might be something more general ("We don't care about performance in this release. The product can be slow, as long as it works. If we have time in version 2, we'll optimize the slow bits.") These nongoals are likely to cause some debate, but it's important to get it out in the open as soon as possible. "Not gonna do it!" as George Sr. puts it.

An Overview. This is like the table of contents for your spec. It might be a simple flowchart, or it might be an extensive architectural discussion. Everybody will read this to get the big picture, then the details will make more sense.

Details, details, details. Finally you go into the details. Most people will skim this until they need to know a particular detail. When you're designing a web-type service, a good way to do this is to give every possible screen a canonical name, and provide a chapter describing each one in utter and mind-numbing detail.

Details are the most important thing in a functional spec. You'll notice in the sample spec how I go into outrageous detail talking about all the error cases for the login page. What if the email address isn't valid? What if the password is wrong? All of these cases correspond to real code that's going to be written, but, more impor

Sample spec

"Here are some of the things I put in every spec.

A disclaimer. Pure self defense. If you put a paragraph saying something like "This spec is not complete", people won't come into your office to bite your head off. As time goes on, when the spec starts to be complete, you can change it to say "this spec is complete, to the best of my knowledge, but if I forgot something, please tell me." Which reminds me, every spec needs:

An author. One author. Some companies think that the spec should be written by a team. If you've ever tried group writing, you know that there is no worse torture. Leave the group writing to the management consulting firms with armies of newly minted Harvard-educated graduates who need to do a ton of busywork so that they can justify their huge fees. Your specs should be owned and written by one person. If you have a big product, split it up into areas and give each area to a different person to spec separately. Other companies think that it's egotistic or not "good teamwork" for a person to "take credit" for a spec by putting their name on it. Nonsense. People should take responsibility and ownership of the things that they specify. If something's wrong with the spec, there should be a designated spec owner, with their name printed right there on the spec, who is responsible for fixing it.

Scenarios. When you're designing a product, you need to have some real live scenarios in mind for how people are going to use it. Otherwise you end up designing a product that doesn't correspond to any real-world usage (like the Cue?Cat). Pick your product's audiences and imagine a fictitious, totally imaginary but totally stereotypical user from each audience who uses the product in a totally typical way. Chapter 9 of my UI design book (available online for free) talks about creating fictional users and scenarios. This is where you put them. The more vivid and realistic the scenario, the better a job you will do designing a product for your real or imagined users, which is why I tend to put in lots of made-up details.

Nongoals. When you're building a product with a team, everybody tends to have their favorite, real or imagined pet features that they just can't live without. If you do them all, it will take infinite time and cost too much money. You have to start culling features right away, and the best way to do this is with a "nongoals" section of the spec. Things we are just not going to do. A nongoal might be a feature you won't have ("no telepathic user interface!") or it might be something more general ("We don't care about performance in this release. The product can be slow, as long as it works. If we have time in version 2, we'll optimize the slow bits.") These nongoals are likely to cause some debate, but it's important to get it out in the open as soon as possible. "Not gonna do it!" as George Sr. puts it.

An Overview. This is like the table of contents for your spec. It might be a simple flowchart, or it might be an extensive architectural discussion. Everybody will read this to get the big picture, then the details will make more sense.

Details, details, details. Finally you go into the details. Most people will skim this until they need to know a particular detail. When you're designing a web-type service, a good way to do this is to give every possible screen a canonical name, and provide a chapter describing each one in utter and mind-numbing detail.

Details are the most important thing in a functional spec. You'll notice in the sample spec how I go into outrageous detail talking about all the error cases for the login page. What if the email address isn't valid? What if the password is wrong? All of these cases correspond to real code that's going to be written, but, more impor

• You should write the spec before you start the project, not during.
  
• It should have one and only one author
  
• You need to flag Open Issues and Side Notes by themselves so you can search for them later.
  
• The functional spec should be a living document.
  
• Be funny: specs are only good if they are read. The more funny anecdotes the better.
  
• Be pithy and understandable.
  
• Lots of screenshots, tables and diagrams to break up long pages of text.
  

Painless Functional Specifications--not precisely what you were looking for, but pretty close, I think.

Summary:
This series of articles is about functional specifications, not technical specifications. People get these mixed up. I don't know if there's any standard terminology, but here's what I mean when I use these terms.

1. A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.
2. A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.

One of his books: Joel on software

His blog: What's a Spec?

Highly recommended!

The day of receiving unsolicited coupons for your next latte as you walk by a Starbucks is one step closer.

One of my favorite quotes from joel on software: "It solves the one problem that coffee shops DON'T have, namely, advertising to peoplewho are standing right in front of the store!"

Paul Graham did a pretty good job at killing most spam, for an awful lot of people.

I'm not alone in thinking so: Joel Spolsky says "in practice, in the presence of lots of spam, human beings are far more likely to delete a real email than a well-implemented Bayesian filter".

Plus I think it's pretty cool that one guy with a Lisp compiler beat the crap out of Microsoft Research.

The proper solution is to use the named character entity references -- in this case ampersand + "eacute" + ; which will work regardless of the code page in use.

As refererence, I'd send you to the remarkable joelonsoftware article that explains why your approach fails to work in many cases:

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Look at how much MS or Apple have given back to BSD as opposed to how much linux has got from IBM. Who has the better dynamic community of sharing?

Wow! I like when people are really openly intelectually dishonest! Do you fail to see that IBM is in the server market, and that Linux OS is just a complement it needs to turn into a commodity to them? OTOH, Apple did give back to FreeBSD (see Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD. Apple's pattern is to sync every major Mac OS X release with the latest major FreeBSD release. and Apple hires open-source leader.)

Just because you are desinformed, or because you think Leenox is Kewl does not change the facts.
Here are some simple facts of life:
1) A pure open-source software house is a very hard to maintain thing. I'm not the one saying that, Miguel de Icaza of GNOME/Mono fame says it here

2) Because some company incorporates code under BSD license, does not mean the code went away. It's still there. Otherwise, is it envy that moves you, because some people are more technically knowledgeable than you? In that case, your problem is not a license problem, it is a problem only solved by study. Envy only means you've got mental problems, too. For instance, BitMover wrote better code than the open-source guys. Tough luck.

I want to know if anyone out there has done a successful migrations from Visual Basic on Windows to any application framework on GNU/Linux."

It's VBScript, rather than VB, but FogBugz has been automatically translated from ASP/VBScript to PHP. IIRC, some of the trickier problems were resolved through a hack that relies on Hungarian notation.

Today, the preferred system is 3Ghz, 64bit, with at least 2 gigs of RAM. Why? What's the point of such a powerful system? Speed! That's the point. Speed is important. Code efficiency is important. But, as programmers continue to deny this and produce poorly written and bloated/slow apps or use inefficient languages, the time will come when a 6Ghz processor is not enough. Doesn't that sound stupid?

Sure it does. But let's take a look at it:

1) It might cost the company an extra $25,000 to go through the performance tweaking to get it "right". Yes, a small team of coders, and a calendar month.

2) Let's say that they improve performance by 100%.

3) Assume that the software is server-based.

4) Cost to get software running "right" - $25,000. Cost to upgrade the server to a dual proc - $1,500. Which are YOU going to do?

I'd suggest that you read a bit more on the realities of software "BLOAT" before you go judging.

It's not what you think it is.

People, given the choice of better performance or better features will almost always choose the latter, because they can "do more". So, what's the economic incentive to hand-craft everything in assembler?

"c" is a compromise solution - I remember when it was considered a HIGH level language! The price/performance curve is always reshaping itself towards higher and higher level languages. Get used to it!

I see this as effectively raising prices for those of us who send rebates, since it will eliminate segmentation. Segmentation is the concept of getting customers to pay as much as the are willing to for a product. Here's a great article on Joel on Software on pricing. I don't see how best buy can offer the same deals after rebate, w/o rebates since they are eliminating the surplus from the folks that don't send them in. I'm also a bit skeptical of the 80% figure.

If you want your app to work for multiple versions, then only use the feature set exposed by the lowest version you want your app to be capable of running on. I don't think that's creating an unfair situation for developers at all.

Some of us developers do.

If you create a new feature that doesn't need any new system-level stuff in the new OS release, and you make it available as a library that developers can ship with their apps, then any version of Mac OS X can run the app.

At first, it seems to provide less incentive for users to upgrade: I can run all my cool apps with 10.3, so why buy 10.4? But I think it actually works out better. The big apps (like Photoshop) don't use these features; Adobe has the resources to make Photoshop run on 10.2 still. But people would gladly upgrade their OS ($129) to be able to run the latest Photoshop ($600). It's the little apps ($20 shareware stuff) that this affects, because they're 1-man jobs, and they're precisely the sort of things people won't upgrade their OS for.

Apple's cool linking mechanism just *begs* for this ("use the system library if it's at least version Y, else use the version of that library included with my app").

From the newest JoelOnSoftware:
"If one of our competitors think this is cool, they can copy us, but it'll take them a while, especially if they read my site and bought my line about only shipping every 18 months."

Isn't that the spirit? At least *they* don't need patents to do what they do.

(The article)

He has some of it online. Scroll down to "Tog invented the concept of the mile high menu bar...".

Cheers.

Hailing "blogging" is effectively like hailing paper - it's just a way to get your word out. Independent writers and publishers, like John Gruber (http://daringfireball.net/) and Joel Spolsky (http://joelonsoftware.com/) as well as the personal thoughts from people that are inside different industries - like Om - are what you like, the gems of which you speak. Sure - "blogging" as a media sure has its upsides, and I'm not sure we would have seen these writers without the rise of it. But hailing "blogging" - as some people here do - is no more correct than saying that all comments on Slashdot ought to be rated 5, Insightful. The opposite - degrading something for being based on the "blogging" format just because kids use it, too - is in essence no different than degrading the New York Times because the New York Times publishes on paper, and kids draw stupid stuff on paper. I hope we'll finally get away from all the hype on the particular media.

That is all true, but if you look at routing protocols, e.g. even the simple RIP protocol, you'll see that it crosses several network layers.
The same for other network services such as ICMP and so on.
Of course, there have to be instances in the routing process which know a lot of information about several things to make good decisions.

There was once an article on /. which was about leaky abstractions. This is IMHO a case of a leaky abstraction. But only because an abstraction is leaky doesn't mean that one should throw it out of the window! The most powerful thing we have that makes us able to deal with complexity is to build hierarchies :)

You might mean this.

Divers have a similar mantra, especially ones who do technical diving; nitrogen narcosis exaggerates emotions and a minor problem turns divers into a panic. The mantra- "as long as you're breathing, you're OK". Stop. Relax. Solve one problem at a time (incidentally, the other mantra is not to let problems pile up, because they compound each other; fix things as soon as you notice them...but it's a little late now). Tomorrow, if you see or remember a problem, just solve it. If anything, others might be inspired or encouraged by the activity.

You obviously have a lot of talented people. Get everyone to sit down, make a list of problems. Categorize them. Divide them up and hand them out or post them up on a page. Don't make committees- committees are great at wasting time. When you're behind the eight ball, you don't need a group of people to decide which way is the best direction to move- you've just gotta MOVE.

This might be a good time to plug Joel on Software's essay Fire and Motion.

The Chen Camp was the thing that made Microsoft the defacto OS, and the reason why people don't defect to other OSes: applications.

Using the Motley Fool's terminology, it looks like the Chen Camp lived in the Stage 2 days and the MSDN Camp is winning out in Stage 3.

I think your post adds to this guy's article and perhaps sheds some light as to what is going on in Redmond. I have to admit I find it interesting that Longhorn has been delayed for so long and that they have until recently totally dropped the IE ball.

Well, the real reason for the "Set" command was because it was a way to get around the lack of access to pointers.

I don't care what the reason was. Languages are an abstraction. That abstraction needs to be useful. One should not need to have the details of the implementation revealed to them. Certainly the implementation can force certain options in the implementation, but this is not (IMO) one of those cases.

Check out the following 2 links regarding the set statement:
http://www.joelonsoftware.com/items/2005/03/14.htm l
http://discuss.joelonsoftware.com/default.asp?joel .3.93789.16

Note that there is no disagreement that the set statement is wrong.

Yes, but they can make it more readable. I'm not a huge fan of default properties either, but they do have their place.

My opinion of languages is that they should try to enforce people writing good code. Find the one or two good ways to do something and only provide those options. See my comment in this thread on perl for example. I think default properties are on the borderline, but I'd be inclined to say that they should not be included as an option in the language.

Well, the real reason for the "Set" command was because it was a way to get around the lack of access to pointers.

I don't care what the reason was. Languages are an abstraction. That abstraction needs to be useful. One should not need to have the details of the implementation revealed to them. Certainly the implementation can force certain options in the implementation, but this is not (IMO) one of those cases.

Check out the following 2 links regarding the set statement:
http://www.joelonsoftware.com/items/2005/03/14.htm l
http://discuss.joelonsoftware.com/default.asp?joel .3.93789.16

Note that there is no disagreement that the set statement is wrong.

Yes, but they can make it more readable. I'm not a huge fan of default properties either, but they do have their place.

My opinion of languages is that they should try to enforce people writing good code. Find the one or two good ways to do something and only provide those options. See my comment in this thread on perl for example. I think default properties are on the borderline, but I'd be inclined to say that they should not be included as an option in the language.

Didn't someone earlier today comment on how Windows XP still runs programs from 1981?

There ain't no way Microsoft is going to scrap the Win32 API anytime in our lifetimes. They cannot. Their lifeline of revenue depends upon it.

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

The dumping of VB6 really underscores how Microsoft no longer cares about being backward compatible.

Maybe this hasn't been mentioned because there is no email client supporting an SQL database already. I think that Thunderbird should show the way and offer the possibility to store emails as an SQL database.

That searches give instantaneous results would make a part of my job way easier. It seems to me that many email programs fail at that. There is Spotlight from Apple, but it's a feature of the OS. I like the way iTunes lets me navigate through MP3/AAC files. The whole interface of iTunes is built around the idea that you're going to look for a tune. Much more often than search a tune, what I find important is to quickly find what my friends and co-workers told me, and what I told them.

There are many big limitations in email programs, but they often are subtle in that they leave the responsability to the user. For example, Thunderbird with the default options puts the cursor at the end of the text when replying to an email. So I often receive an email response starting with a whole page of the very message I wrote! Only at the end do I read: "Agreed. John." Some might say it's the fault of whoever wrote the response; I think the email program is flawed.
Another example is the discouraging difficulty of create filtering rules. I don't know many people who have filters programmed. I think that 1% of email users is a realistic figure.

A good email program should make it easy to write good emails, not just tons of emails. All email programs are archaic. As, I said, they make searches a hassle.

A possible explanation for the very little sophistication of email programs is that typically, people that design software (1) are not the best communicators, (2) are not very good at improving their own tools.

For those interesting in the design of Social Software, Joel Spolsky wrote an interesting article on his blog. Recommended reading.

There seems to be an assumption that Groove was a success. Joel gives us a lot of food for thought:

Platforms

www.joelonsoftware.com/articles/Platforms.html

Don't Let Architecture Astronauts Scare You

www.joelonsoftware.com/articles/fog0000000018.html

Response from Groove

www.joelonsoftware.com/articles/fog0000000011.html

There seems to be an assumption that Groove was a success. Joel gives us a lot of food for thought:

Platforms

www.joelonsoftware.com/articles/Platforms.html

Don't Let Architecture Astronauts Scare You

www.joelonsoftware.com/articles/fog0000000018.html

Response from Groove

www.joelonsoftware.com/articles/fog0000000011.html

There seems to be an assumption that Groove was a success. Joel gives us a lot of food for thought:

Platforms

www.joelonsoftware.com/articles/Platforms.html

Don't Let Architecture Astronauts Scare You

www.joelonsoftware.com/articles/fog0000000018.html

Response from Groove

www.joelonsoftware.com/articles/fog0000000011.html

The market rewards more then the tax costs, but Income tax does work against the individual doing better. There are other taxes (property, stock sales/value, corporate, VAT, etc...) which don't go against the individual improving themselves.

Income & Sales taxes are the two staples in the US government tax diet, and they are the two which penalize the average individual even as they work to increase their skills.

Now yes, it's prone to cheating, but that's because we've made it so complicated.

True that a flat(er) tax would curb cheating, but we added in all the crazy laws for reasons. Some of them were even legitimate reasons. (No, I don't want to guess at what percentage.) Do you want to answer for Home ownership incentives, single parents, Earned Income Tax Credit, renters deductions,... I'm not asking you too, just saying that taxes are a mess, and we can't just go with a flat tax +\- a few rules. Remember how botched it was the last time someone suggested a flat tax, (Forbes in 1996?,) it was: revenue stays the same, the rich pay less, and the poor, uh... they won't pick up the tab, honest, its better!

Makes me think of when Netscape decided to ditch all the 'ugly old' ftp code and remake it clean, only to realize that it was tried and tested, and worked.

We do need changes though, and big ones, but I don't know how to reconcile what I said above and the need for change...

Joel is an insightful guy, but he approaches software exclusively as a deliverable intended to Get The Job Done Now

That is a good point, and Joel himself touches on this in Five Worlds of Software.

(I am a Joel but not that Joel)

"Yo' codebase's so fat, when it get in a lift it has to go down!"

"Yo' codebase is so bloated, it's got its own dialling code!"

"Yo' codebase's so big, NASA includes it in orbital calculations!"

Etc. etc., ad nauseam et infinitum...

Software rewrites may be considered harmful, but at which point do you declare that enough is enough and start again, breaking it down into smaller, easily tested modules? Big, old projects (like, say, OpenOffice.org) can get so appallingly baroque that there must be vital areas of code which haven't been modified (or, more importantly, understood) in years - how do you test those?

Ah boy, I wouldn't want to hire you. Microsoft sits on a treasure chest, namely 10 years of bugfixed, known-to-be-working code. It contains every little obscure bugged that grandma Uxbuklu in outer Mongolia have ever encountered. And you want them to throw that away? That sounds great! If you're a Linux developer that is.

I would recommend you read what Joel has to say, since he say it so much better than I have time to do.

I think Google is smart enough to evolve from HTML+Java-Script+images to something like 0install+python+images and then you'll have the OS one the net with only a cache copy of the scripts+images locally, just like a cache copy of a web page. As for this guy....

Google doesn't necesarely needs a guy with inside Windows knowledge but they need a "smart guy that gets things done"

I don't think you can justify the price premium of an Apple based on design and manufacturing costs.

Apple simply charges a price that (some) people are willing to pay - they position themselves as a premium product and therefore they *have* to charge more - even if their costs are no higher than any body elses.

There's a very interesting article on Joel Spolskys site about pricing.