7 ms·

Clojure allows me to express thoughts that I wouldn't know how to express in for, while, if, variables and objects. And on readability, what do you prefer?

by j-pb 11y ago

Clojure allows me to express thoughts that I wouldn't know how to express in for, while, if, variables and objects. And on readability, what do you prefer? List<Integer> even = new List() for(int i = 0; i < 100; i++){ if((i%2)==0){ even.add(i); } } return even; vs. (filter even? (range 0 100))

incepted 11y ago
Of course, dynamically typed languages will win on one liners against Java but in the long run, the absence of types can really bring an entire code base (and project) down, which is why Clojure is hardly used at all and why Java is everywhere. Besides, Clojure doesn't even win in the one line department against modern JVM languages (e.g. Kotlin).
- arohner 11y ago
  > which is why Clojure is hardly used at all and why Java is everywhere. Surely that has nothing to do with Java being 20 years old, and Clojure 1.0 being 6 years old? > Clojure doesn't even win in the one line department against modern JVM languages (e.g. Kotlin). Example, please.
  - incepted 11y ago
    > Surely that has nothing to do with Java being 20 years old, and Clojure 1.0 being 6 years old? Lisp has been around for 50+ years, hasn't really helped its popularity much. But I'm willing to bet with you that in 14 years from now, Clojure will have even fewer users than it has today. > > Clojure doesn't even win in the one line department against modern JVM languages (e.g. Kotlin). > Example, please. Here it is in Kotlin: (0 .. 20).filter { it % 2 == 0 }
    - j-pb 11y ago
      I'd say clojure won that one liner.
    - huahaiy 11y ago
      > Lisp has been around for 50+ years, hasn't really helped its popularity much. But I'm willing to bet with you that in 14 years from now, Clojure will have even fewer users than it has today. Computer science has too short a history to make any sound arguments from history. However, if you insists on arguing from history, let's look at the long term trend. Would you agree that the trend of programming language is progressing to higher and higher level of abstraction and further and further away from the machine details? From machine code, to assembly language, to C, to Java, and now FP languages, this trend of mainstream programming language evolution is very clear. In this sense, if you take Lisp as a pioneer of function programming, it was simply ahead of its time. If you are implying that Lisp syntax is somehow an impediment to its popularity. That may well be. It's a personal preference issue. Some people like more syntax in their language, some people like less. If you are in the later camp, Lisp is surely very attractive. For example, in your kotlin one-liner, there are just too much syntax to understand "()", "..", ".", "{}", etc. Life is too short, I just don't want to learn all these idiosyncrasy invented by someone just for the sake of being different. I wished I had knew Lisp sooner, certainly not having programmed for 20 years. I am sure you will lose that bet.
      - dragonwriter 11y ago
        > Would you agree that the trend of programming language is progressing to higher and higher level of abstraction and further and further away from the machine details? That's...less than clear. The extreme high level of abstraction in PLs is consistently increasing, or at least non-decreasing, over time, but the mean/median used in actual programming may not be.
        huahaiy 11y ago
        With some minor assumptions, my assertion would be correct. Yours needs a lot of strong assumptions to be mathematically feasible. Basically, you are saying, when the max of a sequence is increasing, the mean/median stays or even decreases. That would require that the frequencies on the lower end to increase much faster than that on the higher end, which is certainly not the case. For example, the number of C programmers is growing faster than the number of Java programmer today? No one would think that's correct.
    - dkersten 11y ago
      I still find the clojure version (ever so slightly) simpler. Mostly because this has magic implicit it variable. In real code, this of course wouldn't matter, though.
    - jiyinyiyong 11y ago
      There will have fewer users according to Google Trend: https://www.google.com/trends/explore#q=java&cmpt=q&tz=Etc%2FGMT-8 https://www.google.com/trends/explore#q=java&cmpt=q&tz=Etc%2... And Clojure, not many is interested in it: https://www.google.com/trends/explore#q=clojure&cmpt=q&tz=Etc%2FGMT-8 https://www.google.com/trends/explore#q=clojure&cmpt=q&tz=Et... Actually I'm on the Clojure side. News comer will always pick a language which is simpler, more expressive, newer. Java is no longer such a language comparing to others.
