Ruby performance woes
in [Lisp]
|
Prev: comp.lang.lisp charter
Next: Casio Collection Men's GOLD LABEL Edifice Watch - Replica Watch Fake
From: Jason Nielsen on 22 Apr 2008 18:46 On Tue, 22 Apr 2008, Duane Rettig wrote: > > Or perhaps become implementors of those languages themselves: > > http://common-lisp.net/project/clpython/ > Too bad it only runs on Allegro as I doubt this project will gain any traction among the Pythonista relying on a commercial lisp as its "vm". If a common lisp system was the "jvm" of today I'd be a happy man... an open source common lisp system of course ;-)! Jason
From: Willem Broekema on 22 Apr 2008 18:59 On Apr 23, 12:46 am, Jason Nielsen <j...(a)cs.sfu.ca> wrote: > >http://common-lisp.net/project/clpython/ > > Too bad it only runs on Allegro CLPython works completely on LispWorks as well. The website is outdated, sorry about that. The porting was done in the last weeks, to have something to brag about at the ECLM last weekend. Support for CMUCL or SBCL is next, then it's time for a 1.0 version. - Willem
From: Jason Nielsen on 22 Apr 2008 19:11 On Tue, 22 Apr 2008, Willem Broekema wrote: > On Apr 23, 12:46 am, Jason Nielsen <j...(a)cs.sfu.ca> wrote: >>> http://common-lisp.net/project/clpython/ >> >> Too bad it only runs on Allegro > > CLPython works completely on LispWorks as well. > > The website is outdated, sorry about that. The porting was done in the > last weeks, to have something to brag about at the ECLM last weekend. > Support for CMUCL or SBCL is next, then it's time for a 1.0 version. > > - Willem > Well I stand corrected by the man himself ;-)! Just out of curiosity I'm assuming you have dropped the reliance on Allegro's version of yacc. What of the environments stuff? If there is nothing major stopping porting I'd be happy to help out with the leg work of adding a few #+sbcl (sb-pcl:.... etc. to get this working on sbcl and cmucl. Jason
From: Brian Adkins on 22 Apr 2008 21:29 On Apr 22, 3:52 pm, Ken Tilton <kennytil...(a)optonline.net> wrote: > Scott Burson wrote: > > Just came across this... > > > http://www.regdeveloper.co.uk/2008/04/21/bray_ruby_rails/ > > > You'd think there would be some way for Lisp to fill this gap. > > http://gitorious.org/projects/hunchncells "Yet another web-framework. This one uses cells and XMLHttpRequest to create dynamically updating models on the server that update their state on the client. The dynamically updating bit isn't working yet but hopefully we'll have it working by the time anyone notices this." Too late.
From: Brian Adkins on 22 Apr 2008 21:46
On Apr 22, 3:01 am, Scott Burson <FSet....(a)gmail.com> wrote: > Just came across this... > > http://www.regdeveloper.co.uk/2008/04/21/bray_ruby_rails/ > > You'd think there would be some way for Lisp to fill this gap. There's not much of a gap to fill. Sure, Ruby is dog slow, but the number of customers it takes to saturate a reasonable dedicated server running Ruby on Rails is substantial enough to make the cost of the server a *non-issue* for a very large set of web apps. Now, if you can get an equivalent, or superior, development productivity (I'm referring to web apps only) with a Lispy solution along with faster speed, that would be fantastic, but given the track record, I think we'll see dozens of mediocre (at best) web frameworks spring up rather than one good one that provides the productivity close to Rails. Python had a diffusion of frameworks also, but Django seems to have taken enough of a lead to gather a community. I had high hopes for Arc ( http://arclanguage.com/item?id=6245 ), and those may be realized someday; however, it still lacks many important features and seems to have stalled out. |