At the risk of inviting ridicule, I have a proposal and am looking for
feedback, suggestions, tips and pointers that can help me out.
I've been a LISP-lurker for a while now, attempting to learn LISP and
keeping an eye on what's going on everywhere. Windows is my platform
of choice (for various reasons) and I've found that Windows is a tad,
um, underserved when it comes to Common LISP and somewhat newbie-
unfriendly (it's a little better for Scheme but I'm not interested -
much - in Scheme just yet).
After playing with various implementations, IDEs, libraries, etc. on
Windows (or rather, trying to play with them), it's all rather grim.
ASDF-INSTALL is not Windows-friendly (who was it that said that Common
LISP didn't have to rely on external utilities? Hah!), various major
libraries don't run on Windows are or a nightmare to get working
(MCCLIM anyone? Yes, I know it's been done but documentation is, well,
fragmented), some major implementations have only partial Windows
support (SBCL? Yes, I know they're working on it: kudos to those brave
fellows/gals).
In short, for just about any problem you encounter on Windows, there
*is* a solution of some sort, but finding that solution and then
getting it to work, in most cases, is a challenge at least. I think
this explains the newbie-fright-syndrom that pops up so often.
I've looked at various attempts to resolve some of this (Gardeners',
LispBuilder, etc.) but I think all of these are slow in getting
established because it's just too big a challenge: they all try to do
all three major platforms at once (Mac, Linux, Windows). Although I
admire the intent, and some of the things already achieved are very
impressive, I don't think it's practical to try to do this (yet).
Rather than bombard communities like these with a zillion questions to
solve individual problems, I thought I'd get of my behind and try to
help improve the situation, following examples of some of the leading
lights here.
So, I propose the following: that I put together a turn-key Common
LISP installation package that includes most of what the average
newbie would want. Below is a list of my current ideas for that and
I'm looking for feedback, suggestions, pointers to things that may be
of use, etc. I will try and do most of the actual work involved in it
(installer, configuration, patches, testing, hosting, etc.) but no
doubt I'll have to ask some of you for help at a few points (I'm far,
far, from being LISP-fluent).
Note: most of this idea borrowed from Peter's LispBox, naturally. Note
that this may grow to be a very large download so I'd need to look at
pulling in things during install on-demand instead as well.
I imagine multiple packages or a single packages but with choices (the
former is probably easier to build, the latter easier to maintain once
built: TBD). The main point is to avoid newbies having to go hunt for
packages/downloads to get simple things done (simple as in what *they*
are used to being simple: putting up "Hello, world" in a dialog box
should be a no-brainer (and bundled as working example)). Same for
networking (usockets?), multi-threading (need that for proper GUI work
anyway), database access, etc.
CONTENTS:
One or more IDEs or IDE of choice (at least GNU/X/W32-Emacs, with
optionally easily-activated VImpulse thrown in for VI die-hards;
others may be ABLE, Eclipse+Cusp, etc.)
One or more Common LISP implementations:
CLISP - for the size-sensitive
SBCL - for the speed-freaks; may need to contribute to Win32 port to
make this happen
ECL - for the C/C++ lovers
Lispworks Personal Edition - coz' it's good
Allegro Express Edition - ditto
Corman Common LISP - well, it's the only Windows-only
implementation; can hardly leave that out, now, can i?
A set of (optional) packages (idea borrowed from Edi's StarterPack).
General requirements: must work on Windows (but I'd be willing to
contribute patches to make that happen for important ones), must be
easily installable (which means handling dependencies), should be
downloaded on-demand (preferably pulling them from Cliki or home site
etc. on demand, so may need to hack ADSF-INSTALL for Windows or use
CLBUILD or ask Edi how he did it, etc.).
A GUI built-in/ready-to-go. I'd prefer it to be something like Cells-
gtk, which provides two good things in one but it's a hairy beast to
get up and running (esp. on Windows). Alternatives: MCLIM+GTK, MCCLIM
+Graphics-forms, LTK, RNDZL with pre-built GUI examples, wxCL (yes, I
know it's dead), etc. Will need to figure out how to bundle the
servers for these if need be.
Other packages: regular expressions, rational (for the current times)
path/filename abstraction, networking, database access, containers,
series, utilities, Qi, CLOCC, etc. Main requirements is that they
should be complete (i.e. not half-finished) *or* stable and still
being maintained.
CONFIGURATION
Everything should work out-of-the-box, meaning that after installation
(and the choices the user made during that), starting up the IDE
should be a double-click affair, packages should be pre-loaded or
hints should be provided on how to load them (e.g. could be menu in
the IDE).
There should be ready-to-run examples that demonstrate just about
every basic facility and package. Examples must be discoverable
(another menu?).
There should be an easy way to deploy a program: this requires careful
balancing of the whole program-as-you-go/image/core model with the
build-an-executable-and-send-it-out model: both should be obvious,
supported, explained and demonstrated.
Some sort of tutorial should be bundled (maybe Peter's book, or Lisp
In Spells or something: copyright issues here, so must get appropriate
permissions). Hyperspec (CLtL?) bundled and integrated.
Anyway, that's about it. I'm sure I've forgotten a lot (tell me!) and
I'm over-reaching (will probably need to trim some of this down so I
my addled brain can handle all of it). This is not something I'm
aiming to have up-and-running in a few weeks; this will take some
time. I think it may be best to start with a single IDE, single
implementation, with GUI and multi-threading and some other minor
packages, examples and tutorial pre-installed; that will already be a
major step.
Some reality-check questions:
Is this is good idea or should I instead direct my efforts to helping
some of the other somewhat similar initiatives? If so, which one(s)?
Are there any download stats for Lisp-in-a-Box, Peter's LispBox, Edi's
Starterpack, etc. Are these things popular?
As said, I'll probably need to trim it down a bit. What do you think I
should drop?
Is this better as a Gardeners project? If so, why? If not, why not?
Anybody willing to help?
Any and all feedback welcome (especially if you think I'm crazy to
even try it).
Ben.
> So, I propose the following: that I put together a turn-key Common LISP
> installation package that includes most of what the average newbie would
> want. Below is a list of my current ideas for that and I'm looking for
What's wrong with Lispbox? http://www.gigamonkeys.com/book/lispbox/
And once the user has learned enough Lisp so that Lispbox is not enough
any more, he/she will know enough to move on.
HTH,
Tamas
> Any and all feedback welcome (especially if you think I'm crazy to
> even try it).
Not really directly answering your question, but I plan for the next
release of ABLE to make it more of a complete starter pack style
install. So you would get a Lisp, an IDE, GUI, ASDF and a set of
common (working!) libraries with instructions for how to extend it
with other libraries. Although people think they want a single click
exe and that's what I eventually caved in to pressure and provided,
this way will make more sense, very much along the lines you have
suggested (and along the lines of Lispbox.
I certainly think alternatives are good though and concentrating on
the Emacs/Slime side would make sense as many people want that based
on years that they've invested in Emacs before looking at Common Lisp.
I'm not sure how up to date Lispbox is but maybe it's a good place to
start?
Good luck!
--
Phil
http://phil.nullable.eu/
bobi
There's nothing wrong with LispBox and it is, in fact, how I got
started myself (I owe a lot to Peter's efforts for his book as well as
LispBox).
But I worked through all of his book using his LispBox (CLISP version)
and then wanted to try the usual: customise Emacs a bit, get a GUI
going, connect to a DB, etc. I succeeded in doing all of this in the
end, but it took me days to get it all together and working.
For doing simple things, this should not be necessary: CL is so
powerful, and ostensibly designed or well-suited to making the
impossible doable and the difficult easy (I'm quoting here), so it
should be possibly to deliver a start-up environment that is easy to
use as well as complete.
Peter's LispBox is easy to use, but is not complete from a newbie's
point of view. I hope to improve that.
Ben.
Jumping in at random, I am sorry, this thread has to stop, it contains a
contradiction:
The OP suggests that ACL Express is in play. With that you get an IDE
including an editor (Windows-y or Emacs-y) and a project manager, a GUI,
Allegrograph, embedded Prolog, AllegroServe, WebActions (way cool), html
gen, documentation, tutorials, and all the stuff I left out.
LW Trial comes in a close second and was also in play, so the proposal
makes no sense. Take those off the table and it makes sense to have that
huge undertaking, or, looked at another way, why the hell would anyone
take those off the table?
kenny (hoping some FSF nutjob says something)
Hah! My first Kenny "Start writing apps!" Tilton post! I'm honored ;-)
I'm not an FSF nutjob (thogh arguably I am a nutjob in the general
sense), but I'm just looking at reality: Allegro and Lispworks are
availbale (and just as good) on Linux as well, but still we have
several non-commercial Common LISP implementations on Linux, one of
which seems to be doing very well (SBCL) and probably rivals Allegro/
Lispworks in terms of number of users.
So, obviously, various people have reasons (or think they do) to
choose non-commercial over commercial, even if the commercial ones are
available for free (albeit crippled). This may be a matter of
religion, practical considerations or the toss of a coin: I don't
really care. Fact is, lots of people ask for free/Free implementations
so I don't feel I should ignore it. At the same time, I feel I may be
doing a disservice if I don't point newbies to the wonderful
commercial versions so they at least know what a professional
environment brings.
I'll grant you that packaging up Allegro and Lispworks in a LispBox-
style pre-loaded things is a stretch since they come with so much
already built-in but for the sake of cross-implementation
compatibility it may be worth doing (Peter did it and he's likely much
smarter than I am; he must have had his reasons).
But as I said, I'll probably need to trim things down and perhaps
Allegro/Lispworks should be offered in a different way or maybe only
pointed to rather than packaged up. At this point, I'm not locking
things down so I'm open to opinions and suggestions.
Ben.
That's excellent news! I used ABLE and loved it for its simplicity and
effectiveness. Improving ABLE would be a great thing to happen to the
community.
I don't know how you built ABLE (i.e. what's under the hood), but
since our efforts overlap we may be able cross-pollinate somewhat,
especially when it comes to getting packages wrapped up, stable and
working, bundling tutorials and such. I'll be happy to discuss once my
direction is a bit more firm.
Ben.
> So, obviously, various people have reasons (or think they do) to choose
> non-commercial over commercial, even if the commercial ones are
> available for free (albeit crippled). This may be a matter of religion,
> practical considerations or the toss of a coin: I don't really care.
> Fact is, lots of people ask for free/Free implementations so I don't
> feel I should ignore it. At the same time, I feel I may be doing a
> disservice if I don't point newbies to the wonderful commercial versions
> so they at least know what a professional environment brings.
Look at the title of the thread - the potential users of this already use
a commercial OS, one with a nasty company behind it. I don't see why
they should avoid commercial Lisps as a matter of principle, especially
since vendors offer free trials. And no, they are not really "crippled",
the restrictions should not be binding to a newbie for years.
People who insist on free/libre CL implementations/environments while
they are using Windows are making little sense.
Tamas
> On Nov 10, 4:49 am, Tamas K Papp <tkp...@gmail.com> wrote:
>> On Sun, 09 Nov 2008 18:10:29 -0800, jvdvyah wrote:
>> > So, I propose the following: that I put together a turn-key Common
>> > LISP installation package that includes most of what the average
>> > newbie would want. Below is a list of my current ideas for that and
>> > I'm looking for
>>
>> What's wrong with Lispbox? http://www.gigamonkeys.com/book/lispbox/
> 1.emacs- another obstacle for new users 2.clisp ( not a part of the big
> 4 - so lack of libraries) ACL users will use ACL ide.
If Emacs is an obstacle, perhaps they should not be programming at all.
I am not saying that everyone should be using Emacs, they can use
whatever environment they like. But if they want free tools, yet they
are unable/unwilling to invest a bit of time in them, then tough luck.
Tamas
This discussion will go nowhere but here's my two bits anyway. I don't
care if people are "right" or "wrong" asking for specific things, I
also don't care if they make sense or not; their "sense"is not mine I
don't presume to know what they *should* do or want.
All I see is that newbies have issues and there's a definite demand
here. If we can reduce the number of stupid newbie questions we get
(leaving only the smart ones :-)) and grow Common Lisp at the same
time, that's good enough to put some effort into it for me.
Ben.
Welcome!
> Scheme but I'm not interested
I am sorry.
> So, I propose the following: that I put together a turn-key Common
> LISP installation package that includes most of what the average
> newbie would want.
That sounds really interesting. You should nail down exactly who is
your intended audience, the exact problems that they face, separate
your steps from your goal, define your expectations on the audience,
and define your vision for what your project will and will not "be".
Focus on narrowing the scope rather than expanding it. Here is one
vision:
1. My audience is beginners to Common Lisp.
2. My goal is to lower the barrier to entry for people to study,
learn, and practice Common Lisp.
3. My expectation is that once the audience gains sufficient
experience and confidence, they will move on to their own preferred
solution (Emacs/Slime, Lispworks, VI, echo...).
Without that I fear you will suffer:
1+2. Satisfying no one, there are too many needs.
3. Providing an all-in-one professional (free or not) distribution has
got to take a lot of work, are you up for it?
> Some reality-check questions:
>
> Is this is good idea or should I instead direct my efforts to helping
> some of the other somewhat similar initiatives? If so, which one(s)?
It is a good idea because it is your own idea. To top it off, you are
getting feedback. Sure, maybe people will tell you it is stupid and a
waste of time, but that is a compliment compared to talking behind
your back. If I were you, I would just download Lispworks or DrScheme
and be done with it.
> As said, I'll probably need to trim it down a bit. What do you think I
> should drop?
As much as humanly possible. You should define an achievable goal,
build a solid foundation, and grow from there.
> Anybody willing to help?
There are always people who are willing to help.
> Any and all feedback welcome (especially if you think I'm crazy to
> even try it).
Even if you are crazy, you will learn a lot from the experience (win/
lose).
Good luck!
bobi
>
> Tamas
> > Scheme but I'm not interested
>
> I am sorry.
It's not that I don't like it (I worked through SICP using a Scheme),
but there are a few batteries-included Scheme implementations so the
newbie threshold is already lower. In addition, Scheme's problem seems
to be incompatibility issues between implementations which is a
problem I don't think I can address.
> 1. My audience is beginners to Common Lisp.
> 2. My goal is to lower the barrier to entry for people to study,
> learn, and practice Common Lisp.
> 3. My expectation is that once the audience gains sufficient
> experience and confidence, they will move on to their own preferred
> solution (Emacs/Slime, Lispworks, VI, echo...).
Good summary of goals: I can add "on Windows" to number two to further
narrow it down.
> 3. Providing an all-in-one professional (free or not) distribution has
> got to take a lot of work, are you up for it?
Don't know, but I can try (depends on the scope which may be a problem
as you rightly point out). Phil, Peter and Edi all put together
something that's instantly useful and usable; I just want to take
those ideas one step further to get the best of each combined into
one. I may well fail but it won't be for lack of trying :-)
> As much as humanly possible. You should define an achievable goal,
> build a solid foundation, and grow from there.
Good advice.
You sounded like someone who got off on organizing things, documenting
them, and making them manageable more than Actually Programming so you
were spared the flamethrower. And the plan is to sucker you eventually
into doing something more useful and finite like documenting Cells, but
I do not want to tip my hand.
>
> I'm not an FSF nutjob (thogh arguably I am a nutjob in the general
> sense), but I'm just looking at reality: Allegro and Lispworks are
> availbale (and just as good) on Linux as well, but still we have
> several non-commercial Common LISP implementations on Linux, one of
> which seems to be doing very well (SBCL) and probably rivals Allegro/
> Lispworks in terms of number of users.
>
> So, obviously, various people have reasons...
Sure. They place no value on their time*, so they think they are getting
something for free. Why are bars packed on buy one get one free night?
* I cannot argue with them.
>... (or think they do) to
> choose non-commercial over commercial, even if the commercial ones are
> available for free (albeit crippled). This may be a matter of
> religion, practical considerations or the toss of a coin: I don't
> really care. Fact is, lots of people ask for free/Free implementations
> so I don't feel I should ignore it. At the same time, I feel I may be
> doing a disservice if I don't point newbies to the wonderful
> commercial versions so they at least know what a professional
> environment brings.
>
> I'll grant you that packaging up Allegro and Lispworks in a LispBox-
> style pre-loaded things is a stretch since they come with so much
> already built-in but for the sake of cross-implementation
> compatibility it may be worth doing (Peter did it and he's likely much
> smarter than I am; he must have had his reasons).
Well to do a universal free as in beer package he had to start with
Emacs+Slime+ASDF so by the time he got to the Lisp it was no time to
start talking about the LW IDE or the ACL IDE (where it exists).
>
> But as I said, I'll probably need to trim things down and perhaps
> Allegro/Lispworks should be offered in a different way or maybe only
> pointed to rather than packaged up.
Yes, for Windows I would certainly point them to the ACL and LW trials
and then start on the deets of getting free environments going, telling
those choosing the ACL/LW options to skip to chapter 42 where the free
stuff setup will have been completed to learn how to beat ASDF into
submission so you can load o/s libs.
kxo
Feel free, it is your time. I admire your generosity, I prefer to spend
my coding time on projects that _I_ find useful.
Good luck,
Tamas
>> If Emacs is an obstacle, perhaps they should not be programming at all.
> Tell that to pg he's using vi. Many great programmers don't like emacs,
I didn't say that they have to like it. I think that PG and other vi
users could easily master Emacs, they just chose to use something else,
fine with me. But those who are not _capable_ of learning either are
perhaps not well suited to programing.
> this weirdo emacs thingie came into picture? Oh now I have to install
> linux to have a free implementation without heap limit, no way, cl has
You mean that the heap limit is relevant to people who are just trying
out the language? Give me a break.
Tamas
I wanted to add this: from what I have seen, free software projects where
the author is writing software explicitly for "someone else" start out
with enthusiasm but die sad and neglected. To make a project
sustainable, you have to be paid to do it or it has to provide some
benefit to you. The warm fuzzy feeling people get from helping others
usually doesn't last long enough.
Tamas
> I wanted to add this: from what I have seen, free software projects where
> the author is writing software explicitly for "someone else" start out
> with enthusiasm but die sad and neglected. To make a project
> sustainable, you have to be paid to do it or it has to provide some
> benefit to you. The warm fuzzy feel
ing people get from helping others
> usually doesn't last long enough.
Yes, in my experience *all* free projects die at some point or another
(or morph into something different). I only intend to get this done
and then sustain it for as long as I'm willing/able. Maybe at some
point I'll stop (or die or whatnot) and it will die with me. Or maybe,
at that point, there are a few people willing to keep it going without
me. I don't know and at this point, it's irrelevant.
> Look at the title of the thread - the potential users of this already use
> a commercial OS, one with a nasty company behind it. I don't see why
> they should avoid commercial Lisps as a matter of principle, especially
> since vendors offer free trials. And no, they are not really "crippled",
> the restrictions should not be binding to a newbie for years.
>
> People who insist on free/libre CL implementations/environments while
> they are using Windows are making little sense.
>
> Tamas
Tamas,
Your response is non sense too.
Sometimes people have not choosen to use Windows, but are constrained too by
their work.
I'm using a lot of langages on Windows, and I don't pay anything to use them
(take C++, Ruby, Python, Perl, etc). Why should I pay for Lisp then ?
Good luck in your project Ben, for sure I'm a potential user.
YES PLEASE!
I am a Lisp noob, working on Windows. I am your intended audience. And
I sorely want what you describe. And if you're able make it while
staying away from emacs, I will give you my first born.
Others have asked questions why this would be desirable. I'll try to
answer from my perspective.
Q: Why wouldn't Windows users just run a commercial version?
A: Same reasons non-windows-users don't run a commercial version. I'm
a piss-poor student. I won't pay for a Lisp I'm not going to be using
commercially, and odds are I won't be using it commercially before
I've learned the language. And any free trial version I've seen has
been crippled in a way that makes it unusable for me. Yes, I will use
more heap than that limit (in fact I have, in my ~4 months of Lisp).
Q: Why not emacs?
A: I don't want to start a flame war. However, emacs' apparent
popularity is a mystery to me. I take it it's supposed to be text
editor. My minimum expectations for text-editor is for it to have ctrl-
c/ctrl-v and a proper undo function. Emacs has neither. I can
configure it for cut and paste, but I think I'm stuck with its undo
function. I could go on. I get that emacs can be configured to work
right, but I don't want to configure it. Any text-area widget from a
GUI toolkit already meets these requirements. When I have to configure
something to do ctrl-c/ctrl-v, that just screams "Fuck you windows
user", to me. I can imagine that that is on purpose.
Q: Why not LispBox and Able?
A: LispBox gave me a set up that allowed me to write and evaluate Lisp
code, and I don't know what I'd do without it. Still, I was stuck with
emacs. It also seems to be a stack of lots of different software that
no one fully understands. See my thread on printing unicode.
A: Able looks like it's great, but it crashes as soon as I load it.
Q: But Windows users hate our freedom and like to kill kittens!
A: Most don't. I run Debian on my server, and have even sold macs. For
my personal computer I prefer windows, for many reasons I wont get
into.
From what I can tell after a some months of using it, Common Lisp is
fantastic language. Languages like Python and Ruby are really popular
these days; Lisp has all their features plus 50 times the speed. I see
no reason why Lisp couldn't be huge, if getting just started with it
was a little easier.
As for the general direction of your project, I think you may be
making a mistake in trying to do to much. Like being compatible with
many implementations of Lisp. If the solution is supposed to "just
work", I think it would be better to choose a single Common Lisp
implementation and make it work flawlessly, choose one GUI toolkit,
one IDE etc. Whatever you do I wish you the best of luck, because this
is a something I think many people want, and it may be huge for the
popularity of Lisp.
That would be awesome! Although I'm heavily investing my time in EMacs,
and I'm having great fun (too much Ctrl+C and Ctrl+X sometimes)...
But It's still a good idea to have a more common editor (common in this
case is strictly subjective - based on my experience) that most people
would be used to.
Thanks, Phil!
> Q: Why not LispBox and Able?
> [...]
> A: Able looks like it's great, but it crashes as soon as I load it.
If you send me an email I can try and help you resolve the problem. I
can't promise anything but there are dozens of ABLE users on Windows.
Unfortunately the Windows version does suffer the most with
reliability issues which often relate to the use of Tcl/Tk for the
GUI. I once exchanged several emails with a Windows user who was
having trouble and we eventually tracked it down to a system tray icon
loaded by his ISP connection software. Apparently things like this are
quite common with Tcl/Tk on Windows for some reason...
I may have also jumped the gun using SBCL on Windows for the 0.15
release but quite a few people asked for it over CLISP so I took the
chance with it. Possibly you're hitting some issue there.
I also think that if I switch from compiled exe's to a bundle it will
be far easier to diagnose crashes as you can see output in a console
window.
--
Phil
http://phil.nullable.eu/
Will do:)
I agree that we should have a well-developed Lisp IDE other than
Emacs, for people who are coming to Lisp from other commonly-used
IDEs. Newcomers already have to get used to Lisp syntax, which we
can't and wouldn't change; there's no point in putting yet another
barrier in their way by forcing them to learn Emacs.
That said, you should understand why Emacs is the way it is: not to
fuck over Windows users, but simply because it is older than the C-c/C-
v convention you refer to. Emacs dates back to 1976, while this
convention was introduced, AFAIK, by the first Macintosh in 1984.
-- Scott
I'm not an Windows+Emacs user, but it should be possible to use
Emacs with some more Windows-like key bindings.
On the Mac there is a variant of GNU Emacs called Aquamacs
which tries to adapt to Apple conventions. command-x/c/v
there works as expected. One can use Emacs/Slime and
have some Mac adoption via Aquamacs. Isn't there anything
like that on Windows?
But I agree, I personally am also not a fan of an Emacs based IDE.
The commercial Lisp IDEs (Allegro CL, LispWorks, Corman CL (?))
should be usable without Emacs-knowhow. LispWorks for
example has Preferences for the editor to set the emulation.
Allegro CL has that, too, IIRC.
There are some alternatives. Like using Eclipse and a Lisp plugin, ...
But - I haven't seen a single free (!) good integrated
development environment for Lisp on Windows and Mac OS X
for quite some time (besides MCL for PowerPC Macs).
One that does not look clumsy and is written in Lisp.
The Clozure CL guys are looking for sponsoring for improving
their Mac IDE:
http://article.gmane.org/gmane.lisp.openmcl.devel/2972/
Since Clozure CL is currently being ported
to Windows, maybe there is some interest to base an IDE
on top of it? I guess it would take some time to
get it into a usable state, but what is another year? ;-)
For LispWorks, the special 50% offer still runs for a few
days: http://www.lispworks.com/buy/50-50-special-offer.html
Students wanting to use Allegro CL should check with
the conditions the university has. For example years
ago we had a site license here at the University of Hamburg
that allowed everyone with access to the SUN cluster
to use Allegro CL (and CLIM). Don't know what the state of that is
now.
I'm not sure how popular site licenses are currently
at universities, but sometimes LispWorks and Allegro CL
are available to students via special University licenses.
Thanks for the ideas, Rainer. To pre-empt answers: yes there are plug-
ins/versions of GNU EMacs to make it more palatable to Windows users
(there's EmacsW32, EasyMacs, etc.). It's something I'll definitely be
looking into.
The main problem with solutions like these it that they tend to cause
impedance between Emacs and SLIME key-bindings (with Emacs now
behaving as Windows and SLIME as Emacs :-)). We could also change
SLIME key-bindings as well of course, but that will render many
tutorials awkward to follow.
Anyway, something to think about...
my recipe:
a) find out what the currently 'best' key bindings for
windows users are.
b) check if some SLIME users use those and have changed
the SLIME key bindings to work better under Emacs/Windows
(typically via the SLIME mailing list)
c) if necessary change/extend the key bindings and publish those
Also note that with Emacs many commands can also be reached
via menus.
It would actually be helpful if the SLIME developers also
would make a release from time to time. RELEASE means
a stable piece of software that is known to work on
the supported platforms and is somehow in sync with its
documentation. This would mean that the
software would need to be tested (manually and automated)
before a release. The minimum would be tags on the
source repository so that 'stable' software can be identified.
> After playing with various implementations, IDEs, libraries, etc. on
> Windows (or rather, trying to play with them), it's all rather grim.
> ASDF-INSTALL is not Windows-friendly (who was it that said that Common
Try Eclipse + CUPS + SBCL (bundled with CUPS or separate) for a quick
start.
Am I asking too much?
Pedro
In the course of my investigations, I looked for it as well. Short
answer: there isn't one (at least, not out of the box).
However, there is a GTK2 backend for McCLIM that somebody got working
on Windows: it's (tersely) covered in the McCLIM mailing lists;
haven't tried it myself yet. Also, Jack Unrue has started building a
native Windows API back-end for McCLIM called graphic-forms and has
progressed quite a bit, although development has slowed down of late.
You can read about that on his blog: http://awayrepl.blogspot.com/.
Also, there has been mention of .Net back-end but I haven't seen
anything tangible about that yet.
I hope to be able to provide it with my solution but that will
probably take some time. MOst certainly not in the first efforts.
Ben.
Whatever your definition of "free", I think the OS argument is a bit
different than the application argument.
First, many computer vendors simply pre-install Windows on everything
and, even with web search engines, I think most people are not aware
that computers can be bought naked or, sometimes, with other OSes
pre-installed. Even if they are, they may be wary of doing business
with companies they've never heard of. For bad or for worse, Windows
comes pre-installed on 80+% of all computers sold.
Second, the majority of programmers today are neither CS grads nor are
they interested in developing software commercially. Instead they are
students, IT/IS/business people, scientists, engineers, etc.
interested only in their own applications. For most of these people
the programming language may be an important consideration but the OS
is irrelevant.
George
>Q: Why not emacs?
>A: I don't want to start a flame war. However, emacs' apparent
>popularity is a mystery to me. I take it it's supposed to be text
>editor. My minimum expectations for text-editor is for it to have ctrl-
>c/ctrl-v and a proper undo function. Emacs has neither. I can
>configure it for cut and paste, but I think I'm stuck with its undo
>function. I could go on. I get that emacs can be configured to work
>right, but I don't want to configure it. Any text-area widget from a
>GUI toolkit already meets these requirements. When I have to configure
>something to do ctrl-c/ctrl-v, that just screams "Fuck you windows
>user", to me. I can imagine that that is on purpose.
So, the fact that Emacs has more powerful undo and more powerful copy/paste
is a disadvantage to you? I'm a Windows user and I found these features of
Emacs completely natural. I mean, how are you supposed to learn Lisp if you
can't even understand how Emacs undo works?
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
> On Nov 11, 7:50 pm, George Neuner <gneun...@comcast.net> wrote:
>> First, many computer vendors simply pre-install Windows on everything
>> and, even with web search engines, I think most people are not aware
>> that computers can be bought naked or, sometimes, with other OSes
>> pre-installed. Even if they are, they may be wary of doing business
>> with companies they've never heard of. For bad or for worse, Windows
>> comes pre-installed on 80+% of all computers sold.
>
> And without Macs that are almost exclusive to USA, has almost 99.999%
> everywhere else. In my country users are offered choice of Windows and
> Linux for desktops, and they either buy windows or replace linux
> immediately with pirated Windows. Laptops , sorry notebooks, come only
> with Vista. Linux & FreeBSD are only on servers, in some organizations
> who don't want to pay for windows and few loud fanboys.
That's funny, because this is quite dependant on the country.
For example, in France, Macs are quite successful, as well as Linux.
At my current employer, there's only Linux boxes, but perhaps one
MS-Windows used by a tie. I know other companies where there are only
Macintoshes. Actually, last time I worked on MS-Windows was more than
15 years ago, with MS-Windows 3.11.
On the other hand, in Spain, there's much less Macs. But in some
areas, Linux is strong too.
> Why people don't use linux? Because there are no apps and hardware
> doesn't work.
Which is wrong. Or How many word procesors do you need?
> I have a ubuntu box that's used primary by my father and
> I'm damn sure that clueless non-technical user can't configure it to
> work, no matter what FSF pricks say. And I keep it only because it's
> used for browsing (Firefox), printing (the hell broke until I found
> drivers and configured it to work them) and maybe little word
> processing (Open Office ) and listening music (totem - primitive but
> stable and plays everything).
So it works too.
> So whenever I see development tool that doesn't have a windows
> version I ask myself what were you people thinking?
This:
>> Second, the majority of programmers today are neither CS grads nor are
>> they interested in developing software commercially. Instead they are
>> students, IT/IS/business people, scientists, engineers, etc.
>> interested only in their own applications. For most of these people
>> the programming language may be an important consideration but the OS
>> is irrelevant.
The OS is not a concern of the "end-users". If you sell a program
that can write programs from specifications, even if it runs only on
Linux, ties will buy it to avoid emailing/phoning India, along with
the hardware (by the way, such a program would probably need specific
hardware anyways).
> You just excluded
> 95% of developers out there. And don't give me that BS that it's a web
> app, most developers develop on windows and later deploy on linux or
> freebsd. So when all the LAMP letters have good windows tools that's a
> pretty good clue that you should make one too, and be sure to make it
> good because it's probably the only one that *most* developers will
> ever try. One more thing, It must feel native(installer or unzip&run,
> editor with windows shortcuts BY DEFAULT and window with File Menu )
> that's it.
Depends on the market. Shrink wrap is not the same as professionnal
systems. There, installation may take weeks, and is done in general
by consultants provided by the software vendor. Again, in these
situations, the customer won't care if the OS is MS-Windows, Unix or
MacOSX, or if you bring new hardware along.
--
__Pascal Bourguignon__
..hm..
On Thu, 2008-11-13 at 07:42 -0800, Slobodan Blazeski wrote:
> So whenever I see development tool that doesn't have a windows
> version I ask myself what were you people thinking? You just excluded
> 95% of developers out there.
ok, if we combine these, we get:
* clueless
* non-technical
..and..
* developer
yeah .. i'm sure the "FSF'ers" are going *facepalm* over their losses ..
lol
>> yeah .. i'm sure the "FSF'ers" are going *facepalm* over their losses
>> ..
> They're complaining why people aren't using OSS and GNU/Linux. If they
> clearly state that GNU/Linux is only for developers willing to learn the
> system than in that market they probably have the majority of the users.
> Bust most people over there are neither developers, nor admins nor ready
> to become power users, they just want their job done. if FSF don't want
> those they should say that and leave the market to ms and apple.
I installed Ubuntu for a couple of friends and relatives, none of them
very computer literate. Install is quite easy, I just pop in the CD,
select a few options and wait for stuff to install, then add some media
and other repositories, I did it for them, but then taught them how to
upgrade. They have been using it ever since, no complaints.
The key point has been educating them about what to expect. The benefits
are no more malware, no more tedious hunting for software and/or
upgrades, rock-solid reliability. The downside is that you can't install
any exe file you just get from the net, but having seen where that leads
(unusable computer in 1 year), I consider that a benefit.
When making Linux vs Windows comparisons, many people are tend to ignore
that Windows has a high TCO and needs expertise if you want to keep it
operating for a longer duration.
Anyhow, back to the original point: I agree with Lars here. I see little
benefit in providing sugar-coated IDEs for developers who are otherwise
clueless. Sun tried that with a whole language called Java, look at the
results.
Tamas
er, no .. most do not care, really .. they follow what for them(!) makes
most sense, is most fun or pays
heh .. you `winxp-with-keygen-included.torrent' people are weird ..
people don't write software for you; they write it for themselves in one
way or another .. you do not _deserve_ anything by-default
> If they
> clearly state that GNU/Linux is only for developers willing to learn
> the system than in that market they probably have the majority of the
> users. Bust most people over there are neither developers, nor admins
> nor ready to become power users, they just want their job done. if FSF
> don't want those they should say that and leave the market to ms and
> apple.
who are we talking about again? what jobs? how does this (and these
jobs) relate to programming?
If it's all the same to y'all; I really don't care one iota about any
of this. I just know that there are numerous people using Windows as
their main platform who would like to get into LISP (a few responses
to this thread demonstrate as much).
I'm sure that out of those at least a few (if not many) will have the
intellectual capabilities necessary to actually be able to learn
Common LISP (previous posts to the contrary notwithstanding; once
you've figured how to make anything run stably on Windows, you should
be able to tackle a lot more :-))
After all, there are some very clever on this list who have Windows as
at least one of their Common LISP environments already (Edi comes to
mind: of course, he did the smart thing and chose Lispworks and I'll
be pointing newbies to that and Allegro and Corman as well, to follow
his good example).
Nevertheless, fact remains, a lot of people are disappointed to see
the licensing and crippling of free editions of Lispworks and Allegro,
and the relative bareness of Corman; I just intend to lower that
particular threshold and a few others.
So, since this thread has degraded, I'm just going to go ahead and do
what I set out to do and will start a brand new all-shiny, singing and
dancing new thread when I have some progress to report.
You all have fun continuing the discussions!
Ben.
Sorry, please ignore the previous post. What I wanted to say is that I
see everyone making much ado about nothing. What's the problem? That if
you want to have a noncommercial lisp environment you have to run it in
linux? If none of the free Windows options satisfies your requirements,
choose among these:
- make room for a new partition where to install linux and install it there.
- install linux in a vm in your existing windows partition.
- install linux in a partition and windows in a vm. (This is what I did)
After choosing one of those, you can install emacs+sbcl+slime in linux.
If you install ubuntu (as I did) you can just get the necessary packages
via Synaptic. You can start learning Common Lisp in no time. Some time
later you will be able to get rid of clc and install everything yourself.
In the end you will have learned about CL, linux, slime and emacs.
What's wrong with that? Isn't that good?
If you are going to say that this is a procedure way too involved for a
newbie, please don't. We like to imagine that people learning to program
can handle situations like resizing a partition or installing (and
learning the basics of) a new OS. Please don't tear our illusion apart.
Leandro
>Slobodan Blazeski <slobodan...@gmail.com> writes:
>
>> On Nov 11, 7:50 pm, George Neuner <gneun...@comcast.net> wrote:
>
>>> Second, the majority of programmers today are neither CS grads nor are
>>> they interested in developing software commercially. Instead they are
>>> students, IT/IS/business people, scientists, engineers, etc.
>>> interested only in their own applications. For most of these people
>>> the programming language may be an important consideration but the OS
>>> is irrelevant.
>
>The OS is not a concern of the "end-users". If you sell a program
>that can write programs from specifications, even if it runs only on
>Linux, ties will buy it to avoid emailing/phoning India, along with
>the hardware (by the way, such a program would probably need specific
>hardware anyways).
Yes, but I'm talking specifically about non-professional programming -
power-users who script applications, students who write programs for a
thesis, engineers and scientists who write programs to aid whatever
work they happen to do, etc.
These people largely care nothing about the OS (or window manager,
etc.) as long as there is enough information about it to allow their
programs to be written.
George
> First, many computer vendors simply pre-install Windows on everything
Odd. My compute vendor didn't pre-install Windows. Oh well.
> Second, the majority of programmers today are neither CS grads nor are
> they interested in developing software commercially. Instead they are
> students, IT/IS/business people, scientists, engineers, etc.
> interested only in their own applications. For most of these people
> the programming language may be an important consideration but the OS
> is irrelevant.
Hmmm. My informal observation is that a significant fracion (40-60%) of
the non-CS scientists that I have worked with didn't use Windows
machines. Now, in the business world that may be different.
--
Thomas A. Russ, USC/Information Sciences Institute
That's just one option.
There's always the free versions of Allegro or LispWorks. They use,
AFAIK, the standard editing conventions.
And there's always the option of using your absolutely favorite text
editor like Notepad or whatever and running the lisp as a separate
process. Of course, you then have to configure YOUR text editor to
understand how to indent lisp and balance parentheses, but that
shouldn't be too hard. At least it must be easier than setting cua-mode
in Emacs, right?
> Yes, but I'm talking specifically about non-professional programming -
> power-users who script applications, students who write programs for a
> thesis, engineers and scientists who write programs to aid whatever work
> they happen to do, etc.
>
> These people largely care nothing about the OS (or window manager, etc.)
> as long as there is enough information about it to allow their programs
> to be written.
I am under the impression that people in academia do care about their OS
a lot - linux usage is much higher among the scientists I know than in
the general population. Computational clusters are already using some
variant of Unix, so using it on your own computer entails no extra cost,
and you gain a lot in ease of maintenance and stability. Consider apt-
getting all your Emacs-TeX-numerical libraries-[favourite programming
language] toolchain once and then running apt-get update once in a while
vs hunting down everything separately.
Just because scientists are not programmers per se doesn't mean that they
like wasting their time with Windows.
Tamas
> Hmmm. My informal observation is that a significant fracion (40-60%) of
> the non-CS scientists that I have worked with didn't use Windows
> machines.
I have the same impression.
Tamas
I guess you're right about educating, but in the end the user must
decide. I've installed pc-bsd to a classmate and he loves it, now I
ask him to help me with the console when I need it. The irony is that
he doesn't know english very well but still manages to install from
source.
bobi
And if we must infer anything from the audience at lisp conferences,
95% of lisp programmers use MacOSX laptops, and the remaining 5% of PC
laptop are probably running Linux.
--
__Pascal Bourguignon__
Maybe the Windows users don't use Windows laptops at Lisp conferences
and listen to the talks instead?
you mean windows *still* has a problem with multi-tasking?
--
Joost Kremers joostk...@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
> Anyhow, back to the original point: I agree with Lars here. I see little
> benefit in providing sugar-coated IDEs for developers who are otherwise
> clueless.
There is a general assumption on this group that those who don't use
emacs are "clueless". I certainly hope for my own sake that this isn't
the case (but I guess it's a paradox: do the "clueless" know that they
are?!).
I don't understand why we celebrate the choice that the Lisp world
offers when referring to the multitude of implementations yet
inexplicably have the opposite opinion when it comes to editors?
To me, getting programmers using Lisp is the most important point. I
know for a fact that some users of ABLE have eventually moved to Slime
once they were comfortable with CL and it's even possible that one or
two may eventually buy a commercial Lisp system. I'm happy to play
even a tiny part in keeping that momentum going.
--
Phil
http://phil.nullable.eu/
Maybe someone want to hire me to write/find such a SLIME/Emacs
keybindings together with a docs and all blah-blah-blah.
It wont'be expensive as I'd like to have this too.
I'd suggest to take Visual Studio keybindings. Visual Studio has keys
for almost every feature. Though my personal preference is Borland
Classic.
Here is a fragment of my .emacs
But it is very insufficient...
(modify-syntax-entry ?- "w" lisp-mode-syntax-table)
(add-hook 'slime-load-hook (lambda () (require 'slime-fancy)))
(defun slime-show-sbcl-buffers () "Shows *slime-repl sbcl* и *inferior-
lisp*"
(interactive)
(delete-other-windows)
(switch-to-buffer "*inferior-lisp*")
(switch-to-buffer-other-window "*slime-repl sbcl*")
)
(global-set-key [(control ?\;)] 'slime-show-sbcl-buffers)
(defmacro define-lisp-keys (mode)
`(progn
(define-key ,mode '[(meta backspace)] 'backward-kill-sexp)
(define-key ,mode '[(meta delete)] 'kill-sexp)
(define-key ,mode '[(meta right)] 'forward-sexp)
(define-key ,mode '[(meta left)] 'backward-sexp)
)
)
(define-lisp-keys slime-mode-map)
(define-lisp-keys slime-repl-mode-map)
(define-lisp-keys emacs-lisp-mode-map)
(setq common-lisp-hyperspec-root "/usr/share/doc/clhs/")
(define-key slime-mode-map '[(f1)] 'slime-hyperspec-lookup)
(define-key slime-repl-mode-map '[(f1)] 'slime-hyperspec-lookup)
(global-set-key [C-f3] 'comint-dynamic-complete-filename)
; (global-set-key '[(meta f7)] (iswitchb find-buffer-visiting "sldb"))
(global-set-key '[(control x) (f3)] 'find-file-at-point)
(global-set-key '[(f3)] 'find-file)
(global-set-key '[(meta f3)] 'kill-buffer)
(global-set-key '[(f2)] 'save-buffer)
(global-set-key '[(f6)] 'other-window)
----------(desperately) looking for a lisp job----------------
(tool-bar-mode 0)
(iswitchb-mode 1)
(iswitchb-default-keybindings)
(global-set-key '[(control f12)] 'iswitchb-buffer)
; (defalias 'read-buffer 'iswitchb-read-buffer)
(slime)
(custom-set-variables
;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(column-number-mode t)
'(scroll-bar-mode (quote right))
'(show-paren-mode t)
'(transient-mark-mode t)
'(x-select-enable-clipboard t))
> Rainer Joswig wrote:
>> In article <7cvduqr...@pbourguignon.anevia.com>,
>> p...@informatimago.com (Pascal J. Bourguignon) wrote:
>>> And if we must infer anything from the audience at lisp conferences,
>>> 95% of lisp programmers use MacOSX laptops, and the remaining 5% of PC
>>> laptop are probably running Linux.
>>
>> Maybe the Windows users don't use Windows laptops at Lisp conferences
>> and listen to the talks instead?
>
> you mean windows *still* has a problem with multi-tasking?
>
>
I belive it is men that have a problem with multi-tasking.
--------------
John Thingstad
> And without Macs that are almost exclusive to USA, has almost 99.999%
> everywhere else. In my country users are offered choice of Windows and
> Linux for desktops, and they either buy windows or replace linux
> immediately with pirated Windows. Laptops , sorry notebooks, come only
> with Vista. Linux & FreeBSD are only on servers, in some organizations
> who don't want to pay for windows and few loud fanboys.
In the last couple of (web based) projects I've worked on, all
deployment was on linux, and development machines are about 50% linux
desktops (and one linux notebook) and the other 50% are mac notebooks.
A couple of years ago I was astounded by the number of mac notebooks I
saw at developer conferences. Currently, I'm more surprised if someone
isn't using OS X on his notebook.
That's in the Netherlands,
YMMV.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
> I have installed more than a dozen
> ubuntu and pc-bsd to friends and relatives but only 2 or 3 keep them,
> the rest switched to windows.If they play games, it's no brainer it
> MUST be windows, wine is not an option for standard user, actually
> many times graphic drivers either suck or are unavailable.
And these are people who are potentially willing to wrap their mind
around macros, closures and programming in general? Or what is the
relationship between these people and Lisp programming?
One shouldn't confuse technical people with consumers who basically want
just an interactive TV. There will never be a "one-size-fits-all"
solution anywhere.
>> yeah .. i'm sure the "FSF'ers" are going *facepalm* over their losses ..
> They're complaining why people aren't using OSS and GNU/Linux. If they
> clearly state that GNU/Linux is only for developers willing to learn
> the system than in that market they probably have the majority of the
> users. Bust most people over there are neither developers, nor admins
> nor ready to become power users, they just want their job done. if FSF
> don't want those they should say that and leave the market to ms and
> apple.
Thankfully we live in a world where one can write software freely
without having to ask the FSF (or any other body) for permission or
having to conform to their regulations.
In short: You overestimate the role of the FSF in the free software world.
Hmmm... Am I the only one running FreeBSD on my laptop? [Maybe...] ;-}
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
It's not *always* cluelessness. In my case it's simply having
learned "the moded way" nearly four decades ago [hint: TECO]
and thus being much more comfortable with moded editors such
as Vi in which most editing commands are lower-case letters
(or at worst, upper-case). Conversely, my fingers simply don't
work well with the monster chords Emacs wants. Sobeit. Using
Vi doesn't get in my way, so it's a non-issue for me.
+---------------
| I don't understand why we celebrate the choice that the Lisp world
| offers when referring to the multitude of implementations yet
| inexplicably have the opposite opinion when it comes to editors?
+---------------
Well, I certainly am willing to believe that Emacs+Slime is *better*
for coding Lisp in the hands of an expert (if your fingers permit
their use!) than other editors/IDEs. The only question for me is
how *much* better? My personal experience [reported elsewhere, so
I'll be brief here] is that the answer is -- for me -- not *enough*
better to be worth the pain of switching. Look, to my knowledge
my choice of editor has *never* been an obstacle (or at least not
so large that I noticed) to coding in either Scheme or Common Lisp.
+---------------
| To me, getting programmers using Lisp is the most important point.
+---------------
Yup. In the words of his Kennyness, "Shut up & code!" Whatever editor
you already have that you feel comfortable with is almost certainly
"good enough" to start coding in Lisp... to get very far, in fact.
+---------------
| I know for a fact that some users of ABLE have eventually moved
| to Slime once they were comfortable with CL...
+---------------
Sure, but the important thing is to *start coding*...
You are now. I'm a long time FreeBSD user that is in the process of
switching to Linux because commercial software that I require only
supports Linux. As soon as the Linuxulator goes 64bit, or FreeBSD gets
Xen, I'll probably switch back. I much prefer FreeBSD over any other
OS.
I agree with the need for something like what you're describing. I
come from a Windows background, and I've been spoiled by things like
Visual Studio and Delphi. I once gave a short introduction to Common
Lisp for my students, and to my surprise they readily accepted the
power of the language but didn't feel like doing actual work in it.
They simply felt the existing tools would be an obstacle.
I took a look at ABLE and it seems to be among the most promising
newer Lisp IDEs. Is it sufficient or do we need a brand new project? I
don't know. I think I should download it and play with it a bit.
Moving on, I think there are 2 important strategic decisions you'll
need to make if you decide to go forward in creating a new IDE:
1- Do you intend it to be always Windows-only or to be eventually
cross platform?
If it's Windows forever, I'd consider making the GUI toolkit a Lispish
interface to native Win32. If it's to be cross platform then something
like GTK or a CLIM might make sense.
2- Do you intend to use SLIME? An advantage of SLIME is that it's
quite feature rich and complete, a disadvantage is that it's an
external dependency designed for slightly different goals than yours.
Anyway, I'm certainly interested in what you'd be doing!
--Mohamed Samy
> Yes, in my experience *all* free projects die at some point or another
> (or morph into something different).
Oh, the BSD-projects are quite old and don't look like they'll die
anytime soon. Of course viewed from a geological point of view, I don't
think that they'll exist in 34 million years but actually, that's ok with
me.
regards,
Marek
bobi
Pedro
I took a look at ABLE, and while it does look promising I think it's
somewhat limited in scope. For example it doesn't seem to intend to
provide, say, a GUI designer or a debugger. ABLE would be fine for a
new Lisper's first steps, but when he moves on to more interesting/
more complex types of applications he still has to hunt down for
libraries and tools, without an adequate one-stop solution for his or
her requirements.
No offense, but I believe the case is far from closed :(
--Mohamed
> Are there plans for including a GUI library in ABLE?
ABLE has included LTK since the version 0.1 release. While LTK isn't
perfect it is unfortunately the only viable cross platform, open
source GUI toolkit currently available to Common Lisp programmers.
--
Phil
http://phil.nullable.eu/
>> > I took a look at ABLE and it seems to be among the most promising
>> > newer Lisp IDEs. Is it sufficient or do we need a brand new project?
> Are there plans for including a GUI library in ABLE?
>
> Pedro
I'm sure Phil will answer as well but since ABLE was built in Common LISP
using a GUI library, it has one built-in (using Tk). Currently, this is not
exposed explicitly to the user but that is something that Phil will
undoubtedly look at (and if not he, then I will see if I can contribute that
to ABLE for my own project).
would you like some fries with that, sir?
> I took a look at ABLE, and while it does look promising I think it's
> somewhat limited in scope. For example it doesn't seem to intend to
> provide, say, a GUI designer or a debugger. ABLE would be fine for a
> new Lisper's first steps, but when he moves on to more interesting/
> more complex types of applications he still has to hunt down for
> libraries and tools, without an adequate one-stop solution for his or
> her requirements.
> No offense, but I believe the case is far from closed :(
>
> --Mohamed
Phil has plans to extend ABLE; it's a product in development so features will
be added as time progresses. The usual Common LISP debugger is present (the
SLIME interface to the compiler's debugger); we'll have to see if a more
integrated or graphical debugger warrants the effort required, but since ABLE
is still in development (it's only at 0.15 now; a long way to go still), I
wouldn't assume it's not going to happen.
As for a GUI designer: that may well come since we may be able to leverage
some other stuff here (take another Tk designer; have it generate LISP). I'm
sure that will be looked at as well.
However, we need to get the basics right first; there are many other things
to be done in ABLE.
If you have specific needs, please offer your help to Phil, I'm sure he'll
welcome it.
Ben.
> I took a look at ABLE, and while it does look promising I think it's
> somewhat limited in scope. For example it doesn't seem to intend to
> provide, say, a GUI designer or a debugger.
The debugger issue is a problem and has been on the to-do list for
about 18 months. At the moment, I'm erring towards simply making the
Lisp an 'inferior Lisp' and then you can use whatever debugger that
happens to provide. This is not likely to be the same as a nice
"stepping debugger" that you might be used to from Visual Studio,
Eclipse or Netbeans but it is at least something.
The issue with including this is that it's more comfortable to invoke
a sub-process Lisp on a multi-threaded host Lisp and this pretty much
leaves Windows out right now (which rather steps on the title of this
thread). That said, it looks as though CCL may be first to get
threading on Windows in a free Lisp implementation so that may be the
way to go unless the SBCL situation changes soon (or already has, but
I don't think so).
The GUI designer is not in scope though. You want a GUI designer,
someone else wants to colour print their source files, another person
doesn't like that ABLE invokes their regular web browser to display
the Hyperspec and wants me to embed a web-browser inside ABLE
itself...the fringe requests are never ending, unlike my free time :-)
> ABLE would be fine for a
> new Lisper's first steps, but when he moves on to more interesting/
> more complex types of applications he still has to hunt down for
> libraries and tools, without an adequate one-stop solution for his or
> her requirements.
It depends what you mean by complex and interesting. I use ABLE for
all of my Lisp programming, including my day job. With regard to
libraries, this will hopefully become easier in 0.16 - see the
comments earlier in this thread.
> No offense, but I believe the case is far from closed :(
I agree with you. CUSP for example is far more of an "IDE" and it
sounds like it may be more to your liking. Slime and Limp are ideal
for those used to the power of emacs and Vim respectively. And of
course LispWorks and Allegro come with very comprehensive IDEs and I
know that at least LW comes with a GUI builder (maybe Allegro too...).
They're all free so you can grab them all to try.
--
Phil
http://phil.nullable.eu/
Sorry, didn't mean to sound offensive. I certainly didn't come with a
list of demands for features in ABLE but my point was that the
original poster shouldn't be discouraged from attempting to create his
own IDE if he wants to, since there's still a (perceived) need for
such an integrated tool.
To Ben Kooijman:
> Phil has plans to extend ABLE; it's a product in development so features will
> be added as time progresses. The usual Common LISP debugger is present (the
> SLIME interface to the compiler's debugger); we'll have to see if a more
> integrated or graphical debugger warrants the effort required, but since ABLE
> is still in development (it's only at 0.15 now; a long way to go still), I
> wouldn't assume it's not going to happen.
Thanks for this information. It's not easy to know what a program's
author intends or doesn't intend to do in his application. My
perception about ABLE from trying it and from the name (A *Basic* Lisp
Editor) is that's intended more like a quick tool than a full blown
IDE. It seems I wasn't that accurate.
> If you have specific needs, please offer your help to Phil, I'm sure he'll
> welcome it.
Actually, I've somewhat drifted away from Common Lisp these days.
Currently working on a Windows IDE for my own (yet another) Lisp
variant running on .Net
That said, a good newbie friendly IDE for Common Lisp is certainly
good news. Perhaps I should keep a closer look at either ABLE or your
proposal (if you decide to go for something different) and see if I
have something to offer.
--Mohamed
> This is not likely to be the same as a nice
> "stepping debugger" that you might be used to from Visual Studio,
> Eclipse or Netbeans but it is at least something.
> ...
> The GUI designer is not in scope though. You want a GUI designer,
> someone else wants to colour print their source files, another person
> doesn't like that ABLE invokes their regular web browser to display
> the Hyperspec and wants me to embed a web-browser inside ABLE
> itself...the fringe requests are never ending, unlike my free time :-)
I appreciate that you completely understand where I'm coming from. I
never intended to criticize ABLE or diminish the value of your work,
but my point is that there's a class of programmers who would happily
use Lisp if it had a fancy IDE comparable to familiar Windows
development tools; Some of which contain features that are
(understandably) out of the scope of ABLE's intended specification.
>> ABLE would be fine for a
>> new Lisper's first steps, but when he moves on to more interesting/
>> more complex types of applications he still has to hunt down for
>> libraries and tools, without an adequate one-stop solution for his or
>> her requirements.
> It depends what you mean by complex and interesting. I use ABLE for
> all of my Lisp programming, including my day job.
I was thinking about stuff like, say, a graphing calculator or a game.
In the university where I used to work, I tried to pull the students
from mainstream languages like C# and into more interesting stuff like
Lisp or Ruby. The problem is that tools like Visual Studio let them
create a basic GUI or Web app. in a matter of minutes, and "trains"
them to resist anything that requires a lot of preparation to create
similar programs. Much of my opinion in this thread comes from that
experience or my own first Lisp steps.
--Mohamed
With built in file menu and asdf directory it would be great start for
newcomers and *essential* features like debugger and maybe asdf-
install could be added later. Neither Phil nor sbcl/ccl folks have
backing by big bucks to bundle all the drums and bells. If one wants
IDE with all the candies there are vendors offering them or befriend
with Emacs.
bobi
Nonsense. What about Cells-Gtk, Celtk, Cello, and McCLIM?
As for LTk, it talks over a pipe. Too slow. And it cannot do OpenGL.
Game over.
otoh, the only GUI that matters any more is the Web, I recommend
qooxdoo. (Thx for the tip, Lars!) Once I have it fully figured out we
can do Xello or some other Lispy wrapper such as SymbolicWeb. And this
aint just the Web with AIR/WebKit.
hth, kt
> > ABLE has included LTK since the version 0.1 release. While LTK isn't
> > perfect it is unfortunately the only viable cross platform, open
> > source GUI toolkit currently available to Common Lisp programmers.
>
> Nonsense. What about Cells-Gtk, Celtk, Cello, and McCLIM?
For each of the Cel* projects, I couldn't get them working even after
a reasonable amount of fiddling. McCLIM did work OK for me on Linux
but I couldn't get it to work on Windows. Unfortunately this is where
75% of my users are so it's an important platform.
> As for LTk, it talks over a pipe. Too slow.
A couple of years ago you slammed me on this very list for suggesting
that LTK was a little slow...
--
Phil
http://phil.nullable.eu/
Understood, but that does not make them unviable and /some/ people Just
Build and Use Them (even Cello once!) without a problem or after
emailing for support so nope don't say unviable, say you gave up on them
too soon. This from someone who has now spent three weeks fighting tooth
and nail with Dojo and then YUI and now qooxdoo to find a better way
than jQuery. I passed "reasonable" on Dojo and YUI and did not give up
because getting started can be a bitch even when there is something to
be had and we /need/ something better than jQuery's widget here widget
there philosophy. I am struggling just a little with qooxdoo but I see
the promise so I keep on struggling.
You settled for LTk (ugly Tk and no Cells) because those were good
enough for you, fine, just do not glamorize your choice as A Survey of
Common Lisp GUIs.
> McCLIM did work OK for me on Linux
> but I couldn't get it to work on Windows. Unfortunately this is where
> 75% of my users are so it's an important platform.
Sorry, I was just trying to be nice to the McCLIM crowd for once in my
life, you are right.
>
>
>>As for LTk, it talks over a pipe. Too slow.
>
>
> A couple of years ago you slammed me on this very list for suggesting
> that LTK was a little slow...
That was you?! Doh! I thought I would get caught on that anyway (it is
in my fortune cookie list), but not by the addressee himself.
Right, LTk is plenty fast for most GUIs, my /real/ point was about not
being able to leverage a Togl (OpenGl) widget over a pipe. Thus if
anything is not viable it is LTk because there is no way around that.
And even without OpenGL, what happens when one wants to do Snack and
real-time audio? LTk is fine as far as it goes, but in the end it is not
an adequate solution.*
hth, kenny
* Not that stealing the FFI-layer from Celtk would be all that hard. kt
I'd rather stick with what I actually said which is that I gave up on
them "after a reasonable amount of fiddling". Of course, that is a
highly subjective measure which I'm sure we could argue endlessly
over.
> just do not glamorize your choice as A Survey of Common Lisp GUIs.
There was no glamorization nor was there a survey. Merely an opinion
was offered. I do however concede that my choice of the word "viable"
was a little passive aggressive and as we all know, it's far better to
go straight for the throat on this newsgroup!
--
Phil
http://phil.nullable.eu/
No need, the record is compleat.
>
>>just do not glamorize your choice as A Survey of Common Lisp GUIs.
>
>
> There was no glamorization nor was there a survey. Merely an opinion
> was offered.
Misinformation cannot be passed off as opinion.
Peter Hildebrandt after a reasonable amount of /work/ had a ball with
Cells-GTk and extended/refined it three/four major ways. His work
followed the fine stewardship of Peter Denno who picked up on my
CFFIcation (or was it UFFIcation?) of Vasilis Margioulas's brilliant
extrapolation of my Cells-ification of Peter Herth's LTK. ie, There is
quite a reception line awaiting you.
If you have a bug report to make send it in, otherwise shut yer damn pie
hole.*
> I do however concede that my choice of the word "viable"
> was a little passive aggressive and as we all know, it's far better to
> go straight for the throat on this newsgroup!
:)
kt
* The Obama administration wants to know everything embarrassing I have
posted on-line and the courts, dates, and fines of all traffic
violations. Talk about a degree-of-difficulty toss-up! k
Cool, keep me posted on this; I've had to dive back into using "Plain
Old HTML" as widgets for a while now. It works in simple contexts, and
my current task is simple (doesn't require fancy widgets) -- at least
for now.
So in other words I _still_ haven't settled on one of the higher-level
widget frameworks out there. It's surprisingly hard to decide; much
harder and more timeconsuming than I thought it would be.
The good thing is that (most of) the really hard problems I deal with
will be useful when I settle on a higher-level framework later.
Hooking things together using Cells should be possible; I'd like to keep
things optional or separate though, same as with the messy MVC-stuff I'm
trying to figure out atm.(#1). I'm not forcing users to use it, but
instead implementing it as a component or layer "outside" the "plain
direct manipulation of widgets" stuff(#2). Seems it'll take a couple of
iterations or tries to get right though ..
I'm not even forcing users to use the widgets SW provide; one can just
comment out all the widget stuff in the .asd-file, then build a
widget-framework on the basic low-level stuff like APPLICATION (a
session), VIEWPORT (a browser tab/window), ADDRESS-BAR (the URL really)
and RUN (send JS to the client) etc.
..so yeah, I'm trying to keep things, everything, separate.
Someone on IRC has taken an interest in the new HTTP backend(#3) btw..
I've had to work on other stuff for a while now, so this part of "the
plan" has been lagging behind also.
#1: Progress is good here btw. I've found a couple of much much simpler
solutions than what I had when I started.
#2: I'm working on a way that'll enable on to manipulate the "Model" of
a (any) container widget as a plain Lisp list:
http://groups.google.com/group/comp.lang.lisp/msg/6bbe8acb99707aa4 ..
it's very cool. I should convert some more of this stuff to methods so
one can do the same with different "backends" than a Lisp list. Working
on it ...
#3: The one that scales like crazy (20000+ concurrent sessions) and has
potential wrt. portability (to, say, CLISP (read; small install size) on
Win32) or these "AIR" or Google Gears offline concepts).
Oh, and: http://paste.lisp.org/display/70560 .. still calling
make-instance directly etc.; no nice API for this stuff yet.
Nothing wrong with that, except browser variability if one pushes things
too far. major claim to fame of these frameworks is handling browser
variability.
>
> So in other words I _still_ haven't settled on one of the higher-level
> widget frameworks out there. It's surprisingly hard to decide; much
> harder and more timeconsuming than I thought it would be.
Frickin exhausting. I will probably write up my results eventually. I
think Dojo (just awful documentation) or qooxdoo are the way to go.
Qooxdoo tosses markup and with it the declarative thing which is fine by
us since we intend our own declarative thing on the Lisp side, but if
one is worried about being a thin wrapper qooxdoo is a major decision:
one is really committing to being a qooxdoo add-on. I am just trying to
get one client's screens up so not an issue. qooxdoo not only hides
browser variability it also hides html and css, so it takes those off
the learning curve for interwebby noobs such as Moi.
>
> The good thing is that (most of) the really hard problems I deal with
> will be useful when I settle on a higher-level framework later.
Yes, this is what we must tell ourselves as we bang our heads against
the wall.
>
> Hooking things together using Cells should be possible; I'd like to keep
> things optional or separate though, same as with the messy MVC-stuff I'm
> trying to figure out atm.(#1).
I detect a slippery slope of Premature Perfection leading to Never
Shipping derived from forgetting Lisp code is Easily Refactorable. Just
plunge in!
> I'm not forcing users to use it, but
> instead implementing it as a component or layer "outside" the "plain
> direct manipulation of widgets" stuff(#2). Seems it'll take a couple of
> iterations or tries to get right though ..
Later. Just Ship(tm).
>
> I'm not even forcing users to use the widgets SW provide; one can just
> comment out all the widget stuff in the .asd-file, then build a
> widget-framework on the basic low-level stuff like APPLICATION (a
> session), VIEWPORT (a browser tab/window), ADDRESS-BAR (the URL really)
> and RUN (send JS to the client) etc.
Cool, maybe Xello can sit on that layer.
kt
Not sure what I was seeing there. It looks as if one connects two values
by putting them in the same container? And then if one gets changed they
all get the same value? Cool. What if I want to be one half of some
other value? (If I understood correctly).
kzo
I'm aware of this; I've fallen into this trap a couple of times, but
I've got a real application(!) I'm working on here - and having multiple
widgets/containers sync with a single shared model backend automatically
is very very useful.
I just uploaded an example by the way:
http://sw2.nostdal.org/mvc-container-app
http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/examples/mvc-container.lisp
..if I where to change the first element, say, from the REPL or
whatever, both views would update automatically and maintain their
different properties wrt. color etc..
> > I'm not forcing users to use it, but
> > instead implementing it as a component or layer "outside" the "plain
> > direct manipulation of widgets" stuff(#2). Seems it'll take a couple of
> > iterations or tries to get right though ..
>
> Later. Just Ship(tm).
I've already shipped a version without this MVC stuff. :)
(..well, still got some integration to do with the clients mail-software
etc. left, but anyway..)
God bless you, my son!
> and having multiple
> widgets/containers sync with a single shared model backend automatically
> is very very useful.
Well, yes. But try to tell these yobbos that.
>
> I just uploaded an example by the way:
> http://sw2.nostdal.org/mvc-container-app
> http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/examples/mvc-container.lisp
>
> ..if I where to change the first element, say, from the REPL or
> whatever, both views would update automatically and maintain their
> different properties wrt. color etc..
Awesome. We just have to get rid of the exposed wiring. :)
>>>I'm not forcing users to use it, but
>>>instead implementing it as a component or layer "outside" the "plain
>>>direct manipulation of widgets" stuff(#2). Seems it'll take a couple of
>>>iterations or tries to get right though ..
>>
>>Later. Just Ship(tm).
>
>
> I've already shipped a version without this MVC stuff. :)
All is forgiven.
Now go get qooxdoo, it is as good as it gets, the Lisp of JS frameworks.
But you knew that! Thx again for the heads up on that.
cheers, kzo