3 ms·

Assuming that you are mapping the results to a Dictionary, sure it would be similar. My point was more that C#/Java developers (myself included at one point in

by adamkl 6y ago

Assuming that you are mapping the results to a Dictionary, sure it would be similar. My point was more that C#/Java developers (myself included at one point in time) would typically reach for classes to store the results, rather than just a Dictionary<String, String>. It’s not that other languages can’t to this, it just that this approach doesn’t always jive with their conventions like it does with Clojure.

Jare 6y ago
I can't help but feel that all arguments defending how this Clojure solution supposedly can't be done as elegantly in other languages, use "idiomatic Clojure" as the judging criteria. Of course the conclusion writes itself.
- adamkl 6y ago
  Well, you can write code a lot like this in JavaScript using a library like Ramda, and get a lot of the benefits. But then everyone that you on-board to that project has to be up to speed with how the code is being written and why. With Clojure, that understanding is table-stakes. So in that respect, the conclusion does write itself.
  - onetom 6y ago
    I've actually tried that: https://github.com/enumatech/sprites/blob/master/lib/__tests__/sprites-tests.js#L77-L82 https://github.com/enumatech/sprites/blob/master/lib/__tests... reads quite like Clojure, but looks foreign to JavaScript programmers... I even made extensions to Ramda, so you can thread a mixture of async and non-async code with it: https://github.com/enumatech/sprites/blob/master/lib/fp.js#L51-L54 https://github.com/enumatech/sprites/blob/master/lib/fp.js#L... At the end the friction was just annoying and no one else really understood the greatness of this approach, since they didn't know Clojure...
- didibus 6y ago
  In my experience, it's not that you can't do these things in some other languages, it's that you won't, and if you try too, there will be more ceremony and friction. That said, this is where a lot of people who took a detour through Clojure, come out of it saying when they went back to their prior language or some other language, they felt like they had suddenly become better programmers, and it helped them even in other languages to write better programs. Clojure showed them the way, and now they can recognize it and think of doing it as such in other languages as well. Maybe a different way to think of it is that you can do OOP in Clojure if you really want, but you won't. Similarly, in Java, you could try and do FP with immutable collections and value semantics, but most likely you're not going too. And I'm using Java here because in theory, Java and Clojure have the exact same set of available features, they run on the same JVM, same runtime, compile to the same bytecode, can share libraries, etc. So it goes to show that the language itself does influence the style that is most convenient for writing your programs in.
jmchuster 6y ago
Right, the more idiomatic approach in java would be - define the class - let the framework fully handle serializing/deserializing it from your file to the neat in-memory object
- adamkl 6y ago
  That’s great if your dealing exclusively with CSV files and a fixed set of data types, but the point is that this approach in Clojure is universal regardless of where the data is coming from, or going to. Everything comes in as a map, gets manipulated with the powerful set of core Clojure core functions, and spit back out as a different shaped map. It’s a very flexible approach to dealing with data, and that is one of the main appeals of Clojure.
  - deleted 6y ago
    [deleted]
  - jmchuster 6y ago
    Yup, Java in its current incarnation is definitely a better fit for larger companies that can present more standardized workloads. You want to give each team clean and explicit interfaces that they have to work with, and not have to worry about different shaped maps. Flexibility and power just lets junior developers shoot themselves in the foot.
    - adamkl 6y ago
      I agree, I wouldn’t suggest Clojure for a large company with lots of junior developers. I wouldn’t suggest Java either, though. Go would be a better fit for that situation these days. I look at Clojure and Go as different sides of a coin. One is a powerful language the let’s a small team of experienced developers get a lot done with a small amount of code. The other is a simple language that lets a lot of less experienced developers get a lot done with a lot of code. I want to stress in this comparison though, that I don’t view one as better than the other. Go was designed for development at scale, where you have lots of developers, all at different levels, all needing to contribute large amounts of code. In this respect, it does a great job at removing most of the rope that people can use to hang themselves. If I needed to pick one language to use at a large enterprise, it would probably be Go. Clojure gives you a (different) set of limited functionality, but what it gives you is very powerful, and very foreign to most developers, so you can definitely hang yourself trying to force everyone into using it. If I got to choose one language for myself to use, it would be Clojure.

