On Tue, 2009-01-13 at 18:00 +0100, Wolfgang Mederle wrote:
> Slobodan Blazeski wrote:
>
> > It's not just Microsoft. Friends of mine got a Photoshop for free
> > through some learning course for noncommercial use. After a several
> > years when he become a good graphic designer and opened his own studio
> > and even hired some folks to help him. What do you think he's using
> > now GIMP? Oh no he bought licenses for him and his employeess
> > And it's not just the big boys. One of the former companies I worked
> > for used the noncommercial only database driver because programmers
> > hated the preinstalled one, after few months the manager had no choice
> > but to buy license. The other got UI widgets with something like
> > unlimited time trial. When application was built with those widgets
> > and it got online and they went to purchase licenses, you know what
> > was the answer? Guys wait for few months to see if your app is making
> > you money then you'll pay us if our widgets helped you. Now they made
> > money licenses, and got their reference clients amd applications. Also
> > there is a network effect of programmers leaving for other companies
> > and spreading the word, because they're famigliar with those widgets.
> > Another colleague of mine spread those widgets through 4 companies he
> > worked for in the previous years and at least 2 dozen of projects.
> > Lisp vendors aren't competing with themselves or OSS implementations
> > they're competing with other languages. And unless the word is spread,
> > lisp will stay IRRELEVANT.
> > Now it seems that lisp vendors are eating the corn seed.--
>
> I don't get the Lisp vendors in this respect. I wrote my Magister thesis
> in Common Lisp, and I got weird stares for my choice of language from my
> Professor already. I wanted to make the case for CL at the institute
> where I studied. When I asked Xanalys whether I could have a full
> version of their implementation for writing my program with it, they
> brushed me off suggesting to use the personal edition or wossname, which
> was of no use because of the limited heap space -- my app was built
> around large hash tables.
>
> In the end I used cmucl and stuck a TBNL-based web interface on it
> instead of a nice GUI. It was enough for my purposes, but didn't look as
> impressive as it could have, and installation of the system is daunting
> to say the least*, so after my thesis was done, the project was dead for
> the institute, no matter how good it performed.
>
> There was nothing to lose for Xanalys, as I could not have afforded
> the full version of Lispworks as a student in any case, but a lot to
> gain. That was pretty disillusioning to me. Microsoft knows that you
> need to get them as students.
>
>
> Wolfgang
>
> * CMUCL, Emacs, SLIME, screen, asdf, cl-ppcre, split-sequence, TBNL,
> cl-who, Apache, mod_lisp, if I remember correctly. Not for the faint
> of the heart.
>
Hmmm .. there is a difference between installation/distribution and
setup and configuration of a development environment required for some
library or application, regardless of languages/tools.
What about just dumping an executable core and compressing it (about
10-15mb with SBCL) and .. go?
mod_lisp isn't used anymore, people just use the standard mod_proxy now
and it is already available at the touch of a key or two in most cases.
So installation from a user p.o.v. is basically reduced to:
* Downloading a compressed core dump.
* Configuring the mod_proxy module of your HTTP server/frontend
(Apache or other). This is very simple; any newbie admin can do it.
* ..then start the executable core dump under screen or detachtty.
It'd probably be nice if this happened on bootup, so just basic
admin skills again; place something that executes the core dump (as
correct user) under screen in /etc/rc.local
So that's installation/distribution how I do it or tell my users to do
it. It's actually _much_ simpler and nicer than dealing with the
surprises that show up in, say, PHP between minor versions IMHO.
I agree with the other things you say; it's probably a good idea to
think a bit long term .. it's very simple strategy.
Lars Rune N�stdal wrote:
> Hmmm .. there is a difference between installation/distribution and
> setup and configuration of a development environment required for some
> library or application, regardless of languages/tools.
>
> What about just dumping an executable core and compressing it (about
> 10-15mb with SBCL) and .. go?
This was a very memory-heavy app that used around 1 GB of RAM. I'd guess
that would make for a huge core file. I cannot remember if I tried
that -- I finished my thesis in 2005.
I wrote a Mac app once that formats phone numbers in Address Book
correctly. The frontend was made with AppleScript, so I made the whole
thing an AppleScript bundle that contained a complete cmucl runtime.
Worked only on a specific version of OS X 10.3, but nicely on that.
Installed with drag & drop, started by clicking the icon.
> So that's installation/distribution how I do it or tell my users to do
> it. It's actually _much_ simpler and nicer than dealing with the
> surprises that show up in, say, PHP between minor versions IMHO.
In case of my thesis, you'd have no problem getting it to run on a
current cmucl, provided you have the source code for the program plus
the code of the libraries in the versions I used. TBNL is obsolete these
days, for example. (If I worked on the program again, I'd use
Hunchentoot standalone instead of Apache.)
--
Wolfgang Mederle
<URL:http://mederle.de/>