Gauche is an R5RS Scheme implementation that aims to be a handy tool for daily work. Quick startup, a built-in system interface, and native multilingual support are some of its goals. It has an OO system similar to STklos and Guile. It supports UTF-8, EUC-JP, and Shift-JIS multibyte encodings natively.
I've been using autoconf for quite a while, and recently have used automake. For me, those two tools are very different, with different goals and different design principles. And I always feel uneasy when people talk those two as if they're single tool.
In my personal opinion, autoconf's design is good, but the tool itself is badly abused. Its design is good because it achieves a simple goal (to generate bunch of shell commands to test features) by a simple method (macro expansion). Although the quantity of the generated script is indeed intimidating, it is simply built on top of small number of simple rules, so it doesn't take long for programmers to grasp the idea.
The beauty of macro is that you can mix the base language (shell script) and macro calls freely, which is very comfortable if you know shell programming. If you don't like the behavior of pre-defined macros, you can usually go by combining lower level macros with shell commands. The downside is that the generated script can easilly be bloated when macro is overused. I like to delegate complex test to a subscript or a small test program and to keep configure.in slim.
On the other hand, automake seems to do too many things at once. I assume it's main goal is to generate a lots of cliche of typical makefiles. However it also checks the distribution is sane and copies some "standard" scripts, which looks like a sign of creeping featurism for me, even though I can turn off the feature. Automatically generating the make rule to re-run "configure" again, as the author of the article complains, is another example of what automake does too much. Furthermore, if I don't like automake's default handling of primaries, I have to fall back to bare make rules, instead of extending existing primary behavior. I also like to have separate tool for creating distribution, instead of "make dist".
To be fair, I think automake works great if your package follows the way automake assumes. It only becomes a problem when you want to do some nontrivial tricks during a build process.
Re: Why is this taking the form of a religious debate?
I do agree that fixed-length character string representation is more efficient than variable-length one.
But I think it's not so bad as some claim.
> To be more clear about this, getting the
> Nth character of a fixed-char-size
> string is a constant-time operation (O1)
> and takes the same amount of time
> whether N is equal to 5 or 500. On the
> other hand, getting that same character
> in a variable-width-char string is a
> linear operation (On) and takes
> approximately one hundred times as long
> to get the 500th character versus the
> 5th character. The same holds true for
> substring operations.
I wonder if this is really an issue. When I process the text, what I do mostly is either scan the text sequentially, or use some search operation (like substring match or regexp match). Indices are returned as the result of the search operation so that I can extract the matched region from the string, but they're not necessary to be a character index---any kind of pointer does the job, and it's possible to create such pointer object that access any part of string in constant time.
I hardly see the case that I have to apply a pre-determined character index that is not a result of search operation. Maybe my experience is limited.
The searching operation for variable-length characters is slower than the one for fixed-length. That's an issue. But it's not as bad as O(N) versus O(1).
%Character replacement gets a lot more tricky as well.
Yes, it is tricky. But again, how common is the operation to substitute characters in place? When I use the programming languages that don't have automatic memeory management, I tend to do the in-place replacement as much as possible.
But in many situations the size of replacement string differs from the size of original region and I end up reallocating whole string.
If the language supports garbage collection, I even think that prohibiting in-place replacement is more beneficial,
because it allows me to share substrings without worrying that the shared storage will be modified inadvertently.
(I assume I use some kind of "string object" that has the pointer to the storage of actual string).
I don't have any concrete performance comparison between fixed- vs variable-length string representation.
Excuse me if my idea is irrelevant.