Well, specifying the API before you write is certainly a good idea. But you hardly need Javadoc to do that. The problem with Javadoc -- and all LP tools I've seen is that it confuses documentation with specification. A specification just has to be clear to other working on the project. It can be written by someone with no training in technical communication. The writer doesn't even have to have a full grasp of the language he or her is writing in -- computer terms are pretty universal.
None of that is true for technical writing. It's a discipline onto itself. It's not just about good writing. (I've known computer scientists who'd written award-winning papers and articles, but couldn't write technical docs worth beans.) It's about understanding your audience and the (often painfully boring) task of writing in the clearest possible language.
Not every project needs technical writers. If you're a small software shop, and you're building a set of components with an uncomplicated API, and hiring a professional writer isn't cost effective -- then yeah, use Javadoc or some other LP tools.
But for big projects... Back in 1998, I was in charge of production for the doc set of a large Java framework. Having the API docs embedded in the source code was a nightmare. Javadoc was supposed to allow any of the engineers who wanted to to do their own API docs -- but many botched it, because they didn't understand Javadoc or HTML very well. We had professional writers, but many of them couldn't be trusted with source code. Hell, some of them didn't understand why they couldn't edit the SCCS archives!
Worst of all was when the release cycle entered code freeze. Document freeze is always later than code freeze -- but you cannot let people modify the release code base during code freeze. The only solution was to split the source, then merge the docs back in after release. Very painful.
I looked at the cost of putting up a building just to block out direct sun from my office. Too expensive. Besides, what about the people who have to work in the new building?
Had a conversation with my optometrist on the whole eyestrain issue. His suggestions:
Close the blinds. No way, that crow outside the window would be offended.
Get "computer glasses". These reduce eye strain by being finely tuned to help you focus on your specific monitor setup. I got them, and they work -- but they're not practical for me, since I don't just look at the monitor.
Lower your monitor so it's at least 10 degrees below eye level. This one suprised me: everybody has tons of computer accessories designed to raise their monitors. I had a machine in an AT-style case -- designed to have the monitor sit on top -- and my monitor came with one of those swivel pedestal that raises it even further. But when I move the monitor off the computer and got rid of the pedestal, it did indeed help. Enough to make other measure unnecessary.
Oh, and as for the people who complain about the inferior quality of copy protected CDs, most of you are lying, especially when you listen on cheap speakers, about 5 metres from a pnumatic drill.
Uhm, I'm pretty sure "lying" means saying something you know to be untrue. Admittedly, most people mind being called stupid just as much as they mind being called dishonest -- but hey, if we can't keep our facts straight, we can at least keep our insults straight!
Investors (at least those who know what they're doing) do fixate on what they paid for a stock. If you've got 10,000 shares priced at $2 each, you've got $20,000 worth of shares. It simply doesn't matter how much you paid for it.
Maybe you took a loss buying those shares, or maybe somebody else took the loss and sold them to you for $2 a share. Either way, it just doesn't matter. What you care about now is turning your $20,000 into $30,000. The usual way for that to happen is wait for the company to grow. But if you know your share of the company's liquidation would be $30,000, you have every incentive to liquidate -- especially if the company is likely to burn through its assets, making your shares worthless.
What's the point of giving up one failing business model for another?
Caldera needs to find itself a nice niche. Given it's links to Novell, a Linux distro with tightly integrated NDS...
Uh, hello! Netware is dying too! Besides, no matter how good your distro is, it's pretty clear that there's a lot more to a successful Linux business model than a good distro.
Yeah, the mutation of Broadband from "using a broad frequency band" to "supplies a lot of bandwidth" is irritating. But face it, words change. Especially when they express technical distinctions most people don't know or care about.
So, umm... Why did they invest in the company in the first place?
To make a buck, of course. That's the only reason anybody buys stock. It's just the these stockholders see liquidating the company as a more likely way to make a profit than trying to fix the company.
This is an extreme case, but this problem is not unusual. Publically-held companies are always jumping through hoops to make their stockholders happy, and more often than not that means doing things that actually work against the long term growth of the company. Or, in this case, the short term growth!
Hey, computers don't "think" in variables and expressions either. Does that mean that C programmers are wankers that can't handle registers and address modes? No, it just means that C adds concepts that make programming easier. And that's all that OOP languages do.
Sure, there's a lot of crap C++ and Java code that's written by people who don't know what they're doing. That's true for any language. And a powerful language is easier to screw up in, just as it's easier to kill yourself in a Massarati than in a Model T. But that's a problem with the programmer/driver, not the language/car.
The price I quoted was from the Wolfram web site. I'm guessing that your school got a hefty discount by buying in bulk. Hmm, maybe I'll go make friends with a student....
A good PDA is a deliberately limited gadget. Palm was the first company to realize this, and that's why they came to dominate the PDA market. A good PDA has a slow processor, because PDA users need battery life more than they new raw computing power. A good PDA has synchronization (Apple never did get this) so people can use their computers to manage their data, and just use the PDA to access the data, or perform minor updates, when the computer isn't available. A good PDA has a very small screen, so the system itself is small enough to slip into a pocket -- but too small for things like graphing or sketching.
If you want a portable scientific computing appliance, your only choice is a Linux-based laptop. (I guess Sparc or PowerPC is preferable to Pentium for this kind of computing, but it probably doesn't matter that much.) Yes, a cheap laptop is pretty heavy, but no worse than some of your heavier textbooks.
If I were in your shoes, I'd really, really want to get a copy of Mathematica. But if I were in your shoes, I couldn't afford it: $900 for an academic license! Sigh.
It sounds to me like your alma mater has some very bad priorities. They're structuring their entire curriculum around demands that they produce engineers that pass some absurd shopping list of qualifications. Undergraduate education is supposed to be about developing your ability to acquire knowledge. If you concentrate solely on currently required technical skills, you end up with a set of qualifications that may put you in demand now, but puts you at a nasty disadvantage when (not if) the technology base evolves, rendering your current skill set obsolete.
The reboots are due more to external factors than the box needing it. Reliability is not an issue in the Windows based systems that I build.
Well, it sounds like you build solid NT systems. I never doubted that it was possible. But.
I often hear NT people claim that their boxes can be made as reliable and as secure as a box using any other platform, provided you do everything the right way. I actually believe this. The problem is, there's so much more that you have to do right. Every complexity, every hidden feature is an open invitation to Captain Murphy.
Saying that a complex computer system is a reliable as a simple computer system, provided you take all the right steps -- that's like saying raw Nitroglycerine is just as safe as Plastique, provided you don't drop it.
Samples, Learning
on
Perl and XML
·
· Score: 5, Insightful
The sample chapter on the O'Reilly site contains a lot of what I dislike about about O'Reilly books: too much cuteness, not enough organization, too many useless examples. The last are particularly dumb: you don't want to do your own XML parsing, the authors say repeatedly that you don't want to do your own parsing -- yet most of the examples are parsing code!
It's also dumb to have any introductory XML material if you're not going to be serious about it. Which gives me an excuse to plug my favorite XML for beginners book, Harold's XML Bible, 2nd edition. Yeah, stupid title (who are you, Moses?), and the CD-ROM is badly put together (you'll need to convert some text files from Mac format!). But the book itself is very good. No assumptions at all about previous knowledge If you know jack about XML, or you understand the basics, but can't figure out how it's used, this is the book you want.
I should have said "pre-emptive multitasking". MacOS 9 and earlier (and also Windows previous to Windows 95) only support a sort of voluntary multitasking, which assumes that all programs are well-behaved and give up the CPU when the don't need it. Since programs are rarely that well-written, it doesn't work very well. Serious OSs (like Unix) consider pre-emptive multitasking a basic feature.
This is also obvious when you see how rare the MPAA rereleases great films. How many out there who own 2001 on DVD would pay to see it on the big screen.
Well, me for one. Actually, I'd settle for one of those $10,000 hires umpteen inch TV sets (plus a DVD player with digital output, of course). Which I'd never consider worth the cost, even if I had that kind of money to throw around. Just as good would be a place that rented time on such a system. Even if it were expensive, it'd be something you could chip in on with friends, and it'd be a fun social evening.
Except. People have already tried to set up such operations. Well, when I read about it, it was projection analog TVs and VCRs, which might or might not have succeeded financially. But they had no chance to find out -- they were soon confronted with studio lawyers, pointing at the "no public performance" fine print on the tape boxes.
I think you read too much into Apple's decision making. Maybe there are people out there who bought Macs because, or partly because, they were infatuated with the iPod -- but I haven't seen any of them. Face it, the iPod isn't that much better than its competition. Not enough to justify the high initial cost for the unit itself, plus the additional cost of a firewire interface for the majority of PC people who don't already have them.
(It's nice that Macs have always come standard with fancy options like networking and special interfaces. But it's also why Mac prices are higher and profit margins are lower.)
If the internal politics at Apple are anything like other development orgs, it went like this. The FAT versus HFS decision was made by engineers, not marketeers. The marketeers either didn't understand the impact of this decision or were not consulted. Somewhere along the line, somebody realized that this was excluding most of the potential market, so there had to be a FAT version. But obviously they didn't even start on this until the HFS version was finished. (If the iPod had been less succesful, they never would have started at all. I'm still waiting for my Windows port of the Newton Development Kit.) This might seem dumb in terms of grabbing market share, but working on both versions in tandem would have meant hiring more people -- and development orgs are under a lot of pressure to keep their head counts down.
Well, I certainly deserved to be modded down, since I had my facts wrong. But "Flamebait"? That makes assumptions about my motives, which everybody seems too ready to do.
Yeah, go ahead, mod this one down as "offtopic". That's what it is after all. Unless, of course, you can think of a better way to use your mod points.
Even though I'm a PC person, I'm forced to concede that the Mac hardware is far superior. If I made my choices based solely on hardware sexiness (not an option for most of us), I'd refuse to use anything else.
But jeez, the software. For years, they've been stuck with an antiquated, non-multitasking OS with a bloated, overdesigned API. Now, among the few little things I found to admire about MacOS were monitor spanning and adherence to the Apple HUIG. But apparently OS X supports neither! That's just sad.
When I was a Solaris user, I had no trouble getting vim working. Download the source,./configure, make. Then add the executable to your path.
One trick: some Motif programs (notably Netscape) have bad palette manners and grab a lot of colors they don't even need. I would always have at least one copy of gvim running so it always had the palette colors it needed.
Oh, before I start my rant, a reminder: Vim is charityware, and the charity is a very good one. If even a fraction of Vim users did the right thing, it'd make a big difference in the world. Used to be a pain to transfer, but now Bram has a PayPal account, so there's no excuse.
Ok, rant time. I'm big Vim fan. Every computer I own or use (well, every working computer) has it installed. The only editor that approaches EMACS's feature set, and nowhere near the great bloatware's klunkiness or unpredictability. But.
I'm rather disappointed that EMACS and Vi (and its clones, of which Vim is the best and mostly widely used) remain the most widely used text editors. Now each has strengths and weaknesses relative to the other, and it's no use rehashing those wars here. What's important is that both these editors are designed around constraints that are about 20 years out of date. Most especially, they were designed to be used by a text-mode terminal (very fancy ones, in the case of EMACS, very limited ones in the case of vi) over a relatively slow connection.
I won't comment on EMACS, since I lack the obsessiveness to be a serious user. But on vi, the big design decision was to build in a lot of modes to get around the limitations of the terminal. This allowed a lot of commands without function keys or complicated keystrokes. It also allowed the user to enter blocks of text without realtime update -- an essential feature on a 300 baud connection!
But, in a GUI environment, modes are a Bad Thing. Yeah yeah, some of you like being able to do complicated edits without moving your hands off the keyboard to grab the mouse. But most people have an easier time if they don't have to keep a state map current in their head.
Now Vim has impressive GUI support (platform-independent GUI support, which is the main reason I use it), but it still has all the modes of vi, plus 3 or 4 of its own. And its macro language is a kludgy extension of the simple-minded command language Bill Joy invented for the original ex/vi editor, itself a minor extension of the ed command language.
Various projects have tried to do all this over using modern design principles, but the EMACS and Vi user communities are just too entrenched. If I were a better programmer, I'd try it myself, maybe using the vim engine as a basis. But probably I'd be the only user!
Slashdot Mirror
None of that is true for technical writing. It's a discipline onto itself. It's not just about good writing. (I've known computer scientists who'd written award-winning papers and articles, but couldn't write technical docs worth beans.) It's about understanding your audience and the (often painfully boring) task of writing in the clearest possible language.
Not every project needs technical writers. If you're a small software shop, and you're building a set of components with an uncomplicated API, and hiring a professional writer isn't cost effective -- then yeah, use Javadoc or some other LP tools.
But for big projects... Back in 1998, I was in charge of production for the doc set of a large Java framework. Having the API docs embedded in the source code was a nightmare. Javadoc was supposed to allow any of the engineers who wanted to to do their own API docs -- but many botched it, because they didn't understand Javadoc or HTML very well. We had professional writers, but many of them couldn't be trusted with source code. Hell, some of them didn't understand why they couldn't edit the SCCS archives!
Worst of all was when the release cycle entered code freeze. Document freeze is always later than code freeze -- but you cannot let people modify the release code base during code freeze. The only solution was to split the source, then merge the docs back in after release. Very painful.
Had a conversation with my optometrist on the whole eyestrain issue. His suggestions:
For this, you must die!
Maybe you took a loss buying those shares, or maybe somebody else took the loss and sold them to you for $2 a share. Either way, it just doesn't matter. What you care about now is turning your $20,000 into $30,000. The usual way for that to happen is wait for the company to grow. But if you know your share of the company's liquidation would be $30,000, you have every incentive to liquidate -- especially if the company is likely to burn through its assets, making your shares worthless.
I'd kill for the dual-head setup depicted on that page.
Yeah, the mutation of Broadband from "using a broad frequency band" to "supplies a lot of bandwidth" is irritating. But face it, words change. Especially when they express technical distinctions most people don't know or care about.
This is an extreme case, but this problem is not unusual. Publically-held companies are always jumping through hoops to make their stockholders happy, and more often than not that means doing things that actually work against the long term growth of the company. Or, in this case, the short term growth!
No, this is not a Troll! It seems to me that Perl is as much about expressiveness as it is about creating software.
Sure, there's a lot of crap C++ and Java code that's written by people who don't know what they're doing. That's true for any language. And a powerful language is easier to screw up in, just as it's easier to kill yourself in a Massarati than in a Model T. But that's a problem with the programmer/driver, not the language/car.
That's better!
The price I quoted was from the Wolfram web site. I'm guessing that your school got a hefty discount by buying in bulk. Hmm, maybe I'll go make friends with a student....
If you want a portable scientific computing appliance, your only choice is a Linux-based laptop. (I guess Sparc or PowerPC is preferable to Pentium for this kind of computing, but it probably doesn't matter that much.) Yes, a cheap laptop is pretty heavy, but no worse than some of your heavier textbooks.
If I were in your shoes, I'd really, really want to get a copy of Mathematica. But if I were in your shoes, I couldn't afford it: $900 for an academic license! Sigh.
It sounds to me like your alma mater has some very bad priorities. They're structuring their entire curriculum around demands that they produce engineers that pass some absurd shopping list of qualifications. Undergraduate education is supposed to be about developing your ability to acquire knowledge. If you concentrate solely on currently required technical skills, you end up with a set of qualifications that may put you in demand now, but puts you at a nasty disadvantage when (not if) the technology base evolves, rendering your current skill set obsolete.
I often hear NT people claim that their boxes can be made as reliable and as secure as a box using any other platform, provided you do everything the right way. I actually believe this. The problem is, there's so much more that you have to do right. Every complexity, every hidden feature is an open invitation to Captain Murphy.
Saying that a complex computer system is a reliable as a simple computer system, provided you take all the right steps -- that's like saying raw Nitroglycerine is just as safe as Plastique, provided you don't drop it.
It's also dumb to have any introductory XML material if you're not going to be serious about it. Which gives me an excuse to plug my favorite XML for beginners book, Harold's XML Bible, 2nd edition. Yeah, stupid title (who are you, Moses?), and the CD-ROM is badly put together (you'll need to convert some text files from Mac format!). But the book itself is very good. No assumptions at all about previous knowledge If you know jack about XML, or you understand the basics, but can't figure out how it's used, this is the book you want.
I should have said "pre-emptive multitasking". MacOS 9 and earlier (and also Windows previous to Windows 95) only support a sort of voluntary multitasking, which assumes that all programs are well-behaved and give up the CPU when the don't need it. Since programs are rarely that well-written, it doesn't work very well. Serious OSs (like Unix) consider pre-emptive multitasking a basic feature.
Offtopic! Jeez, the moderators are getting more and more self-righteous.
Except. People have already tried to set up such operations. Well, when I read about it, it was projection analog TVs and VCRs, which might or might not have succeeded financially. But they had no chance to find out -- they were soon confronted with studio lawyers, pointing at the "no public performance" fine print on the tape boxes.
Damn it, IP hoarding is a pain.
(It's nice that Macs have always come standard with fancy options like networking and special interfaces. But it's also why Mac prices are higher and profit margins are lower.)
If the internal politics at Apple are anything like other development orgs, it went like this. The FAT versus HFS decision was made by engineers, not marketeers. The marketeers either didn't understand the impact of this decision or were not consulted. Somewhere along the line, somebody realized that this was excluding most of the potential market, so there had to be a FAT version. But obviously they didn't even start on this until the HFS version was finished. (If the iPod had been less succesful, they never would have started at all. I'm still waiting for my Windows port of the Newton Development Kit.) This might seem dumb in terms of grabbing market share, but working on both versions in tandem would have meant hiring more people -- and development orgs are under a lot of pressure to keep their head counts down.
Yeah, go ahead, mod this one down as "offtopic". That's what it is after all. Unless, of course, you can think of a better way to use your mod points.
But jeez, the software. For years, they've been stuck with an antiquated, non-multitasking OS with a bloated, overdesigned API. Now, among the few little things I found to admire about MacOS were monitor spanning and adherence to the Apple HUIG. But apparently OS X supports neither! That's just sad.
One trick: some Motif programs (notably Netscape) have bad palette manners and grab a lot of colors they don't even need. I would always have at least one copy of gvim running so it always had the palette colors it needed.
Ok, rant time. I'm big Vim fan. Every computer I own or use (well, every working computer) has it installed. The only editor that approaches EMACS's feature set, and nowhere near the great bloatware's klunkiness or unpredictability. But.
I'm rather disappointed that EMACS and Vi (and its clones, of which Vim is the best and mostly widely used) remain the most widely used text editors. Now each has strengths and weaknesses relative to the other, and it's no use rehashing those wars here. What's important is that both these editors are designed around constraints that are about 20 years out of date. Most especially, they were designed to be used by a text-mode terminal (very fancy ones, in the case of EMACS, very limited ones in the case of vi) over a relatively slow connection.
I won't comment on EMACS, since I lack the obsessiveness to be a serious user. But on vi, the big design decision was to build in a lot of modes to get around the limitations of the terminal. This allowed a lot of commands without function keys or complicated keystrokes. It also allowed the user to enter blocks of text without realtime update -- an essential feature on a 300 baud connection!
But, in a GUI environment, modes are a Bad Thing. Yeah yeah, some of you like being able to do complicated edits without moving your hands off the keyboard to grab the mouse. But most people have an easier time if they don't have to keep a state map current in their head.
Now Vim has impressive GUI support (platform-independent GUI support, which is the main reason I use it), but it still has all the modes of vi, plus 3 or 4 of its own. And its macro language is a kludgy extension of the simple-minded command language Bill Joy invented for the original ex/vi editor, itself a minor extension of the ed command language.
Various projects have tried to do all this over using modern design principles, but the EMACS and Vi user communities are just too entrenched. If I were a better programmer, I'd try it myself, maybe using the vim engine as a basis. But probably I'd be the only user!