Hacker News new | past | comments | ask | show | jobs | submit login

TL,DR: repeats old misconceptions.

Task: go to the Apple Macintosh App Store. Download Clozure CL. Get Quicklisp. Get libraries. Start hacking. Connect via #lisp, reddit/lisp, the CLozure CL mailing list. Put your stuff on Github, make it available via Quicklisp.

http://ccl.clozure.com/ http://www.quicklisp.org/

Have fun.




I grabbed Clozure CL. Started it up, got a REPL. Wanted to know what I could do with it, so I went searching for help. The help is a silly, mostly empty window that starts with "Aren't you glad you waited so long to see this window ?" The first hyperlink in it is broken. The second (and only other) hyperlink takes me to something about OpenMCL, whose relationship to Clozure CL is a complete mystery to me.

Giving up on the help, I go back to the REPL and try some basic things. I quickly discover that this REPL window lacks essential features like pressing the up arrow to get the last thing you typed. And that was the point where I came back to my web browser and started writing this reply.

I realize these are small things to nitpick in the grand scheme of things, but it's such a horrible first impression compared to what I get from e.g. starting up Python for the first time.


This parallels my first exposure to scheme with guile, but in truth most repls suck more than they should. I can rant about pretty much all the ones I've ever used. With guile, I learned at some point that I had in fact built it with GNU readline support, and that I could activate it by putting in ~/.guile (analogous to $PYTHONSTARTUP):

    (use-modules (ice-9 readline))
    (activate-readline)
Ahh, much better. Later interaction with Gambit Scheme was much nicer. Clisp was alright, more or less the same experience as Gambit. I hear DrRacket is nice but haven't tried it. Clojure uses jLine, so it's finicky. (I hate jLine.) Oh wait, I lied. You can use jLine, but it's not default:

    alias clj='java -cp /home/kevin/clojure-1.3.0/jline-0.9.94.jar:/home/kevin/clojure-1.3.0/math.combinatorics.jar:/home/kevin/clojure-1.3.0/clojure.jar jline.ConsoleRunner clojure.main'

