Hacker News Reader

Comment by leishulang | Hacker News Reader

Lisper trend to write one-liners with functions such as map, doseq etc. with big combination chains with many other functions. When doing this in a dynamic type language with no documentation, I guess that's why he calls it magic.

View on HN

I think magic is not the right word here (and I see that you do not endorse it yourself, merely attributing it to him, a distinction others are ignoring.) Instead of magic, I would call it bad or unfamiliar style caused by a habit of doing everything in a single expression with large unnamed sub-expressions. This is much easier to do in functional languages because of how well functional idioms compose with each other. Martin Odersky gave an example of this in Scala in his style talk at Scaladays. Sometimes it seems simplest to express things in one expression:

    jp.getRawClasspath.filter(
             _.getEntryKind == IClasspathEntry.CPE_SOURCE).
             iterator.flatMap(entry =>
               flatten(ResourcesPlugin.getWorkspace.
                 getRoot.findMember(entry.getPath)))

But giving informative names to the subexpressions can make things clearer for the next programmer to come along:

    val sources = jp.getRawClasspath.filter(
             _.getEntryKind == IClasspathEntry.CPE_SOURCE)
    def workspaceRoot = ResourcesPlugin.getWorkspace.getRoot
    def filesOfEntry(entry: Set[File]) =
             flatten(workspaceRoot.findMember(entry.getPath)
    sources.iterator flatMap filesOfEntry

When to use named vals instead of subexpressions is a matter of style and judgment. From my limited and dated experience, the "one big expression" style is more common and more culturally accepted in Common Lisp than in other languages I've used. You could even call it the norm. In less expressive imperative OO languages, programmers are used to using a plethora of named variables, simply because they usually can't avoid it. In languages like Scala and Clojure, there's bound to be some culture clash when people who are used to more or fewer explicit names have to read each others' code.

How in hell does 'map' qualify as a magical function? Though I suppose that for a programmer who couldn't understand a simple concept like map, damn near anything would look like sorcery to them. ( to clarify, I'm not accusing you of being unintelligent , just wondering-out-loud )

As a Clojure noob I can see 'map' and quite a few other functional things seeming seeming like magic to programmers who aren't used to the paradigm. Until you get used to thinking that way and using the tools, they seem a lot less intuitive.

I can't speak a speck of German. The words look so long and intimidating and I find that if I try to pronounce them I get lost from the beginning to the end. The worst part is that sometimes German words look like something in English and when I try to use them in sentences my German speaking friends giggle at me. German definitely seems less intuitive as a spoken human language.

There is very little that is 'magical' about a lisp-like language (in terms of the bastardized vision of 'magic' popularized by blessed hashes, operator overloading, and dynamically constructed objects in various scripting languages). There are few concepts required to understand it:

    (function arg arg) ; is the default form

And every form is passed to eval, which calls apply, which calls eval... until you get to a fully expanded form and the final call to eval.

    (map #'my-func '(1 2 3 4)) ; might eval to
    (lambda () (my-func 1) (my-func 2) ...) ; which when passed to apply might result in
    (list 1 4 9 16) ; which eval's to itself, a list object... 'list being a primitive

I just describe a theoretical evaluator (#'map is probably not implemented this way in most lisps). You can implement eval/apply in terms of a register machine if that makes you happy. Just read SICP for a good, basic description of one.

I appreciate what the Algol-derivative languages have done and what they're useful for; but there are a large class of programming problems where telling the compiler how to solve your problem for you is far more efficient than manipulating the machine with primitives. It all boils down to that eventually and lisp-like languages simply take you to higher levels of abstractions with consistent semantics.

Reply on news.ycombinator.com