yeukhon 11y ago
But what is even? I am sure functional programming has its natural appealing in areas like recursion, but this example doesn't seem too convincing for winning readability, I can always write this in python filter(even, range(0, 101))) where even is a function I wrote. Please give an example for "Clojure allows me to express thoughts that I wouldn't know how to express in for, while, if, variables and objects." if you can.
- j-pb 11y ago
  We were talking about java here. ^^ So python is offering a lot more already with it somewhat first class functions. What would you guess even? does, btw? But sure, let's make things a bit harder. As below, let's produce a sequence of the form [true false false true true true false false false false ...] of exact length 1000 without computing any more than exactly 1000 elements. (take 1000 (mapcat (fn [i] (repeat i (odd? i))) (range))) Of course the really interesting stuff is hard to do in one liners. But I think one of the more mind bending things is probably core.async. Go style coroutines and channels implemented as a library on top of the language. Which allows for concurrent programming inside clojurescript which is compiled to JS and thus inherently single-threaded. http://swannodette.github.io/2013/08/02/100000-processes/ http://swannodette.github.io/2013/08/02/100000-processes/
  - yeukhon 11y ago
    My point was "even" and "filter" can be built by someone, just to be fair about the whole readability. If "even" is already built into the language, then that's a given. Readability and language understanding are not separable. I for one have a hard time actually understand what the code does above (although I can guess it). But I am not sure how ^ translate into [true false false true true true false false false false ...] sequence because, I thought we were calculating oddity of 1000 numbers. [1 2 3 4 5 6 7 8 9 10 ...] ==> [T F T T F T F T T T ] Perhaps the lack of understanding Clojure syntax to comprehend what the code is doing.
    - j-pb 11y ago
      It's part of the std lib. But yeah you're basically on the same page as me. Java doesn't have the ability to be extended in the ways that clojure or python can. Python also allows for functional programming to a certain degree, but clojure is a lot more powerful when it comes to language extensions. Threads as a library (for js environments) for clojure. https://github.com/clojure/core.async https://github.com/clojure/core.async Logic programming for clojure. https://github.com/clojure/core.logic https://github.com/clojure/core.logic Declarative UI building, with dataflow semantics. http://reagent-project.github.io http://reagent-project.github.io Additionally immutability makes your life a lot easier. Parallel computing in clojure is a no brainer, you just change your map to pmap, and that's it.
deleted 11y ago
[deleted]
toong 11y ago
That's not a fair comparison. What about: IntStream.range(0, 100).filter(i -> i % 2 == 0).collect(Collectors.toList()); Disclaimer: I'm not writing Java nowadays, so this is my quick prototype from a quick google-session, it probably won't compile :D Edit: looks like I'm second, my google-session took too long :-) Maybe bonus points for C#: Enumerable.Range(0, 100).Where(i => i % 2 == 0);
- pmelendez 11y ago
  True... although that is to me even less readable than the first Java version. The clojure version still wins by a large distance in my book because of its elegance.
- yogthos 11y ago
  That's better, but Clojure still has less noise, and in my experience that adds up significantly in the long run.
  - toong 11y ago
    Less noise, true. But the grand-grand-parents' point is that some of that noise provides context, which (arguably) improves readability.
    - yogthos 11y ago
      The examples don't support that assertion though.
- highCs 11y ago
  > IntStream.range(0, 100).filter(i -> i % 2 == 0).collect(Collectors.toList()); This has been added to java to catchup with functional programming languages.
  - toong 11y ago
    I know those are functional concepts, but it feels more like trying to catch up with C# (LINQ) to me.
skizm 11y ago
One hand picked example from someone who prefers closure, which only works because there is a keyword "even".
- raspasov 11y ago
  It's a function in clojure.core, not a keyword. Sorry I didn't have to write a class for that.
- j-pb 11y ago
  Ok you provide a example in java, and I'll bet you a beer that I can write it more concise.
deleted 11y ago
[deleted]

huahaiy 11y ago

