The Nature of Lisp (2006) | Hacker News Reader

The Nature of Lisp (2006)

defmacro.org

54 pointsb-man33 comments

Commenting on the last paragraph: I honestly believe that one of the biggest obstacles for newcomers to Lisp is Emacs.

Don't get me wrong, I love Emacs and it is truly the superior environment to do work in Lisp. However it has a bit of a steep learning curve just like Lisp itself and fighting two battles (one with Lisp and one with Emacs) is no easy task for someone coming from a Java / C# and Eclipse / Visual Studio background. I know because I've been there. That's why I decided to start work on an open source Visual Studio add-in to support for Common Lisp in Visual Studio itself. I think being able to do the first steps in a familiar environment would be a great help for newcomers. I wonder what you guys think of the idea?

Did you ever tried Drscheme?

Yes, DrScheme is awesome. However, I was specifically thinking of supporting Common Lisp, not Scheme as Scheme already has enough friendly tools for beginners.

How about cusp[1] then? It is an eclipse plugin. Never tried myself, but it could be a starting point.

[1] http://sergeykolos.com/cusp/intro/

Yes, I've never seen that one before but it definitely looks promising. I'll have a look at it and see what it can do.

Why not just bootstrap knowledge of Common Lisp by learning Scheme first, then?

You want LispIDE

http://www.daansystems.com/lispide/

Hardly a substitute for Emacs/Slime, but for beginners, you can get a lot done. I use it when I am not plugged into in A/C outlet; it saves battery ;-)

Yes I know LispIDE, however it is really nothing more than notepad.exe with syntax highlighting and some basic REPL integration. I think of the VS F# editor with REPL ("interactive mode" as it is called there) as an example of what I'm trying to achieve.

The other way round could also work: Make people use Emacs for C first, then switch them to Common Lisp.

(However I like Scheme better anyway.)

I started using emacs as a C programmer; even for C, emacs was a great environment, especially back in 1989; good integration with the compiler and cvs, auto indent, syntax highlighting, etc..

As a C# developer in my day job, I think that is a completely awesome idea.

An oldie but goodie. This helped explain a lot of the often-praised features of Lisp and functional programming that had never made sense before.

Older post: http://news.ycombinator.com/item?id=127736

Ditto. Thanks to the RethinkDB guys for doing these all those years ago...

Yes. However keep in mind that Lisp has left the forefront of functional programming mostly to ML derived languages.

Common Lisp isn't even very functional. Not much more than e.g. Python. Scheme is a bit more functional oriented.

Clojure, OTOH, is beautifully functional. Also, it is supported by NetBeans and Eclipse, so no SLIME needed.

Yes, I forgot about Clojure.

> Lisp has left the forefront of functional programming mostly to ML derived languages

I'd be grateful if you could expand upon that statement. I'm a Lisper, and half the time I see one of these Haskell articles, I wonder if there really is a there there. For sure, functional programming can be a whole lot better than CL or Scheme, but I'd like to know if the difference is significant.

Depends on what you want to achieve. If you leave out the dimension of static vs dynamic typing, you could get most of Haskell's benefits by making your Scheme pure, and confining side-effects. (Monads are one solution for this, but not the only one. Have a look at Functional reactive programming, or see how Clean uses linear typing.) You could probably hack most of the pureness stuff together with macros in an already existing Scheme.

Purity by (strong) default makes it easier to combine your programs. Lazyness can help, too, but I am not completely sure whether you should make lazy the default. Chris Okasaki's "Purely Functional Data Structures" argues for needing both lazy and strict evaluation to guarantee asymptotic run times.

Have a look at, say, Software Transactional Memory to see what purity can buy you. Combinatorial parsers are another interesting application in Haskell; however they should be easily implementable in Scheme, too.

Please have a look at how http://www.cs.kent.ac.uk/people/staff/smk/redblack/rb.html uses the type system to statically guarantee the balance of red-black trees.

