Re: [dev] lisp

From: Alexander Sedov <alex0player_AT_gmail.com>
Date: Tue, 2 Jul 2013 17:32:35 +0400

2013/7/2 Andrew Gwozdziewycz <web_AT_apgwoz.com>:
> SBCL and Racket are certainly faster than Python, PHP, Ruby, Perl in most
> cases. SBCL, since it is more or less an interactive native code compiler is
> faster yet. You'll have to qualify painful. Are you referring to syntax? If
> so, no Lisper even sees parentheses.
Nah, I like parens, and I understand that they are usually made as
pale as possible, and all text editors do everything to make you write
less parens by yourself. What I was referring to is -no consistent OS
interface, -keywords straight from the land of CREAT, and -funky
(personal opinion here) abstractions of Common Lisp. Racket is great,
as it is Scheme implementation that is not slow, but the absence of
syntax still makes programs a bit less terse than I like them to be.
> Yes, the Racket (previously PLT Scheme) has certainly made it even more
> viable, but they've also made a practical, quality implementation for real
> work. Many other Lisps are similar, certainly many of the Common Lisps.
Yet there is apparently nothing non-proof-of-concept-y written in
Racket, which is sad. Maybe it's because Racket still provides nothing
other than theoretical beauty compared to C, as all other Schemes do?
There is just no niche for it.
> I urge you to check out Quicklisp (for Common Lisp,
> http://www.quicklisp.org/) and reevaluate your statement. While the
> Quicklisp + other Common Lisp library repos aren't as exhaustive as CPAN,
> they usually contain very high quality code (unlike CPAN, or PyPi, or
> whatever the fuck PHP and Ruby use). The fact that "nobody uses Lisp" is a
> huge advantage since the people who do are actually smart and very
> productive.
Or have nothing better to do...
Quicklisp is splendid. 700 packages, about a half of which are some
network protocol wrappers, and others are numeric utils in
experimental state, image handling, and html5 parsing. So, all in all,
Common Lisp looks like glue language with all these packages. Do we
seriously need another poorly supported glue language with a small
amount of libraries?
And I don't really care for the quality of library code as long as it
works and has tolerable API.
> You should not forget Kawa, Clojure and ABCL from where you have
> access to all java library stack. And there is CFFI, implemented by almost
> all Common Lisp implementation, from where you can access all shared
> libraries installed on the system.
>
> Best.
Well, nowadays every toy language out there has CFFI, and it's far
less pleasant to use than native libraries. I have nothing to say
about Java library stack because I haven't used it, bu I doubt its
usage is seamless. Correct me if I'm wrong.
Received on Tue Jul 02 2013 - 15:32:35 CEST

This archive was generated by hypermail 2.3.0 : Tue Jul 02 2013 - 15:36:05 CEST