four hours of creative work is about the limit for a mathematician.
Mathematics is a whole other kettle of yarn. It requires a far greater level of abstract thought than programming. A mathematician working on a problem is exercising a very narrow mental facility to its utmost limits. Programming typically requires less concentration and offers more variety. Maybe it approaches mathematics for really deep algorithms and really subtle bugs, but that's the exception in most programmers' lives.
I'm not dissing programming. But it's well known from anecdotal evidence at least that the all-night hack session, in which a programmer remains intently focused on a problem, is entirely feasible given the right challenge and environment. This is barely imaginable in abstract math. Abstract math is deeper by far than what most people think of as mathematics.
Phil wasn't talking about how to satisfy the programmer who just wants to pay the bills so that he can fulfill himself with family or other interestes. They shouldn't work for Phil. Nor should anyone force them to.
Phil was talking about how to get the best software out of top programmers. The answer is to motivate them, make them comfortable, and encourage them to work intensely. How many hours per week do you think the top 10 Linux developers work? How about OpenBSD or Perl hackers? Do you hear them complaining?
Perhaps it's not possible to motivate programmers to work hard on some tasks. Maybe some software (or the companies that write it) is just too boring, and will inevitably be done by 9-5'ers, who may not get as much done, but are lower risk and easier to manage. Those of you protesting should take consolation: there will always be a place for you. However, you may never realize how fast good software can be written by small teams of top programmers working intensely--and how exhilarating is the experience.
PS. If you really find this hard to believe, find some people working for ArsDigita and ask them how they like it. I have a friend there who describes the experience as "addictive".
The whole point of engineering is to create solutions that are simple, flexible, and effective - and that can be *understood*.
Simplicity is a critical value in software development. But there are two aspects to consider: simplicity of concepts, and simplicity of their manifestation in design and code. For many problems, deep and subtle concepts allow top programmers to address the problem faster. Some problems require them. The implementation is necessarily at least as complex as the concepts. One should always avoid making it more complex. One should also always consider whether simpler concepts would do, as many good programmers tend to overcomplexify (as Greenspun attests). But that is not always the right answer.
Furthermore, it is sometimes a simple matter of volume. In a fast-moving project, lots of ideas and designs are constantly being generated, and these take time to comprehend even if they are simple. A top programmer can pick up many simple ideas faster than an average programmer, just as he can comprehend one deep idea faster.
If you don't think programmers should spend a significant amount of their time understanding others' code, I think it's likely the programers in your team don't have adequate understanding of issues global to the project.
Can you or anyone provide more details? I find it really hard to believe both you and the company get of scot free. This would be an egregious loophole.
First, there are zillions of free template fill-in packages out there. It's hard to believe you can't find one that works with your app server.
Second, it only takes about a day to write your own template fill-in routines in whatever language your app server uses. It can be dead simple--just open a template file (cache it for performance) and replace placeholders ($foo, <var>foo</var>, whatever makes you happy) with supplied values. You have the code compute all the placeholders, then call the template fill-in routine.
HTML hackers work on the templates and don't have to worry their little heads over anything more scary than your friendly placeholders. Coders just need to know what values to compute and what templates to pass them to. Not fancy, but what more do you want?
I would think techies of all people would realize where their perks are coming from--the same budget that pays their salaries. Most of the top choices in the survey could be as easily obtained if perks were replaced by higher salary--with the bonus of greater choice. Most geeks don't trust the government to choose what's good for them--why do they trust employers?
The only perks that make sense are those that can't be replaced by cash. Like things that improve the work environment (I'm sure you can find an alternative if you don't like foosball!).
(Yes, the company may get a better deal on the perks than you would, but I doubt the difference is worth the loss of choice. And yes, an employer has reason to subsidize items that make employees more productive, but I take perks to mean "above what the company should rationally give".)
I don't like office chairs. No doubt due to unforgivable mistakes in my upbringing, I cannot stay in a reasonable position in a chair for more than a short time. I inevitably end up slouched, or with foot/feet on the chair, or at an angle to the keyboard, or leaning on an arm-rest (which really makes my shoulders sore!). This is ok for lounging, but awful for working. I admit I haven't used an expensive chair, but I have sampled a few, and I think they're still incompatible with my fidgeting.
I just bought a Stokke Variable. It's one of the half-kneeling breed, but with runners beneath (like a rocking chair). The kneeling posture makes it easier to sit straight, and the rocking satisfies my need to squirm a bit without putting me in an awkward position. Basically, it allows sitting to be an active endeavor, which strikes me as healthier than finding a single perfect pose (the Stokke web page goes into this at more length, eg "Some Thoughs about Sitting in General).
I must warn that I have only had the Variable for about a week, so I can't be sure I will like it in the long term (my cow-orker does, though). Also, it's nearly impossible to get Stokke furniture in the US. (There's a store in MA where I live and apparantly another in NM; the Stokke site itself has no information on US distributers.)
Yes, despite the fact that the article states that it doesn't run MS Windows yet, and that nearly everyone who runs VMware on Linux uses it to run MS Windows, Plex86 is by an inexplicable mystery a viable alternative to VMware.
probable emerging standard (don't make me laugh - linux is anarchy - BSD is more standard since it is committe based)
IBM seems to think so, according to recent articles ("We think that Linux could do for applications what the Internet did for networking. That is, become the standard of choice for developing applications."). Why do you think all the Unix vendors are working on Linux binary compatibility? Sometimes a standard is just where everyone is, and everyone's going to Linux.
existing high-quality implementation (have you ever looked at linux code? And it changes every two minutes)
So some of it's not pretty, but in the end it works damn well for a lot of purposes. Remember, this is an industry that puts up with Windows NT.
existing widespread hardware support (DVD? Hardware RAID even?....)
Hardware RAID is coming along ok. DVD is a special case. The important points are that Linux supports more hardware than anything but Windows now, and that support for new stuff will almost certainly get better.
non-techies are comfortable with it (please...)
If you thought I meant comfortable using it, I was unclear. I meant comfortable about it being used in their organizations.
Liberal licencing (GPL!!!)
Look, BSD isn't in the picture here. If BSD advocates know what's good for them, they'll ride Linux's coattails. The alternatives to Linux in this context are Windows, Monterey, and other proprietary stuff.
What compelling defense of RedHat 7.0 am I missing here?
You are missing that any large software development effort, if they are honest and have high standards, must admit that they have zillions of "bugs". Most don't make the product unusable or even bad; instead they are things that could be done better, or that some person doesn't like based on taste, or are just notes worth keeping around to think about. (This isn't even counting the many bogus, incomplete, and duplicate bug reports.)
There is in fact good reason that most organizations call it an "issue" database instead of a "bug" database.
The 2000 (or whatever) "bugs" in RedHat's bugzilla is a meaningless number, and by itself is no cause for alarm (by users), shame (by RedHat), or criticism (by sanctimonious know-nothings). Go count the bug's in Debian's database. (Don't bother telling me when you get finished, because you won't.)
I think Bob was trying to say that counting the bugs is a silly response to the availability of RedHat's bug database. A more "enlightened" response is to appreciate the value that the mere existence of a public database gives you.
So all.NET code is supposed to use the common type system? But isn't the differences among type systems one of the main reasons for choosing a particular language for a particular job? This sounds like "use whatever language you want, just be sure to smoosh it into the.NET paradigm".
Anyone who examines Linus's management of the kernel will see that, above all, he optimizes for simplicity and long-term maintainability. The "big iron" features would affect many core parts of the kernel. At that level, the interrelationships are many and subtle. It's hard enough for hacker to get their heads around one model--adding permutations at this level increases the complexity significantly and I doubt Linus would ever accept it.
Basically, I don't think you realize how intimately entwined parts of the kernel are. Even if you put the "big iron" code in separate files, changes elsewhere would break it every minor release.
Hey, cool, I'll do this once I start tracking unstable again. (I maintain machines that are still on slink, and I promised myself that I'd keep my machine on potato until all the others are upgraded!)
the "do-everything" button was an abstraction. you should have realized that.
I did. I also realized that it was the wrong abstraction.:-)
There's a big difference between "give me easy access to all the relevant information" and "figure out what to do". Now, I admit that there were elements of both in my original message. But as far as the package manager is concerned, the first is primary. Because once the ability to get all the information (and the hooks to act on it) is there, people can start figuring out how to make use of it. I think there's plenty of room for improvements that hackers would appreciate before we get into the realm of "the computer is smarter than you" idiot-ware.
your views on what a package management system should be able to do for the user are off the wall
We might disagree about what should be in the package manager proper, but I maintain that the package manager should facilitate some of the potential front-end features I described.
Picking option D gives me a context diff run though the default system pager (normally 'less'). Option Z gives you a shell and you're free to do whatever you want. The new file is in.dpkg-new
And where is the old original config file? You have soooo much more information to work with if you have that. In my opinion, you can't do a proper merge without all three files (mine, older, and yours in diff3 terminology).
On debian-changes, I see that uploads have a priority. Say I want only high-priority upgrades. (For that matter, why don't I see this priority anywhere in the installer or the package? What's the point of dropping useful information?)
Why are you running unstable, if you want to only risk installing critical updates?
I've been following unstable, and my system is happy now, but I just got some important work to do. I don't want to take any chances for the next week, unless they're security upgrades (or dependencies thereof).
If your testers only test random parts of the code, then your testing department is seriosuly lacking. Part of the duties of a good QA department is to create test plans that cover the entire code base.
Mabye in very mature development organizations. But lets face it: the space of inputs is enormous and testing resources are limited. Since tests are basically discrete (to use a rough analogy, a single test covers a measure zero subset of input space), coverage in any rigorous sense is a mirage. Inevitably, entire categories of possible inputs will be missed.
Saying that testers fire "at random" was obviously an exaggeration. They certainly have some notion of what's important to test. But they don't have the sniper's accuracy of a careful developer.
Also, the QA department should be involved right from the very beginning, even before a single line of code is written.
Bah, this has way too much overhead for most projects. Give me a realistic example of an early design mistake that would likely be found by a tester.
Slashdot Mirror
Mathematics is a whole other kettle of yarn. It requires a far greater level of abstract thought than programming. A mathematician working on a problem is exercising a very narrow mental facility to its utmost limits. Programming typically requires less concentration and offers more variety. Maybe it approaches mathematics for really deep algorithms and really subtle bugs, but that's the exception in most programmers' lives.
I'm not dissing programming. But it's well known from anecdotal evidence at least that the all-night hack session, in which a programmer remains intently focused on a problem, is entirely feasible given the right challenge and environment. This is barely imaginable in abstract math. Abstract math is deeper by far than what most people think of as mathematics.
Phil was talking about how to get the best software out of top programmers. The answer is to motivate them, make them comfortable, and encourage them to work intensely. How many hours per week do you think the top 10 Linux developers work? How about OpenBSD or Perl hackers? Do you hear them complaining?
Perhaps it's not possible to motivate programmers to work hard on some tasks. Maybe some software (or the companies that write it) is just too boring, and will inevitably be done by 9-5'ers, who may not get as much done, but are lower risk and easier to manage. Those of you protesting should take consolation: there will always be a place for you. However, you may never realize how fast good software can be written by small teams of top programmers working intensely--and how exhilarating is the experience.
PS. If you really find this hard to believe, find some people working for ArsDigita and ask them how they like it. I have a friend there who describes the experience as "addictive".
Simplicity is a critical value in software development. But there are two aspects to consider: simplicity of concepts, and simplicity of their manifestation in design and code. For many problems, deep and subtle concepts allow top programmers to address the problem faster. Some problems require them. The implementation is necessarily at least as complex as the concepts. One should always avoid making it more complex. One should also always consider whether simpler concepts would do, as many good programmers tend to overcomplexify (as Greenspun attests). But that is not always the right answer.
Furthermore, it is sometimes a simple matter of volume. In a fast-moving project, lots of ideas and designs are constantly being generated, and these take time to comprehend even if they are simple. A top programmer can pick up many simple ideas faster than an average programmer, just as he can comprehend one deep idea faster.
If you don't think programmers should spend a significant amount of their time understanding others' code, I think it's likely the programers in your team don't have adequate understanding of issues global to the project.
I'd say it counts--it sounds to me like you guys have figured out what this stuff is really (or should be) about. Run with it!
Can you or anyone provide more details? I find it really hard to believe both you and the company get of scot free. This would be an egregious loophole.
Second, it only takes about a day to write your own template fill-in routines in whatever language your app server uses. It can be dead simple--just open a template file (cache it for performance) and replace placeholders ($foo, <var>foo</var>, whatever makes you happy) with supplied values. You have the code compute all the placeholders, then call the template fill-in routine.
HTML hackers work on the templates and don't have to worry their little heads over anything more scary than your friendly placeholders. Coders just need to know what values to compute and what templates to pass them to. Not fancy, but what more do you want?
The only perks that make sense are those that can't be replaced by cash. Like things that improve the work environment (I'm sure you can find an alternative if you don't like foosball!).
(Yes, the company may get a better deal on the perks than you would, but I doubt the difference is worth the loss of choice. And yes, an employer has reason to subsidize items that make employees more productive, but I take perks to mean "above what the company should rationally give".)
I just bought a Stokke Variable. It's one of the half-kneeling breed, but with runners beneath (like a rocking chair). The kneeling posture makes it easier to sit straight, and the rocking satisfies my need to squirm a bit without putting me in an awkward position. Basically, it allows sitting to be an active endeavor, which strikes me as healthier than finding a single perfect pose (the Stokke web page goes into this at more length, eg "Some Thoughs about Sitting in General).
I must warn that I have only had the Variable for about a week, so I can't be sure I will like it in the long term (my cow-orker does, though). Also, it's nearly impossible to get Stokke furniture in the US. (There's a store in MA where I live and apparantly another in NM; the Stokke site itself has no information on US distributers.)
Yes, despite the fact that the article states that it doesn't run MS Windows yet, and that nearly everyone who runs VMware on Linux uses it to run MS Windows, Plex86 is by an inexplicable mystery a viable alternative to VMware.
IBM seems to think so, according to recent articles ("We think that Linux could do for applications what the Internet did for networking. That is, become the standard of choice for developing applications."). Why do you think all the Unix vendors are working on Linux binary compatibility? Sometimes a standard is just where everyone is, and everyone's going to Linux.
existing high-quality implementation (have you ever looked at linux code? And it changes every two minutes)
So some of it's not pretty, but in the end it works damn well for a lot of purposes. Remember, this is an industry that puts up with Windows NT.
existing widespread hardware support (DVD? Hardware RAID even? ....)
Hardware RAID is coming along ok. DVD is a special case. The important points are that Linux supports more hardware than anything but Windows now, and that support for new stuff will almost certainly get better.
non-techies are comfortable with it (please ...)
If you thought I meant comfortable using it, I was unclear. I meant comfortable about it being used in their organizations.
Liberal licencing (GPL!!!)
Look, BSD isn't in the picture here. If BSD advocates know what's good for them, they'll ride Linux's coattails. The alternatives to Linux in this context are Windows, Monterey, and other proprietary stuff.
Now which of these does HURD offer?
s/Bear/Egan/
So will I. Thus follows the irrelevance of raw bug counts.
You are missing that any large software development effort, if they are honest and have high standards, must admit that they have zillions of "bugs". Most don't make the product unusable or even bad; instead they are things that could be done better, or that some person doesn't like based on taste, or are just notes worth keeping around to think about. (This isn't even counting the many bogus, incomplete, and duplicate bug reports.) There is in fact good reason that most organizations call it an "issue" database instead of a "bug" database.
The 2000 (or whatever) "bugs" in RedHat's bugzilla is a meaningless number, and by itself is no cause for alarm (by users), shame (by RedHat), or criticism (by sanctimonious know-nothings). Go count the bug's in Debian's database. (Don't bother telling me when you get finished, because you won't.)
I think Bob was trying to say that counting the bugs is a silly response to the availability of RedHat's bug database. A more "enlightened" response is to appreciate the value that the mere existence of a public database gives you.
That's the idea.
That's why you use cron instead of writing a long-running daemon.
This is a reasonable position, but I'm not sure Linus would go for it. It may dilute his focus so that he can't maintain either one well.
So all .NET code is supposed to use the common type system? But isn't the differences among type systems one of the main reasons for choosing a particular language for a particular job? This sounds like "use whatever language you want, just be sure to smoosh it into the .NET paradigm".
Basically, I don't think you realize how intimately entwined parts of the kernel are. Even if you put the "big iron" code in separate files, changes elsewhere would break it every minor release.
Hey, cool, I'll do this once I start tracking unstable again. (I maintain machines that are still on slink, and I promised myself that I'd keep my machine on potato until all the others are upgraded!)
Thanks for the tip.
You're dead-on, and I haven't given a coherent argument for why it should be in rpm. Some other day :-)
I did. I also realized that it was the wrong abstraction. :-)
There's a big difference between "give me easy access to all the relevant information" and "figure out what to do". Now, I admit that there were elements of both in my original message. But as far as the package manager is concerned, the first is primary. Because once the ability to get all the information (and the hooks to act on it) is there, people can start figuring out how to make use of it. I think there's plenty of room for improvements that hackers would appreciate before we get into the realm of "the computer is smarter than you" idiot-ware.
your views on what a package management system should be able to do for the user are off the wall
We might disagree about what should be in the package manager proper, but I maintain that the package manager should facilitate some of the potential front-end features I described.
And where is the old original config file? You have soooo much more information to work with if you have that. In my opinion, you can't do a proper merge without all three files (mine, older, and yours in diff3 terminology).
No, dpkg isn't perfect, but it is really nice.
I agree with that :-)
On debian-changes, I see that uploads have a priority. Say I want only high-priority upgrades. (For that matter, why don't I see this priority anywhere in the installer or the package? What's the point of dropping useful information?)
Why are you running unstable, if you want to only risk installing critical updates?
I've been following unstable, and my system is happy now, but I just got some important work to do. I don't want to take any chances for the next week, unless they're security upgrades (or dependencies thereof).
Mabye in very mature development organizations. But lets face it: the space of inputs is enormous and testing resources are limited. Since tests are basically discrete (to use a rough analogy, a single test covers a measure zero subset of input space), coverage in any rigorous sense is a mirage. Inevitably, entire categories of possible inputs will be missed.
Saying that testers fire "at random" was obviously an exaggeration. They certainly have some notion of what's important to test. But they don't have the sniper's accuracy of a careful developer.
Also, the QA department should be involved right from the very beginning, even before a single line of code is written.
Bah, this has way too much overhead for most projects. Give me a realistic example of an early design mistake that would likely be found by a tester.