Please pardon that I mostly talked about the `how' and not so much the `why'. I hope giving some examples might not totally be in vain.

I know. The article covers both (or did I mix it in with another of coffeemug's articles?). But coming from C# 2.0, Lisp's functional-supported-but-optional was still a big jump.

Yes. Lisp is an acceptable functional language, and its communities also value functional approaches. (Whereas Python gives you almost the same support from the language, but much less from the communities and libraries. (My main grief is that dicts only have side-effecting operations.))

> After all, I was almost blinded by the infamous Lisp parentheses!

Lisp's parenthesis seem to share their deterrence factor with Python's significant indentation. Most people who have used one of them for a while don't even notice them any longer. At least not as a problem.

Interestingly, Haskell seems to be strange enough, that nobody fears its significant indentation.

If it's any consolation, I do not like its line noise. I already work with perl. I wanted to step up towards beauty.

Yes, Common Lisp is somewhat ugly. Scheme looks nicer.

I meant Haskell. :) Turns out CL is pretty light on the funny syntax, and the few places it is used are optional -- but nice.

OK, I guess then I just have different preferences. I find Haskell much more bearable than CL in terms of beauty.

Scheme is nice, too.

I have heard similar opinions on Haskell. I am definitely attracted to the convenient function currying and composition, but I realized I could do similar in CL and make it look like whatever made sense to me. I find the ability to create my own look and feel to supercede accepting someone else's look and feel.

I have no issues with Scheme, except that I have chosen to use CL over Scheme because it does feel like something of a batteries-included system.

On the other hand, I was annoyed by what I felt was inconsistent syntax with Haskell revealed in Real World Haskell chapter 13 (unfortunately my only experience with it) when they showed this function definition:

  mkFuncRec :: String -> (Int -> Int) -> FuncRec

vs this function definition:

  simplify :: (Num a) => SymbolicManip a -> SymbolicManip a

The =>, previously used to instance types, confused me here (they never explained how this definition differed), and I was having a hard time keeping up with all the various times I needed to use each special symbol. Of course, I tolerated it through C++ and perl, so if I ever decided to try a project, I could probably get used to it.

I see that the namespaces for values and types are somewhat separate in Haskell. Could you please describe your confusion again in different words?

Perhaps I am too used to Haskell, but I do not see anything confusing in those two definitions. What do you mean with "previously used to instance types"? As far as I can remember => is only ever used in the context shown above.

The book introduced the second pattern out of the blue. What is the difference between those two function definitions? What does "=>" mean in this context? a :: b -> (c d) -> e makes sense to me, but f :: (g h) => i -> j -> k does not.

Here is the page that suddenly introduced that second form: http://book.realworldhaskell.org/read/data-structures.html

It is entirely possible I missed some context somewhere in there; "namespaces for values vs types" might be my clue. :)

In the example

  my_fun :: (TypeClass1 a, Typeclass2 b) => a -> b

the stuff preceeding the => declares what typeclasses the types you mention later should fall into.

A good example is the module Data.Map; this module deals with finite mappings of keys to values. Since those Maps are based on balanced trees, the keys have to be orderable/comparable. So for inserting a key into a map (http://hackage.haskell.org/packages/archive/containers/0.2.0...) we get the following type

  insert :: Ord k => k -> a -> Map k a -> Map k a

This just says that the type of keys has to be an instance of the class Ord (http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0...). I.e. there has to be an instance declaration with the function

  (<=) :: a -> a -> Bool

Does that help?

By the way, if you want to find documentation about a function and you know its name or type, you can use Hoogle (http://www.haskell.org/hoogle/).

the stuff preceeding the => declares what typeclasses the types you mention later should fall into.

That makes it clear. Thank you!

Interesting. I instantly liked Python's significant whitespace. It just made sense: I was already indenting for readability, so why not make it meaningful as well and do away with curly braces and semicolons?

It was the same for me. Plays nice with "Say it once and only once.".

Reply on news.ycombinator.com