9 ms·

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

by crucini 17y ago

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

jrockway 17y ago
My elevator pitch is, "A slow lisp without a real object system."
- radu_floricica 17y ago
  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?
  - stcredzero 17y ago
    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!
- Shooter 17y ago
  slow And yet you like Perl?! ;-)
  - jrockway 17y ago
    I do not like Perl for programs that need to execute quickly.
    - gaius 17y ago
      And if your bottleneck is I/O?
      - jrockway 17y ago
        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 :)
        gaius 17y ago
        I'm no great fan of Perl - yet in its niche, performance is not a reason not to use it.
- swannodette 17y ago
  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 http://code.google.com/p/explorersguild/wiki/XGModelAndGF.
  - jrockway 17y ago
    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.)
    - weavejester 17y ago
      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.
radu_floricica 17y ago
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"))
- vicaya 17y ago
  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.
  - durin42 17y ago
    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.
  - mattrepl 17y ago
    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.

by crucini 17y ago

jrockway 17y ago

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

radu_floricica 17y ago
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?
- stcredzero 17y ago
  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!
Shooter 17y ago
slow And yet you like Perl?! ;-)
- jrockway 17y ago
  I do not like Perl for programs that need to execute quickly.
  - gaius 17y ago
    And if your bottleneck is I/O?
    - jrockway 17y ago
      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 :)
      - gaius 17y ago
        I'm no great fan of Perl - yet in its niche, performance is not a reason not to use it.
swannodette 17y ago
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 http://code.google.com/p/explorersguild/wiki/XGModelAndGF.
- jrockway 17y ago
  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.)
  - weavejester 17y ago
    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.

radu_floricica 17y ago

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"))

vicaya 17y ago
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.
- durin42 17y ago
  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.
- mattrepl 17y ago
  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.