Until corporate accounting evolves to properly label customer service as a means for profit rather than expense, this will always be a problem.
On rare occasion, I've had a company blow me away with tremendous customer service, and that almost guarantees I'll be a repeat customer. At least, I'll think of that company, again. Customer service really should be viewed as advertising, where it is the company's chance to define their image to customers. Even though the total number of people exposed are few, the power of word-of-mouth should not be underestimated.
The last couple of times I've bought from lesser-known retailers listed at Pricewatch, I'll do a google search for "company-xyz sucks OR 'poor service'", for example. The results can be suprising and help me determine whether a vendor is an acceptable risk.
Many of us know what a bitch it is to develop a code and feature intensive site that works correctly for all browsers.
No, only people who jump on every bandwagon since HTML 3.2 know this. In reality, cross-platform websites are easier than browser-specific websites through cutting back on the buzzword payload. For example, small amounts of JavaScript can be used and easily tested. Websites that use JavaScript until the "programmer" is foaming coffee at the mouth should be taken out and thrown in the lake (if that were possible for a website).
Web developers that complain about cross-browser support really are not doing their job properly, nor should they be considered professionals. The reason I say this is that the intentions of the WWW are universality, equality, and ease of use. A website that won't post my form data because of a JavaScript bug doesn't meet these criteria. The fact that every corporation who got their dirty hands on the WWW has tried to corrupt it is not an excuse, either.
(The terms I am speaking in make the assumption that online voting is the only option. This is not yet the case, but taking technological trends into consideration, traditional voting means may eventually fade into obscurity. If we continue on this road of platfor dependence, we may create problems in the big picture.)
A more likely scenario will be the same traditional polling places, but with Windows terminals available for the public. I'd love to see if the system uses cookies or the disk-based browser cache (hey, Betty Lou voted for Bush!)
Please don't tell me that they are going to try to do this with some stupid, insecure ActiveX control, please, please don't tell me that.
Given that they will only pay for three 22-year-old graduates from Microsoft University to build the system, ActiveX will be only the beginning...(this is how gov't contracting seems to work, unfortunately)
To get it to work on any other platform, though, would require supporting a completely different browser.
So much for the World-Wide Web, then. Why do companies have to take a perfectly decent thing and molest it until it is worthless to society?
I know this isn't what you meant, but there's another good point here: although 80% or more of personal computers run Windows, the percentage of Mac or Linux or BSD users who would like to try online voting is probably higher than the percentage of Windows users who would like to try it.
This is probably true. In a way, requiring Windows for voting is analogous to requiring everyone drive a particular model of car to the voting booth. Anyone not driving a Chevy should get turned away.
Web browsers use the Internet and cars use the roads, so I think only people using Windows and driving Chevys should be allowed to vote.
Security through obsurity is worthless - you can always assume that the bad guys will always find the hole in the system...
For something as significant as voting, you can be assured the bad guys will find the hole in the system and exploit it. I wouldn't be suprised if, for every politician supporting e-voting, there would be another politician with organized crime tie-ins supporting e-vote fraud.
The whole key infrastructure for this should be FIPS-140 compliant for hardware-based key modules, and require the coordinated actions of two or more actors in managing/engaging keys. There should be strict operational guidelines for the separation of roles in the management, deployment and retreival of these devices, and a separate role with an auditory function. The Auditory role needs a key that can reveal and validate any information on the system, yet create or modify nothing.
Hmmm...er, uh...how 'bout we use paper ballots? We can even make them from recycled paper and soy-based ink, so tree-huggers are happy, too!
Seriously, when to do something properly with high-tech gizmos costs ten times more than to do it properly with multiple multi-party volunteers at polling places and paper and pencil with an optical scanner or two, then we should consider not using the new gizmos.
It sounds like high-tech voting could be a market, where doing things the old-fashioned way might be the only way. In 100 years, where we have to worry about absentee ballots from Mars, then we can reconsider (the USPS can only guarantee delivery in 190 to 265 days or whatever from Mars, unfortunately, and warp-speed FedEx costs $185,000 per envelope).
On Linux at any rate, virtually an program that uses glade, or loads data files/artwork from an external file, will have paths hard coded into it by the C preprocessor at build time. Removing these hardcodings is a royal pain in the ass.
I've seen this, too, and along with hard-coded absolute paths throughout GNOME files and library.la files, it makes the Windows registry look pleasant by comparison.
I swear that somewhere along the line, open source took a really big step backwards with resepct to libraries and software configuration. There is simply no excuse for so many files to have absolute paths stuck into them (my GNOME 1.4 installation is absolutely a disgrace in this regard). If I had a nickle for each time LD_LIBRARY_PATH was completely ignored in favor of some assinine config file somewhere....
It's not news that to be highly productive whether in literature or aerospace engineering, people need to forego the traditional family life. People who claim to be highly productive in their career while raising a family are really falling short on one or both without realizing it.
I would bet that nearly everyone who is a really big-time contributor to open source, for example, is single and lives by themselves. This is not meant to paint them in an anti-social light, but simply says that they had to make choices to let them do what they enjoy doing most.
You clearly are not a serious programmer and I do not find you competent to have an opinion...
I'm glad you are such a good judge of character.
I actually don't disagree with what you wrote about your experiences as an uber-elite programmer, because that's the reality of working with a large corporate bureaucratic mess of software that was created over years of short-sighted decision-making. My original argument was simply against the kludges being presented in the open-source world as suitable build tools, when they create as many problems as they solve and make Open Source look no better than Windows (the worst kludge of them all). It doesn't take a programmer to see that progress is not being served either by these tools nor by stubbornness that clings onto what should be embarrasing historical baggage.
Re:It's great to see some metaprogramming related.
on
Latest Proposals for C++0x
·
· Score: 2, Insightful
No wonder so many people propose using C rather than C++.
One reason C is so popular today is that it reached a critical threshold in abstraction: it isn't assembly code. C can be learned very quickly, and, given that prior programmers weren't too supidly clever, C-based programs can be easy to learn. I say "stupidly clever" because some people really do try to shoehorn functions into structures (oooo...I make C object-like) or use the preprocessor as if they have to, because it's there.
C, used as intended (structures and functions that use structures), is actually quite refreshing to program in. You know, even Motif (a C library) isn't all that bad, as long as it is used directly without resorting to compulsive-big-clever-framework-because-I'm so-smart-syndrome.
If you haven't caught on, I don't care for programmers who are so caught up in their genius that they invent these beasts of programs just to make them feel like they are architecting a space station or something. Usually, these are people just out of college, or "experienced" folk too stubborn to see their outside of their fantasy micro-universe. People need to realize that other people have to work with that code, too!
Perhaps they are referring to the weight of the new spec document (i.e., this thing weighs more than livestock, now).
In college, a professor provided a very concise argument for why we were learning Scheme instead of C++. All he did was hold up the C++ spec (several inches thick, duplex) and, then, hold up the Scheme spec (a pamphlet, by comparison).
And, I do remember Scheme being very easy to learn. I also remember a later class project, where a one-page Scheme-based compiler for some sort of combinatoric expression language took thousands of lines of C++ code to re-implement.
It's too bad there are so many cultural stigmas against Lisp and Scheme (picture freshly hatched contractor-babies saying "Ewwww...Lisp? XML is a much better scripting programmatical language" and trying really hard not to punch them).
Any number of firms (SCO, Sun etc.) haven't managed to achieve a small fraction of the success which Linux has done - on the Intel platform.
Thanks for qualifying that at the end. It doesn't have to be Sun, but it is very very important that non-Intel options remain and remain strong. Even if the alternatives consolodate or drop out, as many people predict, there absolutely has to remain alternatives to x86 and Intel. People that disagree with this should stop lying about why they love their country of choice and free-market economics and move to an island somewhere.
If Sun does indeed pick up stakes in SCO, they'd be hated more than Microsoft - if ever that would be possible.
Not necessarily. What matters most is what Sun does with their stake. Sun does good stuff, sometimes (OpenOffice.org, GNOME support, SPARC standards, Java, etc. etc.)
Please don't confuse philosophy with religion. Branded development processes are religions, where dogma replaces understanding. With understanding, religion becomes irrelevant.
A yugo that runs is better than walking to work in the rain...er, perhaps I need a better analogy.
Anyway, my point is that XP seems to be more of an academic effort--an experiment--that gets press and starts a bandwagon rolling. Then people blindly attempt to jump on the bandwagon, but most miss and land in the mud.
What is better than no process is the team recognizing that basic things need to be done to be successful. A version control system is a start, but someone on the team really needs to know how to use it. A non-verbal communication method is needed, even just a mailing list, so that every nifty idea isn't lost the next day. People need to respect that no one person is the "driver" of the project, unless there is a designated architect (who should have oodles of experience), and that the typical programmer egos need to be set aside. Simplicity should be favored over buzzword-completeness. Flash-in-the-pan IDEs and development tools should be avoided. A mix of developer ages is critical (two college grads, two mid-career, one or two seniors, etc.). Older developers should mentor younger ones. Etc.
The fact that job descriptions are changing every three years helps nothing in developing mature teams. There was also a very insightful comment a few days ago that profit-interests for contracting also force hiring all-junior teams (I found this terribly discouraging). So, it seems that getting a good process rolling is truly an uphill battle. The software industry still has a very long way to go.
No, it's just the requirements are being defined by girls choosing an outfit for the prom.
I believe it is a fact that humans are roughly the same as they were 10, even 20, years ago! Why is it that we can't come up with a plan and stick with it?
What you need is a methodology which emphasizes development in stages.
My problem with branded methodologies, is that by the time the team is up to speed on the method, the software was due two weeks before. What there really needs to be is a cultural evolution, where people default to simply thinking before acting. A Professional Engineer that starts building a dog house in a manner like Homer Simpson would be laughed out of town. Why is it that no one is laughing at the software "engineers", who, essentially, are no better or smarter than our thick-skulled friend, Homer?
Oh, come now, poor people should be allowed to have their own version of the simpsons.
After WWE and Real TV, is there really a need for more shows????
I just thought of a great idea: Let's replace Fox News with a 24/7 slide show of kittens sleeping and playing. There would be no reduction in content, but the entertainment value skyrockets.
Clearing major changes with your cowworkers is generally a good thing.
This is 110% true. A group of people who don't communicate is not a team. I've seen what kind of software is built when the team decomposes into people to don't talk to eachother. It is crap.
Worse, are people who chase new buzzwords independently. That team is a non-starter, no matter how much money and PHB speak makes it seem otherwise.
A build system for software must reflect the complexities what it is attempting to build.
Compiling a program and linking it into executables, libraries, jar files, etc. simply isn't that hard to do. A programmer that doesn't understand how to do it has some learning to do. Tools that claim to make the learning unnecessary are misleading--what does the programmer do those tools break and leave them stranded?
Ever tried to compile XFree86 by hand from source?...it's a complicated set of programs with a complicated build order and no matter how hard you try, it would take a full-fledged AI to make it "easy".
There would certainly be many makefiles, but they don't have to be complex. Just the bare minimum rules and environment variables should do. A separate file containing all volatile variables make customizing the build for platforms not difficult. Build systems do not need to be clever nor convoluted. All they need to do is compile the program properly and consistently.
Make can be improved on, it's a decades old design with multiple layers of hacks jostling each other. A new, clean design can at least simplify away the parts of the build process that involve "fighting with make".
Make can certainly be improved, but a new clean design has yet to be presented. Build systems that depend on Java or Python are not clean, because they introduce unneeded and unwanted dependencies into non-Java and non-Python programs, and they make for a build system that can be more complex than the program being built.
Proof by counterexample: autoconf exists, therefore it is clearly necessary, because nobody would trouble to build it if it didn't address a problem.
I'm not exactly sure what the original problem was that motivated autoconf, but autoconf and libtool cause me many many many problems on non-Linux platforms. I'd much rather have a single configuration file that tells gcc and ld where all the needed libraries are. All the tricks and things built into the 15000 (yes, fifteen thousand) lines of shell script that are libtool and configure simply break builds. Often.
given its vast popularity in the open source meritocracy I'd say the onus is on you to show that it truly causes more problems then it solves
The reason it's popular is that they are GNU, and people lap it up. Searches on newsgroup archives, especially for BSD systems, indicate that I am not alone in critizing these tools.
every project that uses it is a vote against that statement
And every project that won't build on Solaris because of libtool is a vote for it.
Odds are every single line you see during configure, with the possible exception of some really standard ones that seem to be a standard part of the package ("CC works?"), is used somewhere in the program
Perhaps the fault is in the overly-complex program? It seems the programmers write what they please and, then, invent these kludges of tools to deal with those programs. It is completely backwards. If a program is requiring tons of smoke and mirrors and special allowances and rules and exceptions, then the program is due for an overhaul.
The good thing about doing ant conf files in XML, si if they change the format, you can use xsl to transform ALL of your xml to a new format.
Layers upon layers of complexity. XML, XSL, Java, Ant Schemas...all for compiling a program. My sig is appropriate, here, too. A build system for software should be easy, intuitive, transparent, etc. etc. There has yet to be a replacement for make that has these attributes (makes tab syntax really isn't that big of a deal, either, even though that's what most people latch onto when complaining about it).
Small shell scripts and makefiles. Is more really necessary to call cc and ld or javac or whatever for each file in a directory tree? The differences among platforms can't be so dire as to require gigantic build automation tools, which introduce more problems than they solve!
Well, I haven't actually looked at scons, but in Make, there is only built-in support for a limited amount of languages.
Adding implicit rules in make is not difficult. It's in the man page (even Solaris' crappy man page for make describes it well enough, and the system default rules file has lots of examples).
Well, the fact that it isn't based on Java or XML gives it a good head start:-)
Slashdot Mirror
Until corporate accounting evolves to properly label customer service as a means for profit rather than expense, this will always be a problem.
On rare occasion, I've had a company blow me away with tremendous customer service, and that almost guarantees I'll be a repeat customer. At least, I'll think of that company, again. Customer service really should be viewed as advertising, where it is the company's chance to define their image to customers. Even though the total number of people exposed are few, the power of word-of-mouth should not be underestimated.
The last couple of times I've bought from lesser-known retailers listed at Pricewatch, I'll do a google search for "company-xyz sucks OR 'poor service'", for example. The results can be suprising and help me determine whether a vendor is an acceptable risk.
Many of us know what a bitch it is to develop a code and feature intensive site that works correctly for all browsers.
No, only people who jump on every bandwagon since HTML 3.2 know this. In reality, cross-platform websites are easier than browser-specific websites through cutting back on the buzzword payload. For example, small amounts of JavaScript can be used and easily tested. Websites that use JavaScript until the "programmer" is foaming coffee at the mouth should be taken out and thrown in the lake (if that were possible for a website).
Web developers that complain about cross-browser support really are not doing their job properly, nor should they be considered professionals. The reason I say this is that the intentions of the WWW are universality, equality, and ease of use. A website that won't post my form data because of a JavaScript bug doesn't meet these criteria. The fact that every corporation who got their dirty hands on the WWW has tried to corrupt it is not an excuse, either.
(The terms I am speaking in make the assumption that online voting is the only option. This is not yet the case, but taking technological trends into consideration, traditional voting means may eventually fade into obscurity. If we continue on this road of platfor dependence, we may create problems in the big picture.)
A more likely scenario will be the same traditional polling places, but with Windows terminals available for the public. I'd love to see if the system uses cookies or the disk-based browser cache (hey, Betty Lou voted for Bush!)
Please don't tell me that they are going to try to do this with some stupid, insecure ActiveX control, please, please don't tell me that.
Given that they will only pay for three 22-year-old graduates from Microsoft University to build the system, ActiveX will be only the beginning...(this is how gov't contracting seems to work, unfortunately)
To get it to work on any other platform, though, would require supporting a completely different browser.
So much for the World-Wide Web, then. Why do companies have to take a perfectly decent thing and molest it until it is worthless to society?
I know this isn't what you meant, but there's another good point here: although 80% or more of personal computers run Windows, the percentage of Mac or Linux or BSD users who would like to try online voting is probably higher than the percentage of Windows users who would like to try it.
This is probably true. In a way, requiring Windows for voting is analogous to requiring everyone drive a particular model of car to the voting booth. Anyone not driving a Chevy should get turned away.
Web browsers use the Internet and cars use the roads, so I think only people using Windows and driving Chevys should be allowed to vote.
Darn, and I really wanted to vote next time.
Security through obsurity is worthless - you can always assume that the bad guys will always find the hole in the system...
For something as significant as voting, you can be assured the bad guys will find the hole in the system and exploit it. I wouldn't be suprised if, for every politician supporting e-voting, there would be another politician with organized crime tie-ins supporting e-vote fraud.
For the record, I think at this current point in time, electronic voting is a bad idea.
That never stopped the pork-barrel from rolling, before, has it?
The whole key infrastructure for this should be FIPS-140 compliant for hardware-based key modules, and require the coordinated actions of two or more actors in managing/engaging keys. There should be strict operational guidelines for the separation of roles in the management, deployment and retreival of these devices, and a separate role with an auditory function. The Auditory role needs a key that can reveal and validate any information on the system, yet create or modify nothing.
Hmmm...er, uh...how 'bout we use paper ballots? We can even make them from recycled paper and soy-based ink, so tree-huggers are happy, too!
Seriously, when to do something properly with high-tech gizmos costs ten times more than to do it properly with multiple multi-party volunteers at polling places and paper and pencil with an optical scanner or two, then we should consider not using the new gizmos.
It sounds like high-tech voting could be a market, where doing things the old-fashioned way might be the only way. In 100 years, where we have to worry about absentee ballots from Mars, then we can reconsider (the USPS can only guarantee delivery in 190 to 265 days or whatever from Mars, unfortunately, and warp-speed FedEx costs $185,000 per envelope).
Ah, another linux-only discussion
One problem with humans is that they easily forget alternatives in light of the current "one true way". Linux will become the next Windows. Just wait.
On Linux at any rate, virtually an program that uses glade, or loads data files/artwork from an external file, will have paths hard coded into it by the C preprocessor at build time. Removing these hardcodings is a royal pain in the ass.
.la files, it makes the Windows registry look pleasant by comparison.
I've seen this, too, and along with hard-coded absolute paths throughout GNOME files and library
I swear that somewhere along the line, open source took a really big step backwards with resepct to libraries and software configuration. There is simply no excuse for so many files to have absolute paths stuck into them (my GNOME 1.4 installation is absolutely a disgrace in this regard). If I had a nickle for each time LD_LIBRARY_PATH was completely ignored in favor of some assinine config file somewhere....
It's not news that to be highly productive whether in literature or aerospace engineering, people need to forego the traditional family life. People who claim to be highly productive in their career while raising a family are really falling short on one or both without realizing it.
I would bet that nearly everyone who is a really big-time contributor to open source, for example, is single and lives by themselves. This is not meant to paint them in an anti-social light, but simply says that they had to make choices to let them do what they enjoy doing most.
You clearly are not a serious programmer and I do not find you competent to have an opinion...
I'm glad you are such a good judge of character.
I actually don't disagree with what you wrote about your experiences as an uber-elite programmer, because that's the reality of working with a large corporate bureaucratic mess of software that was created over years of short-sighted decision-making. My original argument was simply against the kludges being presented in the open-source world as suitable build tools, when they create as many problems as they solve and make Open Source look no better than Windows (the worst kludge of them all). It doesn't take a programmer to see that progress is not being served either by these tools nor by stubbornness that clings onto what should be embarrasing historical baggage.
No wonder so many people propose using C rather than C++.
One reason C is so popular today is that it reached a critical threshold in abstraction: it isn't assembly code. C can be learned very quickly, and, given that prior programmers weren't too supidly clever, C-based programs can be easy to learn. I say "stupidly clever" because some people really do try to shoehorn functions into structures (oooo...I make C object-like) or use the preprocessor as if they have to, because it's there.
C, used as intended (structures and functions that use structures), is actually quite refreshing to program in. You know, even Motif (a C library) isn't all that bad, as long as it is used directly without resorting to compulsive-big-clever-framework-because-I'm so-smart-syndrome.
If you haven't caught on, I don't care for programmers who are so caught up in their genius that they invent these beasts of programs just to make them feel like they are architecting a space station or something. Usually, these are people just out of college, or "experienced" folk too stubborn to see their outside of their fantasy micro-universe. People need to realize that other people have to work with that code, too!
"plusox"
Perhaps they are referring to the weight of the new spec document (i.e., this thing weighs more than livestock, now).
In college, a professor provided a very concise argument for why we were learning Scheme instead of C++. All he did was hold up the C++ spec (several inches thick, duplex) and, then, hold up the Scheme spec (a pamphlet, by comparison).
And, I do remember Scheme being very easy to learn. I also remember a later class project, where a one-page Scheme-based compiler for some sort of combinatoric expression language took thousands of lines of C++ code to re-implement.
It's too bad there are so many cultural stigmas against Lisp and Scheme (picture freshly hatched contractor-babies saying "Ewwww...Lisp? XML is a much better scripting programmatical language" and trying really hard not to punch them).
Any number of firms (SCO, Sun etc.) haven't managed to achieve a small fraction of the success which Linux has done - on the Intel platform.
Thanks for qualifying that at the end. It doesn't have to be Sun, but it is very very important that non-Intel options remain and remain strong. Even if the alternatives consolodate or drop out, as many people predict, there absolutely has to remain alternatives to x86 and Intel. People that disagree with this should stop lying about why they love their country of choice and free-market economics and move to an island somewhere.
If Sun does indeed pick up stakes in SCO, they'd be hated more than Microsoft - if ever that would be possible.
Not necessarily. What matters most is what Sun does with their stake. Sun does good stuff, sometimes (OpenOffice.org, GNOME support, SPARC standards, Java, etc. etc.)
...their net income was "only" 4 million.
I'm just glad it's positive!
I'm not going to follow links because this Slashdot thread itself appears astroturfed...
Then what other place could be more appropriate for discussing the merits of a football game?
the philosophy of Extreme Programming
Please don't confuse philosophy with religion. Branded development processes are religions, where dogma replaces understanding. With understanding, religion becomes irrelevant.
XP is better than no methodology.
A yugo that runs is better than walking to work in the rain...er, perhaps I need a better analogy.
Anyway, my point is that XP seems to be more of an academic effort--an experiment--that gets press and starts a bandwagon rolling. Then people blindly attempt to jump on the bandwagon, but most miss and land in the mud.
What is better than no process is the team recognizing that basic things need to be done to be successful. A version control system is a start, but someone on the team really needs to know how to use it. A non-verbal communication method is needed, even just a mailing list, so that every nifty idea isn't lost the next day. People need to respect that no one person is the "driver" of the project, unless there is a designated architect (who should have oodles of experience), and that the typical programmer egos need to be set aside. Simplicity should be favored over buzzword-completeness. Flash-in-the-pan IDEs and development tools should be avoided. A mix of developer ages is critical (two college grads, two mid-career, one or two seniors, etc.). Older developers should mentor younger ones. Etc.
The fact that job descriptions are changing every three years helps nothing in developing mature teams. There was also a very insightful comment a few days ago that profit-interests for contracting also force hiring all-junior teams (I found this terribly discouraging). So, it seems that getting a good process rolling is truly an uphill battle. The software industry still has a very long way to go.
The world changes too quickly.
No, it's just the requirements are being defined by girls choosing an outfit for the prom.
I believe it is a fact that humans are roughly the same as they were 10, even 20, years ago! Why is it that we can't come up with a plan and stick with it?
What you need is a methodology which emphasizes development in stages.
My problem with branded methodologies, is that by the time the team is up to speed on the method, the software was due two weeks before. What there really needs to be is a cultural evolution, where people default to simply thinking before acting. A Professional Engineer that starts building a dog house in a manner like Homer Simpson would be laughed out of town. Why is it that no one is laughing at the software "engineers", who, essentially, are no better or smarter than our thick-skulled friend, Homer?
Oh, come now, poor people should be allowed to have their own version of the simpsons.
After WWE and Real TV, is there really a need for more shows????
I just thought of a great idea: Let's replace Fox News with a 24/7 slide show of kittens sleeping and playing. There would be no reduction in content, but the entertainment value skyrockets.
Clearing major changes with your cowworkers is generally a good thing.
This is 110% true. A group of people who don't communicate is not a team. I've seen what kind of software is built when the team decomposes into people to don't talk to eachother. It is crap.
Worse, are people who chase new buzzwords independently. That team is a non-starter, no matter how much money and PHB speak makes it seem otherwise.
A build system for software must reflect the complexities what it is attempting to build.
...it's a complicated set of programs with a complicated build order and no matter how hard you try, it would take a full-fledged AI to make it "easy".
Compiling a program and linking it into executables, libraries, jar files, etc. simply isn't that hard to do. A programmer that doesn't understand how to do it has some learning to do. Tools that claim to make the learning unnecessary are misleading--what does the programmer do those tools break and leave them stranded?
Ever tried to compile XFree86 by hand from source?
There would certainly be many makefiles, but they don't have to be complex. Just the bare minimum rules and environment variables should do. A separate file containing all volatile variables make customizing the build for platforms not difficult. Build systems do not need to be clever nor convoluted. All they need to do is compile the program properly and consistently.
Make can be improved on, it's a decades old design with multiple layers of hacks jostling each other. A new, clean design can at least simplify away the parts of the build process that involve "fighting with make".
Make can certainly be improved, but a new clean design has yet to be presented. Build systems that depend on Java or Python are not clean, because they introduce unneeded and unwanted dependencies into non-Java and non-Python programs, and they make for a build system that can be more complex than the program being built.
Proof by counterexample: autoconf exists, therefore it is clearly necessary, because nobody would trouble to build it if it didn't address a problem.
I'm not exactly sure what the original problem was that motivated autoconf, but autoconf and libtool cause me many many many problems on non-Linux platforms. I'd much rather have a single configuration file that tells gcc and ld where all the needed libraries are. All the tricks and things built into the 15000 (yes, fifteen thousand) lines of shell script that are libtool and configure simply break builds. Often.
given its vast popularity in the open source meritocracy I'd say the onus is on you to show that it truly causes more problems then it solves
The reason it's popular is that they are GNU, and people lap it up. Searches on newsgroup archives, especially for BSD systems, indicate that I am not alone in critizing these tools.
every project that uses it is a vote against that statement
And every project that won't build on Solaris because of libtool is a vote for it.
Odds are every single line you see during configure, with the possible exception of some really standard ones that seem to be a standard part of the package ("CC works?"), is used somewhere in the program
Perhaps the fault is in the overly-complex program? It seems the programmers write what they please and, then, invent these kludges of tools to deal with those programs. It is completely backwards. If a program is requiring tons of smoke and mirrors and special allowances and rules and exceptions, then the program is due for an overhaul.
The good thing about doing ant conf files in XML, si if they change the format, you can use xsl to transform ALL of your xml to a new format.
Layers upon layers of complexity. XML, XSL, Java, Ant Schemas...all for compiling a program. My sig is appropriate, here, too. A build system for software should be easy, intuitive, transparent, etc. etc. There has yet to be a replacement for make that has these attributes (makes tab syntax really isn't that big of a deal, either, even though that's what most people latch onto when complaining about it).
Small shell scripts and makefiles. Is more really necessary to call cc and ld or javac or whatever for each file in a directory tree? The differences among platforms can't be so dire as to require gigantic build automation tools, which introduce more problems than they solve!
Well, I haven't actually looked at scons, but in Make, there is only built-in support for a limited amount of languages.
:-)
Adding implicit rules in make is not difficult. It's in the man page (even Solaris' crappy man page for make describes it well enough, and the system default rules file has lots of examples).
Well, the fact that it isn't based on Java or XML gives it a good head start
Agreed.