On Thu, Jul 24, 2008 at 02:16:30PM -0700, Micah Cowan wrote: > I'm not sure I agree on "people know them well" for Haskell. Scheme > /Lisp probably has a larger developer base than Haskell does.
Last time I looked, on Freenode, #haskell has around double the number of people that #scheme has. While I think more people know *of* Scheme and Lisp and understand the basics, my impression is that there is a lot more people actively writing Haskell every day than there are people actively writing Scheme every day. However, I wouldn't recommend Haskell as an extension language for an existing C-based application -- Haskell isn't designed for that role. (cf. Lua was designed for *exactly* that role.) > The only reasons I prefer Guile over those, is (1) it's much more > straightforward to use complex constructs, such as loops, within an > expression, and (2) GNU recommends it as first choice for scripting in > GNU projects (it's a GNU project, so would be "eating our own dogfood"). How many *active* projects use guile as an extension language, and aren't trying to get rid of it? How large is the guile user community (people writing code and libraries in guile)? How active is the guile developer community (people improving guile itself)? My impression is that *nobody* likes Guile. At all. Over the years, I've met *one* guile user who actively advocated it, and about twelve months ago he learned CL and admitted that he liked that much better. >>> I would really like to see scripting, but if it means an >>> emacs-like distribution of 100+ MB of scripting files and the >>> generation of a program which does everything well except what it >>> was designed for, then the point has been missed. $ printf '%s\t%s\n' `grep-aptavail -sInstalled-Size,Package -S --regex ^emacs22 | cut -d: -f 2` 412 emacs22-bin-common 4032 emacs22-common-non-dfsg 7120 emacs22-nox 7548 emacs22 7548 emacs22-gtk 13264 emacs22-el 51780 emacs22-common emacs22, emacs22-nox and emacs22-gtk are alternative front-ends, so the smaller two can be ignored in the count. The emacs22-el package is not used (since emacs22-common contains the byte-compiled versions), so it can also be ignored. Arguably most of emacs22-common should also be ignored, since it mostly constitutes applications that are written on top of Emacs and aren't needed by Emacs itself. Even if you count it, that's a total of (+ 412 4032 7548 51780) ==> 64MB, not "100+ MB". There's no real reason emacs22-common couldn't be split up into the "core" files needed to run Emacs itself, plus a separate package for applications. This isn't done because in general, nobody really cares about wasting 50MB of disk space. > I suspect we don't have to worry too much about that for Screen; but > part of that may depend on how choosy we are about what we let into the > Screen distribution. For my part, I don't currently see any reason why > we would need to provide any Scheme code with Screen whatsoever, apart > from probably a sample ~/.screenrc.scm, and perhaps other example > scripts. Sure, a powerful programming language means that folks could > write "Towers of Hanoi" or an email client within Screen; but that > doesn't mean we have to include it. And anyway, why would they want to > do that when they could just do it in Emacs? > > To be honest, implementing a Screen within Emacs makes almost as > much sense as giving Screen Emacs-like scriptability; Screen has > already duplicated quite a bit of Emacs' layout functionality and > such, some of it not yet as well as Emacs itself does it. But I > doubt anyone's interested in seeing that happen. :) ElScreen is an Emacs window session manager modeled after GNU screen by NaotoMorishima, http://www.emacswiki.org/cgi-bin/wiki.pl?ElScreen _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
