Many years ago, using flow charts was a requirement in many software jobs. (For those of you less than 40, a flow chart was a stylized picture of small-scale flow control: little diamonds for "if", square blocks for computations, other funny shapes for IO, etc. All connected by arrows.) Flow charts were pretty useless, but you had to produce them, so we built tools that parsed Fortran77 and generated nice flow charts. No one actually used them, but they looked nice hanging outside your office, especially if you had access to a color flatbed plotter.
Now, I know that Rational can generate UML from code. Which makes me wonder how often UML is actually used for design and how often it's generated after the fact to make pointy-headed managers happy.
If this actually works for you, you are very lucky.
First, detailed specs aren't available in most cases. Clients want a solution, and they don't want to be bothered with gathering requirments, reviewing proposals,etc. They believe that's your job, not theirs. Even if you get a buy-off on a spec, it will be done without much thought and will change once they see your solution.
Second, the estimates of the smaller tasks will be wrong. You will have to rely on people who are intimately familiar with the code to make the estimates, and some of them aren't good at estimation. If you try to do it all yourself it will take you years to even comprehend the existing source-code base.
Third, sickness, turnover, etc., will cause unexpected delays in many cases.
Fourth, unexpected problems---a bug in a vendor tool that has to be worked around, for example--- will cause further delays.
I've noticed a very good trend in recent Supreme Court decisions: they have been very strict in their interpretation of laws passed by congress.
All courts in recent times have largely ignored the actual wording of the Constitution and simply made stuff up. Personally, I think this is bad, but the Constitution is vague or silent in many areas, and it's very hard to fix because the amendment process is so difficult. So I can sort of see why it happens.
However, in the last few decades, the Supreme Court has routinely done the same with laws passed by congress. There is really very little excuse for this; congress can and does change laws all the time. However, in the last few years, this has largely stopped. The Supreme Court now seems to be interpreting laws passed by congress as written. A very good thing if you believe in representative democracy and the rule of law. It will force congress to write clear laws and explicitly change them when necessary.
Re:There is plenty of cost justification.
on
The Eyes Have It
·
· Score: 1
I think you're missing the point entirely. The suicide bombings brought home two facts. First, that there is a fairly large cadre of people who are willing to die if they can take a few thousand Americans with them. Second, that they are inventive about how to kill. Unless these folks are dealt with ("dealt with" being a polite euphemism for "killed or imprisoned") they will be setting off atomic weapons or releasing nerve toxins in large cities before the end of the decade.
What has people worried is not so much what the current crop of terrorists have already done, although that is bad enough. It's their obvious willingness to kill as many Americans as they can, regardless of the consequences to themselves or their cause.
That's a strange thing to say. Christ himself, and all his early followers, were certainly religious zealots. In fact, if they were around today they would certainly be considered a cult. They probably were when they were alive. So how is being a religious zealot anti-christian?
You have to use/bin/sh and test on all platforms. There isn't anything else you can rely rely on finding on all distributions. Yes, there are probably slight differences between what purports to be/bin/sh on various platforms, but I can't imagine it will be very hard to write a script that runs fine under all of them---just avoid the dark corners.
Suggestions for other shells (ash or whatever) that might be better are pointless for your purposes because you can't rely on them being there.
You will get a lot of answers to this, but all of them will be rationalizations. The real reason the HURD exists is inertia. When the project started, it was really pretty interesting and to some extent ground-breaking. They were attempting to take cutting-edge research and build a real system. Unfortunately, after languishing for as long as it has, and developing as little mind-share as it has, the HURD is just not very interesting anymore. The cutting-edge research has moved on. In fact, it's pointless from a practical point of view and uninteresting from a research point of view.
Redhat does make Gnome the default, as opposed to KDE. But what that means is that during installation a screen comes up, with a bunch of choices. Gnome is initially checked. Changing the default is as simple as checking KDE. I hardly think this belongs in the top 10 reasons to choose a distribution.
Jobs are nothing like school. Finish your degree, get a job, and try a few companies. (They vary wildly.) If you still hate it, find a company that lets you change focus. There are plenty.
Perl going the way of C++
on
Perl6 for Mortals
·
· Score: 3, Interesting
Perl6 suffers from the same problem that C++ has had over the years. In both cases, people tend to look at lots of tiny examples and come up with cool ideas to make things "nicer" for that example. The problem with this approach is that there are a very, very large number of cool ideas that make one situation or another "nicer." So lots of them get stirred into the mix. Adding two or three hundred cool new features to each version makes for a very complicated language after a few versions, especially when they interact and get used in unexpected ways. This is exactly the problem that C++ has had over the years, and the reason that other languages (Java, etc.) have gained in market share.
So, here's what will happen. Perl gurus will follow along. After all, Perl6 isn't that much more complicated that Perl5. Incrementally speaking, it's not too bad. But more and more newcomers will go with something a lot simpler: Python, Ruby, or the Next Big Thing. Why? First, if you look at Perl6 from ground zero, it is extremely daunting. The Perl6 Camel book is going to come in three volumes if it tries to maintain the same sort of coverage. Second, the design of a lot of Perl6 will be inexplicable except to people who know Perl5 and understand the history of the language. Finally, new programmers, especially good ones, want to really understand their tools from the inside out. They don't take kindly to the idea that they should learn 10% of the language, start using it, and catch up with the experts in a few years. So, over time, interest in Perl will dwindle. The old timers will retire or go into management, the newbies will be using something a lot simpler and more elegant. By the time Perl8 or Perl9 roll out, no one will care.
This is silly. There are Unix/Linux systems that were last rebooted long before Windows XP came into existence, even in Beta. How could you possibly know that XP is that stable? Granted, it's a lot more stable than it's illustrious predecessors. Which counts as damning with faint praise.
There is a huge problem with your solution. If I, completely on my own, want to create a commercial favoring one candidate and pay to put it on cable television or in a newspaper, am I allowed to do so? If I am, then your campaign finance law is completely toothless. Virtually all campaign spending will be done by billionaires, corporations, unions, etc. If I am not, then my right to free speech has been removed. The Supreme Court has so ruled, and they are entirely correct.
Or are you arguing that the Federal government should regulate the content of private media?
We already rely on disclosure, so if the real source of money is easy to hide then current and future campaign laws are pointless.
In fact, with hundreds of thousands of very small donors, it probably is pretty difficult to get to the bottom of it. (In fact, we saw the way Clinton arranged for very large donations from foreign contributers to be split between hundreds of U.S. citizens, many of whom didn't know anything about it.) On the other hand, if a candidate had 150 huge donors, the press would be all over them like flies. Every single one would be scrutinized. And, too, his opponent would have a team of investigators checking them out, putting every one in the worst possible light, and using them as fodder for campaign ads.
Mr. Love's first sentence of his first answer is flat-out incorrect, which makes me wonder about the rest of his answers.
Ruling that campaign spending is protected free speech is not what forced politicians to become full-time fundraisers. It was the stupidity of allowing limits on campaign contributions that caused the problems. Before limits were in effect, politicians had a range of techniques for funding campaigns. Some raised money in small increments. Others got big contributions from organized labor. Others got big contributions from corportations. Others got big contributions from a few rich folk.
We ought to remove all restrictions on donations and simply insist on full and immediate disclosure. Then politicians could get plenty of money without attending 300 fund-raisers per year, and voters could see exactly where it's coming from.
Yeah, copper is another case in point. Nice idea, but of course we'll never see it. Oh, wait...
Re:Beauty for beauty's sake makes crappy software
on
Software Aesthetics
·
· Score: 1
You missed a phrase. Software has to
1. Meet user requirements now and in the future.
Which means you had better write nice and pretty code, unless you know it will never have to be fixed or enhanced. "Getting something working" is about 10% of most software jobs. The other 90% is keeping it working, which depends critically on beauty, because ugly code is very expensive to maintain.
What, exactly, does the lack of unsigned prevent you from doing? Note that you can specify numbers in hex (0xFFFFEEEE). You can shift them without sign extension (a >>> 3). Bitwise & and | work. What is missing?
I disagree. The individuals primarily responsible are the members of the House of Representatives and the Senate who voted for the DMCA, and especially President Clinton, who signed it into law. Adobe is a bit player in this and the FBI is just trying to enforce a stupid law.
How do you plan to manage the transistion from GPL v2 to v3? On large projects with hundreds of contributers (e.g., Linux, gcc, emacs, Gnome, KDE) it seems next to impossible to get approval from all contributers. Without approval, is is possible to re-license? If it is not possible to re-license, will it be necessary to reimplement large portions of the GNU codebase before v3 makes any difference?
Even if you could multitask perfectly, without any context-switching overhead, it wouldn't be the best way to operate most of the time. Most jobs are demand-driven: a bunch of people are asking for tasks to be completed. Multitasking is useful for giving the illusion you are making progress on a number of tasks simultaneously. But almost any other schedule is better for actually finishing tasks sooner.
Suppose you have ten tasks that will each take two days. If you multitask perfectly, they will all be done at the same time: in four weeks. Ten people will be pissed because you just took a month to finish a two-day job for them. If you instead finish one at a time, then nine of your customers will get their tasks done sooner. Some of them a lot sooner. Even the last task you finish won't be done any later than if you had multitasked. The advantages of unitasking are even greater if the jobs aren't the same size. By working on shorter jobs first, you minimize the average wait time while not increasing the maximum wait time at all.
It doesn't make economic sense to ask if there is a "shortage" of something in a free market. If you think you see a shortage, it's because you aren't paying enough.
If you want 10 programmers, and are willing to pay $50K/year/programmer, there is a shortage. If you are willing to pay $200K/year/programmer, there is a surplus.
I've had interviews like this, and in both cases got job offers. In neither case did I take the job, basically just because I also got better offers. However, I've thought about what I'd do if I again encountered that sort of situation.
I would answer your questions politely. I'm smart, I'm good at thinking on my feet, and I have a lot of math under my belt, so I'd do pretty well. Then I would emphatically turn down the job offer. My answer to your boss would be that life is too short to work with a immature jerk like you.
Slashdot Mirror
Many years ago, using flow charts was a requirement in many software jobs. (For those of you less than 40, a flow chart was a stylized picture of small-scale flow control: little diamonds for "if", square blocks for computations, other funny shapes for IO, etc. All connected by arrows.) Flow charts were pretty useless, but you had to produce them, so we built tools that parsed Fortran77 and generated nice flow charts. No one actually used them, but they looked nice hanging outside your office, especially if you had access to a color flatbed plotter.
Now, I know that Rational can generate UML from code. Which makes me wonder how often UML is actually used for design and how often it's generated after the fact to make pointy-headed managers happy.
If this actually works for you, you are very lucky.
First, detailed specs aren't available in most cases. Clients want a solution, and they don't want to be bothered with gathering requirments, reviewing proposals,etc. They believe that's your job, not theirs. Even if you get a buy-off on a spec, it will be done without much thought and will change once they see your solution.
Second, the estimates of the smaller tasks will be wrong. You will have to rely on people who are intimately familiar with the code to make the estimates, and some of them aren't good at estimation. If you try to do it all yourself it will take you years to even comprehend the existing source-code base.
Third, sickness, turnover, etc., will cause unexpected delays in many cases.
Fourth, unexpected problems---a bug in a vendor tool that has to be worked around, for example--- will cause further delays.
I've noticed a very good trend in recent Supreme Court decisions: they have been very strict in their interpretation of laws passed by congress.
All courts in recent times have largely ignored the actual wording of the Constitution and simply made stuff up. Personally, I think this is bad, but the Constitution is vague or silent in many areas, and it's very hard to fix because the amendment process is so difficult. So I can sort of see why it happens.
However, in the last few decades, the Supreme Court has routinely done the same with laws passed by congress. There is really very little excuse for this; congress can and does change laws all the time. However, in the last few years, this has largely stopped. The Supreme Court now seems to be interpreting laws passed by congress as written. A very good thing if you believe in representative democracy and the rule of law. It will force congress to write clear laws and explicitly change them when necessary.
I think you're missing the point entirely. The suicide bombings brought home two facts. First, that there is a fairly large cadre of people who are willing to die if they can take a few thousand Americans with them. Second, that they are inventive about how to kill. Unless these folks are dealt with ("dealt with" being a polite euphemism for "killed or imprisoned") they will be setting off atomic weapons or releasing nerve toxins in large cities before the end of the decade.
What has people worried is not so much what the current crop of terrorists have already done, although that is bad enough. It's their obvious willingness to kill as many Americans as they can, regardless of the consequences to themselves or their cause.
That's a strange thing to say. Christ himself, and all his early followers, were certainly religious zealots. In fact, if they were around today they would certainly be considered a cult. They probably were when they were alive. So how is being a religious zealot anti-christian?
Destroyed the World Trade Center?
I'm curious. What, exactly, is the Linux packaging system?
-mike
You have to use /bin/sh and test on all platforms. There isn't anything else you can rely rely on finding on all distributions. Yes, there are probably slight differences between what purports to be /bin/sh on various platforms, but I can't imagine it will be very hard to write a script that runs fine under all of them---just avoid the dark corners.
Suggestions for other shells (ash or whatever) that might be better are pointless for your purposes because you can't rely on them being there.
You will get a lot of answers to this, but all of them will be rationalizations. The real reason the HURD exists is inertia. When the project started, it was really pretty interesting and to some extent ground-breaking. They were attempting to take cutting-edge research and build a real system. Unfortunately, after languishing for as long as it has, and developing as little mind-share as it has, the HURD is just not very interesting anymore. The cutting-edge research has moved on. In fact, it's pointless from a practical point of view and uninteresting from a research point of view.
I basically agree, but a minor quibble:
Redhat does make Gnome the default, as opposed to KDE. But what that means is that during installation a screen comes up, with a bunch of choices. Gnome is initially checked. Changing the default is as simple as checking KDE. I hardly think this belongs in the top 10 reasons to choose a distribution.
Jobs are nothing like school. Finish your degree, get a job, and try a few companies. (They vary wildly.) If you still hate it, find a company that lets you change focus. There are plenty.
Perl6 suffers from the same problem that C++ has had over the years. In both cases, people tend to look at lots of tiny examples and come up with cool ideas to make things "nicer" for that example. The problem with this approach is that there are a very, very large number of cool ideas that make one situation or another "nicer." So lots of them get stirred into the mix. Adding two or three hundred cool new features to each version makes for a very complicated language after a few versions, especially when they interact and get used in unexpected ways. This is exactly the problem that C++ has had over the years, and the reason that other languages (Java, etc.) have gained in market share.
So, here's what will happen. Perl gurus will follow along. After all, Perl6 isn't that much more complicated that Perl5. Incrementally speaking, it's not too bad. But more and more newcomers will go with something a lot simpler: Python, Ruby, or the Next Big Thing. Why? First, if you look at Perl6 from ground zero, it is extremely daunting. The Perl6 Camel book is going to come in three volumes if it tries to maintain the same sort of coverage. Second, the design of a lot of Perl6 will be inexplicable except to people who know Perl5 and understand the history of the language. Finally, new programmers, especially good ones, want to really understand their tools from the inside out. They don't take kindly to the idea that they should learn 10% of the language, start using it, and catch up with the experts in a few years. So, over time, interest in Perl will dwindle. The old timers will retire or go into management, the newbies will be using something a lot simpler and more elegant. By the time Perl8 or Perl9 roll out, no one will care.
This is silly. There are Unix/Linux systems that were last rebooted long before Windows XP came into existence, even in Beta. How could you possibly know that XP is that stable? Granted, it's a lot more stable than it's illustrious predecessors. Which counts as damning with faint praise.
Can someone mod this down? It's overrated.
There is a huge problem with your solution. If I, completely on my own, want to create a commercial favoring one candidate and pay to put it on cable television or in a newspaper, am I allowed to do so? If I am, then your campaign finance law is completely toothless. Virtually all campaign spending will be done by billionaires, corporations, unions, etc. If I am not, then my right to free speech has been removed. The Supreme Court has so ruled, and they are entirely correct.
Or are you arguing that the Federal government should regulate the content of private media?
We already rely on disclosure, so if the real source of money is easy to hide then current and future campaign laws are pointless.
In fact, with hundreds of thousands of very small donors, it probably is pretty difficult to get to the bottom of it. (In fact, we saw the way Clinton arranged for very large donations from foreign contributers to be split between hundreds of U.S. citizens, many of whom didn't know anything about it.) On the other hand, if a candidate had 150 huge donors, the press would be all over them like flies. Every single one would be scrutinized. And, too, his opponent would have a team of investigators checking them out, putting every one in the worst possible light, and using them as fodder for campaign ads.
Mr. Love's first sentence of his first answer is flat-out incorrect, which makes me wonder about the rest of his answers.
Ruling that campaign spending is protected free speech is not what forced politicians to become full-time fundraisers. It was the stupidity of allowing limits on campaign contributions that caused the problems. Before limits were in effect, politicians had a range of techniques for funding campaigns. Some raised money in small increments. Others got big contributions from organized labor. Others got big contributions from corportations. Others got big contributions from a few rich folk.
We ought to remove all restrictions on donations and simply insist on full and immediate disclosure. Then politicians could get plenty of money without attending 300 fund-raisers per year, and voters could see exactly where it's coming from.
Yeah, copper is another case in point. Nice idea, but of course we'll never see it. Oh, wait...
You missed a phrase. Software has to
1. Meet user requirements now and in the future.
Which means you had better write nice and pretty code, unless you know it will never have to be fixed or enhanced. "Getting something working" is about 10% of most software jobs. The other 90% is keeping it working, which depends critically on beauty, because ugly code is very expensive to maintain.
What, exactly, does the lack of unsigned prevent you from doing? Note that you can specify numbers in hex (0xFFFFEEEE). You can shift them without sign extension (a >>> 3). Bitwise & and | work. What is missing?
I disagree. The individuals primarily responsible are the members of the House of Representatives and the Senate who voted for the DMCA, and especially President Clinton, who signed it into law. Adobe is a bit player in this and the FBI is just trying to enforce a stupid law.
How do you plan to manage the transistion from GPL v2 to v3? On large projects with hundreds of contributers (e.g., Linux, gcc, emacs, Gnome, KDE) it seems next to impossible to get approval from all contributers. Without approval, is is possible to re-license? If it is not possible to re-license, will it be necessary to reimplement large portions of the GNU codebase before v3 makes any difference?
Even if you could multitask perfectly, without any context-switching overhead, it wouldn't be the best way to operate most of the time. Most jobs are demand-driven: a bunch of people are asking for tasks to be completed. Multitasking is useful for giving the illusion you are making progress on a number of tasks simultaneously. But almost any other schedule is better for actually finishing tasks sooner.
Suppose you have ten tasks that will each take two days. If you multitask perfectly, they will all be done at the same time: in four weeks. Ten people will be pissed because you just took a month to finish a two-day job for them. If you instead finish one at a time, then nine of your customers will get their tasks done sooner. Some of them a lot sooner. Even the last task you finish won't be done any later than if you had multitasked. The advantages of unitasking are even greater if the jobs aren't the same size. By working on shorter jobs first, you minimize the average wait time while not increasing the maximum wait time at all.
It doesn't make economic sense to ask if there is a "shortage" of something in a free market. If you think you see a shortage, it's because you aren't paying enough.
If you want 10 programmers, and are willing to pay $50K/year/programmer, there is a shortage. If you are willing to pay $200K/year/programmer, there is a surplus.
I've had interviews like this, and in both cases got job offers. In neither case did I take the job, basically just because I also got better offers. However, I've thought about what I'd do if I again encountered that sort of situation.
I would answer your questions politely. I'm smart, I'm good at thinking on my feet, and I have a lot of math under my belt, so I'd do pretty well. Then I would emphatically turn down the job offer. My answer to your boss would be that life is too short to work with a immature jerk like you.