Thanks for a good explanation. My day job is low-latency deeply embedded hard real-time (wow, that's verbose) so Java is obviously not my schtick (to anyone who asks, Android apps don't come even close to that situation). Due to the lack of adoption on the desktop, the slow startup, etc., I always wondered if so many people are writing Java, then what are they writing it for? Now I know.
Too often programmers get very egocentric and think that whatever type of code they develop, it's the be all and end all of programming. They forget about all the areas with different requirements. One size does not fit all, and never will. It's clear why Java may be very appropriate for what you do.
As klugey as it is, it may make perfect sense for them. Lots of old COBOL that works, even if nobody knows how anymore. Rewrites, or even refactoring, are not real popular when you transfer a gazillion dollars a day and can't take a day off. This may be the only way they'll ever be able to move away from COBOL.
Were you around in '95 when Java was first introduced? Seriously.
As for the marketing department, Silicon Valley style isn't so much about ads and whatnot, as creating hype and buzz (with the emphasis on hype). Sun did that in spades.
So, how does it figure out that main.cs depends on util.dll?
Depends('main.cs', 'util.dll')
Magically figuring out dependencies by looking for #include lines is a case of being good for one specific job, while failing to keep up with good old make as soon as you venture outside that one specific job.
Nope. SCons is a very general and extensible tool, that has many pre-written facilities for common cases, like finding header file dependencies in C/C++. You need something different? No problem. It also has facilities for creating your own Builders. And no, even for those, you don't write the Python from scratch. Don't feel like writing a Builder (though it's not that hard), and want a quick hack for one oddball case? No problem, you can do that too, including specifying the dependencies (see above).
Much of the scaling issue comes from SCons' default use of hashes to determine if a file has changed. That means in a large build, it has to read and generate a hash for every file. No big deal if you're re-building the whole thing, but a big slowdown if you've changed only one or two files. You can easily switch to timestamps though, ala make. It's not as robust, but it's good for modify-compile-test on big projects. For the real "gotta make sure everything is right", you can go back to hashes.
In this Lisper's experience, that more than makes up for the unique syntax
Thank you! It drives me nuts when Lispers defend the human readability of the "unique" syntax by saying things like "it's simpler" (true for a computer, a human not so much) and "you don't have to worry about operator precedence" (you can get the same effect in C by putting everything in parentheses, which makes it look like Lisp).
By contrast, you admit that it's a tradeoff. I don't have enough Lisp experience to say whether it's a worthwhile tradeoff, but it's a very solid argument.
nice until you sit on a system without Python (go to big compute clusters and things like Python are suddenly scarce)
I'll take your word for it about Python being scarce on such systems, but why? Installing Python is no big deal. If you can install autotools, etc., you can install Python.
As I heard it told, the reason Make (and Autotools) is the default despite all the suck is because all proposed alternatives suck more once you leave their original use-case.
You may have heard it told, but I've tried it, and I disagree. What do you mean by "leave their original use-case"?
Using a static data structure, as make does, to describe dependencies rather than executable code such as Python, as SCons does, is hugely important in reducing the complexity and increasing the understanding of large build graphs
This is a common misunderstanding about SCons. Just because the user-written construction files are Python files, does not mean that the user writes code to determine dependencies. SCons dependency specifications are just as static as they are in Make - typically just lists of the source. SCons figures out all the dependencies from there.
Human need contrast, but all lisp-likes provides is data structure like XML. (Haha, this comparison must make LISPers mad.)
I hope you realize that you've just started a war that will make the Wars of the Reformation seem tame. Get out of Bohemia while you can! I'm staying neutral.
You could always use Haskell. You have a choice between {}; C-style syntax, and Python style whitespace. Ok, that's a bit of a kluge, but in practice everyone uses the whitespace anyway, so it's not a problem.
If you write a lot of Python in an SCons build file, then you're doing something wrong. The capabilities, including things like checking for header file dependencies, are all built in. It even knows something about commonly used tools, like gcc, so you can start out by saying "use the usual gcc stuff".
Just because your declarations and whatnot are written in Python, doesn't really mean you have to actually write a Python program - that's already been done for you. Sure you can abuse it, but what powerful tool can't be?
First, Makefiles are essentially a declarative language. Second, even though the utility is written in Python, and your "make files" are also in Python, SCons largely uses a declarative approach. You tell it what you have to build, and how to build it, then let it figure out the order and so forth.
Try SCons. It blows the doors off of Make, and once you get the hang of it, is much simpler to use. It's also written in Python, and you write the "build files" (equivalent to make files) in Python. Real honest-to-goodness Python, not just some restricted kind-of-like Python stuff.
The right thing to do is just ban the use of the @%#^! tab character. You can't do that w/ make, but you can with just about everything else. I once wrote a pre-checkin validation script for a VC system, and it would reject any file (of the appropriate source types) that contained a tab.
No matter what you do to it, Make is an antiquated pig. No offense to the GNU folks, who generally make the best versions of the traditional *nix utilities, and yes, you do need to keep Make around for backwards compatibility, yada, yada, yada.
What's really needed is a ground up re-think of how to create a build utility. A number of folks have tried it. I used to use SCons, and before that it's Perl based predecessor, Cons. The reason I'm not using them now has nothing to do with the software, which I though was excellent. The project lead's idea of alpha is what some people call final release.
I suspect the biggest problem to a widely used Make alternative is the sheer variety of options out there. Nevertheless, what are other people's experiences with build utilities other than Make?
Slashdot Mirror
ISO-8859-1
The one with those funny marks on the letters? Bah. ASCII. The eighth bit is just a spare. If you can't do it in English, then it isn't worth doing.
Thanks for a good explanation. My day job is low-latency deeply embedded hard real-time (wow, that's verbose) so Java is obviously not my schtick (to anyone who asks, Android apps don't come even close to that situation). Due to the lack of adoption on the desktop, the slow startup, etc., I always wondered if so many people are writing Java, then what are they writing it for? Now I know.
Too often programmers get very egocentric and think that whatever type of code they develop, it's the be all and end all of programming. They forget about all the areas with different requirements. One size does not fit all, and never will. It's clear why Java may be very appropriate for what you do.
As klugey as it is, it may make perfect sense for them. Lots of old COBOL that works, even if nobody knows how anymore. Rewrites, or even refactoring, are not real popular when you transfer a gazillion dollars a day and can't take a day off. This may be the only way they'll ever be able to move away from COBOL.
Were you around in '95 when Java was first introduced? Seriously.
As for the marketing department, Silicon Valley style isn't so much about ads and whatnot, as creating hype and buzz (with the emphasis on hype). Sun did that in spades.
so heavily optimized that often Java apps can even match the performance of C programs
Benchmarks?
destroying this wealth and peace
Describing 20th century Europe as peaceful is, um well, peculiar.
Benchmarks?
I've heard the "Java can be faster than C/C++" many times, but have never seen benchmarks that back it up.
Leaving aside its pros and cons, the biggest reason that Java initially caught on was Sun's marketing department.
First-World Slavery still kinda feels like slavery.
Don't exaggerate - it's more like indentured servitude.
So, how does it figure out that main.cs depends on util.dll?
Depends('main.cs', 'util.dll')
Magically figuring out dependencies by looking for #include lines is a case of being good for one specific job, while failing to keep up with good old make as soon as you venture outside that one specific job.
Nope. SCons is a very general and extensible tool, that has many pre-written facilities for common cases, like finding header file dependencies in C/C++. You need something different? No problem. It also has facilities for creating your own Builders. And no, even for those, you don't write the Python from scratch. Don't feel like writing a Builder (though it's not that hard), and want a quick hack for one oddball case? No problem, you can do that too, including specifying the dependencies (see above).
So what does scale well?
Much of the scaling issue comes from SCons' default use of hashes to determine if a file has changed. That means in a large build, it has to read and generate a hash for every file. No big deal if you're re-building the whole thing, but a big slowdown if you've changed only one or two files. You can easily switch to timestamps though, ala make. It's not as robust, but it's good for modify-compile-test on big projects. For the real "gotta make sure everything is right", you can go back to hashes.
That link gives a 404.
In this Lisper's experience, that more than makes up for the unique syntax
Thank you! It drives me nuts when Lispers defend the human readability of the "unique" syntax by saying things like "it's simpler" (true for a computer, a human not so much) and "you don't have to worry about operator precedence" (you can get the same effect in C by putting everything in parentheses, which makes it look like Lisp).
By contrast, you admit that it's a tradeoff. I don't have enough Lisp experience to say whether it's a worthwhile tradeoff, but it's a very solid argument.
nice until you sit on a system without Python (go to big compute clusters and things like Python are suddenly scarce)
I'll take your word for it about Python being scarce on such systems, but why? Installing Python is no big deal. If you can install autotools, etc., you can install Python.
As I heard it told, the reason Make (and Autotools) is the default despite all the suck is because all proposed alternatives suck more once you leave their original use-case.
You may have heard it told, but I've tried it, and I disagree. What do you mean by "leave their original use-case"?
Using a static data structure, as make does, to describe dependencies rather than executable code such as Python, as SCons does, is hugely important in reducing the complexity and increasing the understanding of large build graphs
This is a common misunderstanding about SCons. Just because the user-written construction files are Python files, does not mean that the user writes code to determine dependencies. SCons dependency specifications are just as static as they are in Make - typically just lists of the source. SCons figures out all the dependencies from there.
Human need contrast, but all lisp-likes provides is data structure like XML. (Haha, this comparison must make LISPers mad.)
I hope you realize that you've just started a war that will make the Wars of the Reformation seem tame. Get out of Bohemia while you can! I'm staying neutral.
You could always use Haskell. You have a choice between {}; C-style syntax, and Python style whitespace. Ok, that's a bit of a kluge, but in practice everyone uses the whitespace anyway, so it's not a problem.
If you write a lot of Python in an SCons build file, then you're doing something wrong. The capabilities, including things like checking for header file dependencies, are all built in. It even knows something about commonly used tools, like gcc, so you can start out by saying "use the usual gcc stuff".
Just because your declarations and whatnot are written in Python, doesn't really mean you have to actually write a Python program - that's already been done for you. Sure you can abuse it, but what powerful tool can't be?
First, Makefiles are essentially a declarative language. Second, even though the utility is written in Python, and your "make files" are also in Python, SCons largely uses a declarative approach. You tell it what you have to build, and how to build it, then let it figure out the order and so forth.
That's the way some people have to do it, but it's a kluge. SCons is much cleaner and easier to use. Also cross-platform.
Try SCons. It blows the doors off of Make, and once you get the hang of it, is much simpler to use. It's also written in Python, and you write the "build files" (equivalent to make files) in Python. Real honest-to-goodness Python, not just some restricted kind-of-like Python stuff.
Are those build utilities just for Java, or do they handle other languages?
Just like python!
The right thing to do is just ban the use of the @%#^! tab character. You can't do that w/ make, but you can with just about everything else. I once wrote a pre-checkin validation script for a VC system, and it would reject any file (of the appropriate source types) that contained a tab.
No matter what you do to it, Make is an antiquated pig. No offense to the GNU folks, who generally make the best versions of the traditional *nix utilities, and yes, you do need to keep Make around for backwards compatibility, yada, yada, yada.
What's really needed is a ground up re-think of how to create a build utility. A number of folks have tried it. I used to use SCons, and before that it's Perl based predecessor, Cons. The reason I'm not using them now has nothing to do with the software, which I though was excellent. The project lead's idea of alpha is what some people call final release.
I suspect the biggest problem to a widely used Make alternative is the sheer variety of options out there. Nevertheless, what are other people's experiences with build utilities other than Make?