by adamkl 6y ago

Jare 6y ago

I can't help but feel that all arguments defending how this Clojure solution supposedly can't be done as elegantly in other languages, use "idiomatic Clojure" as the judging criteria. Of course the conclusion writes itself.

adamkl 6y ago
Well, you can write code a lot like this in JavaScript using a library like Ramda, and get a lot of the benefits. But then everyone that you on-board to that project has to be up to speed with how the code is being written and why. With Clojure, that understanding is table-stakes. So in that respect, the conclusion does write itself.
- onetom 6y ago
  I've actually tried that: https://github.com/enumatech/sprites/blob/master/lib/__tests__/sprites-tests.js#L77-L82 https://github.com/enumatech/sprites/blob/master/lib/__tests... reads quite like Clojure, but looks foreign to JavaScript programmers... I even made extensions to Ramda, so you can thread a mixture of async and non-async code with it: https://github.com/enumatech/sprites/blob/master/lib/fp.js#L51-L54 https://github.com/enumatech/sprites/blob/master/lib/fp.js#L... At the end the friction was just annoying and no one else really understood the greatness of this approach, since they didn't know Clojure...
didibus 6y ago
In my experience, it's not that you can't do these things in some other languages, it's that you won't, and if you try too, there will be more ceremony and friction. That said, this is where a lot of people who took a detour through Clojure, come out of it saying when they went back to their prior language or some other language, they felt like they had suddenly become better programmers, and it helped them even in other languages to write better programs. Clojure showed them the way, and now they can recognize it and think of doing it as such in other languages as well. Maybe a different way to think of it is that you can do OOP in Clojure if you really want, but you won't. Similarly, in Java, you could try and do FP with immutable collections and value semantics, but most likely you're not going too. And I'm using Java here because in theory, Java and Clojure have the exact same set of available features, they run on the same JVM, same runtime, compile to the same bytecode, can share libraries, etc. So it goes to show that the language itself does influence the style that is most convenient for writing your programs in.

jmchuster 6y ago

Right, the more idiomatic approach in java would be - define the class - let the framework fully handle serializing/deserializing it from your file to the neat in-memory object

adamkl 6y ago
That’s great if your dealing exclusively with CSV files and a fixed set of data types, but the point is that this approach in Clojure is universal regardless of where the data is coming from, or going to. Everything comes in as a map, gets manipulated with the powerful set of core Clojure core functions, and spit back out as a different shaped map. It’s a very flexible approach to dealing with data, and that is one of the main appeals of Clojure.
- deleted 6y ago
  [deleted]
- jmchuster 6y ago
  Yup, Java in its current incarnation is definitely a better fit for larger companies that can present more standardized workloads. You want to give each team clean and explicit interfaces that they have to work with, and not have to worry about different shaped maps. Flexibility and power just lets junior developers shoot themselves in the foot.
  - adamkl 6y ago
    I agree, I wouldn’t suggest Clojure for a large company with lots of junior developers. I wouldn’t suggest Java either, though. Go would be a better fit for that situation these days. I look at Clojure and Go as different sides of a coin. One is a powerful language the let’s a small team of experienced developers get a lot done with a small amount of code. The other is a simple language that lets a lot of less experienced developers get a lot done with a lot of code. I want to stress in this comparison though, that I don’t view one as better than the other. Go was designed for development at scale, where you have lots of developers, all at different levels, all needing to contribute large amounts of code. In this respect, it does a great job at removing most of the rope that people can use to hang themselves. If I needed to pick one language to use at a large enterprise, it would probably be Go. Clojure gives you a (different) set of limited functionality, but what it gives you is very powerful, and very foreign to most developers, so you can definitely hang yourself trying to force everyone into using it. If I got to choose one language for myself to use, it would be Clojure.