On Sat, Jun 29, 2013 at 12:12 PM, Craig Brozefsky <cr...@red-bean.com>wrote:
> Andrew Gwozdziewycz <w...@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