But I like that Clojure has built-in (doc) and (dir). I like Node's colors and it has decent tabcompletion. PyPy's REPL is probably the coolest out-of-the-box experience I've had--it reminded me of MySQL with how it helpfully gives you edit access to a whole chunk of code you wrote over multiple lines with one up-arrow. PyPy did it better, though. I've used emacs' Slime before, it was pretty sweet, but I'm a vim guy. (I'm aware of the various screen hacks to get a more or less the same experience.) I haven't messed with R in a while but I remember it offered to save the state for next time I launched.

I totally agree with you that first impressions matter. If command history and a sane consistent parsing of left/right/backspace/delete aren't features in your repl it's unusable, I can tolerate other deficiencies. It's especially annoying when REPLs are encouraged by the users of some language and they still stink. Python's (before I started using PyPy even!) is really the only one I've spent a lot of time in building a program, iteratively, albeit that's after disabling those annoying '>>> ' and '... ' prefixes so I can copy/paste-file/save/modify/paste-repl variations back and forth without pain. The rest of the repls I use mostly for isolated "will this work" style of questions since it's faster to check with the computer than simulate it myself in my head.


Regarding Clojure and JLine and the general niceness of REPLs, honestly I thinks it's a bit of a distraction. You don't need JLine at all, if you want to run a Clojure REPL in xterm or Terminal.app, just use rlwrap.

Most people who end up doing serious Clojure development move on to something more integrated, like SLIME for Emacs, slimv or the screen hacks you mentioned for vim, or Counterclockwise for Eclipse. I would much prefer the Clojure/core devs work on making Clojure awesome than re-inventing readline.

Anyway, once you've used the SLIME analogue for your language of choice, where you can select regions of code in your editor buffer for evaluation, copying and pasting to and from a REPL seems rather quaint.

I agree somewhat that first impressions are important, but I think that most programmers spend more time thinking than writing code, and that's especially true when you're first learning a language, and it's a big shift from that languages you know. I don't think that unfamiliarity with the tooling should be this big turn off, yet everyone makes it out to be one. When I started learning Clojure, my first impressions were based on the features of the language, and that's way more interesting than the fact that clj is a bit raw and rough around the edges.


Overall I agree with you. When I was a newbie programmer I was turned off by Python's forced indentation, and that cost my younger self about 6-8 months (when I looked at it again) of fun times that could have been had earlier. Now I'm capable of looking past the blemishes when trying something, but if it's a particularly grating blemish I'm going to spend less time looking at it by nature. (Thanks for the reminder about rlwrap, I was trying to remember what that command was called a few days ago. I hadn't considered using it instead of jLine as I've had bad experiences with it as well; a minute of playing around indicates it's at least as good. Which is sad for jLine. I wonder if `lein repl` uses jLine or rlwrap...)

I suspect I'll eventually outgrow my quaint process of copy/pasting here and there and embrace some variant of vim-slime. I agree most programmers spend more time thinking than writing code, but the two aren't so separate; what I like tremendously about repls in general is the ability to think with the aid of the computer, it speeds things along a lot. When the computer and I produce something worth keeping I save it. Of course I like my couch sessions (in lieu of a hammock) when they're needed.

It's easy to make it seem like a problem is bigger than it is. For all the ranting I can do about repls for various systems, it's not that big a deal in the grander scheme of things. (With repls specifically it's just an annoyance that readline behavior isn't default like it should be, not necessarily unfamiliarity with the ecosystem at large.) If the biggest criticism of Clojure is its crappy default repl, then one should think it must be a killer language if no other criticisms were mounted instead. (Personally I've only done a few applications with it but I'm already convinced it's fantastic even if I can think of some issues more important than the repl.)


Have you tried pry for ruby?


OpenMCL was renamed to Clozure CL several years ago. It was called OpenMCL, because it originally was an open sourced version of MCL, Macintosh Common Lisp.

The Up-Arrow is for textual navigation in the Listener window. Like in a normal text editor window, which it is based on.

A typical way to use the history in Clozure CL is to move with the cursor keys to the input of interest and press RETURN to have it copied to the current prompt.

To get the last things you typed, press option-p. 'p' as in previous. As in Emacs, since Clozure CL has an Emacs-variant (derived from called Hemlock) at its core. But written in Common Lisp.


Just took a look at QuickLisp and that's a big improvement over the last time I looked at Common Lisp. On the other hand, there's a couple of points to make.

1) While quick lisp does have an amazing array of packages, there's still some simple, yet glaring deficiencies. For instance, there's no package to talk over a serial port. If I go to Google, the top link is a stack overflow post with some code on how to do that on Windows. The next few posts links are either people being told to use the FFI or raw writing to /dev/stty with the unix command line being used to set the tty parameters.

Comparatively, the first link Google returns for python is for PySerial, which will handle all the serial port settings on its own.

I was originally going to use this as an example of contrasting documentation, since I assumed that both languages would at least have a serial library.

2) If I want to send an e-mail, quicklisp offers cl-smtp and smtp4cl, while python mostly just offers smtplib. On the other hand, the documentation for smtplib (http://docs.python.org/library/smtplib.html) is readily available, while cl-smtp is limited to the (admittedly clear) README file.

---

I happen to love the lisp aesthetic (though I'll admit to preferring scheme over CL). Still, the main thrust of the article is that Lisp is cursed with a disorganized array of unsupported, poorly documented, incomplete solutions. QuickLisp has only solved the disorganized part of that. If there's a bug in smtplib, I can feel pretty secure that it will get fixed. Honestly, I bet I'd have the same luck with cl-smtp, but what about smtp4cl?

I don't believe that it's a curse and I do think that it can be solved. However, this is a cultural problem in the lisp community and ignoring it. To put it differently, if we'd had this discussion four years ago, someone would have brought up asdf and said that that solved all the problems. However, we now have QuickLisp because asdf wasn't solving all the problems. It's great and things are better than they were, but we're not done yet.


ASDF and Quicklisp are two different things. Quicklisp uses ASDF.

ASDF hasn't solved many problems. It was basically another system definition tool (with a different license). We had them before. What ASDF provided was that open source / free software used a common system definition.

Quicklisp OTOH provides a service. It uses ASDF. I provides library management and a collection of libraries.

The process over that to improve these libraries, make them better documented / more portable / rated / ... is something that happens over time.

Quicklisp does not solve all problems. It does not aim to. But it solves some.


I agree with you completely. QuickLisp does a damn fine job of solving some major problems. Honestly, looking through QuickLisp while writing up my post has made me consider moving from scheme back to CL for the first time in a long time.

My comment about asdf mostly comes from my experiences back in 2005 when I repeatedly heard that Common Lisp had NO problems and that asdf was so superior to CPAN or rubygems that there was no need to implement a new package system. In the same way, I often heard that we didn't have an issue with insufficient libraries, since UFFI (or was it CFFI?) has solved all of that. I wouldn't have been surprised if those same commentators would today declare that QuickLisp has solved everything.

However, those conversation that I had back in 2005 were not with you and I apologize for putting words in your mouth.


1.) You named one deficiency. You Googled it and although there were answers, you didn't like the answers that you received. Please enumerate the other deficiencies so I can laugh at how incredibly lame your perceived problems are.

2.) The docs for smtplib are longer than the code for cl-smtp. You'd get going quicker by reading the code and examples (tests) included in cl-smtp. Docs are wrong as soon as someone forgets to update them anyway.

---

We have had this discussion for much longer than four years. The problem is people whine about not having documentation, but refuse to put in the effort to go document libraries themselves. Same with serial ports.

How long does it take to write a few CFFI wrappers and put them on Github? If you want it so badly, do it yourself. Of course, you'd rather just use Python, which is fine, Python is fine... Norvig likes it too. You probably already know Python. Python is safe, Python is your friend. The reality is that you are justifying your perfectly reasonable desire to stay in your comfort zone with python by saying 'blah library doesn't exist'. Creating 'blah library' sounds like a perfectly reasonable place to start learning the language to me.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: