Hacker News Reader

Comment by crucini | Hacker News Reader

Like most language advocacy, this piece implicitly compares the beloved language to one other. In this case, Java.

"Java sucks, so use language X!". Problem is, this argument works for many values of X.

I think the elevator pitch for Clojure is more like: "Java libraries without Java verbosity". Or: "Lisp finally meets the real world".

(I've played with Clojure, and found a startling contrast in seeing Java objects inside such a friendly, dynamic environment.)

View on HN

I think the shortest code example would be:

  button.addActionListener(new ActionListener()
    public void actionPerformed(ActionEvent e) {
        System.out.println("Button clicked");
    }});

vs defining a two line function then writing:

  (add-action-listener button #(println "Button clicked"))

Or maybe:

  (new Thread #(println "In thread"))

Well, although the syntax/idiom is different, the design pattern is the same the Observer pattern.

IMHO, design patterns transcend language idioms and enable people to understand/communicate higher level abstraction.

The difference to me has been that really great programming languages cause me to not notice my use of design patterns, because they become trivial. For example, Factories are basically nonexistent in idiomatic Python, because they're essentially free with the language.

As design patterns became popular in the world of statically typed, class-based OO languages that lacked first-class functions (C++, then Java and C#) there always seemed to be an emphasis on the implementation details, namely counterfeit function objects.

The higher level abstraction aspects of a design pattern are usually better expressed without introducing codewords. E.g., the Observer pattern is just, "let's call a function on objects that want notification." It's the baggage that comes along with implementing these abstractions in blub that justifies a name as a pointer.

Related to the above, design patterns connote boilerplate; all that generic code that's needed to setup the pattern in blub.

My elevator pitch is, "A slow lisp without a real object system."

I'd been half a decade since Java hasn't been considered slow, and in clojure when you really care about speed you can always go to java's level.

As for what a real object system is... does this even mean anything?

I'd been half a decade since Java hasn't been considered slow

This is precisely why snark doesn't work. Snark isn't based on substantive analysis and argument. Instead, it's the same sort of stuff that had lots of us geeks ostracized in high school. It's the hipster/school clique side of human dominance and group-think instincts.

It's the reason why such inaccurate yet ineradicable notions continue to circulate in the programming field.

If one considers oneself a thoughtful computer programming expert, leave out the snark!

slow

And yet you like Perl?! ;-)

I do not like Perl for programs that need to execute quickly.

And if your bottleneck is I/O?

If the bottleneck is development time, I use Perl. It also works well in IO-bound apps.

I don't want to say something like, "do you know who I am", but you maybe click the links in my profile before trying to convince me of Perl's merits :)

I'm no great fan of Perl - yet in its niche, performance is not a reason not to use it.

Slow compared to what? Most benchmarks I've seen show that it easily beats most of the other popular dynamic languages if you care about that. In my own experience with macro hackery you can often get very close to Java (2x-3x).

The lack of an object system is a downright feature since it forces you to take a functional approach. Most of the things you would want from an object system (polymorphism, multiple inheritance) are readily available via multimethods/hierarchies.

If you really want something CLOS-like, there's a library for that, http://code.google.com/p/explorersguild/wiki/XGModelAndGF.

forces you to take a functional approach

I don't think Clojure is really a functional langauge, it's more of an imperitive/OO mix with immutable objects. Immutable objects aren't "functional programming", they're simply common sense.

Functional programming is about composing parts of programs ("functions") with generic combinators. I have not seen anyone in Clojure doing this. Haskell is a different story; combinators are very reusable, and there is no way to combine functions (and other "categories") without them. (In Clojure, you combine program fragments by typing a closing paren and then opening a new one. Your program doesn't control its sequence of operations, a Magical Runtime does that for you. Inflexible.)

The reusability in Haskell is quite interesting; for example, application in a monad is defined as "liftM2 ($)", the usual function application operator ("($)", itself a function of two arguments) lifted into a monadic context for functions of two arguments. Cool.

The reusability is everywhere; you use the same Arrow combinators to traverse an XML document as you do to parse plain text. (See HXT and PArrows.) And of course, you compose Arrows with (.) (the function composition function), because (.) works on all Categories, not just functions.

That is functional programming; Clojure is just immutable data and parens. (Both good ideas, mind you. But it's not doing anything that Pure Java can't.)

Your definition of "functional programming" is unusual. Wikipedia defines it as:

"A programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data"

Wikipedia goes on to consider Erlang and Scheme functional programming languages, so it would seem your definition of what consists a functional programming language is more narrow than the norm. Most people would consider Clojure to be a functional programming language, just not a pure functional programming language.

I'm also not sure why you describe a language with macros as being "Inflexible". I've used Clojure and Haskell extensively, and Clojure wins on flexibility. It's a dynamically-typed Lisp, after all.

I think I am agreeing with Wikipedia's definition. What function is evaluated that makes "foo" execute before "bar" in "(foo) (bar)"?

Wikipedia goes on to consider Erlang and Scheme functional programming languages

Yeah, people have diluted the term to near meaninglessness.

Generally, in Clojure you'd write (do (foo) (bar)). The do form tells Clojure to evaluate its arguments in order. Some forms have an implicit do, e.g. (when x y z) is (if x (do x y)), but in general the order in which forms are evaluated depends on the form containing them.

> I have not seen anyone in Clojure doing this.

Sounds like you need to get out more.

Thanks for the link...

I decided to take a look at your Clojure code on Github, and I am not seeing anything functional. Lots of OO/imperitive things going on; global variables (all instances of your HTTP client share the same cookie jar?), mutating objects, standard "imperative" control-flow (try/finally, with-<foo>, etc.), and so on.

It looks basically like Emacs Lisp but with fewer parens in "let" clauses and with "defun" spelled "defn".

That is not functional programming.

I'm so glad that someone is keeping it real when it comes to functional programming. sigh

You don't mention where you saw all the "global variables", but I'll bet that what you saw were actually vars used in conjunction with binding.

Are we really to the point where only monadic IO is acceptable to the high priests of functional programming?

FP has always had two parallel tracks, the ML school and the lisp school. Maybe you prefer the former, but just because you really, really like Haskell doesn't mean you get to bar all other lisps from the FP club (as all of your problems with clojure -- i.e. it not being haskell -- certainly apply to all lisps I've worked with).

You are attaching too much meaning to an expression. Who cares if you write functional programs? It doesn't matter.

But calling a bunch of mutable state and non-composable program fragments that run from top to bottom is not really functional programming, and calling it that just confuses people. The idea of language is to be able to speak clearly about something; having a nebulous expression with no meaning is not helpful, right?

I suppose I don't care that much about whether clojure is really, honestly FP, but you brought it up...

Again, it sounds like you think any given scheme code isn't functional programming, either, it not being lazy by default, etc. Small world, that.

Laziness is not relevant. SML is definitely functional.

> all instances of your HTTP client share the same cookie jar?

It's cool that you're expanding your horizons by reading code in a new language, but if you hold off on snarkiness until you actually understand the code you're reading, (particularly with regard to what the binding form does) that would be great; kthxbai.

Reply on news.ycombinator.com