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.) Inst

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.