even? is a predicate that test if the parameter is an even number, as the name suggests. ? is part of the function name, not a syntax symbol (there's not much syntax in a Lisp, after all). By convention, function name ends with ? are predicates (or Boolean functions) in Clojure. Any competent Clojure programmer would likely have known most of the Clojure core functions by heart: map, reduce, filter, etc. There are maybe about a hundred of them? Unlike imperative programming languages, where you use three primitives (assignment, condition and loop) to construct everything, in Clojure, you use these core functions to construct your program. In a sense, the process of learning Clojure is the process of learning the use of core functions. These functions are simply at a higher level of abstraction than the three primitives, hence some people say that Clojure is more expressive, because it's closer to human thoughts than Von Neumann machine specificity.

sanderjd 11y ago
> Any competent Clojure programmer would likely have known most of the Clojure core functions by heart I really like Clojure, but I've always found the relatively huge set of core functions to be a major barrier to entry. I always have this nagging feeling of "there's probably a core function I'm missing to make doing this or that easier", and end up spending a lot of time poring over documentation instead of just programming. Maybe that's just how it is, and the answer is to push through it until you know the functions better, but there's something to be said for shipping a language with fewer, simpler, more primitive operations.
- huahaiy 11y ago
  From a cognitive point of view, learning a large number of idioms is more manageable for human beings than having to reinvent the mental constructs from primitives every time. This human capacity of dealing with idioms is what called "chunking" in psychology (https://en.wikipedia.org/wiki/Chunking_%28psychology%29 https://en.wikipedia.org/wiki/Chunking_%28psychology%29) Human has unlimited memory capacity and fast memory access, whereas human logical processing power is fairly limited and error prone. That's why any real human language has a large vocabulary.
- cobaltblue 11y ago
  It's definitely a taste thing. I found going from the batteries-included Python to the very limited strict C89 ansi-pedantic-standard rather annoying, but at the same time I got a lot of pleasure building a game from scratch in SDL instead of using a full-fledged engine that would have replaced a lot of my code with one-liners or even automagically managed bits in the background. I think a more overkill approach is better economically than being conservative, and in Lisp especially including a ton of common macros like 'or out of the box saves every other programmer from writing their own. I could go the rest of my life without seeing yet another custom <insert data structure here> in C or C++ which has a good implementation natively in almost every other language. I wish JavaScript had more builtin as I'm often in the position that things I take for granted as being there in Python, Java, or Clojure require me to roll my own in JS and that can easily take hundreds of lines of my own code or dependencies depending on what it is. (e.g. anything involving large integers.) I'm greatly thankful for regex support in my daily languages. I remember in a high school programming contest, one guy didn't know Java had regexes (or even what regexes were) while I knew them from using them in PHP to validate form inputs... Needless to say, he never got a fully working parser in the time he had for the problem. You may find https://github.com/jonase/kibit https://github.com/jonase/kibit helpful for some things. Otherwise I'd recommend just dedicating time to exploring the builtins so that you can resist the urge to wander while you should be programming -- there was a very interesting series a few years back some blogger made that covered all of Python's builtin modules, doing it yourself (or maybe there's one now for Clojure) is worthwhile. I also like to visit things like http://www.clojure-toolbox.com/ http://www.clojure-toolbox.com/ from time to time to see if there's anything new and exciting in areas of my interest.
- dkersten 11y ago
  "there's probably a core function I'm missing to make doing this or that easier" Would you prefer if there wasn't such a function to make it easier? You lose nothing if there isn't (or you don't know about it) and gain if there is. Why is this a barrier to entry?
  - sanderjd 11y ago
    I would prefer if there were very few un-namespaced functions which are limited to those I'm likely to use on any given line of code, and an intuitive namespace hierarchy for everything else. Basically, I think the core functions should be similar to reserved syntax is in other languages: a limited set of things that form the structure of most code, with more specific stuff imported from elsewhere. Note I'm not saying that the clojure way is "wrong", just that this[0] is a daunting set of information to be expected to "know by heart". [0]: https://clojure.github.io/clojure/clojure.core-api.html https://clojure.github.io/clojure/clojure.core-api.html
    - dkersten 11y ago
      Ah, I see. I can't disagree with that :)