On Thu, Jul 24, 2008 at 8:22 PM, Trent W. Buck <
address@hidden> wrote:
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".
Comment withdrawn, the number was drawn from the last time I installed emacs, which was back when I used windows several years ago, and the emacs package for cygwin was 105mb and the native install was 120mb. Evidently it has been streamlined significantly in the meantime.
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
I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world.