On Sat, Jun 29, 2013 at 12:12 PM, Craig Brozefsky <craig_AT_red-bean.com>wrote:
> Andrew Gwozdziewycz <web_AT_apgwoz.com> writes:
>
> > I don't speak for the suckless community, but despite the fact that I
> > love it, Lisp is complicated and not very simple at all, which I'm
> > guessing is why you don't hear about it. I'm currently playing around
> > with attempting to make a minimal, embeddable, unix friendly, without
> > complications dialect, called tin. I have no idea if I'll succeed in
> > any of those goals, but it'll be fun regardless.
>
> Fun project, but I disagree 8^)
>
> Lisps (and I include scheme varianets in this) are very simple languages
> for the most part -- with obvious exceptions like Common Lisp. Minimal
> syntax, a few natve data types, programs are code, and functional
> composition.
>
> The runtimes however can vary in complexity depending upon their
> implementation goals. Highly performant lisp means an intelligent
> compiler. A common lisp design trope is to pay complexity costs in
> implementation for maximizing simplicity of use.
>
I include Scheme as well when I reference Lisp--also Clojure. While I agree
that Scheme is relatively simple, this simplicity doesn't really bring much
to
anyone. Anyone trying to make practical programs in scheme must go past
the standard, and seek an implementation the basis to be able to support
the practical goals. There's a million and 1 implementations, and they all
have various warts and reasons why you might not want to use them.
I can't imagine trying to sanely embed Chicken, for instance. I can imagine
writing a scheme program that utilizes the FFI to produce an executable
directly from Chicken, of course. But, then the entire program is exposed
to the "Cheney-on-the-MTA" technique, which certainly has some overhead
compared to the finally tuned C, sprinkled with some of the embedded
language approach.
Racket is just plain huge. It's goals don't align with simplicity at all.
Gambit, and the rest of the "compile to C" Schemes just don't have
a big enough community to make it possible to *not* have to do everything
yourself.
And, none of these really play nicely with POSIX, and if they have some
layer of compatibility, it's completely awkward to use.
Common Lisp suffers from the same sorts of things. It's spec is hundreds
of pages, and is that way for portability and practicality--only it doesn't
define anything related to the OS, which means again, the implementation
must provide it, and every implementation provides it slightly different.
This
requires packages that exist to conditionally do the right thing across
the various warts of each implementation... Not very simple.
Clojure--well, just being on the JVM complicates that for practical
purposes.
If you consider Go, Python, Lua--even Perl, they have relatively few
concepts that one needs to learn to utilize before they become really
productive languages. You don't have to worry about how to specify
filesystem
paths as in Common Lisp, because in these other languages you just do it.
Maybe they provide you with a library that helps be portable (Python for
instance
has os.sep, which is either '/' or '\' depending on POSIX vs Windows), but
you
just don't give a shit most of the time.
In Scheme, I can't break out of a loop without understanding continuations,
or
restructuring loop such that conditions that should break me out of the
loop
are flagged in a recursive "final step" sort of way.
Lisps are loaded with this sort of stuff, and while I love it, and enjoy
using them
thinking about them, reading about them, they just aren't practical for
mortals
who are used to PHP.
Final thought: Have you ever actually tried to embed Guile? Oh man, is that
fun. (And, I LOVE Guile) Tinyscheme is a much better experience when
embedding, but it's not exactly a practical implementation...
--
http://apgwoz.com
Received on Sun Jun 30 2013 - 14:06:41 CEST