looking for a Lisp job..
Alex Mizrahi
some 10 months ago I've left my C++ job to do some projects of my own -- I
had some interesting ideas to be applied in social web sites field, using
kinda advanced information retrieval technologies (there are more than
enough bare 'web 2.0' stuff already..).
needless to say, I was using Common Lisp for programming, but my faith in
CLISP/SBCL/CMUCL is low, and I couldn't afford ACL/Lispworks, so I had a
strange CL implementation of choice -- ABCL. i though i could benefit from
Java libraries, and if something went wrong i could switch to Java.
indeed, sometimes ABCL turned to be pricky -- sometimes I had to "debug a
debuger", but general experience was quite fine -- Java libraries were
useful, I didn't have much problems with deployement.
i've released a "framework" for web programming in ABCL to open source --
http://abcl-web.sf.net/. additionally it had some lispy wrappers to Jena RDF
library, that are quite synergetic with LML2 HTML generation. although there
was no much interest in my stuff, there were some downloads.. maybe it can
be interesting to somebody..
but in this 10 months I was not able to get anything commercially successful
(or at least potentially profitable) -- it appears i've focused too much on
complex information retrieval stuff, and it was too hard for me -- it can be
gradually improved for a long, long time.. hacking ABCL stuff took some time
too..
maybe if i'd focus on a web stuff more than on improving info retrieval
parts, i could do some interesting sites and it would be better..
but i think my main problem was that i didn't have "co-founder" -- perhaps
if at least one more person was at least partly working on this project, we
could communicate, discuss, better prioritize things, and finally deliver
something interesting.. (i actually communicated with one of my friends on
this matter, but it appears it was not enogh intensive communication to
change things).
actually i remember one of "on startups" articles said interesting thing,
that "co-founders" are critical, and it's one of programs of Lisp -- it's so
powerful that even one programmer can do a lot of stuff. so often there is
only one guy in a project -- and that is very bad for a project.
contrarily, C is so hard that it requires a lot of programmers to do
something working -- and actually people who managed to gather in quite a
big group tend to be more successful. additionally, there's a problem that
Lisp is not that popular, so it's simply much harder to found fellows..
ok, i had quite interesting affairs in these 10 months, and i could continue
on this, but i'm out of resources, and i think continuing doing this stuff
in full time is not feasible.
so i'm looking for payed job -- preferably with Common Lisp, of course :). i
know there are not much of those -- but who knows, maybe there are projects
looking for developers now?
i think story above says about me much better than some boring resume/CV --
at least for people who feel such stuff ;). (i also hope this story can be
somewhat interesting to people here, more than boring job request). besides
programming stuff i have master degree in applied math, so i know math and
algorithms stuff.
as for job, i'm certainly looking for a remote job, because i don't think
there are Lisp jobs anywhere in my region. i'm living in Eastern Europe,
living is less expensive here than it is in Europe and USA, so i can have
few times less wages -- a benefit for employer. (i know programmers in USA
and Europe hate outsourcing stealing jobs from them, but there's no much
problem with Lisp outsourcing so far, ye? :)). as for nature of job, i think
i'd prefer some smaller tasks, but it's discussable.. and i'm sympathizing
to open source and "startup" stuff..
P.S. i've already asking about job in this newsgroup in 2005, sorry. i've
even got few replies that time, but suddenly i've became very busy for a
project for my master's degree (it was in Lisp, btw, ABCL too). hope this
time i'll get more lucky..
P.P.S. no "there are no lisp jobs" replys this time, please.
with best regards, Alex 'killer-storm' Mizrahi.
dpapathanasiou
> needless to say, I was using Common Lisp for programming, but my faith in
> CLISP/SBCL/CMUCL is low, and I couldn't afford ACL/Lispworks, so I had a
Just out of curiosity, why do you say that about CMUCL? We use it for
a production app without any problems.
> ok, i had quite interesting affairs in these 10 months, and i could continue
> on this, but i'm out of resources, and i think continuing doing this stuff
> in full time is not feasible.
> so i'm looking for payed job -- preferably with Common Lisp, of course :). i
> know there are not much of those -- but who knows, maybe there are projects
> looking for developers now?
There's a blog dedicated to Lisp jobs at http://lispjobs.wordpress.com/
and you can also post a "Lisp Job Wanted" article about yourself
there.
> as for job, i'm certainly looking for a remote job, because i don't think
> there are Lisp jobs anywhere in my region. i'm living in Eastern Europe,
> living is less expensive here than it is in Europe and USA, so i can have
> few times less wages -- a benefit for employer. (i know programmers in USA
> and Europe hate outsourcing stealing jobs from them, but there's no much
> problem with Lisp outsourcing so far, ye? :)). as for nature of job, i think
> i'd prefer some smaller tasks, but it's discussable.. and i'm sympathizing
> to open source and "startup" stuff..
YC has a jobs page at http://news.ycombinator.com/jobs
They're all startups, looking for hackers, so they might accommodate
your remote work request, but they're not all Lisp-based (Python seems
to be the preferred language there).
VC websites in general are good places to look: if a VC has funded a
company, chances are they're using that money to hire people.
Good luck in finding what you want.
Alex Mizrahi
(you :wrote :on '(Thu, 23 Aug 2007 13:09:14 -0000))
(
??>> needless to say, I was using Common Lisp for programming, but my faith
??>> in CLISP/SBCL/CMUCL is low, and I couldn't afford ACL/Lispworks, so I
??>> had a
d> Just out of curiosity, why do you say that about CMUCL? We use it for
d> a production app without any problems.
basically: just not enough faith :).
i've already evaluated CMUCL for web development few years ago (actually
i've made some small CMS site for Universty in it).
i think CMUCL lacks good threading -- i believe threading is a good thing
for web development in general, and especially when we have multicore
processors now, so threading means scalability. threading that is present in
CMUCL, besides it's not native threads, is a bit freaky -- maybe mostly
works, but docs say it can bang (and i know it was banging at least with
debugger). CMUCL with threads is called Scieneer and is sold for big bucks.
there were some problems with I/O -- people said that way implemented in
mod_lisp should work, but i had perfectly reproducible problem with it.
there was a workaround, but this made me a negative impression.
i've made a little benchmarking -- something like ab, some thousands
sequentual requests in several threads. it handled most of 10000 requests
perfectly, but there were one or two blank pages. i dunno why, but i didn't
like it..
CMUCL/SBCL doesn't work on Windows. and they are not always working on Linux
too -- they require large address space chunk. it's not possible to get it
on some VPS hosting plans.
i don't know about CMUCL, but SBCL sometimes says "heap exhausted, good
bye". maybe CMUCL does it too?
that's critical to me, because i work with large data sets, and from time to
time i get low mem conditions. in this cases Java-based ABCL nicely signals
an error, and i can retry my stuff with less items, for example. but if SBCL
was banging to death in this cases, that would be really annoying.
it would be even more annoying if it will happen on a production server.
actually i was benchmarking UCW in SBCL, and when it have allocated enough
continuations, it said this goodbye thing -- this was a negative impression
again.
well, maybe if i had faith in CMUCL it would work for me quite good,
nevertheless :)
additionally, i had some reasons to use ABCL -- besides Java stability,
threading and cool parallel/incremental GC, some Java libraries were useful
to me. one of them is Semantic Web lib -- Jena is a high-quality library,
and it was very easy to wrap it with FFI. as far as i know, Common Lisp has
only toyish stuff in free access, and serious stuff -- RACER and
AllegroGraph only for really big bucks.
d> There's a blog dedicated to Lisp jobs at http://lispjobs.wordpress.com/
d> and you can also post a "Lisp Job Wanted" article about yourself
d> there.
thanks
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"choose no life")
Scott Burson
> additionally, i had some reasons to use ABCL -- besides Java stability,
> threading and cool parallel/incremental GC, some Java libraries were useful
> to me. one of them is Semantic Web lib -- Jena is a high-quality library,
> and it was very easy to wrap it with FFI.
How did you find the performance of ABCL?
-- Scott
David Young
the higher-quality free implementations...
-- david
Alex Mizrahi
(you :wrote :on '(Thu, 23 Aug 2007 17:56:36 -0000))
(
??>> additionally, i had some reasons to use ABCL -- besides Java
??>> stability, threading and cool parallel/incremental GC, some Java
??>> libraries were useful to me. one of them is Semantic Web lib -- Jena
??>> is a high-quality library, and it was very easy to wrap it with FFI.
SB> How did you find the performance of ABCL?
number crunching without type declarations (anyway ABCL doesn't use them
much) is on par with other implementations, even sometimes better.
i've checked dense SVD code from an open source library -- it had some type
declarations, but there was not enough of them. performance of compiled code
in ABCL, CLISP and SBCL was pretty same, while one of commercial
implementations (ACL) was more than two times faster.
after i've added type declarations SBCL went ahead, while ABCL made no use
of them.
simple vector dot-product code was two times faster in ABCL comparing to
SBCL when no type declarations were used. (i guess SBCL could be faster with
type declarations, although it's vectors implementation is not very good
too). i've also estimated how efficient is it in CPU clocks per
multiplication -- it appears it's very efficient for a fully dynamic code.
(optimized code for specific data types should be faster).
certainly there are areas where it's slower than other implementations, and
in some cases it's even patalogically slow. one of such cases is CLOS -- for
example, cl-store is terribly slow. possibly that's some bug -- some
compute-effective-methods function gets recalculated/recompiled, or
something like that. simply there was not enough interest in CLOS
performance so far..
in general, performance in web serving and stuff was satisfying, when
patalogic stuff avoided.
results of Gabriel benchmarks
(http://www.cliki.net/Performance%20Benchmarks) showthings close to what i
experience -- ABCL has best performance in MANDELBROT benchmark on P4
processor, among all implementations. but sometimes performance is terrible.
benchmarking results on core2 processor are surprising -- number crunching
code now is slower. most likely it's a broken benchmark there -- code was
not compiled, or something like that. but there are less terrible results
there :)
but i'm using ABCL on Core2 processor, and it's quite fine, some number
cruching definitely accelerated a lot comparing to P4.
Scott Burson
wrote:
> SB> How did you find the performance of ABCL?
>
> number crunching without type declarations (anyway ABCL doesn't use them
> much) is on par with other implementations, even sometimes better.
>
> in general, performance in web serving and stuff was satisfying, when
> patalogic stuff avoided.
>
> results of Gabriel benchmarks
> (http://www.cliki.net/Performance%20Benchmarks) showthings close to what i
> experience -- ABCL has best performance in MANDELBROT benchmark on P4
> processor, among all implementations. but sometimes performance is terrible.
Okay, thanks. That's a lot better than I would have guessed (even
with the occasional pathologies). I'll take a closer look at it.
-- Scott
alexisr...@gmail.com
Thanks for sharing your experiences. I too am thinking of doing some
web / startup development and lisp would be my preferred
implementation language. So is your conclusion then that for a high-
availability site that the only real choice amongst open-source
implementations is ABCL? That's a bit discouraging - it seems that
for me the most rational choice would be Ruby/Rails or Python, though
that would be a bit disappointing as this seems to confirm the Reddit
experience.
Does anybody here have a different experience in terms of a high-
load / availability lisp-based site? I'd like to avoid ACL (due to
high-cost and lack of a comprehensive Mac implementation) though I
would consider LispWorks.
Thanks again,
--Alexis
John Thingstad
Edi Weitz and B9 write web cites in Lisp.
You can take a look at their work perhaps.
Me I'm a LispWorks fan, but opinions differe here.
Rob Warnock
+---------------
| Does anybody here have a different experience in terms
| of a high-load / availability lisp-based site?
I've been using CMUCL on several fairly low-load sites,
the busiest getting ~60k hits in the last 3 years, with
peak traffic being one every couple of seconds [like I said,
"low-load"], and even though I do use its green threads
[spawning a new one for every HTTP request] it's never
crashed on me.
[My *app* occasionally crashed in the early days, but
that wasn't CMUCL's fault! And I was able to patch it
and keep running without restarting CMUCL.]
My app infrastructure uses HTOUT <http://www.cliki.net/htout>
for HTML generation, and PG <http://www.cliki.net/Pg>
to connect to PostgreSQL.
YMMV, but I think it'd be just fine for the development
and early-deployment stages. If you had to switch to
something else later, well, at least you'd have some
realistic working code to benchmark it with!
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Alex Mizrahi
(you :wrote :on '(Fri, 24 Aug 2007 16:26:35 -0000))
(
a> implementation language. So is your conclusion then that for a high-
a> availability site that the only real choice amongst open-source
a> implementations is ABCL?
typically web sites do not really require "high availability". if it passes
your performance/stress test, most likely it would be satisfying :).
some people say that choosing platfrom beforehands is kind of "premature
optimization", and you might know, that "premature optimization is the root
of all evil".
so, if your application is portable Common Lisp, you can develop it first
(with implementation you're comfortable with), and then test it --maybe
switch to other implementation.
certainly, typically it needs also non-portable stuff like external
libraries. if there are not a lot of them, that wouldn't be a problem --
there are some compatibility libraries. it depends on what is your project
about..
about ABCL, it's a matter of personal preferences -- if you like Java, want
Java libs, and think that you can fix implementation's code written in Java,
it seems like a good choice :)
a> Does anybody here have a different experience in terms of a high-
a> load / availability lisp-based site? I'd like to avoid ACL (due to
a> high-cost and lack of a comprehensive Mac implementation) though I
a> would consider LispWorks.
Mark Battyani said:
----
The most visible web site I have is the Common Lisp Directory
http://www.cl-user.net
As for "industrial strength", today cl-user.net has an uptime of 456 days,
has served 130306440 requests so far and it's still the same Lispworks
process since the beginning. The other applications all have a similar
uptime.
----
so Lispworks looks like a good choice :).
if there would be no probems with external libs, you can develop application
with, say, SBCL, and than possibly switch to Lispworks if SBCL woudn't be
satisying.
i believe that's no unsolvable problem, just a bit more challenging than
Python (for example). but it's possible to get problem with any software
anyway :)
Alex Mizrahi
(you :wrote :on '(Thu, 23 Aug 2007 18:17:41 -0000))
(
DY> Why is your faith low with CLISP? I've always found it to be one of
DY> the higher-quality free implementations...
possibly because i've seen CLISP's source code :).
certainly there are both advantages and disadvantages.. CLISP appears to be
more portable than CMUCL/SBCL -- e.g. it runs on Windows. also it has
tunable long-float precision, that's good for numeric calculations. i was
using CLISP for solving tasks when i was in University -- that was my
implementation of choice that time.
but it completely lacks threading support, that's supposed to be bad for web
applications. it's not absolutely required -- actually it makes sense to
handle requests via Apache and serialize requests one at time. but that
could be annoying -- this can mean that REPL is not easily available in
working web-serving image, most web frameworks lack support for CLISP or
only offer only basic support etc.
also i have a feeling that CLISP has quite a lot of bugs -- both segfault
crashes and incompatibilities. possibly because of somewhat chaotic source
code.
i've found incompatibility of special variable behaviour in 2005:
initial example was a bit incorrect, but i've than reduced it to: (let ((x
5)) (let ((x (1+ x))) (declare (special x)) (print x)))
this was a confirmed bug in CLISP and it got fixed.
it's very strange to get stuff like this in 12-year old (at 2005) Common
Lisp implementation. quite possibly it was regression, but how did that come
into a public release, they don't have tests? that distracts me from using
CLISP..
Scott Burson
> Does anybody here have a different experience in terms of a high-
> load / availability lisp-based site? I'd like to avoid ACL (due to
> high-cost and lack of a comprehensive Mac implementation) though I
> would consider LispWorks.
Among commercial implementations, I would suggest taking a look at
Scieneer CL. It is a derivative of CMUCL so it has the high-quality
compiler from that implementation; plus it has robust kernel threads.
And the pricing is not unreasonable. I am using it for a data mining
project which, well, I haven't had much time to work on in a while.
But Scieneer's target market niche is high-performance web servers; I
hear that ITA (Orbitz) is using it.
(I have no financial interest in Scieneer; I'm just a satisfied
customer.)
-- Scott
Matthias Buelow
> crashes and incompatibilities. possibly because of somewhat chaotic source
^^^^^^^^^^^^^^^^
A MIGHTY understatement...
Juho Snellman
> it's very strange to get stuff like this in 12-year old (at 2005) Common
> Lisp implementation. quite possibly it was regression, but how did that come
> into a public release, they don't have tests? that distracts me from using
> CLISP..
There are many subtle points in implementing (declare special)
correctly. It's easy to make mistakes there, and it's easy to not have
written the correct test case for all corner cases, and nobody
actually gives a fuck about them in real life. So I wouldn't be
surprised if a couple of years ago most CL implementations had bugs
related to that.
Here's a cute example I found a bit over a year ago. The latest
versions I had available of clisp, ecl and Allegro seem to be broken.
And all of them in a different way!
(print (list (eval '#1=(let ((*a* 1))
(declare (special *a*))
(let ((*a* 2))
(labels ((a ()
*a*))
(declare (special *a*))
(list (a) *a*)))))
(funcall (compile nil '(lambda ()
#1#)))))
cmucl, sbcl, gcl, lispworks: ((2 1) (2 1))
clisp: ((2 2) (2 2))
ecl: ((2 2) (2 1))
acl: ((2 1) (1 1))
So really, dismissing clisp due to this doesn't make a lot of sense.
--
Juho Snellman
Michael Livshin
> So really, dismissing clisp due to this doesn't make a lot of sense.
indeed. in my experience, clisp is quite solid. once you manage to
build it, anyway.
today it is one of the most stable, mature, standard-conforming and
surprise-free lisps around. and its compiler is fast, too!
the last thing the Lisp community (I know, I know...) needs is
unfairly maligned implementations.
cheers,
--m