Slashdot Mirror
$100,000 Open Source Design Competition
Hrvoje Niksic writes "The Software Carpentry project has announced its first Open Source design competition. They offer prizes totaling $100,000 for people who come up with good design for tools that replace autoconf, make,
as well as a bug tracking system and a regression testing suite.
Good luck!"
I hereby announce the competition to rewrite the
free unix kernel of your choice in python.
First prize is the IP number of an e-commerce site storing 100000 credit card numbers.
Free Slash !
DER MEDICATIONEN IST UNNECESSARCHICHHHCH LOOK OUT BELOW!!!!!! ahahahahahah, I can't believe I just did that.
My god. I have masturbated out a window. I am no longer a human, I am some kind of sick animal. FUCK ME.
Wow.
You go, uh, thing.
Tell me, how long has it been since you last took your medication?
hey dumbass, what do you think X4.0 is all about? How about kdevelop? That program is far superior to any winblows devel suite! You aren't worthy of LINUX, install NT.
oh wait, but you knew that already.
Well, you can keep using make, and you are
probably pretty good at it. That doesn't
mean it's perfect (did you even read some
of the material on that site?). The rest
of us will move onto better things, which
will probably be easier to use as well. Feel
free to catch up anytime.
Any wasting your time?? You instigated this
fucking "discussion". He was only defending
himself. Get a life!
except that there were very good reasons
on the site for why they were mandating
python.(read the faq)
to the original poster:
Are you advocating C++ (because of compiler
availability?), or are you advocating use of
any old language?
In short, dealing with a lot of languages
is a pain, one language used all over is
easy and consistent (especially when it's
a decent language like python) and python
(or eg. perl) makes the kind of programming
these tools need easy (easier than C++, think
automatic mem. managment, if nothing else).
Peter.
but this is slashdot, so I'll get moderated
down.
what? you may have a point, but details!
to make use of lex and yacc. I have done
it. It's not a clean as a makefile (it
is a special case), but you can do it.
Peter.
Yes! I was thinking about this the other
day. The ideal for me: editing a program
involves editing the data structures
representing the program. Source code
is simply a textual representation of the
data structures. Some languages (lisp) make
this easier than other languages (c).
Peter.
One of the topics was a bug tracking software. Unfortunatly, the people running the compitition did not look very far. A helpful piece of software is Jitterbug for handing mail tracking. Note this is really good for NON tech organizations with help desks. The big problem with a lot of the bug tracking software is that they are impossible to install. This issue may have been solved. Unfortuntly, this coward has not yet tried it (but problably will) How do you install a bug tracking system easily? install a Debian linux box and then install the deb file for the debian bug tracking system.
*Only if you agree to restrict your code in the same nasty way we do. Do not mix with free nor commercial products. Valid while supplies last. Offer voids in NY, CA, IL and where prohibited by law. On participants stores only. Giving away your soul may be required.
Man, I love this guy. His "wget" is one of the most beautiful pieces of software I've seen. That thing does practically everything you could want. His XEmacs hacks are priceless.
ergo GNU is not good
The whole autoconf/automake/libtool toolchain is an impressive one, but it is inheritently bound to the GPL. If we ever want a true free BSD, we have to think of an alternative. But as with the system compiler, we have other, more important work to tackle with limited resources right now.
And that's why *BSD stuff will never beat GNU software - they took the time to do it properly; you're "too busy" to bother.
Now that is a truly lame comparison. Well done, dork.
if you look closely, you will notice that
the python programs must not just do the
task at hand, but also generate C versions
of themselves. They have considered your
point, and have added this clause to eliminate
this redundancy, and also appeal to C hackers.
(joke)
No reason to mount him: he had a good point. (Although as someone already pointed out, Minix was "broken" in a sense.)
No, you are free to port GNU tools to whatever you want - SO LONG AS you don't subsequently try to allow anyone [the possibility those tools, modify them, and stop people porting them to another platform] -[]which the BSD license allows. EG. the BSD derived code in Win98.
I find gnu make's rule-based interface not at all confusing. It makes sense to me as the most logical way to structure dependency trees for minimal recompilation time-wasting.
and why don't you stop insulting make. It's you who is problematic, not the tool. With make you can do whatever you want, provided you learn how it works. There are some excellent tutorials out there. Dig in.
I've always been fascinated by the fact, that after mister JFK, said those words. That the US evolved it's 3D image, and moving picture alteration capability to such a degree, that no man today can see anything else, but that the crew on Star Trek are really standing inside the space ship Enterprise. Imagine, JFK says: Let's land on the moon... and the next thing we know, man is capable of creating animated pictures that give us an artists view of what the Universe might look like, and artificial worlds like man has never known before. And before a mars expedition ever comes to life... man has already created an artists view, of what such a thing might look like.
It's almost like if that certain evolution, started with the moon landing. And I wonder if a success of a mars expedition is line with the artists realistic quality of his representation of it.
if you don't know crap shut up.
There are so many other tools which would be much more useful than re-inventing gmake and autoconf. For what autoconf (and related tools) do, they're an excellent suite.
Since this stuff is being sponsored by everyone (ie, US taxpayers) it really should be put into the Public Domain so everyone is free to use it as they please, since they are paying for it. That's what US copyright law writers intended when they wrote that works of the government are not protected. Too bad it so easy for agencies like this sponsor to just hand off to a private organization or even a private company, like in this case (or the case of parts of Linux), and let THEM own what is, essentially, a work of the government. (People who are paid for their work are usually paid for their rights too or, actually, never have the rights -- see the US Code if you don't believe that.)
but I don't think you're smart enough to pull a stunt like that, given that you can't even figure out the basics of "make". I hear VB has a nice gui you can use, and there are a plethora of WYSIWYG html editors you can purchase. Maybe then you have a prayer of dragging-and-dropping your way to code production.
The "time greater than" approach has never been a significant source of problems in my experience. How often do you do something "that involves the possibility of a file changing to an earlier date"?
My biggest complaint is that there seems to be no way to get make to ignore cosmetic changes. It's very annoying that make wants to rebuild the entire project any time a comment is changed in a header file. I really, really wish I could find some way to explain to make that the project really depends on the output from something like "cpp", and that it doesn't need to rebuild unless that output changes.
don't try to disassociate yourself from the newbies now that you're embarassed.
Maybe you should also try and register and not continue going around flaming as an Anonymous Coward
yeah. first you claim to (ingeniously) have a fake hotmail address and now you're condemning me for not having the sack to have an account. well what is it?
I had no trouble getting VisualStudio to run lex and yacc (actually flex and bison) and then compile the resulting files. If you look, you can set custom make steps for files in the project.
Because that's the only way to write free software. If you don't allow people to make proprietary versions of it, then it is not free. In fact, if it is not free, it IS proprietary because you're claiming ownership and controlling its use. Look it up somewhere else than fsf.org. The point of writing free software should not be to force others to redo your work. It's to avoid that. The world is made better if somebody gets rich off my work and it doesn't harm me except in a special cases, when I'll go the full close-source route. There's no good reason to discriminate between who I open my code to (except maybe between those who'll pay and those who wont if I go that route).
Or do they get more advertising credit when we have to reload a whole new version of the page in a reasonable mode?
I realy think that framing this project in such a way makes it unpleasant. I am not questioning the credentials of the committee members. Rather it is my understanding that the comunity (not some committee) is the final judge in the open source world. If they want to help open source, they can help a project that is already recognized from the community. If they want this particular job done - hire someone for God's sake (whatever the licence). Playing these lame games with commitees and hipe around the money in their hands looks ugly to me. Just my two lines of code. AC
I'm not talking about autoated testing, just test-generation and test tracking. Something that can handle and manage 500-3,000 test scripts, with many-to-many relationships between both scripts and functions. The previous projects I've done have all required that I make custom tools since people are just too damn picky. (Worse yet, it was in Access; tip - if you have to use this DB, don't *EVER* use the scripting tool. Do everything in raw SQL...and if you don't know SQL, learn it...you'll save yourself time and frustration.)
If you make a derivative product, the license means that your product will be copyrighted by both you and the original author AND the derivative product will carry the same license as the original. Neither the law or the license allows you to remove its important clauses.
It's all too complicated to flesh out here (source and binary are treated differently, you can keep your code separate, combining differently-licensed code is more free than GPL, etc.), but I think we need a new almost-free license which does nothing but protect the author from law suits and maybe insists on attribution.
It coulda been perl
The open source community has needed a good haiku generator for a very long time. Kudos!
and uses hotmail
Just because it _works_ doesn't mean it isn't broken. Make _works_, but its interface is confusing and lame.
and IMHO you haven't. You're wasting bandwidth and my time - I should stop chastising you because it's blatant that you'll never learn anyway. I hope you're done humiliating youself here.
provided lusers like yourself take the time to read the documentation. Unix too, but I guess you're having a tough time. Stick with it; maybe some day you'll get it.
he'll be asking questions that are in the fags next
guess I'm not perfect after all
It screams c++ to you, you must have a big headache. I've just spend 10 minutes figuring out way Adobe Premiere crashed on a friends win98 box with 128MB, it turned out it was lack of mem!!! He had a 62MB max swap file, and Premiere was made with C++ (which issued useless runtime errors).
I didn't like c++, now I even hate it...
The Great AIP (Artificial Inelligence Project) has started.
It is open source under the GPL and for Linux.
Did anyone else notice the requirement that "All tools will be ... be implemented primarily in, or scriptable with, Python." And curiously Guido van Rossum is one of the judges.... Perhaps a little bias on the language selection. Note: not intended to a start language war, just an interesting point
It comes down to choosing the best tool for the job. For one web site I was working on I used a combination of c, c++, bash and php. Each did something that it was better suited for than the others. I like having that kind of flexability, so I don't like the idea of python, or any other language being mandated.
I've seen some amazing software engineering support systems done in Python already. Stuff that is quite a bit more complex to design and implement than make et al. Stuff of the kind that previously made a long time C++ user like me say "this screams for C++". Until, that is, I saw it done and maintained in Python with much less (and cleaner) code and time than would ever be possible in C++.
--
Linux user since early January 1992.
In simple terms, the autoconf-automake-libtool chain needs to be unified into a SINGLE program with a SINGLE database of bits and pieces (which could possibly be overlaid by a user's own database). First, there is the speed issue. Second, the problem that version inconsistencies produce (how may times have you had automake or authconf complain...). Third, and most importantly, each part of the toolchain mentioned is a single-point-of-failure in the build process -- reducing that to number to two-ish (gcc,NewMakeTool,possibly libraries) would make building a lot easier, and predictable (the predictability is NECESSARY if you want to distribute source and expect it to compile the same way on someone else's box as it does on yours)
John
John_Chalisque
Forcing the structures in the source code, by (for example) inventing a new language that has uses XML or SGML for the 'authoratative' version sounds like what you are talking about -- this allows for some of the fancy editing features in Visual Braindamage to be added trivially to any such language.
Question: What are pros/cons of what I shall term 'enforced coding structures' -- is there a proper term for this?
John
John_Chalisque
They aren't exactly robust, depending on space vs. tab often leads to problems.
cook home page
The referees are all presented on the project home page.
That's answared in the FAQ. Short version: It's very complex, they want experience with replacing the simple tools first.
I don't think so.
Because Free Software/Open Source Software is based on collaboration while contests are based on competition. The two are almost perfect opposites.
In this contest, we will have programmers duplicating their efforts on many projects rather than having many programmers expending their efforts on a few projects. What's more, not necessarily doing it because they are interested in the project, but in some cases, purely for the money. And after all, no-one writes FS/OSS for the money do they?
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
Incremental compiles.
If you look at the IDE provided by the IBM VisualAge C++ compiler, it provides incremental compiles. So, if you only change a comment within the file, the file wont be recompiled. Again, if a particular function was changed in a manner that didnt impact the rest of the file, only the code for that function is recompiled. This vastly reduces "make" time. Of course, this needs to be supported by the compiler too, but then both the compiler and make are GNU tools, so atleast in theory, this is possible...
There is no such thing as luck. Luck is nothing but an absence of bad luck.
Hmm. Let's see, mandate a particular development language for programs to be adopted by "medium-level" program designers.
Let's apply this "logic" to building skyscrapers: "Design applicants must use Legos (tm) because they are easier for use by new engineers."
My point: Not all languages have the same strengths or weaknesses. Mandating a particular language that may or may not map well into the problem domain is a Bad Idea (tm). Of course, GOOD SOFTWARE DESIGNERS already know that this is a Bad Idea (tm) and so they try to chose the best language for the problem.
The contest is not a bad idea, but the rules are illogical at best. I will be highly surprized if they can build a make or autoconf replacement by the end of this year. These are complex problems and "just using Python" will not make them easier. Cheers
--
"You're gonna need a bigger boat." - Chief Brody
If you look at the page carefully, you will find that the money is being put up by the US Government through the National Labs. So the US Govt is now *directly* funding Open Source. The products would be used to further parallel programming, beowulf, and just plain normal programming in a significant way. Yippee!
,papers, for details.
Why Python? A lot of developers at Labs are Biologists, physicists, chemists, weather folk, etc who develop large beouwulf and other numerical codes. Given that most scientists pick up programming without any formal training, they are more interested in spending time on their coding and science than in Makefile and autoconf arcana(and dont tell me that a m4 based config system is nor arcane).
Python is easyly understandable. A java/C++ programmer would pick it up in 2 hours. A C programmer in a day or two. People without any formal training pick it up in a week or so. existing C and C++ and Fortran code can be easily wrapped using SWIG--this has been used to implement the outer calculation and visualization loop for massively parallel molecular dynamics programs. See http://www.swig.org
This is the basic point: How do you extent the advantages of software enginnering to those who are not software developers, but simulators and scientists, and other engineers. And how do you stop being elitist and lower the barrier of entry into Open Source for the nonexperts and the common man. And how do you ensure extensibility. The answer is scripting, and good coding practises for the non-expert demand python.
The Inscrutable Gargoyle
I can say that it is (a) very easy to learn without sacrificing power.
The problem I have with Python is exactly that it has sacrificed some power. Take lists as an example. Python lists are arrays, so inserts and deletes are O(N)!!.
I agree that more language choices are good. I also think that there is a right tool for the job, and that the job of collecting dependency information doesn't cry out for a scripting language.
JET Program: see Japan, meet intere
a good chunk of the FAQ is spent defending this decision, w/ the crux of the answer being along the lines of "we feel python is the best compromise...". too bad, one would think the most viable approach is to educate new developers rather than dumbing down the tools.
--thi
There's more to make's apparent "slowness" than meets the eye. Peter Miller has written an excellent analysis in his paper, "Recursive Make Considered Harmful" -- his argument is that make has been misused for years, and we need to rethink how we use it. Instead of recursive invocations of make, we need to use the features of modern make implementations (e.g. GNU make) to make whole-project Makefiles that can do the job make exists to do.
Because Unix projects were once small enough to fit in a single directory comfortably, people got used to the idea of "one directory, one Makefile". When projects began to require many directories to organize the source files, many Makefiles and recursive invocations of make became the norm. This turns out to be extremely inefficient and prone to error, for a variety of reasons detailed in the paper. Instead, he advocates using many fragments of a single Makefile (one fragment per directory) and including those with make's include directive. (Hence the need for a modern make.) The paper also contains a section about writing efficient Makefiles, with techniques to significantly improve processing speed even with traditional recursive make techniques.
Common objections to this technique are also addressed:
- 4.1. A Single Makefile Is Too Big
- 4.2. A Single Makefile Is Unmaintainable
- 4.3. It's Too Hard To Write The Rules
- 4.4. I Only Want To Build My Little Bit
- 4.5. The Build Will Take Too Long
- 4.6. You'll Run Out Of Memory
While these techniques don't seem to have caught on much yet, there are some real-world projects (e.g. XEmacs) that seem to be doing so successfully...Take the time to read the paper; it looks to be worthwhile...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Who care if it makes sense? They're paying. I've been using an inappropriate language (required by non-technies) for 13 years, but the paychecks just keep coming. :-)
It's like programming for Windoze. Even if the platform doesn't make sense for the application, that's what the customer has. If the first words out of your mouth are, "Ok, first of all, we need to get you a modern computer," then the job will go to someone else.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
why do they want to replace the tools in question?
Cynical answer: Licensing? make and autoconf being the backbone of a lot of what we do and also being GPL'ed. Their license is not going to be GPL, its going to be MIT-X style.
why not just extend them as appropriate?
Agreed, a good GUI would do the trick for a lot of people. If the intent of this really is to improve functionality though, I am suspicious that radio-buttons would really achieve this.
I read the link pretty quickly...is this the DOE funding it? It looks like it. Does anyone know of any govt issues with GPL'ed software?
This is a response to your comments about a 'database' based compilation system. The ReiserFS filesystem, which has been in the /. news lately due to its support for journaling, is designed for handling a multiplicity of small files/large directories efficiently. The FS creator, Hans Reiser, is trying to move the filesystem in the direction of being able to replace your 'database' without any loss of functionality or speed, and without sacrificing readability.
Check out his future plans on his site. Don't have URL handy, sorry.
Howard C. Shaw III Grum
They are actually throwing (mostly) US taxpayer money at the project, there contibution runs about 40% for the initial design, and about 5% for the total project. The rest is through government grants according to their web page..
LetterRip
autoconf and automake are hideous.
I'm not a dumb guy. I've bee coding for various platforms and languages for many years, and always enjoy playing with new technology and software. But next to sendmail configuration files, autoconf/make seem to be created by the devil himself. I've never seen such an orgy of scripts, binaries and m4 working to create makefiles that take way to long to comprehend and debug. It shouldn't be this complex and bloated.
make, by itself, is perfect as a build tool. What I do like is the way glib/gtk+/gnome/libxml and other tools provide you with a -config script to which you can use backticks in your compile lines (eg. CFLAGS = `gtk-config --cflags`).
glib (not to be confused by glibc), also provides many safe routines (ie. better sprintf()) and utility functions we all could use and have probably made for ourselves. It also guarantees the existence of various core functions, by simply either being an alias for the system function, or if it doesn't exist, providing an implementation. Thus instead of targeting UNICEs, I assume the target platform has ANSI C (or C++) plus glib and any other libs I need. No need to worry if it's strings.g or string.h, or if there's a strdup().
Thus, it is my humble opinion that autoconf and friends should be replaced by simple make, *-config scripts and glib (or some other common library).
Oh man, I wish I had the references handy, but there are a couple algorithms for incremental lexing and parsing, which run big-O(n) where n is the number of *modified* tokens in the input. If you keep intermediate representations around, you don't have to rebuild the entire parse tree just because you changed X *= 2; to X *= 3; in a 50,000 line source file.
Given that the solutions provided by autoconf and make aren't needed by Python programmers, *why* would you expect a Python programmer to want to scratch this itch?
-russ
Don't piss off The Angry Economist
Similarly, make [...] needs a simple GUI front end for newbies more than it needs rewriting.
See http://www.alphalink.com.au/~gnb/maketoo l/
Disclaimer: I wrote it.
Dogsbody
I don't suppose you've considered the facts that:
1) It's an Adobe product, which are all huge resource hogs to begin with.
2) He's running win98 which is even worse about resources than Adobe? Friend of mine has to reboot his win98 box every few hours because it doesn't free memory after using it half the time with Any software.
Dreamweaver
"If a man hasn't discovered something he will die for, he isn't fit to live" -- MLK, Jr.
I think it's a pretty important piece of software, I browsed the project site and saw CVS mentionned in a few places, but RC is not as a project contest item.
Anyone with a rationale on this choice?
I'll add my two cents. As was recently pointed out on the info-cvs mailing list, IDEs have been *miserable* failures at providing any long term stability in build environments. They keep changing. Good old Makefiles and configure.in scripts just keep on going though. The last thing we need is yet another GUI front end to "make" and "autoconf" that stores its data in some un-archivable un-versionalble un-readable un-editable un-common format. There's a reason make and autoconf have lasted so long. They work, and they work in a lot of inhospitable environments. One of the strengths of Open Source is that Open Source programs will usually compile and run on a lot of different platforms. Any replacement for make or autoconf would have to run on just as many platforms to be as successful, and would consequently have just as many warts as make or autoconf. Sure they are not the prettiest, or easiest things to use for a beginner, but they work, and do what they were intended to do, and they stand the test of time. This proposal strikes me as changing things just to be changing things, without giving anything specific about the presumed "problems" with "make" and "autoconf" that are to be addressed by these proposed new tools. (well, I still write my own troff macros, so maybe I'm just incurably old-school.)
Bang the head that doesn't bang!
Sorry, but I think this has alot more to do with how the program was written (and what it is doing) that the fact that it was written in C++.
:)
Now, Java on the other hand
Actually, they're willing to throw other people's mone at it... It's being funded by a government grant, right?
WTF has this to do with C++?? Do you suggest that Adobe rewrite Premiere in Python??
"Bernoulli was wrong. X proves that you can fill a vacuum, yet still it sucks." - Dennis Ritchie
So write a new interface, not a new tool.
"Bernoulli was wrong. X proves that you can fill a vacuum, yet still it sucks." - Dennis Ritchie
I think you really answered your own question.
The problem with replacing autoconf or make
is that they're both "mostly there". Everyone
tends to put up with their limitations when
confronted with some of their inadequacies,
because it seems to be such a hurdle to
start from scratch. If you buy the 'more scriptable' argument behind the contest, it
makes *perfect* sense to offer money for these -- there's no way anyone would ever think about reinventing autoconf or make any other way,
and they're simply never going to get the amount
of portable scriptability that source carpentry
would like to see in them without starting
from scratch.
[
[
What's more, it is organized specifically to engage in an activity normally carried out by for-profit businesses. Ask any IRS examiner: this is not allowed.
Well, I guess we'd have to defer to the IRS examiners who review the FSF's submissions every year and qualify them as a 501(c)(3).
Developing a large body of software to help the citizen's of the US (and the world) through software reuse is a scientific and an educational endeavor. Certainly, the FSF software has greatly aided education by providing high quality free software for education and research.
As to CTC being a FFRDC, CTC takes a number of commercial clients so I'm not sure they qualify.
-Jordan Henderson
Some things I see I missed in the last post.
Yes, well, before GCC there was NO market for independent OS vendors who didn't also supply a compiler. Before GCC, it was pretty much the case that only the hardware vendors could capitalize both an OS and compiler development. This lead to a fractured, non interoperable, marketplace because the hardware/OS vendors were only interested into locking you in to their brands. Today, the situation is rather better, I think.
Sure, GCC may have hurt some compiler vendors, but those businesses were always fairly marginal anyway.
This is an analog to what I think you'll be seeing with Linux. As the basic tools become more available and commoditized, software vendors can concentrate on applications, contract programming and support.
Sometimes it's done, sometimes it's not. Hey, companies sometimes release commercial wares into the public domain. You can depend on the kindness of strangers if you want.
The GPL only demands this of an author who uses GPL'd works. If you want to license for fee, don't use GPL'd works. That's not onerous. Most commercial source licensing is the same. You aren't allowed to modify the SAP code you're provided with their source license and sell the result.
Where does RMS state that the GPL "is designed to reduce programmer's salaries and compromise their livelihoods."?
I've seen him state that it may have that effect, but I don't think you'll be able to back up your claim that this is what it was designed to do.
Even in the face of the ever increasing popularity of GPL'd software, programmer's salaries have been soaring. Maybe creating markets (like for BSD UNIX and BeOS) has been a good thing for programmers livelihoods?
-Jordan Henderson
Those same programmers will just lock up their own modifications and prevent further reuse.
The accretive nature of the GPL is evident. GCC, Linux and a number of other sources indicates that the GPL has caused considerable reuse, and end users have benefitted. Whether it's the OS vendors that build OSs using GCC or it's the many many businesses using Linux productively today, the proof is there to be seen.
The focus of the software industry is all wrong when people consider that those who should benefit the most in the industry are the programmers and not the end users. This is how we've gotten to into the pitiable position where we spend more and more on IT and have less to show for it in terms of real productivity. All of our money is wasted rewarding people for reinventing wheels while the building of good carts is being ignored.
-Jordan Henderson
It's not me who is labeling these organizations as charities. It's the IRS. You have to apply for and receive 501(c)(3) status. Mitretek, one of the 501(c)(3) corporations that spawned from Mitre does considerable consulting for the IRS. It would think that they would understand very clearly their roles and responsibilities under the tax codes.
Chapter and verse, please. I've produced a number of examples to refute your claim that a 501(c)(3) must only engage in non-competitive "charitable" purposes. I'd like to see some substantiation of your claims.
I believe that a non-profit only has to engage in the work that it was chartered to perform. "Charitable" is broadly defined by the IRS as being non-profit work that meets their charter. The FSF meets these qualifications.
If this is not the case, how does Mitre qualify for it's 501(c)(3) status performing C3I for the military?
-Jordan Henderson
This brings up the whole issue of there being too many computer languages in general. Python I've never learned so I don't know if it's suitable for the task or not but when last looking for some graphics / net language for programming I was swamped by everything that was out there. It'd be nice to have one language with extensions that are reasonable, and understandable. ( I know - languages like this probably exist - but how _reasonable_ are they? How understandable are they? )
There's a gorilla from Manilla whose a fella that stinks of vanilla and has salmonella.
Replace autoconf?
.dsp files! HA!), and opens the program up to porting to other platforms.
Replace make?????
These are robust, time-tested tools for creating software. If a better way existed to manage projects we (programmers in general) would probably have it by now.
I see these "good enough" -opinions as a part of the problem.. Of course anything can be improved and still be both forward- and backwards-compatible. I haven't seen a piece of software that couldn't be better in some way.
I was just recently a member of a team that converted a very large project from Microsoft's hideous Visual Studio project (.dsp) files to autoconf, automake, and make. Why was this done? Because it's easier to use, more flexible (try telling MSVC to run lex and yacc and then compile the output files, using only
Please don't compare your tools to the worst ones. Of course they look great that way, but it would be nice to see some piece of OSS as (real) state of the art (not just good enough to beat some crappy windoze shit).
Now on the other hand, if all "Software Carpentry" wants is versions of autoconf and make ported to python, well, I guess it's not that silly, but why would you want to do that? The source code for these programs is extremely portable already. Implementing them in Python gains you nothing.
Maximum portability is always good.
Maybe it's not too bad to standardize on a scripting language.
Python is one of the most portable scripting languages around ant it's easier and faster to optimize the intepreter's code than to rewrite or port the script/program itself.
<SPECULATION>
If the rumors about Crusoe turns out to be true, you could hack (insert your favourite scripting language) intepreter on the chip, replacing the (standard?) x86 emulator?
</SPECULATION>
How about doing something new?
I've seen too many bad X11 Apps, which are only (trying to be) clones of really sucking windoze products. (KDE & Gnome suites etc.)
IMO it's a shame that most X11 stuff is even slower than most Windoze stuff.. Optimize that code, ppl! X11 needs to be rethought at some point too.
"Speaking of which, I wish they would disclose whether (and how much) the judges are paid."
I'm a judge. I'm not paid anything.
I'm a judge of the testing tool, which I hope doesn't cause as much excitement as make. For the record, I think JUnit, expect, and dejaGNU are all wonderful things. I agreed to be a judge not out of any disrespect to their authors. To me, Kent Beck / Erich Gamma in particular are way up there in the pantheon. JUnit, Extreme Programming, and all that are the most exciting things to have happened to testing in quite a while.
If someone comes up with a better extension or replacement, the testing world will be better off. If not, it will get ignored, with little or no harm done.
JUnit doc: http://members.pingnet.ch/gamma/junit.htmJUnit source: http://www.xprogramming.com/software.htm
Extreme Programming: http://www.xprogramming.com/
Python Promotion: I think it's important that tools have a good scripting language. I think using the same one across a suite of related tools is a win. I prefer Python to Perl or TCL (and Lisp to Python). But I probably would have been a judge even if the language were Perl, and I'm sure my Python bias was unknown when I was asked to be a judge.
At worst, it will divert some free software talents towards enhancing and maintaining a little used set of alternative tools, rather than enhancing the tools used by the rest of the community. Most likely, someone will have wasted US$200.000.
This "diverting talent" line really is bullshit.
Look, under the classic OSS model, community recognition, the greater good and sense of personal achievement is enough. Under OSS dogma, the fact that some tools are used by the rest of the community is going to keep those OSS-commited individuals working on those tools.
If people want to enter a competition to replace those tools, then surely, as far as they are concerned, those tools don't have enough promise/investment to retain their attention.
Or have I missed something?
Danny
This is a design competition. It's not an open source issue because there is no source involved until the competition is over. At that point the best design is chosen, and becomes an open source project. Since no code is ever hidden, I see no problem with the design being done in private, since most open source programs start out as personal projects, and are not designed from their conception in an open source process.
It might encourage the best people if, say, they were particularly annoyed with one of the current programs. I couldn't live without make, but partly because I find it so useful, I am especially aware of its limitations, and am tantalized by the idea of a better make.
Also, some people may be willing to take risks on this sort of thing, especially if companies start creating more competitions. I am leaving my current job as a programmer soon, and (for many reasons) will never again work on closed source software. But if there were enough projects of this kind available at differing levels, I could see myself as a sort of software bounty hunter.
They're looking for new designs, which means they want you to look outside the box. Perhaps for one or all of these programs that doesn't need to be done, and the best solution is to improve the existing tool, but you can't know that ahead of time, and it would be hard to judge someone who created their own design against someone who modifed an existing design anyway.
Putting money into anything has to be done with care, and people will always fight over it. But if you can't come to an agreement with the people you're working with, you probably shouldn't be working with them.
Apart from the fact that they're looking for new designs rather than just 'fixing' something, one of the points of open source is that hiring someone to do something doesn't always get the best results. Offering the money to anyone who's interested is more likely to attract someone who really is interested and get a great program.
This is a good idea, but doesn't encourage people who aren't already involved in something to get into it.
I think this competition is A Good Thing, and I hope there are more like it in the future.--
foof
I argued that C, C++, or Perl might be more appropriate depending on the performance (and other) requirements of the application. I think the developer who dreamed up the application should decide what language is best suited for the given task. It should not be dictated in advance based on the founder's pet language.
Unfortunately it seems that Python promotion is the primary goal of the project, even though their $860,000 government grant is supposed to be used for creating new open source development tools.
Is it any surprise that Greg recently chose Guido van Rossum (Python author) as one of the judges? Speaking of which, I wish they would disclose whether (and how much) the judges are paid.
Don't get me wrong, I have nothing against Python. It is a wonderful language. And if the competition $$$ was raised from Python users' groups, I would be cheering them on. My problem is that they appear to be using $860K tax dollars to support Python even though the grant was for a completely different purpose.
Sure, some of you may be thinking that spending tax money to promote Python is not so bad. But imagine if they were spending your tax dollars to promote another language -- like Visual Basic!
I urge them to drop the biases and let the developers choose the most appropriate language. And may be best program win!
-Fyodor (fyodor@insecure.org)
Try the free Nmap Security Scanner: http://www.insecure.org/nmap/
In that case, you have never read the GPL and should not be commenting on it.
The GPL requires that it -- including the manifesto which it euphemistically calls a "preamble" -- be attached whenever the code is distributed. As Bruce Perens states, this is a political statement which many justifiably feel is inappropriate to attach to their work.
--Brett Glass
Actually, they don't review them thoroughly every year. After about 5 years, reviews are only triggered if the IRS sees an egregious violation of the rules (e.g. excessive unrelated business income). This is as per an examiner I interviewed just yesterday as a result of this discussion.
Developing a large body of software to help the citizen's of the US (and the world) through software reuse is a scientific and an educational endeavor.
According to the examiner, a "scientific" organization must be doing bona fide new research, preferably Federally funded and resulting in articles in respected scientific journals. The FSF does not. Its work consists almost exclusively of REimplementing commercial products so as to undercut for-profit companies. It makes no new scientific discoveries, publishes no articles in refereed journals, and does not allow the fruits of its work to be used by everyone. (Commercial software developers cannot feasibly use GPLed code.)
It likewise does not qualify as an educational institution. According to the IRS examiner to whom I spoke, an educational institution must have a curriculum and classes. In most cases, it must grant some form of credential -- such as diplomas, credit, or degrees. And it should be credentialed or accredited itself. The FSF doesn't qualify.
Certainly, the FSF software has greatly aided education by providing high quality free software for education and research.
The FSF doesn't exist exclusively to serve educational or research institutions and does not limit its benefits to them. So, again, it cannot be considered to be an educational or research institution.
The FSF's Web site also hints at other factors which disqualify it.
I invite you to ask the IRS itself about this rather than taking my word: The FSF does not qualify as a bona fide 501(c)(3).
--Brett Glass
None of the labels you mention is entirely off base. His writings definitely do borrow rhetorical techniques and concepts from those of Marxism. I don't know about "Svengali," but there is some legitimacy to the claims that he is a fraud. I personally believe that the FSF's 501(c)(3) tax exemption was obtained fraudulently, because the purpose of the FSF is (and always has been) to compete directly with for-profit businesses. This is not allowed, and since he intended to do this from the start, it may well be that he could be accused of defrauding the IRS.
Let's see, every single OS vendor has a compiler suite which they heavily support.
Yes, let's look at this. BeOS? Hmm.... They use GCC. BSD UNIX? Also GCC. In fact, GCC has usurped virtually all of the compiler business except for a few embedded niches and Microsoft Windows. It has done this via predatory pricing -- an explicitly intended activity of the FSF. Why is this any more justified than Microsoft "cutting off Netscape's air supply?" The answer: It's not.
The GPL is shorter than most EULAs
Actually, the preamble of the GPL by itself -- which is essentially a manifesto designed to "come along for the ride" with all software encumbered by the GPL -- is longer than most EULAs.
Not just by "giving back" -- that's commonly done under other licenses such as the MIT X and BSD licenses. Rather, the GPL demands that the author give up any prospect of licensing his or her work for money. He or she must give the code not only to the original developers but to everyone for free. This is an onerous requirement which, as Richard Stallman himself states, is designed to reduce programmers' salaries and compromise their livelihoods.
The GPL is far less restrictive than any commercial license with which I'm familiar.
Not true. I can pay a fee to license a commercial, royalty-free software library and use it in my work without being forced to compromise my livelihood as a programmer.
[RMS] unfairly gets called all kinds of names.
From what I have observed, what you call name calling is usually very justifiable and deserved criticism. I have rarely, if ever, seen RMS "called names" for no reason.
A reasoned discussion of issues of various "free" licenses is met with "RMS isn't God, GNU isn't a religion and the FSF isn't a bunch of prophets." and absolutely no substantive arguments
RMS's discussion of such licenses isn't reasoned. It's demagoguery which is designed to deceive and to hide his true intent.
and Stallman's agenda is one of spite and malice?
Absolutely. Check your history. It is historical fact, verifiable from RMS's own writings and from his remarks in public and in print, that the GPL was conceived as an instrument of spite against Symbolics -- a commercial spinoff of the MIT AI Lab. And all other companies of its ilk.
--Brett Glass
Here:
This passage shows Richard's angry response to the formation of Symbolics. Richard characterizes the new company as if it were Nirvana for his departing colleagues: all of the fun and interesting work of the AI Lab, but with decent pay, too! Yet Richard, a creature of academia, really could not come along. Angry and spiteful, he begrudged his colleagues their good fortune. He literally advocated "banning" higher pay for programmers than they could get in academia. He vowed revenge not only on Symbolics, but on all commercial ventures of its kind.
Thus, the GPL was born.
--Brett Glass
No, it makes programming much harder by imposing a long, complex, baroque, restrictive license -- loaded with political baggage -- upon the code. The GPL is to open source software what Soviet Communism was to socialism -- a scheme which claimed to be idealistic but in fact had much more base motivations. Want programming to be easier? Want to see the state of the art advance? Use an open source license that makes the source truly available for reuse by all with virtually no strings attached. The GPL is not that license.
Glad to see someone is watching out for the poor IRS!
I'm not just watching out for the IRS; I'm watching out for anyone who pays taxes or contributes to United Way. By dubbing itself a "charity," the FSF has extracted money both from the taxpayers and from people who believed they were making donations to truly charitable causes. The FSF is not a charity, since it does not reserve its work for those in need and because its primary purpose is to compete directly with for-profit businesses.
--Brett Glass
Mitre is not a 501(c)(3) non-profit nor does it claim to be a charity. It is a "not-for-profit" corporation, which means that it attempts to avoid taxes by spending a sufficiently large amount of what it makes to avoid income tax. If you contributed money to Mitre (And who would?) your contribution would not be tax deductible.
Another company that I'm familiar with, CTC (Concurrent Technology Corporation...
Is likewise not a charity and does not claim to be.
Better get your facts straight.
--Brett Glass
Then what's your excuse?
It's clear that you are labeling entities as "charitable" that do not perform any charitable function whatsoever.
What's more, the Internal Revenue Code explicitly states that a tax-exempt charity may only derive a small percentage of its income from activities unrelated to its charitable purpose, and that all of this income must support activities which are charitable. The FSF does not meet either of these qualifications.
--Brett Glass
I have not seen RMS libeled. I have, however, seen legitimate criticism of his mean-spirited agenda, which is anti-commercial and anti-programmer.
you never see RMS suggest that others who don't support the GPL should stop using GPL'd products.
Of course not! This is because the use of his products helps to spread the "viral" GPL license. In fact, it is only because Linus, without fully understanding RMS's agenda, stamped the GPL onto Linux that Richard is now a public figure.
Gcc comes to mind as something that has benefitted many in the Open Source "Community" who snipe at RMS, the FSF and the GPL.
This shows the destructiveness of the GPL. While these people would very much prefer to use another tool, the predatory nature of the GPL has eliminated alternatives.
Now we can see the philosophy of some of those who support other "free" licenses. They are factionalists.
Not so. They differ with RMS, and with good reason. Stallman's agenda is one of spite and malice.
The FSF and the GPL support Freedom in software.
By tying it up with a multi-page license that's rife with legalese and places massive restrictions on its use. Yeah, right.
The software is permitted to be used by anyone, even those who work against FSF goals.
Not so. While many users (in particular, "end users") can use the software in the way that best suits their needs, programmers cannot. This is the purpose of the GPL: to transform open source from a public good into a weapon directed against those who engage in activities of which Richard Stallman does not approve.
--Brett Glass
Again, you're showing your ignorance of tax law. Not all 501(c)(3) corporations are charities. Certain corporations which perform specific activities for the government, as specified by Congress, may also be classified as tax-exempt under 501(c)(3). But they're not charities; they merely qualify for a tax exemption under other provisions in that same part of the Tax Code.
For information, see IRS Publication 557.
--Brett Glass Mitretek, one of the 501(c)(3) corporations that spawned from Mitre does considerable consulting for the IRS. It would think that they would understand very clearly their roles and responsibilities under the tax codes. What's more, the Internal Revenue Code explicitly states that a tax-exempt charity may only derive a small percentage of its income from activities unrelated to its charitable purpose, and that all of this income must support activities which are charitable. The FSF does not meet either of these qualifications. Chapter and verse, please. I've produced a number of examples to refute your claim that a 501(c)(3) must only engage in non-competitive "charitable" purposes. I'd like to see some substantiation of your claims. I believe that a non-profit only has to engage in the work that it was chartered to perform. "Charitable" is broadly defined by the IRS as being non-profit work that meets their charter. The FSF meets these qualifications. If this is not the case, how does Mitre qualify for it's 501(c)(3) status performing C3I for the military?
If someone who uses information gained at the public library to make money, we don't try to deprive that enterprising person of that money because he or she wisely used a public resource. The same is true of open source. Let's not fall into the GPL's mean-spirited trap of spite. If you're going to share software, share it for real, with no strings attached -- not halfheartedly or grudgingly.
--Brett
The FSF is not charitable, because the development of software is not a recognized charitable activity. Also, its benefits are not reserved for those in need.
It is not scientific, as it does not do research, publish papers, etc. In fact, it is devoted to implementing copies of existing works.
It is not educational, as it is not accredited, awards no degrees, and has no curriculum or faculty.
In fact, it flunks the tests for every category of 501(c)(3) organization, as laid out by IRS examiners.
What's more, it is organized specifically to engage in an activity normally carried out by for-profit businesses. Ask any IRS examiner: this is not allowed.
For these reasons, I stand by my belief that the FSF's claim to be eligible for 501(c)(3) status is bogus.
--Brett Glass
Ironically, Python and Perl are both far more portable than C and C++, for which autoconf was primarily designed, because the libraries do a better job of hiding platform dependencies.
Perhaps the competition is barking up the wrong tree in this particular case. Don't get me wrong here; I'm all for liberating autoconf from the GPL. But it would be better still to get rid of it altogether. How about a contest whose goal is to create a standard set of library functions, APIs, and macros for Python, Perl, C, C++, Pascal, etc., that eliminate the need for autoconf?
--Brett Glass
--Brett Glass
Which means they have a strong disincentive to doing it. And the advance may be lost forever.
--Brett Glass
Make a new 'Makefile' which is easier to understand for us newbies to programming.
Maybe this certain fellow is clever enough not to give out his proper address, and get spammed.
Also remember who the coward is.
There has to be some stuff that could replace these crappy window programs, have a competition for that!
If I had 100K and wanted a task done.. I wouldnt make a blooming ocntest out of it. I would hire one or two Programmers with good C and *nix experience and have my software developed that way.. This is smelling of publicity.
You are engaging in faulty parallelism here. JFK's dream was antithetical to the Open Source movement. It was an appeal to the USAian notion of making things work. What about people outside of the US who would like to make things work or make things happen or bring things into existence or... The real gripe here is whether or not we should replace these fundamental utilities at all. They work just fine for me. Why replace them? Why have a competition to do this? If I think I could rewrite make or autoconf or add something to them I would contact the people in charge of those packages not have a competition to get people fired up to address perceived problems. If it ain't broke, don't fix it (as they say here in the South).
The point behind it is - if you keep things at the level they're at just because "They work just fine for you", you're holding back possible advances that could take us far beyond where we're currently at. 386s worked fine, you don't see me using one - technology, both in hardware and in software has a NEED to progress and evolve. If we're not progressing, changing and adapting, we might as well be dead.
I know that software released under that license is free software ( and RMS set that clear ). However, I thought that people willing to contribute/take part of this contest should be warned that the code they submit might be made propietary by the organizer or someone else.
Thus, I think that the MIT license might be good for releasing your own code, but IMO is wrong ( and that's the rational behind the subject of my post ) to make it obligatory in this sort of contest. They might have let the participant choose which license to release their code under, among some widely known free software ones, like X/MIT, BSD, GPL, Artistic License, etc. Of course, YMMV.
Diego
The MIT License (also known as the "X License") is used for all technical material, include program source code, manual pages, and similar material.
and
The project therefore requires source code and other purely technical material to use the MIT License
If you don't see any problem with that, just look at what RMS have to say about it.
I've managed projects with a hierarchy of directories, and therefore, makefiles spawning make over other makefiles. While it works, it can get messy, particularly when you have to automatically keep track of build environment variables that should be different in different directories (i.e. turn on this level of debugging here, here, and THERE).You really want to keep such settings (with defaults on a global, per directory, and per-directory sub--hierarchy, as appropriate) outside of makefiles. That way, you can carry around custom-debug-enabling files separate from the rest of the build tree (ever say, "Heck, I'll start from scratch, but I wanna keep all the local overrides?). These "support" files then need to be included (often recursively up the directory tree) in the makefile as well as automatically generated, when there are no default overrides. Furthermore, as they change, things need to be rebuilt. Ergo: makefiles that have build dependencies on the very files they include. Ugh. You can do all this in GNU make. But, it gets really messy really fast. Regards, Rene S. Hollan
You could've hired me.
I've managed projects with a hierarchy of directories, and therefore, makefiles spawning make over other makefiles.
While it works, it can get messy, particularly when you have to automatically keep track of build environment variables that should be different in different directories (i.e. turn on this level of debugging here, here, and THERE).You really want to keep such settings (with defaults on a global, per directory, and per-directory sub--hierarchy, as appropriate) outside of makefiles. That way, you can carry around custom-debug-enabling files separate from the rest of the build tree (ever say, "Heck, I'll start from scratch, but I wanna keep all the local overrides?).
These "support" files then need to be included (often recursively up the directory tree) in the makefile as well as automatically generated, when there are no default overrides. Furthermore, as they change, things need to be rebuilt. Ergo: makefiles that have build dependencies on the very files they include. Ugh.
You can do all this in GNU make. But, it gets really messy really fast.
Regards,
Rene S. Hollan
You could've hired me.
"How?" Write your tools in whatever language, provide GENERAL interface for scripting (add comment - Python interface will be [user changeable] default) and you violate no rules [IMHO].
"What do you have to improve in make?" Well, you will find this in competition pages when it will end up. :-) Or, if codesourcery won't make it public, - I will do personally. I'm not so fool to disclose ideas I had for several years with "no try" in competition. Especially when even minimal prize is 5 month of my salary worth (C'est la vie in ex-USSR).
Do you believe in success? Yes, I do. And time will show how everything will happen.
A note on Brento's comment about IPO'ing being the only way to get recognition: many recent IPO's had their start in Open Source projects (e.g. sendmail). We hope that this design competition will be a way for fresh talent to get recognition. Recognition leads to funding. Funding leads to rapid development. Rapid development leads to a public offering. Public offerings lead to --- hmm, perhaps best to stop there :-).
Thanks,
Greg Wilson
Software Carpentry Project Coordinator
http://www.software-carpentry.com
Regarding the "missing requirement" of a migration path from make, entrants are free to make that a requirement --- part of the aim of the contest is to pool ideas, as well as effort. However, we don't believe that forward compatibility is an "absolute" requirement --- Java GUIs are not forward compatible with the C/C++ GUIs they are replacing, for example, and C was not forward compatible with any of its predecessors.
Thanks for your posting,
Greg Wilson
Software Carpentry Project Coordinator
http://www.software-carpentry.com
Thanks for your posting --- our reasons for choosing Python are discussed in the project FAQ. In answer to your specific question (about why we didn't choose C or C++), these four tools are mostly concerned with text manipulation, process control, and database access, for which scripting languages (Python, Perl, etc.) are better-suited than stricter compiled languages (C++, Java, etc.).
Thanks,
Greg Wilson
Software Carpentry Project Coordinator
As a footnote to my earlier post, please note that this is a design competition, and not a coding competition. Implementation will eventually be done in Python, but at the level of a 5000-word design outline, most of today's high-level object-oriented languages (C++, Java, Python, Perl, etc.) are pretty much equivalent.
Thanks,
Greg Wilson
http://www.software-carpentry.com
Thanks for your posting. In answer to your first comment, no, this isn't a company --- as the project home page and FAQ explain, this is being funded by Los Alamos National Laboratory (because scientists and engineers need better software tools), and being administered by CodeSourcery, LLC (who believe that it will further the aims of the Open Source community).
As for existing tools being "good enough", that's addressed in the FAQ as well (but yes, we did forget about sendmail, and will correct that).
Finally, as for this being part of Guido's grand plan, he was not involved in the project in any way until after it had been launched --- in fact, he was the last-but-one addition to the list of judges.
Thanks again for your posting,
Greg Wilson
http://www.software-carpentry.com
Thank you for your posting regarding the Software Carpentry design competition. In answer to your point about "educating new developers", please check out the project's white paper. That was the first thing we tried, but again and again we found that the "accidental complexity" of existing tools was getting in the way --- so much so that intelligent, highly-motivated scientists and engineers were choosing not to use the tools at all, rather than try to climb their unnecessarily-steep learning curves.
Greg Wilson
http://www.software-carpentry.com
Thanks for your posting regarding the Software Carpentry design competition. To answer your first point, S.C. is not a company --- it is a project funded by Los Alamos National Laboratory (whose scientists and engineers need software tools that are easier to use), and administered by CodeSourcery, LLC (which believes that the project will further the aims of the Open Source movement).
Your points about encouraging secrecy and non-cooperation are addressed in the FAQ. As for preventing people from fixing the things that are perceived to be broken in existing tools, that is certainly allowed --- we welcome designs based on existing software, as long as those designs include a scriptable Python interface. (I personally believe that a re-design that takes good ideas from several existing tools is more likely to win, but I'm not one of the judges...)
Thanks again for your posting,
Greg Wilson
http://www.software-carpentry.com
Ten years ago, someone could have waved a hundred thousand dollar check in front of Linus's nose, and it wouldn't have got us to this point any faster.
;-)
It wouldn't have gotten us to this point at all - Linus first wrote Linux because he couldn't afford anything else than Minix.
Lack of money can be a good thing. (VERY unusual though.
Why fix something if it isn't broken?
RMS doesn't slam the MIT X license in particular, he is advocating the benefits of copylefts. If you don't want a copyleft, the MIT X license is fine. I believe he described it as "a simple non-copyleft free software license with no particular problems" at one point.
I don't see the relevance of motivation for a postulated "classic OSS model" in a project where US$200.000 will be invested in development.
What can happen is that the new utilities are anough of an improvement for some project to switch to, but that the wast majority will stick to the existing well known tools, since they are "good enough" and most developers already know them. This means that the programmers most likely to improve the existing tools will use something entirely different instead for their projects, so the majority will end up with worse tools than they would without this competition.
If you have a "database" that also can organize chunks of arbitrary data in a tree structure, but is so much faster than ext2 at this that you believe it should be built into programs... why not wrap a filesystem driver around it and build it into every program at once?
Your're right, I was not thinking of arbitrary data when I speak of that "database". I want to exploit features of a certain kind of data, that should be stored efficiently - the intermediate code representation.
We usually store the initial representation of the program (the source) and the final representation (object files, executables, libs..) but throw away the intermediate representations that compilers, assemblers and linkers calculate time and time again.
For a few cases we keep that intermediate representations. Precompiled headers are an example of an intermediate result that is kept near the beginning of the translation chain, template repositories (used in AT&T's cfront derived C++ compilers) are an example near the end.
What I thought of is similiar to one of those relational databases in that the focus shifts from the raw input data to the intermediate representation that would be kept as a whole.
Let's say the running core would consist not of a collection of files of characters but of datastructures that are more suited for compilation, typically of a forest of parse trees and related intermediate information for the whole project.
One could import/export sources from that core, and the compilation process would be a special kind of query that exports binaries from that core.
More global optimization strategies would be possible because the compilation proceeds on the whole project, not only single compilation units as normal compilers do.
The trouble with template instantiation would be gone.
But, yes now comes the but :-), such a system is certainly complicated. I had a lot of fun with precompiled headers and template repositories in the past. So I assume it is not easy to write them in a way that they work flawlessly.
PMake - A Tutorial
Adam de Boor
If there's a missing requirement in the rules of the contest, it's the lack of a migration path from make. Without that, you just have an interesting toy, because no one will move their existing significant system without it.
Important point!
I am sure there is a lot to learn from those old systems. :)
(Why some of the VMS guys inflicted Windows NT on us is a different thing
That we seem to have lost some features as well and did not progress only, shines through in the hacks and rants of great hackers like Richard Stallmann and Jamie Zawinski. Take this quote
Back before the current dark ages began, I hacked on Lisp Machines. (..)
Have you ever wondered why we're stuck with crap like Unix and MS-DOS? Read Richard Gabriel's Worse is Better paper for a great explanation of why mediocrity has better survival characteristics than perfection
from Jamie's page and this quote from Richard
Yes, with string-based interpreters you can represent programs as strings, and you can interpret them as strings, but you can't parse their syntax very easily as strings. In LISP, programs are represented as data in a way that expresses their structure, and allows you to easily do things to the programs that are based on understanding them.
from a recent RMS interview. Both refer to the LISP machines of MIT, which seem to have operated on a higher level program representation than mere strings.
I interpret these rants that todays machines are stronger but dumber in a sense as well.
Question is if one could combine the strengths of both worlds. The higher level representation found in LISP machines and the performance of our present C compiled systems.
Like I tried to explain above, my feeling is that this could be achieved by shifting the primary representation to something closer to the intermediate structures that arise during compilation. It would have indeed similarities to a configuration management system. Adding a line to a text source would, after check-in, result in an immediate update of an persistent parse tree of the program database core.
OpenVMS compilers and the linker can be invoked to operate on CMS objects without having to pre-fetch anything first.
Do you have any reference where I can read more about CMS? (I would be happy also to have some nice review on the strengths of the LISP machines)
If we were to implement something like this for ourselves I'd say the first thing to do is to find a lightweight, fast and efficient implementation of an object repository. Does anyone know of such?
Sounds to me like what OODBs are promising. The one I had to try so far (POET 3 under Win32 and Solaris) was horrible. No idea how they perform today, as they seem to be two major revisions farther.
We've really got two things here.
No, I am not talking revision control repository here. I am talking moving towards a representation that is a bit further down the road of compilation.
Obviously it is possible to represent a programm on many different stages:
If we treat each translation step as a mapping between representations, I can draw the compilation process this way:
1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7
In fact not all mappings are one way (loosing information) but are (or could be made) bijective
1 <-> 2 <-> 3 -> 4 -> 5 -> 6 -> 7
I now suggest focussing more on the programm in representation around stage 3. Why?
Because this is the representation in terms of the language, on that for example the compiler works on for code generation.
And I am not thinking just compilation here. I am more thinking turning the collection of sources into a database of things more understood, e.g. program related units, like classes, functions, macros, ..
Take Emacs for example. Press Esc-x and then spc and you get a listing of all available functions. The Emacs kernel "knows" of all its functions. Compare that to grepping a deep C/C++ source tree for some function. That grepping should be replaced by a more appropriate query on a more appropriate database. (Like that Esc-x spc sequence is a query on the dumped Emacs kernel).
If the source has changed, you are going to have to rebuild the output anyway. If the original has not changed, you can just use the object file from revision control. What is the point?
Not every change to source would result in a complete rebuilding of the internal structures. Some mechanism like the access optimzation found in relational databases had to decide if the whole has to be rebuild, or if only parts have to be changed. This is certainly one of the hard parts.
Now, I suppose you could argue that you don't always need to recompile an entire source file; you may have changed just one function. But to know that, the compiler is going to have to do a source analysis of it anyway.
If I edit on the text stage you are right. Possibly most changes will result in a new translation. If I edit on the language stage ("add a function", "delete that class") not necessarily.
I suggest to have a look at this article on the problems with recursive makefiles.
Here is the one I meant (HTML, PS, ASCII)
As far as I understand ("scriptable from python") they want to be able to run it from python.
What I am more surprised about is to see Chris DiBona on the referee board.
He worked on the "Open Sources" book and is the leading PR guy of VA Linux (for a bad example of his advocacy style listen to this interview). But there it ends. He is certainly not picked because he is an expert of tool design.
Anyone knows about the other referees?
I mean, honestly, what is a "filesystem" except a way of organizing chunks of arbitrary data in a tree structure?
If you have a "database" that also can organize chunks of arbitrary data in a tree structure, but is so much faster than ext2 at this that you believe it should be built into programs... why not wrap a filesystem driver around it and build it into every program at once?
I can't see anyone slapping together a tool to replace make any time soon... that's one piece of heavy parsing code.
The free market is a wonderful thing, and you don't want to discard the parts of it that work well. It's not unreasonable to offer compensation to somebody to write a useful piece of software.
I recently came across a proposal by an economist (in the UK, I think) called "social policy bonds", which is applicable here. His proposal was that the government would create a financial instrument (a piece of paper) which could be redeemed for a fixed amount of money when some measurable social goal was fulfilled. Once the bonds were created, they would be auctioned to the highest bidder. A further free-market tweak could be put on the idea: bonds are issued by individuals rather than the government. Rather than collected tax dollars, an individual puts a chunk of cash in escrow with a private financial institute, which gives the individual a certificate serving the same function. If the condition is met, anybody can redeem the certificate and take the money out of escrow. (Until that time, the escrow agency can invest the money, or collect interest on it.)
I've discussed this idea with a couple of banks in my area and they aren't interested in acting as escrow agents. The idea is too wierd and new for them. Maybe I'll try insurance companies. The viability of a certificate is contingent upon the reputation of the escrow agent.
A similar instrument could be used in place of Software Carpentry's competition. It would remove the stipulation that only one person could prosper for each goal. People would be able to profit by contributing to the efforts of others. As with shares of stock, all the owners have an incentive to cooperate to cause the price of the shares to rise.
The economist who originated this idea is named Ronnie Horesh. His proposal goes into much greater detail than I have done here. It's a cool idea, probably useful for many different goals.
WWJD for a Klondike Bar?
It doesn't. It makes it easier for the evaluators to evaluate. Once they get a set of winners, why don't we port 'em to C++?
"Now we can see the philosophy of some of those who support other "free" licenses."
I seem to recall the original post in this thread called MIT/X the "wrong license". Are you saying that it's okay for GPL advocates to criticize MIT/X, but that it's at the same time wrong for MIT/X advocates to criticize GPL?
A Government Is a Body of People, Usually Notably Ungoverned
"What's wrong with a bit of Marxism, anyway? It sure makes programmming easier - which is what I care about."
With the MIT or BSD licenses, I can include the entire readable and understandable license at the top of each and every source file. I don't have to wonder if I'm going to be sued for using library A with library B. In short, since there are fewer restrictions with the BSD or MIT, programming is easier (unless you like the lack of choice inherent in marxism).
"Just don't try telling me on one hand that the GPL is evil because it forces people to give away their code, and then encourge people to licence under the BSD so the code can be "truly free"."
No one was calling the GPL evil (at least in this thread). But it's absolutely ludicrous to call the GPL more free than the BSDL on the fact that the GPL is more restrictive. And though it's not evil, it is questionable that the GPL requires its users to redistribute political propaganda.
A Government Is a Body of People, Usually Notably Ungoverned
"But neither thr BSD or MIT licence force you to include the source, do they?"
:-)
But you were arguing that the GPL makes programming easier. Stop changing the subject
"...but apart from that I don't know what you are talking about."
I'm talking about that whole introduction at the top of the GPL before section zero.
A Government Is a Body of People, Usually Notably Ungoverned
I agree totally.
For a crowd that likes to toss around the words FREE and FREEDOM as much as they do, they are very stuck on the notion that there is only one right way to do something.
The quickest way to earn the enmity of the Free Software community is to freely and voluntarily choose something. Choose *BSD and they bitch about proprietary exploitation. Choose KDE and they moan that it's illegal. Choose Redhat and they kvetch that it's too commercial.
Choose to award someone $100K in a contest to improve autoconf and they're incensed that someone would spend his money without asking permission of Slashdot first.
A Government Is a Body of People, Usually Notably Ungoverned
"I actually like autoconf, and I have been using it in some of my projects, but the Makefiles generated by automake are just too bloated"
I think you just answered your own question.
A Government Is a Body of People, Usually Notably Ungoverned
Hmmm, I didn't know that the DOE was funding this. This is not a good thing in my view. I can see one of my earlier posts is going to come back to haunt me. You'd think I'd learn to read the entire article first before commenting on it :-)
However, I notice that most people bitching about this are not complaining about the source of funding, rather they are bitching that money is going someplace other than where they want it to.
A Government Is a Body of People, Usually Notably Ungoverned
What exactly is the problem? Yeah, I guess Python won't be installed on every machine - but so won't any of those new tools. And if you are going to install new things, what's the problem with installing Python?
-- Abigail
You speak of checking sources in and out of the "core" (I assume you mean a revision control repository), and checking binaries out. You also mention keeping parse trees and similar temporary data structures in the repository as well.
We've really got two things here.
The first is the question of keeping just "source" files under revision control (and by source, I mean anything you use to build an executable - code, images, resources, etc.), or keeping everything (object files, final executables, etc.) under revision control.
The argument for "just source" is that you should always be able to build an identical finished product from the proper source, and so keeping generated output files around is a waste of machine resources. You also run into fewer problems with the unexpected dependencies and conflicts you encounter during debugging.
The argument for "everything" is that you can reduce build times by having those ouput files pre-generated, so the burden of rebuilding on a change is put on the person making the change, and everyone else just uses their output. You can also make the argument that finding the above-mentioned dependencies early on will lead to better code.
As far as I'm concerned, this is largely a matter of opinion, and you should go with whatever works for you.
Now, the second issue is a bit different. You talk about storing intermediate data, such as parse trees. An extension to the "everything under revision control" method. What benefit does this get you? If the source has changed, you are going to have to rebuild the output anyway. If the original has not changed, you can just use the object file from revision control. What is the point?
Now, I suppose you could argue that you don't always need to recompile an entire source file; you may have changed just one function. But to know that, the compiler is going to have to do a source analysis of it anyway, so why bother trying to cache the output? If your source files are big enough that this is a significant problem, youprobably need to look at splitting up your source a bit more. It isn't just increased build times that are at issue here; programmer comprehension drops the bigger a source file gets.
Don't get me wrong; I'm not trying to shoot you down here. I'm just trying to see what benefits one would get from the ideas you are suggesting.
Incidentally, Borland's Incremental Linker, used in C++Builder and Delphi, does do something similar to what you are suggesting. If you change one object file and go to relink to make an updated executable, it simply replaces the parts of the executable that depend on the changed object code. The parts that did not change stay the same. Saves a little time.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
That said, I still prefer makefiles. Much easier just to set up a general rule and tell make to go to it.
What's wrong with a bit of Marxism, anyway? It sure makes programmming easier - which is what I care about.
Glad to see someone is watching out for the poor IRS!
But at least then when that programmer is gone you can guarentee that you have an up to date copy of the source - try that with a commercial licence - and don't give me that line about how all BSDL software producers are nice guys who throw in the code for free - that is the same as GPL, and invalidates your arguement.
Until you need to fix a bug in that library, and find you don't have the source and the company is out of business.
As opposed to your well resasoned and level headed criticisms of the GPL, say?
You know what I like best about the BSD licence? The fact you can re-licence code under it to the GPL. Life is beautiful, sometimes!
Look, I have nothing against the BSDL - it is a nice licence if you want to let others make money off your code. Just don't try telling me on one hand that the GPL is evil because it forces people to give away their code, and then encourge people to licence under the BSD so the code can be "truly free".
GPL - all the source, all the time!
The source code is available for FreeBSD & OpenBSD, right? There is no difference between that, and GPL'ed code, except that GPL'ed code can never be hidden, while BSDL code can.
That means that if a company wants to make some advance then with Linux they have to release the code (ignoring Binary Kernel Modules) while with *BSD they don't.
I guess you'll say "but they often do release the code after a while" - well, I don't want to wait and hope. I want it guarrented!
Whilst I applaud any company who's ready to spend substantial wads of cash on OpenSource development, I really think that competitions are the wrong way to go about it:
I thought this at first, too. Seems like a dumb thing for an "Open Source" company to do, since it appears to encourage competition at the expense of the OSS model. But upon reading the webpage I discovered there's more to the story.
Actually, after the initial design phase, finalists are monetarily encouraged to join forces, since they can double their take if they win.
This is not obvious from just reading the blurb, but the biggest part of the competition is purely to design such tools; implementation details are discouraged. Though a good design is quite hard, it doesn't take six months, especially if the designer in question has already bounced around such ideas. Perhaps the money will draw out a designer who's been itching but hasn't yet scratched.
Also, the deadline for the initial design submissions is March 31, so the most one could waste is ten weeks of planning. (And since it's just a design, there's no debugging!)
From the rules (emphasis is mine): "Designs based on existing tools, written in any language, are welcome. Such designs will be judged on the same basis as those written from scratch." So this is still possible.
You're right on with this one. The rules of the game change a bit when we're talking about quantities of money rather than merely number of listings in the CREDITS file.
Failing that, break the money up into $20k 'grants' and offer them to people who are already working in the right direction.
As I said, existing projects can compete. And the $100,000 is broken up into $2500 apiece for each of four finalists in the four categories, and then a second award of $7500 for the final winner in those categories and $2500 each for the runners up.
This competition is A Bad Thing.
Again, that's what I thought at first. But after reading the rules I had to agree it's not as dumb as it sounds. They're merely putting some money into trying to find the best design for some new tools (since they're claiming that the inherent design limitations of the existing tools are what they're trying to overcome). Then once the initial submissions are weeded through, they basically let the OSS model take over, even monetarily rewarding finalists who join forces and end up with a better final design.
Graham "Teach" Mitchell, computer science teacher, Leander HS
This is a real question, no offense meant, no flamebait. Isn't autoconf just there to work around a) the problems of the C programming languages with programming across platform bounds (e.g. sizeof(int) differs) and b) the differences between *ix systems (function call XYZ is not available on some systems, has another name on another system etc.)?
If so, wouldn't it be a better approach to use a standardized high-level programming language that is a bit more away from the operating system? I know C cannot be dropped immediately, but if more and more tools are built to cover its shortcomings...
OTOH, I like make, I'm using it on all kinds of platforms (Linux, Sun OS, Win32) to create programs in different languages or just to rebuild some LaTeX source.
How can one expect to actually call himself a developer if he can't even manage to understand Makefiles? IMHO the standard make does wonderfully what it was designed for, and the GNU make is half-way to creeping featurism. The consistency and interoperability of each of the system utilities adds elegance to Unix, and learning how to use them helps to keep the brain working! :) Stupidifying it is a mistake.
This isn't elitism, but I believe that replacing make(1) to make it more accessible to dumb people doesn't make sense, except if you dumbify the programming languages as well.
(I actually like autoconf, and I have been using it in some of my projects, but the Makefiles generated by automake are just too bloated. I use my own nice very nice recursive Makefiles to build and package the system, and it works quite well!)
Arrogance and ignorance are a bad combination.
I direct your attention to this page, where it is stated:
Mitre was a 501(c)(3) that broke up recently into two 501(c)(3) companies, Mitre and Mitretek.
Being a 501(c)(3) doesn't mean you are a traditional "charity", although you could indeed give tax deductible contributions to Mitre.
Although I can't provide a web reference for CTC, I recently attended a briefing at CTCs headquarters where it was stated plainly that CTC is indeed a 501(c)(3) corporation. In fact, the briefing materials did mention that you can make tax deductible contributions to CTC!
So, perhaps I was right initially. People do routinely libel RMS. You accused him of committing criminal fraud in his incorporation of the FSF as a 501(c)(3) entity.
Gosh, do you need more examples of 501(c)(3) corporations that compete with for-profit corporations? Many Hospitals and some HMOs are 501(c)(3) corporations. There are both 501(c)(3) and for-profit consumer counseling services. I could go on. Your assertion that 501(c)(3) corporations are not allowed to compete with for-profit corporations is absurd.
I suppose the rest of your unfounded conjectures and suppositions are about as reliable.
It's no surprise that RMS, the FSF and the GPL are so negatively represented in the Computer Industry Press when columnists routinely bluster authoritatively on subjects about which they know nothing.
-Jordan Henderson
I'm sure this has good intentions, but will OSS developers of the future have to compete against each other with duplicated efforts to write the best free software, in hopes of winning cash and prizes?
Sounds like some kind of game show to me...
--
--
E2 IN2 IE?
[From the Software Carpentry project coordinator]
Thank you all for your postings regarding the Software Carpentry project. To answer some of the points that have come up several times:
This is a design competition, rather than a programming competition. Good entries should be relatively language-neutral --- we believe that at the 5000-word level, the similarities between modern object-oriented languages (C++, Java, Python, etc.) are more important than their differences.
Designs based on existing tools are very welcome. If, for example, you think the only way to meet the criteria for the "build" category is to extend the syntax of standard Makefiles, then please submit that as a design. (However, for the reasons discussed in the FAQ, if your plan for an implementation is simply to provide a Python scripting interface to GNU Make, you'll have to convince the judges that there's no "pure Python" way to achieve the same ends.)
No, Software Carpentry is not a company looking for some publicity. The project is being funded by Los Alamos National Laboratory, who believ that computational scientists and engineers need easier-to-use software engineering tools, and administered by CodeSourcery, LLC, who believe that those tools would be of use to the whole Open Source community. The FAQ talks about LANL's reasons for funding the project, as does this article from Doctor Dobb's Journal.
Yes, one of the project's goals is to give up-and-coming software designers a chance to get some attention, just as architects and classical musicians do.
Yes, the competition is open to submissions from any country.
No, this is not part of some perfidious Pythonesque plot for world domination :-). We thought very seriously about using Perl for the implementations, but after teaching classes in both Perl and Python at Los Alamos National Laboratory, came to the conclusion that the latter had a gentler learning curve. (This is not meant as disparagement of Perl as a tool for full-time professional programmers, it is simply an empirical observation of computational scientists and engineers.) Neither Guido nor any other member of the Python development team had any part in setting up the project, choosing Python, or choosing the competition categories.
Don't get me wrong, I have nothing against python, or scripting in general, but these tools scream c or c++ to me.
I can understand wanting to standardize on one language to help make this "suite" a cohesive whole, but they've got to select the right tool for the job. Hell, I don't even have python installed on most of the boxes I use, but you can bet c and c++ will always be there.
From their FAQ... "Requiring that all tools be written in, or scriptable with, a single language will make it easier for newcomers to learn, use, and extend these tools."
How does does implementing a tool in a scripted language make it eaiser for newcomers to learn and use?
Oh well, other than that mandate this looks like a really cool project. I wish Software Carpentry all the luck on the world!
The same is true for all the programs they want to replace. At best, this competition will give some developer experience they can use for enhancing the standard tools. At worst, it will divert some free software talents towards enhancing and maintaining a little used set of alternative tools, rather than enhancing the tools used by the rest of the community. Most likely, someone will have wasted US$200.000.
That is a stupid remark, especially the time argument. Both cultures have excellent results, are fruitful to each others and are likely to stay with us for a while.
The lack of a BSD compiler is the result of no one interested enough so far in writing one. Not more not less. No reason why this could not change one day.
That's the point behind every pie-in-the-sky competition. When JFK got up on the podium and said he wanted a man on the moon, he was really standing in front of a hundred thousand engineers and saying, "I dare you." This group is doing the same thing.
Will we get a new make out of it? You and I would say no, but all it takes is a few kids sitting around somewhere listening to us laugh, and they get even more fired up.
The money isn't going to be what drags the programmers out of the woodwork - it's going to be the recognition that goes along with the money. (Sadly, the only way to get recognition in these IPO days is money, but that's another rant.) Ten years ago, someone could have waved a hundred thousand dollar check in front of Linus's nose, and it wouldn't have got us to this point any faster.
What's your damage, Heather?
So many of the previous posts are about why this is a Bad Thing because it diverts talent away from other things, why replace something that works, yada yada yada. The same could have been said of Linus' work on linux instead of contributing to BSD, etc. etc. Why are people so hung on "investing in open source (no, I refuse to capitalize open source)" and sticking with something "because that's how we've always done it?"
Here's a company willing to throw money at open source development and they get blasted. Who cares what they do. Does it affect you? NO. It doesn't. You do your thing, let Software Carpentry do theirs. If you love make, then use it. If you don't, that doesn't mean you're dumb or stupid as previous posters seem to imply, it just means that you would like an alternative to "make." Common folks, let's put the FREEDOM back in FREE code.
The open source zealots (and slashdotters in particular) are, ironically, (moderator: that's my own damn observation, not flame bait) among the most UNFREE people in this world. You seem to like any idea as long it jives with what you already believe. Live and let live.
More open source s/w will NEVER be a Bad Thing. After all, it will only result in more FREE code and that means more FREEDOM.
Certainly autoconf needs some work to tidy it up (particularly the generated configure script), but it's not as bad as they make out. As for it being the last major application to use m4, I guess they've forgotten about sendmail...
Similarly, make has some deficiencies, but again, it's mostly there, and what it does lack can be fairly easily added. It needs a simple GUI front end for newbies more than it needs rewriting.
Overall, it's not a bad idea, but I think that the effort should have been put into more pressing areas, such as having an embeddable editor API for X (so that individual apps can have an editable text area, and the users gets to choose which editor is actually used).
I can't help thinking that perhaps this is part of Guido's grand plan for Python to take over the world (not necessarily a bad thing in itself, but I'm always suspicious of things with political motives).
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Replace autoconf?
.dsp files! HA!), and opens the program up to porting to other platforms.
Replace make?????
These are robust, time-tested tools for creating software. If a better way existed to manage projects we (programmers in general) would probably have it by now.
I was just recently a member of a team that converted a very large project from Microsoft's hideous Visual Studio project (.dsp) files to autoconf, automake, and make. Why was this done? Because it's easier to use, more flexible (try telling MSVC to run lex and yacc and then compile the output files, using only
Now on the other hand, if all "Software Carpentry" wants is versions of autoconf and make ported to python, well, I guess it's not that silly, but why would you want to do that? The source code for these programs is extremely portable already. Implementing them in Python gains you nothing.
________________________________
- It encourages secrecy and non-cooperation between the various people working on projects like this. That transforms the usual model for OpenSource development from web-based cooperation into commercial competition.
- It doesn't encourage the best people to do the work because they'll say to themselves "I could work for six months on this - and then lose the competition and get nothing". Since they have already fostered a competitive model, that's a bad thing.
- The wording of the competition seems to prohibit developers from doing the rational thing which is to start with the best parts of the existing autoconf/make system and just fix whatever is perceived to be broken. Even worse, the people who might have been working on improving those projects are now dragged off to start again from scratch.
- Putting money into OpenSource teams has to be done with great care since it can often result in serious internal debates about who contributed most and who deserves what share of the money.
It would have been much better if this company had hired a good programmer for a year or two and had them work on 'fixing' whatever it is that they dislike in autoconf/make.Failing that, break the money up into $20k 'grants' and offer them to people who are already working in the right direction.
This competition is A Bad Thing.
www.sjbaker.org
Replace make?????
These are robust, time-tested tools for creating software. If a better way existed to manage projects we (programmers in general) would probably have it by now.
I was just recently a member of a team that converted a very large project from Microsoft's hideous Visual Studio project (.dsp) files to autoconf, automake, and make. Why was this done? Because it's easier to use, more flexible (try telling MSVC to run lex and yacc and then compile the output files, using only .dsp files! HA!), and opens the program up to porting to other platforms.
First, I completely agree with you that project configuration through MS Developers Studio projects is inferior to UNIX style configuration.
I had many fruitless discussions about this with some of my collegues (sigh). For some reason it is seems nearly impossible to convince people with a DOS/Windows background that the complicated make syntax is less a PITA than the fact that a myriad of parameters is hidden behind various corners of the MS Dev Studio graphical user interface.
My theory is that UNIX people love ASCII representations while the Windows crowds loves roaming GUIs. No idea why. But believe it or not there are people who for example can memorize an astounishing list of key/value pairs from the NT registry.
On the other hand one must admit, that it is hard to understand make without being familiar with the way the basic UNIX tools (awk, sed, grep, sh..) interact in the more complex make files.
My objection against make is not it's complicated syntax (which is only complicated because different levels of parsing - make's and sh's - intermix and regular expressions need a bit familiarity), but that it is slow.
This is not a failure of make itself but because of the way we traditionally organize programms into files and directories. In fact we use the filesystem as database, and query this database by giving paths.
I would expect a speed up, if we would move away from that organization into some kind of program database. A database that is very close to the semantics of the used programming language. Like a database of classes, makros, functions, globals etc So I expect that it would be possible to improve the speed of a make dependency aware construction tool in such a environment.
It would also solve some issues with C++ (especially template resolution).
However I have not seen a move away from that traditional C style project break up, compilation and linking to something which more resembles a database with tools on it yet.
Possibly because it would give up many benefits, the most obvious ones the ASCII representation and the flexibility and power of interaction with the UNIX simple-tools-work-together style. Which is a very good style. In fact it is a very clever hierarchical design.
Another reason is that the database thing would also have some other drawbacks. The slowness of make is part to scanning the file hierarchy. On the other hand this allows to add or delete components in an easy way. A database solution would insist of registring new items and eventually be more complicated to use here.
My objection to autoconf is mostly license based. The whole autoconf/automake/libtool toolchain is an impressive one, but it is inheritently bound to the GPL. If we ever want a true free BSD, we have to think of an alternative. But as with the system compiler, we have other, more important work to tackle with limited resources right now.