4 ms·

These Talebian references got me thinking. Couldn't you argue that it shows a certain arrogance and non-results oriented "falling in love with ideals and tools"

These Talebian references got me thinking. Couldn't you argue that it shows a certain arrogance and non-results oriented "falling in love with ideals and tools" detachment from reality to use Clojure instead of good ol' Java?

krn 7y ago
> non-results oriented I think Clojure's ecosystem is more results-oriented than almost any other currently available[1]. It just requires a completely different mindset to understand, which an average software developer lacks. Therefore, Java is a much better fit for an Apache project. [1] https://news.ycombinator.com/item?id=19728502 https://news.ycombinator.com/item?id=19728502
jrs95 7y ago
Oh I'm sure people make that argument all the time. I just don't think it holds up to reality. It's sort of just a dismissal of better options. The reality in my experience is that Java is just a poor choice for a lot of software. That's why you end up with frameworks built upon frameworks & AspectJ to basically make it behave like a dynamic language and try to hide some of the ugliness of the underlying APIs from you. And it's just because it's corporate approved and "everyone knows Java". I don't see how it can reasonably be considered the pragmatic choice. It's just not productive, and the final product isn't something that I would consider easy to understand or maintain most of the time either.
TeMPOraL 7y ago
> Couldn't you argue that it shows a certain arrogance and non-results oriented "falling in love with ideals and tools" detachment from reality to use Clojure instead of good ol' Java? Since when trying to do better than using a tool designed for mass-producing software with dumb and cheap labor is "falling in love with ideals and tools"? It's kind of like saying that using an excavator over a bunch of people with shovels is "falling in love with ideals and tools". No, it just allows a single person to get more work done faster and better. Our industry is weird. When recruiting, companies claim they want "the best of the best" and will often test you on ridiculous stuff. But when it comes to actual work, on industry scale, learning, growing professionally, and doing things in a clean and efficient way is frowned upon. Best take the weakest tool available and compensate for its shortcomings with third party services.
- enlyth 7y ago
  > trying to do better than using a tool designed for mass-producing software with dumb and cheap labor This is completely disregarding the available developer pool of Java programmers, and the fact that a lot of them are really talented and can write efficient, production ready software. The fact is, there is at least an order of magnitude more developers to choose from compared to Closure, and hiring and replacing people is hard. Ignoring business realities like this is bad, and akin to "falling in love with ideals and tools". Also, someone using Java does not automatically make them dumb cheap programming labour, same as someone using Closure is not automatically going to be a 10xer who has memorised Knuth. It's possible to write bad FP code as well.
  - TeMPOraL 7y ago
    > Also, someone using Java does not automatically make them dumb cheap programming labour, same as someone using Closure is not automatically going to be a 10xer who has memorised Knuth. I'm not claiming that. I'm claiming that Java has a long history of enabling factory-farming software development, whereas Clojure doesn't lend itself to this style. I mean that in the sense that an army of cheap labor with shovels can, in principle, do the same job as a few trained operators in construction machines. The physics of dirt is the same, and so the job done is essentially the same - just some tools let you do it faster with fewer people. And then, the quantity (or lack of it) has a quality of its own - the more people you engage doing smaller and smaller pieces of work, the more your work becomes about coordinating people than doing the actual job. (I'm aware that since version 8, Java is growing to be a quite decent programming language. This somewhat weakens my criticism, but not all that much.) But yeah, I'm also claiming that ceteris paribus, the pool of Clojure developers will yield you higher-skilled programmers on average than the pool of Java programmers - simply because everyone and their dog knows some Java nowadays, and some Java is enough to make some progress in factory-farming software development, whereas Clojure is somewhat atypical and requires expanding your competences beyond the very basics. (Or, in other words, I'm claiming that the distribution of skill of Java programmers is wider than that of Clojure programmers, with the latter having higher minimum and mean values, and comparable max values.)

krn 7y ago

> non-results oriented I think Clojure's ecosystem is more results-oriented than almost any other currently available[1]. It just requires a completely different mindset to understand, which an average software developer lacks. Therefore, Java is a much better fit for an Apache project. [1] https://news.ycombinator.com/item?id=19728502 https://news.ycombinator.com/item?id=19728502

jrs95 7y ago

Oh I'm sure people make that argument all the time. I just don't think it holds up to reality. It's sort of just a dismissal of better options. The reality in my experience is that Java is just a poor choice for a lot of software. That's why you end up with frameworks built upon frameworks & AspectJ to basically make it behave like a dynamic language and try to hide some of the ugliness of the underlying APIs from you. And it's just because it's corporate approved and "everyone knows Java". I don't see how it can reasonably be considered the pragmatic choice. It's just not productive, and the final product isn't something that I would consider easy to understand or maintain most of the time either.

TeMPOraL 7y ago

> Couldn't you argue that it shows a certain arrogance and non-results oriented "falling in love with ideals and tools" detachment from reality to use Clojure instead of good ol' Java? Since when trying to do better than using a tool designed for mass-producing software with dumb and cheap labor is "falling in love with ideals and tools"? It's kind of like saying that using an excavator over a bunch of people with shovels is "falling in love with ideals and tools". No, it just allows a single person to get more work done faster and better. Our industry is weird. When recruiting, companies claim they want "the best of the best" and will often test you on ridiculous stuff. But when it comes to actual work, on industry scale, learning, growing professionally, and doing things in a clean and efficient way is frowned upon. Best take the weakest tool available and compensate for its shortcomings with third party services.

enlyth 7y ago
> trying to do better than using a tool designed for mass-producing software with dumb and cheap labor This is completely disregarding the available developer pool of Java programmers, and the fact that a lot of them are really talented and can write efficient, production ready software. The fact is, there is at least an order of magnitude more developers to choose from compared to Closure, and hiring and replacing people is hard. Ignoring business realities like this is bad, and akin to "falling in love with ideals and tools". Also, someone using Java does not automatically make them dumb cheap programming labour, same as someone using Closure is not automatically going to be a 10xer who has memorised Knuth. It's possible to write bad FP code as well.
- TeMPOraL 7y ago
  > Also, someone using Java does not automatically make them dumb cheap programming labour, same as someone using Closure is not automatically going to be a 10xer who has memorised Knuth. I'm not claiming that. I'm claiming that Java has a long history of enabling factory-farming software development, whereas Clojure doesn't lend itself to this style. I mean that in the sense that an army of cheap labor with shovels can, in principle, do the same job as a few trained operators in construction machines. The physics of dirt is the same, and so the job done is essentially the same - just some tools let you do it faster with fewer people. And then, the quantity (or lack of it) has a quality of its own - the more people you engage doing smaller and smaller pieces of work, the more your work becomes about coordinating people than doing the actual job. (I'm aware that since version 8, Java is growing to be a quite decent programming language. This somewhat weakens my criticism, but not all that much.) But yeah, I'm also claiming that ceteris paribus, the pool of Clojure developers will yield you higher-skilled programmers on average than the pool of Java programmers - simply because everyone and their dog knows some Java nowadays, and some Java is enough to make some progress in factory-farming software development, whereas Clojure is somewhat atypical and requires expanding your competences beyond the very basics. (Or, in other words, I'm claiming that the distribution of skill of Java programmers is wider than that of Clojure programmers, with the latter having higher minimum and mean values, and comparable max values.)