This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Jay Glascoe writes: ... > > Hmm. I think your definition of slow and mine are different. Could > > you clarify what you mean when you say 'slow'? How do you account for > > the performance of Stalin? ... > the functional guy is sleek and pretty, but those "vector->list" and > "append" bits are performance killers. I think the issue is that a functional programming style makes for a lot of copying (with some associated garbage collection). Computers work much more quickly on in-place algorithms, where no copying is necessary. And, deep down, (all?) computers are imperative. However, programming in a functional style can lead to great optimizations, because the behavior can be predicted before runtime much better. I imagine Stalin uses this to its advantage(?) Distributed programming also benefits from this -- I'm sure there are other benefits as well. But Guile isn't compiled or optimized, so the advantages of functional programming are mostly stylistic/aesthetic. As to the size of C/Perl/Guile programs, I think a lot of it has to do with the libraries. I find the various C libraries to not be able to integrate themselves into the language very nicely at all. Perl does this much better, not to mention having so much functionality built right into the language. I also find that shell scripting (who's library is the programs on my machine) works very nicely for me. And what could be shorter than an Awk script for a job which Awk is good at? But now I've gotten to thinking about libraries. I'm not sure what the Scheme environment really is -- it's stuck in the elegance of its mathematical roots. But *practical* elegance is to make a system whereby a programmer can work in a rich environment while maintaining certain things: * Readable programs: both a matter of making all function calls as meaningfully named as possible -- where namespace-declarations *aren't* meaningful, but short descriptive names are; making the library functions fit well into the structure of the code the programmer is writing -- avoiding wrapping everything in lambdas and allowing the code to be structured as best fits the problem. * Transparent code: all aspects of the code can be inspected and understood, including the library functions. * Mnemonic: a rich environment means having a lot of functions. Remembering each one and the forms it takes will get difficult without some means of managing it. Keyword arguments are (IMHO) a great way of doing this. * Documentation: both reference -- a listing of functions and what they do; and concept-based -- what you want to do and the functions (and data structures) provided to help you do those things. Optimally, closely integrated with the process of writing code, e.g., a good Emacs environment. I don't think Guile does particularly well on any of these. Documentation, of course, we all know about and know how to fix. The other's aren't so obvious. There's two issues: what could a good library system in Guile fix, and what could language extensions in Guile fix. I wouldn't stand behind language extensions -- when does it stop being Scheme and become some little brother of Common Lisp? But maybe there's a way to do these things in Scheme and I just don't see it. Readability: Scheme has a way of leading to long expressions. When you get down to it, any functional procedure will be made up of one (long) expression. That's hard for humans to parse. I like the highlighting that DrScheme does -- when you are at a open or close parenthesis, it highlights (without being obnoxious) the expression that is enclosed by that parenthesis. The passive nature of the highlighting is what makes it nice. (The static code analysis that DrScheme does is also nice, but I'm not sure it's helpful enough to warrant the complexity of implementing the interface) There might be other ways of representing the Scheme to make it more readable. But this is mostly a complaint about Scheme as a language, not the libraries. Along the library side, it would be nice to think about the naming system for all the library procedures and coming up with a consistent, concise, and meaningful system for naming (this also helps mnemonics). I wish I could give a concrete example, but I haven't really worked with any complex libraries in Scheme. However, what I haven't seen that I think is important is that Guile should be viewed as including not only the core language, but a set of modules which provide commonly-used functionality. These are too essential to the language and it's practical use too simply be add-ons. A rich set of datatypes could also be a powerful addition. Make dictionaries, not hash tables -- mostly that's just a matter of terminology, but I think it's important. As a programmer, I don't care about the fact that hash tables use hashing, I care about the fact that hash tables are a collection of values indexed by keys. Transparent Code: Well, write as much of it in Scheme as possible. If, for performance reasons, it isn't written in Scheme consider providing a reference implentation which does the same thing as the C (just slower). If/when debugging in Guile becomes pleasant, allow people to actually use these reference implementations so that they can access everything their code does to a fine degree of granularity. For instance, if you provide a bad hash function to a hash-table, the error (or worse: the lack of error) might pop up inside some hash-table function. Being able to inspect the innards of that function will make it much easier to find the bug. Mnemonics: As with readability, some deep thought about the naming system will help. Also, keeping the number of functions to a minimum is also important. I think keyword arguments could be of great help here. They allow a very general function (with lots of parameters) to masquerade as a less general function. Also, argument order is almost always arbitrary (and thus hard to remember): keywords help solve this. I think they could be important enough to be used heavily in Guile, even if it is (in effect) a language extension. An object system could also help. With dynamic typing, it seems so close... all the compromises are there (space, time, lack of static analysis), but the benefits are not completely reaped. An object system allows a function which can work conceptually for many datatypes to actually do so, without cond statements (which are ugly). I guess, to me, it's a question of Guile being just a language (which it is) or an entire environment (which it isn't -- at least yet). My, I wrote a lot more than I was expecting to. <-------------------------------------------------------------------> < Ian Bicking | bickiia@earlham.edu > < drawer #419 Earlham College | http://www.cs.earlham.edu/~bickiia > < Richmond, IN 47374 | (765) 973-2824 > <------------------------------------------------------------------->