9 ms·

Challenging Clojure in Common Lisp (2014)

124 points by krat0sprakhar 10y ago

raspasov 10y ago
If the author reads this: Can you elaborate more on what you mean by "lackluster performance"? What is the use case? If you're looking for top speed in terms of C/assembly performance - I'd say yes, probably the JVM will get in your way. However, I spent months building a database/key-value store in Clojure and it's quite doable to write very high performance code in Clojure as long as you put the right type hints everywhere. Tools like YourKit can help you identify the bottlenecks in your program. Again, depends on the use case, but Clojure makes it very, very idiomatic to write code that makes full use of a multicore system - something possible in the like of Java, C, et al but definitely not idiomatic at all.
- pron 10y ago
  (not the author) > probably the JVM will get in your way Not so much the JVM, but Clojure and how it uses the JVM (although, as you say, it's possible to get not too far from top JVM performance with Clojure). It's fairly easy to get C performance (and even beat it in concurrent code) for the same amount of effort on the JVM. Currently, the main handicap the JVM has is the lack of arrays-of-structs which may cause lots of cache-misses, and requires less-than-elegant code to overcome. This, thankfully, is being addressed by the addition of value types.
  - raspasov 10y ago
    Yup, the JVM is something that people (esp. startups & new-co's) are, all things being equal, vastly underusing or over-complaining about :). Before I started doing Clojure the JVM ecosystem was this "scary" thing but 4 years later I've learned to appreciate it a lot - stable AND sound libraries, high performance out-of-the box, and very,very high performance if you really need it.
    - hellofunk 10y ago
      > very,very high performance if you really need it But not as high performance as Java directly. And typically not as high performance as native languages, which the author addresses.
      - pron 10y ago
        There's absolutely nothing about native languages that makes them a-priori faster than the JVM. On the contrary, the JVMs compiler is likely to emit betteroptimized machine code than their compilers. Some low-level languages (like C/C++/Rust) can (and do in many cases) offer better performance, but that's not because they're "native" but because they allow (and require) finer control over every operation. This level of control comes at a significant cost, though.
        hellofunk 10y ago
        Notice I said "typically" because, typically it is true that a native language runs faster than Clojure, which is what my comment was referring to.
    - agibsonccc 10y ago
      What clojure and even scala do with the JVM scares me. The most concrete example I know of is using objects for everything. 1 of the fundamental problems I have with many of the higher level JVM languages is how much they hide from you. That being said, most people won't notice. I do numerical software in java so might be a bit more sensitive to some of this stuff.
      - raspasov 10y ago
        If you ever have the need, checkout this blog post about optimizing math operations in Clojure http://insideclojure.org/2014/12/15/warn-on-boxed/ http://insideclojure.org/2014/12/15/warn-on-boxed/
  - WildUtah 10y ago
    It's fairly easy to get C performance (and even beat it in concurrent code) for the same amount of effort on the JVM. Ha. That's what we were promised back in the mid-1990s. It's no more true today than it was then. Well written Java will always be about 2-4x slower than similar C code. JVM applications have many compensating advantages, including the aforementioned ease of exploiting concurrency. That doesn't erase the reality of single thread performance where Java has never, in twenty years of strong expert effort, caught up.
    - fnordsensei 10y ago
      Agreed, in that the performance benefits you can get out of a higher level language will often depend on the stuff where the limits of human cognition is the performance boundary. As computing gets faster in general, the practical considerations should shift more towards the performance you can get out of an entire system than unit-for-unit performance. On that level, human comprehension often seems to be what needs to be accounted for. I think of it as problem akin to how you can make traffic run better in an entire city rather than optimising the performance of an engine in a single car. It doesn't invalidate making more performant engines, but it's a different level of consideration. When saying, "JVM is as performant as C", it's easy to run the numbers and see whether it's true or not, objectively. The caveat that GP throws in is, for the same amount of effort. Then you need to specify which human and under what circumstances, and the entire thing gets hairier.
      - WildUtah 10y ago
        As computing gets faster in general, the practical considerations should shift more towards the performance you can get out of an entire system than unit-for-unit performance. Those days are over, unfortunately. Computing stopped getting faster in general around 2010. And that also changes the calculus around single thread performance. You can no longer count on hardware eventually to solve performance problems.
        mtrycz 10y ago
        And this is why parallel/concurrent computing/applications are necessary to ease speedups. And that's what the new languages promise to let you get right. For the same effort.
  - agibsonccc 10y ago
    It can though. We are a java shop that does HPC and deep learning. Our work is open source. We've been around 2.5 going on 3 years now. Over the years we've surpassed bottleneck after bottleneck in the JVM. It's a faster wrapper around c code for us. We maintain and created: https://github.com/bytedeco/javacpp https://github.com/bytedeco/javacpp which wraps a lot of c++ components. This is also how we do GPUs and the like with our own memory management for our "numpy for java": https://github.com/deeplearning4j/nd4j/tree/master/nd4j-backends/nd4j-backend-impls/nd4j-cuda https://github.com/deeplearning4j/nd4j/tree/master/nd4j-back... Short of it "off heap and NO GC" matters a lot. We have 1 c codebase we use that's meant to be controlled via JNI here: https://github.com/deeplearning4j/libnd4j https://github.com/deeplearning4j/libnd4j The speed gains we've seen are massive. Java can't compete with good ole simd and the like for numerical computing. We are a big advocate of the JVM as a platform but let's be clear about its weaknesses. You need to use unsafe (see: netty,aeron, and any other low level database written in java or using java as the core language with some c++)and other tricks out of the box for real performance.
    - pjmlp 10y ago
      The problem is that you are using it in areas, HPC and deep learning, where using plain C++ would be a better option. I think. There is a reason why Java 10 aims to improve Java's story in regard to mechanical sympathy.
      - agibsonccc 10y ago
        We wrote a lot of that stack ourselves. And our compute code is in c++. There is a lot of stuff going on in big data land (including us) wrapping a lot of the c++ in java and enabling people to use the JVM for what it's good at (data access). We are pushing this with nvidia: https://blogs.nvidia.com/blog/2016/10/06/how-skymind-nvidia-deep-learning/ https://blogs.nvidia.com/blog/2016/10/06/how-skymind-nvidia-... I also work pretty closely with a lot of the spark/gpu folks at IBM. While I do largely agree with you, we have our own JNI compiler called javacpp that alleviates a lot of those concerns already: https://github.com/bytedeco/javacpp https://github.com/bytedeco/javacpp Having our own pointer class and doing our own memory management has helped a lot. What you're talking about is using java for the compute. There's no reason you can't wrap that in a runtime that most people know how to use. A lot of python folks do that now..but then you have to deal with python's limitations at which point the majority of your code (way more than needs be) will end up being in c anyways vs java where you can write a significant part of your app in java and have it be fast out of the box.
  - virtualwhys 10y ago
    > This, thankfully, is being addressed by the addition of value types. Last I heard (JLS 2016 keynote by Brian Goetz) they have yet to commit/guarantee when value types will land. Java 10 is planned; if they're completed by then we're looking at probably 2020 given the delays with Java 9 release. That's 3 years for other languages/platforms to evolve while the JVM unboxes itself.
    - pron 10y ago
      Large organizations switch programming languages no more than once a decade, and Java is way ahead of the competition as it stands.
- krat0sprakhar 10y ago
  > as long as you put the right type hints everywhere. I'm a novice Clojure programmer and haven't previously heard of this. Can you please elaborate?
  - ajss 10y ago
    (defn [o n] (.write o n)) will have to look up the .write method by doing reflection on o & n at runtime, which is really slow. (defn [^WriteInterface o ^long n] (.write o n)) can be much faster because the compiler knows the type of o & n.
    - abc_lisper 10y ago
      I think you meant to say, (defn func[o n] (.write ^WriteInterface o ^long n)) This is needed only when calling Java methods, because Java allows overloading. Clojure only does arity-overloading, not type overloading, and hence doesn't need the type info.
  - moomin 10y ago
    Short version: put :warn-on-reflection in your leiningen file, And then add type hints (google them) to reduce the warnings to zero. There's no reason the average Clojure project ever need be using reflection for dispatch.
    - raspasov 10y ago
      Correct, a lot of the average application-level code you see in the wild does not have to worry about this. If we're talking about things like load-balancers or databases or endpoints/functions that will be hit 1000s of times per second - then it's a diff. conversation.
  - hkjgkjy 10y ago
    You don't need to specify what type a function takes in Clojure, which is often nice. If you do though, the compiler can sometimes optimize, and make things much faster. Basically, the compiler does not have to * look up the type of the thing * run the action on it but can instead skip straight to step 2. If you somewhere in your Clojure program (or repl) run (set! warn-on-reflection true) it will print to the console when you are doing reflection. I think it's a good idea to put in the beginning of your core namespace - so that it is always on. Why not always wear the seatbelt when driving, you know?
- fsloth 10y ago
  "something possible in the like of Java, C, et al but definitely not idiomatic at all." What on earth is non-idiomatic multicore c code? You have to try really hard with Macro tomfoolery before c becomes non-idiomatic :) .
  - lvh 10y ago
    Isn't this just a convoluted way of arguing that there's no such thing as idiomatic multicore C? If everything's idiomatic, then surely nothing is.
    - fsloth 10y ago
      No, it was a convoluted way to say that the attempt to measure C programs by their quality as "idiomatic" will unlikely bear any fruits of value. That said, if there is any non-idiomatic C code then the attempts of 'experts' in other languages to mangle C to look more like their language surely fall into this category (There are lots of examples where the author starts 'We can make C look more like fortran by defining our macros to replace these keywords..).
- klibertp 10y ago
  I'm not the author, but looking through the sibling comments I feel I should point out the obvious: startup time. It can take long seconds for Clojure REPL to start up. No other dynamic language I had contact with was that bad on that front. Even Erlang and Elixir boot up faster! Of course, I know about various ways of setting up a daemon process in the background, but then there is a need for reloading/hot-swapping code, which Clojure also fails to do well. Both Erlang and Common Lisp (also Emacs... even Emacs!) are better in this regard, both for different reasons. Anyway, Clojure overall performance impression - how fast it feels for users - is bad and will remain bad unless the startup problem is fixed.
hellofunk 10y ago
> Somehow I could not shake the feeling that homoiconic macros were intimately tied to the very essence of functional programming That's the first time I've heard anything like this. Lots of great FP languages exist that are not dynamic or offer such macros, why would they be a requirement for FP?
- fnordsensei 10y ago
  It's not, he just couldn't shake shake the feeling. Kind of how you can't shake the feeling that there should be left-over pizza in the fridge, knowing very well that you already ate it all. I think many of us probably tend to associate certain styles and features with functional programming that really are orthogonal to whether the program is functional or not. As I've had it explained to me, if you write your program using functions whose output only depends on the arguments provided to that function, and nothing else, then you have yourself a functional program. But then again, people tend to treat the concept like a scale, with some programs (or languages) being more or less functional than others.
  - nickbauman 10y ago
    I think the problem hovers around the idea of first class ness. In Clojure, I can use a function like '<' as a key in a hashmap. In Python, I can't. Because '<' isn't a function, it's an operator in Python. First classedness has to do with non-complectedness. Python has operators and statements in addition to expressions. Clojure, because it's a Lisp, gets by with just expressions.
    - BeetleB 10y ago
      Actually, yes you can in Python - indirectly. Most of the usual operators can be imported as functions: from operator import lt will get you '<' as a function.
      - nickbauman 10y ago
        But I have to use lt as a key, I can't use <. Important difference, no? Writing a DSL is much easier with that difference.
minikomi 10y ago
The end result seems a little strange to me. Why doesn't it KNEAD and BAKE without being told, and yet DECORATE's just by adding sugar? Also, this is a perfect task for core.async / core.match in clojure. Definitely not 6 days worth of work.
deleted 10y ago
[deleted]
lvh 10y ago
You mentioned a desire to get some visibility into the runtime effects of your code. You get that (ASM dumps) out of CL, but you also get JVM bytecode and associated ASM dumps out of Clojure, even if your code is doing FFI. I go into detail on this in my Conj talk: https://www.youtube.com/watch?v=Lf-M1ZH6KME https://www.youtube.com/watch?v=Lf-M1ZH6KME
lvh 10y ago
You mentioned that you wanted something non-hosted. Unless I missed it, the arguments are roughly performance (not really made) and visibility (not true, see [1]). Hosted versus non-hosted seems like a property without a particular intrinsic value judgement. I'm going to argue that for a Lisp, being hosted is a great idea. Firstly, JS is a very credible and easy to use target for Clojure. It has source map support and produces aggressively optimized JS via the Google Closure compiler. (Parenscript, the CL competitor, can claim neither.) I've had plenty of code where I literally rename the "clj" extension to "cljc" and it magically runs in the browser. Secondly, I get to use ample libraries in both cases because they already have thriving ecosystems that are completely independent from all of these parentheses. For example, today I'm writing AWS code, and I get to use AWS's Java SDK painlessly. If I'm on CL, it appears I'm out of luck. Being a hosted language, in and of itself, hence seems like a clear choice if it isn't for the (not made) performance argument. So, perhaps we should talk about that instead :) [1]: https://news.ycombinator.com/item?id=13349747 https://news.ycombinator.com/item?id=13349747
- junke 10y ago
  See ABCL (http://abcl.org/ http://abcl.org/) and JSCL (https://github.com/jscl-project/jscl https://github.com/jscl-project/jscl)
  - lvh 10y ago
    JSCL is quite different from ClojureScript. ClojureScript has a self-hosted form (which, AFAICT, is the default for JSCL), but that's not what you want for most applications if you want to produce efficient minified code. My two specific claims about ClojureScript being good included source maps and aggressive optimizations (and all of the cool side effects from having Closure as your module system) -- neither applies to Parenscript (as I mentioned) or JSCL.
  - lvh 10y ago
    Some Java: public class Main { public int addTwoNumbers(int a, int b) { return a + b; } } Calling it from ABCL: (defun void-function (param) (let* ((class (jclass "Main")) (intclass (jclass "int")) (method (jmethod class "addTwoNumbers" intclass intclass)) (result (jcall method param 2 4))) (format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%" result))) Calling it from Clojure: (defn f [] (prn "calling addTwoNumbers from f" (.addTwoNumbers (Main.) 2 4))) Note that the Clojure version creates the object, and the ABCL version doesn't do that for you; you still need to instantiate a Main yourself. Also, my concrete claim was that I could use AWS easily. I can use both the SDK directly quite painlessly (see above) or use https://github.com/mcohen01/amazonica https://github.com/mcohen01/amazonica. Where is the equivalent CL library?
_halgari 10y ago
Can we get some sort of edit to this title to show that it's from back in 2014? A ton of work has gone into Clojure since then and in some aspects the language has gotten orders of magnitude faster (not that it was really that slow to begin with).
- deleted 10y ago
  [deleted]
- sctb 10y ago
  Thank you, we've updated the title.
_halgari 10y ago
STM and concurrency...sure those are "aspects" of Clojure, Clojure's biggest strength is that it's data-centric. The vast majority of the language is focused around manipulating hashmaps, vectors, sequences, etc, and do that in an efficient way. All the concurrency stuff is just icing. So I really have to sit back and shake my head when the author says he's going to be as good as Clojure, then goes off into the weeds with custom syntax, STM and actors. Really? Why actors? This would have been a much better article if it just left Clojure out of the discussion since whenever the author talks about the language he's mostly wrong. And as always, lies, damn lies, and benchmarks: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=clojure&lang2=sbcl https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... If you're going to use a phrase like "faster", at least spend some time to define the word.
- m0skit0 10y ago
  Isn't a functional language supposed to be function centric?
  - _halgari 10y ago
    Sure, but what do those functions do? In clojure they manipulate data. That's pretty much the gist of the language: using pure functions to manipulate data. Almost all the work I do these days as a software engineer is data transformation. Going from a HTTP request, which is data (even the header is a hashmap), and a HTTP body, which is data, into some business logic that eventually writes to a database in a different format. Even the most complex systems I've built containing dozens of servers and multiple databases, queues, http servers, etc. All boil down to transforming data from format A to format B perhaps with conditional logic applied. So yes, Clojure is a functional language, but functions are just a tool to be used to get the actual work done of transforming data.
  - macmac 10y ago
    Clojure's rich persistent data structures together with protocols facilitates functional programming in Clojure. When Clojure is called a data-centric I think most users mean that it encourages functional programming applied to rich immutable data.
doall 10y ago
To understand concurrent programming in Clojure, at least you should read [1]. In general, the symbolic STM (Refs) is not often used in Clojure programming. Atoms (a wrapper of the Java AtomicReference) is much more lightweight and is used in most cases. [1]: http://clojure-doc.org/articles/language/concurrency_and_parallelism.html http://clojure-doc.org/articles/language/concurrency_and_par...
zengid 10y ago
I feel like the author didn't do this as a way to bash Clojure but to try and progress Common Lisp. Anecdotally, I remember Hickey saying something about a stagnation in the CL community, so if Clojure inspires cross-pollination of ideas then that's a good thing. For instance, Simon Peyton Jones describes [1] how they took the ideas around STM from 'unsafe' languages and put it into Haskell, developed it further, and then later the 'unsafe' languages took the Haskell innovations and put it back into their languages. Clojure isn't perfect, and Common Lisp isn't perfect, but hey, they're better than programming in assembly. We should be stoked about someone trying to innovate; why do these posts always turn into language wars? [1] https://youtu.be/iSmkqocn0oQ https://youtu.be/iSmkqocn0oQ around 3:50, but the video is short so it's worth watching the whole thing.
- brudgers 10y ago
  I didn't take it as Clojure bashing either. On the other hand, it does seem to be a sort of back-footed defense of Common Lisp, to me. Partially because it seems to miss acknowledgement that part of the goal of Clojure was to bring the level of abstraction that Common Lisp affords to the JVM, for example Common Lisp has the abstraction of Seq(uences) and functions that operate upon them. But the big elephant to me is that Common Lisp provides a very strong set of Von Neumann abstractions in addition to its functional abstractions. Lists are an abstraction that maps to sequential reads of a contiguous block of memory. Setf has pointer and offset semantics. And the much maligned `loop` is a brilliant abstraction over iteration that lets a program be explicit about the why of a loop. That's not to say there are not advantages to functional programming. But the popularity of Go and Python etc. suggest that abstractions that run counter to functional programming mores is not a reason to find fault in Common Lisp. Like Clojure, it's a big language that tries to meet programmers where they are in the projects that they work on. Nobody faults Clojure for allowing Java's mutable vectors because they're there in the language for practical reasons.
macmac 10y ago
> "Object orientation falls short here in that it does readily permit mathematical composition." Surely "does" is meant to be negated?

124 points by krat0sprakhar 10y ago

If the author reads this: Can you elaborate more on what you mean by "lackluster performance"? What is the use case? If you're looking for top speed in terms of C/assembly performance - I'd say yes, probably the JVM will get in your way. However, I spent months building a database/key-value store in Clojure and it's quite doable to write very high performance code in Clojure as long as you put the right type hints everywhere. Tools like YourKit can help you identify the bottlenecks in your program. Again, depends on the use case, but Clojure makes it very, very idiomatic to write code that makes full use of a multicore system - something possible in the like of Java, C, et al but definitely not idiomatic at all.

pron 10y ago
(not the author) > probably the JVM will get in your way Not so much the JVM, but Clojure and how it uses the JVM (although, as you say, it's possible to get not too far from top JVM performance with Clojure). It's fairly easy to get C performance (and even beat it in concurrent code) for the same amount of effort on the JVM. Currently, the main handicap the JVM has is the lack of arrays-of-structs which may cause lots of cache-misses, and requires less-than-elegant code to overcome. This, thankfully, is being addressed by the addition of value types.
- raspasov 10y ago
  Yup, the JVM is something that people (esp. startups & new-co's) are, all things being equal, vastly underusing or over-complaining about :). Before I started doing Clojure the JVM ecosystem was this "scary" thing but 4 years later I've learned to appreciate it a lot - stable AND sound libraries, high performance out-of-the box, and very,very high performance if you really need it.
  - hellofunk 10y ago
    > very,very high performance if you really need it But not as high performance as Java directly. And typically not as high performance as native languages, which the author addresses.
    - pron 10y ago
      There's absolutely nothing about native languages that makes them a-priori faster than the JVM. On the contrary, the JVMs compiler is likely to emit betteroptimized machine code than their compilers. Some low-level languages (like C/C++/Rust) can (and do in many cases) offer better performance, but that's not because they're "native" but because they allow (and require) finer control over every operation. This level of control comes at a significant cost, though.
      - hellofunk 10y ago
        Notice I said "typically" because, typically it is true that a native language runs faster than Clojure, which is what my comment was referring to.
  - agibsonccc 10y ago
    What clojure and even scala do with the JVM scares me. The most concrete example I know of is using objects for everything. 1 of the fundamental problems I have with many of the higher level JVM languages is how much they hide from you. That being said, most people won't notice. I do numerical software in java so might be a bit more sensitive to some of this stuff.
    - raspasov 10y ago
      If you ever have the need, checkout this blog post about optimizing math operations in Clojure http://insideclojure.org/2014/12/15/warn-on-boxed/ http://insideclojure.org/2014/12/15/warn-on-boxed/
- WildUtah 10y ago
  It's fairly easy to get C performance (and even beat it in concurrent code) for the same amount of effort on the JVM. Ha. That's what we were promised back in the mid-1990s. It's no more true today than it was then. Well written Java will always be about 2-4x slower than similar C code. JVM applications have many compensating advantages, including the aforementioned ease of exploiting concurrency. That doesn't erase the reality of single thread performance where Java has never, in twenty years of strong expert effort, caught up.
  - fnordsensei 10y ago
    Agreed, in that the performance benefits you can get out of a higher level language will often depend on the stuff where the limits of human cognition is the performance boundary. As computing gets faster in general, the practical considerations should shift more towards the performance you can get out of an entire system than unit-for-unit performance. On that level, human comprehension often seems to be what needs to be accounted for. I think of it as problem akin to how you can make traffic run better in an entire city rather than optimising the performance of an engine in a single car. It doesn't invalidate making more performant engines, but it's a different level of consideration. When saying, "JVM is as performant as C", it's easy to run the numbers and see whether it's true or not, objectively. The caveat that GP throws in is, for the same amount of effort. Then you need to specify which human and under what circumstances, and the entire thing gets hairier.
    - WildUtah 10y ago
      As computing gets faster in general, the practical considerations should shift more towards the performance you can get out of an entire system than unit-for-unit performance. Those days are over, unfortunately. Computing stopped getting faster in general around 2010. And that also changes the calculus around single thread performance. You can no longer count on hardware eventually to solve performance problems.
      - mtrycz 10y ago
        And this is why parallel/concurrent computing/applications are necessary to ease speedups. And that's what the new languages promise to let you get right. For the same effort.
- agibsonccc 10y ago
  It can though. We are a java shop that does HPC and deep learning. Our work is open source. We've been around 2.5 going on 3 years now. Over the years we've surpassed bottleneck after bottleneck in the JVM. It's a faster wrapper around c code for us. We maintain and created: https://github.com/bytedeco/javacpp https://github.com/bytedeco/javacpp which wraps a lot of c++ components. This is also how we do GPUs and the like with our own memory management for our "numpy for java": https://github.com/deeplearning4j/nd4j/tree/master/nd4j-backends/nd4j-backend-impls/nd4j-cuda https://github.com/deeplearning4j/nd4j/tree/master/nd4j-back... Short of it "off heap and NO GC" matters a lot. We have 1 c codebase we use that's meant to be controlled via JNI here: https://github.com/deeplearning4j/libnd4j https://github.com/deeplearning4j/libnd4j The speed gains we've seen are massive. Java can't compete with good ole simd and the like for numerical computing. We are a big advocate of the JVM as a platform but let's be clear about its weaknesses. You need to use unsafe (see: netty,aeron, and any other low level database written in java or using java as the core language with some c++)and other tricks out of the box for real performance.
  - pjmlp 10y ago
    The problem is that you are using it in areas, HPC and deep learning, where using plain C++ would be a better option. I think. There is a reason why Java 10 aims to improve Java's story in regard to mechanical sympathy.
    - agibsonccc 10y ago
      We wrote a lot of that stack ourselves. And our compute code is in c++. There is a lot of stuff going on in big data land (including us) wrapping a lot of the c++ in java and enabling people to use the JVM for what it's good at (data access). We are pushing this with nvidia: https://blogs.nvidia.com/blog/2016/10/06/how-skymind-nvidia-deep-learning/ https://blogs.nvidia.com/blog/2016/10/06/how-skymind-nvidia-... I also work pretty closely with a lot of the spark/gpu folks at IBM. While I do largely agree with you, we have our own JNI compiler called javacpp that alleviates a lot of those concerns already: https://github.com/bytedeco/javacpp https://github.com/bytedeco/javacpp Having our own pointer class and doing our own memory management has helped a lot. What you're talking about is using java for the compute. There's no reason you can't wrap that in a runtime that most people know how to use. A lot of python folks do that now..but then you have to deal with python's limitations at which point the majority of your code (way more than needs be) will end up being in c anyways vs java where you can write a significant part of your app in java and have it be fast out of the box.
- virtualwhys 10y ago
  > This, thankfully, is being addressed by the addition of value types. Last I heard (JLS 2016 keynote by Brian Goetz) they have yet to commit/guarantee when value types will land. Java 10 is planned; if they're completed by then we're looking at probably 2020 given the delays with Java 9 release. That's 3 years for other languages/platforms to evolve while the JVM unboxes itself.
  - pron 10y ago
    Large organizations switch programming languages no more than once a decade, and Java is way ahead of the competition as it stands.
krat0sprakhar 10y ago
> as long as you put the right type hints everywhere. I'm a novice Clojure programmer and haven't previously heard of this. Can you please elaborate?
- ajss 10y ago
  (defn [o n] (.write o n)) will have to look up the .write method by doing reflection on o & n at runtime, which is really slow. (defn [^WriteInterface o ^long n] (.write o n)) can be much faster because the compiler knows the type of o & n.
  - abc_lisper 10y ago
    I think you meant to say, (defn func[o n] (.write ^WriteInterface o ^long n)) This is needed only when calling Java methods, because Java allows overloading. Clojure only does arity-overloading, not type overloading, and hence doesn't need the type info.
- moomin 10y ago
  Short version: put :warn-on-reflection in your leiningen file, And then add type hints (google them) to reduce the warnings to zero. There's no reason the average Clojure project ever need be using reflection for dispatch.
  - raspasov 10y ago
    Correct, a lot of the average application-level code you see in the wild does not have to worry about this. If we're talking about things like load-balancers or databases or endpoints/functions that will be hit 1000s of times per second - then it's a diff. conversation.
- hkjgkjy 10y ago
  You don't need to specify what type a function takes in Clojure, which is often nice. If you do though, the compiler can sometimes optimize, and make things much faster. Basically, the compiler does not have to * look up the type of the thing * run the action on it but can instead skip straight to step 2. If you somewhere in your Clojure program (or repl) run (set! warn-on-reflection true) it will print to the console when you are doing reflection. I think it's a good idea to put in the beginning of your core namespace - so that it is always on. Why not always wear the seatbelt when driving, you know?
fsloth 10y ago
"something possible in the like of Java, C, et al but definitely not idiomatic at all." What on earth is non-idiomatic multicore c code? You have to try really hard with Macro tomfoolery before c becomes non-idiomatic :) .
- lvh 10y ago
  Isn't this just a convoluted way of arguing that there's no such thing as idiomatic multicore C? If everything's idiomatic, then surely nothing is.
  - fsloth 10y ago
    No, it was a convoluted way to say that the attempt to measure C programs by their quality as "idiomatic" will unlikely bear any fruits of value. That said, if there is any non-idiomatic C code then the attempts of 'experts' in other languages to mangle C to look more like their language surely fall into this category (There are lots of examples where the author starts 'We can make C look more like fortran by defining our macros to replace these keywords..).
klibertp 10y ago
I'm not the author, but looking through the sibling comments I feel I should point out the obvious: startup time. It can take long seconds for Clojure REPL to start up. No other dynamic language I had contact with was that bad on that front. Even Erlang and Elixir boot up faster! Of course, I know about various ways of setting up a daemon process in the background, but then there is a need for reloading/hot-swapping code, which Clojure also fails to do well. Both Erlang and Common Lisp (also Emacs... even Emacs!) are better in this regard, both for different reasons. Anyway, Clojure overall performance impression - how fast it feels for users - is bad and will remain bad unless the startup problem is fixed.

hellofunk 10y ago

> Somehow I could not shake the feeling that homoiconic macros were intimately tied to the very essence of functional programming That's the first time I've heard anything like this. Lots of great FP languages exist that are not dynamic or offer such macros, why would they be a requirement for FP?

fnordsensei 10y ago
It's not, he just couldn't shake shake the feeling. Kind of how you can't shake the feeling that there should be left-over pizza in the fridge, knowing very well that you already ate it all. I think many of us probably tend to associate certain styles and features with functional programming that really are orthogonal to whether the program is functional or not. As I've had it explained to me, if you write your program using functions whose output only depends on the arguments provided to that function, and nothing else, then you have yourself a functional program. But then again, people tend to treat the concept like a scale, with some programs (or languages) being more or less functional than others.
- nickbauman 10y ago
  I think the problem hovers around the idea of first class ness. In Clojure, I can use a function like '<' as a key in a hashmap. In Python, I can't. Because '<' isn't a function, it's an operator in Python. First classedness has to do with non-complectedness. Python has operators and statements in addition to expressions. Clojure, because it's a Lisp, gets by with just expressions.
  - BeetleB 10y ago
    Actually, yes you can in Python - indirectly. Most of the usual operators can be imported as functions: from operator import lt will get you '<' as a function.
    - nickbauman 10y ago
      But I have to use lt as a key, I can't use <. Important difference, no? Writing a DSL is much easier with that difference.

minikomi 10y ago

The end result seems a little strange to me. Why doesn't it KNEAD and BAKE without being told, and yet DECORATE's just by adding sugar? Also, this is a perfect task for core.async / core.match in clojure. Definitely not 6 days worth of work.

deleted 10y ago

[deleted]

lvh 10y ago

You mentioned a desire to get some visibility into the runtime effects of your code. You get that (ASM dumps) out of CL, but you also get JVM bytecode and associated ASM dumps out of Clojure, even if your code is doing FFI. I go into detail on this in my Conj talk: https://www.youtube.com/watch?v=Lf-M1ZH6KME https://www.youtube.com/watch?v=Lf-M1ZH6KME

lvh 10y ago

You mentioned that you wanted something non-hosted. Unless I missed it, the arguments are roughly performance (not really made) and visibility (not true, see [1]). Hosted versus non-hosted seems like a property without a particular intrinsic value judgement. I'm going to argue that for a Lisp, being hosted is a great idea. Firstly, JS is a very credible and easy to use target for Clojure. It has source map support and produces aggressively optimized JS via the Google Closure compiler. (Parenscript, the CL competitor, can claim neither.) I've had plenty of code where I literally rename the "clj" extension to "cljc" and it magically runs in the browser. Secondly, I get to use ample libraries in both cases because they already have thriving ecosystems that are completely independent from all of these parentheses. For example, today I'm writing AWS code, and I get to use AWS's Java SDK painlessly. If I'm on CL, it appears I'm out of luck. Being a hosted language, in and of itself, hence seems like a clear choice if it isn't for the (not made) performance argument. So, perhaps we should talk about that instead :) [1]: https://news.ycombinator.com/item?id=13349747 https://news.ycombinator.com/item?id=13349747

junke 10y ago
See ABCL (http://abcl.org/ http://abcl.org/) and JSCL (https://github.com/jscl-project/jscl https://github.com/jscl-project/jscl)
- lvh 10y ago
  JSCL is quite different from ClojureScript. ClojureScript has a self-hosted form (which, AFAICT, is the default for JSCL), but that's not what you want for most applications if you want to produce efficient minified code. My two specific claims about ClojureScript being good included source maps and aggressive optimizations (and all of the cool side effects from having Closure as your module system) -- neither applies to Parenscript (as I mentioned) or JSCL.
- lvh 10y ago
  Some Java: public class Main { public int addTwoNumbers(int a, int b) { return a + b; } } Calling it from ABCL: (defun void-function (param) (let* ((class (jclass "Main")) (intclass (jclass "int")) (method (jmethod class "addTwoNumbers" intclass intclass)) (result (jcall method param 2 4))) (format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%" result))) Calling it from Clojure: (defn f [] (prn "calling addTwoNumbers from f" (.addTwoNumbers (Main.) 2 4))) Note that the Clojure version creates the object, and the ABCL version doesn't do that for you; you still need to instantiate a Main yourself. Also, my concrete claim was that I could use AWS easily. I can use both the SDK directly quite painlessly (see above) or use https://github.com/mcohen01/amazonica https://github.com/mcohen01/amazonica. Where is the equivalent CL library?

_halgari 10y ago

Can we get some sort of edit to this title to show that it's from back in 2014? A ton of work has gone into Clojure since then and in some aspects the language has gotten orders of magnitude faster (not that it was really that slow to begin with).

deleted 10y ago
[deleted]
sctb 10y ago
Thank you, we've updated the title.

_halgari 10y ago

STM and concurrency...sure those are "aspects" of Clojure, Clojure's biggest strength is that it's data-centric. The vast majority of the language is focused around manipulating hashmaps, vectors, sequences, etc, and do that in an efficient way. All the concurrency stuff is just icing. So I really have to sit back and shake my head when the author says he's going to be as good as Clojure, then goes off into the weeds with custom syntax, STM and actors. Really? Why actors? This would have been a much better article if it just left Clojure out of the discussion since whenever the author talks about the language he's mostly wrong. And as always, lies, damn lies, and benchmarks: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=clojure&lang2=sbcl https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... If you're going to use a phrase like "faster", at least spend some time to define the word.

m0skit0 10y ago
Isn't a functional language supposed to be function centric?
- _halgari 10y ago
  Sure, but what do those functions do? In clojure they manipulate data. That's pretty much the gist of the language: using pure functions to manipulate data. Almost all the work I do these days as a software engineer is data transformation. Going from a HTTP request, which is data (even the header is a hashmap), and a HTTP body, which is data, into some business logic that eventually writes to a database in a different format. Even the most complex systems I've built containing dozens of servers and multiple databases, queues, http servers, etc. All boil down to transforming data from format A to format B perhaps with conditional logic applied. So yes, Clojure is a functional language, but functions are just a tool to be used to get the actual work done of transforming data.
- macmac 10y ago
  Clojure's rich persistent data structures together with protocols facilitates functional programming in Clojure. When Clojure is called a data-centric I think most users mean that it encourages functional programming applied to rich immutable data.

doall 10y ago

To understand concurrent programming in Clojure, at least you should read [1]. In general, the symbolic STM (Refs) is not often used in Clojure programming. Atoms (a wrapper of the Java AtomicReference) is much more lightweight and is used in most cases. [1]: http://clojure-doc.org/articles/language/concurrency_and_parallelism.html http://clojure-doc.org/articles/language/concurrency_and_par...

zengid 10y ago

I feel like the author didn't do this as a way to bash Clojure but to try and progress Common Lisp. Anecdotally, I remember Hickey saying something about a stagnation in the CL community, so if Clojure inspires cross-pollination of ideas then that's a good thing. For instance, Simon Peyton Jones describes [1] how they took the ideas around STM from 'unsafe' languages and put it into Haskell, developed it further, and then later the 'unsafe' languages took the Haskell innovations and put it back into their languages. Clojure isn't perfect, and Common Lisp isn't perfect, but hey, they're better than programming in assembly. We should be stoked about someone trying to innovate; why do these posts always turn into language wars? [1] https://youtu.be/iSmkqocn0oQ https://youtu.be/iSmkqocn0oQ around 3:50, but the video is short so it's worth watching the whole thing.

brudgers 10y ago
I didn't take it as Clojure bashing either. On the other hand, it does seem to be a sort of back-footed defense of Common Lisp, to me. Partially because it seems to miss acknowledgement that part of the goal of Clojure was to bring the level of abstraction that Common Lisp affords to the JVM, for example Common Lisp has the abstraction of Seq(uences) and functions that operate upon them. But the big elephant to me is that Common Lisp provides a very strong set of Von Neumann abstractions in addition to its functional abstractions. Lists are an abstraction that maps to sequential reads of a contiguous block of memory. Setf has pointer and offset semantics. And the much maligned `loop` is a brilliant abstraction over iteration that lets a program be explicit about the why of a loop. That's not to say there are not advantages to functional programming. But the popularity of Go and Python etc. suggest that abstractions that run counter to functional programming mores is not a reason to find fault in Common Lisp. Like Clojure, it's a big language that tries to meet programmers where they are in the projects that they work on. Nobody faults Clojure for allowing Java's mutable vectors because they're there in the language for practical reasons.

macmac 10y ago

> "Object orientation falls short here in that it does readily permit mathematical composition." Surely "does" is meant to be negated?