I agree with your call to study logic. There is something systematically empirical about logic & epistemological philosophy[1].
Over the years,I have read a bunch of critical thinking books and have found myself wanting something at a lower level of abstraction. A recommendation based on recent reading would be "An Enquiry Concerning Human Understanding"[2]
Did you find Hume's writing approachable? I'm skeptic by nature and always wanted to read him, but nowadays I tend to read articles instead of diving into 18th-century books...
Although I had similar apprehensions before I started reading Hume, I have found his writing approachable. For "Enquiry Concerning Human Understanding", I found this edition with explanations of certain words/phrases by Jonathan Bennett very useful: https://www.earlymoderntexts.com/assets/pdfs/hume1748.pdf
It was refreshing how open he was to accepting that his research, even decades after its original publication, could have lapses and errors. Research, after all, builds on corpus of knowledge existing at the time, and we should expect corrections as the underlying base shifts & corrects itself.
This past week I read a critical essay penned by George Orwell on Wells, Wells, Hitler and the World State (http://orwell.ru/library/reviews/wells/english/e_whws). It serves as a great supplementary read to this article.
Thanks. It's Orwell writing in 1941 (1) during the WW II about Wells not understanding what the "irrational" leaders like Hitler were able to archive (and more, not everything is about just H. G. Wells there):
... "he could not grasp the tremendous strength of the old world which was symbolised in his mind by fox-hunting Tories. He was, and still is, quite incapable of understanding that nationalism, religious bigotry and feudal loyalty are far more powerful forces than what he himself would describe as sanity."
And:
"The people who say that Hitler is Antichrist, or alternatively, the Holy Ghost, are nearer an understanding of the truth than the intellectuals who for ten dreadful years have kept it up that he is merely a figure out of comic opera, not worth taking seriously. All that this idea really reflects is the sheltered conditions of English life."
(Emphasis mine).
There are enough those who could be associated with these sentences even today. More decades later the world has changed less than I have believed as I was younger.
1) For the context: H. G. Wells published The Time Machine in 1895, died in 1946. Orwel published 1984 in 1948, and was 38 years old in 1941.
I am grateful that I did not work remote at the start of my career (it was not an option offered to me), because it would have been hard to find the self-drive & hand-holding I needed at the beginning of my career all by myself. But I agree with you; remote work is better suited for people who are accustomed to working by themselves. It might not be for everyone. And I certainly do not recommend it at the onset of one's career.
The difficulty is if all the junior are working on site for mentorship and the development of good habits, if the seniors are away, who'll teach them that?
> While Storm's Clojure implementation served it well for many years, it was often cited as a barrier for entry to new contributors. Storm's codebase is now more accessible to developers who don't want to learn Clojure in order to contribute.
It is interesting to contrast this with state of affairs in Apache Spark. Spark has thrived well in spite of being a Scala project; Scala arguably has a higher barrier for entry compared to Clojure (although the flavour of Scala used within Spark closely resembles Java).
> I also consider this a success story for Clojure.
It is a success story for Clojure, but this move is a big negative feedback for the language. A team starting out on an open-source project will be mighty reluctant to start it with Clojure; because it might get rewritten not so much into the future. That is not good news for Clojure
If, five years (or what-have-you) down the line—when you've pretty much enumerated all use-cases for the project, solidified what it's supposed to do and how, learned from your mistakes, and so on—you can't come up with a better design, something is off. With all that knowledge, there should be plenty of space for performance optimizations and pruning of vestigial stuff for a non-trivial project.
As for switching to Java, that makes perfect sense to me if that is what the contributors prefer. If you're going to make a big rewrite, you might as well change the language to one you prefer when you have the opportunity.
As someone who spends 100% of dev time in Clojure, I'm quite happy to see this development. Dipping into Java isn't uncommon for optimizations in Clojure, so this is like someone taking the time to do a massive under-the-hood optimization from the point of view of a Clojure user. I doubt it changes the project's status much in the Clojure community. Perhaps it'll even see an uptake in use.
What it doesn't say much about is Java vs. Clojure in my opinion. Different contributors, with different amounts of pertinent knowledge, and years apart. I'm not sure how you would control for those variables in a comparison. It should be read more as, "we put in a heck of an effort to make this thing faster and more useful", and kudos for that.
> A growing Clojure shop in Seattle seems to be having success with this, onboarding the language is a small fraction of overall onboarding.
I can attest to this fact, as part of a unicorn upstart with dev offices in Sao Paulo and Berlin. Clojure onboarding has never been a major roadblock for new engineers. And we never hire asking for "X years of lang experience". Almost everyone in the (~300 strong) engineering team started with zero-to-little Clojure background.
What do you look for? I mean the "X years of experience" is a shorthand proxy for "can get stuff done in the language we use". So I imagine you must have some other way of getting an idea of how a candidate can get things done. Would love to hear more about it.
What we have found is that it is enough to verify 'can get stuff done', and leave out 'in the language we use'. So, much of the interview turns out to be a process of validating two things:
1. can do what is claimed in the language of choice.
2. gauge enthusiasm and interest to pick up our language.
FWIW, that's been our experience as well (both at a largeish publicly traded company and now at a small private consultancy). Go get work sample tests :)
(It's fine if your work sample test really just focuses on one language! But then make it part of the rubric if that's the answer you want, and tell the applicant about that rubric.)
Mostly in our conversations, in an informal way. I would say the assumption we make is that developers with a penchant for any form of functional prog and/or Lisps, and with an acute focus on testing have an easy time grasping Clojure. And we bias our rubric towards this.
Also, we encourage our candidates to choose Clojure for their take-home assignment, even if they do not have any prior taste of it. This, for those of them who choose that option, gives an idea of if they would enjoy working in it. Our rubric however does not have a bias against developers who do not choose Clojure for their assignments, and we make this explicit to the candidates as well.
I guess the difference here is if they have to learn Clojure just to contribute to a single project, then they may be put behind some other things they want to learn and contribute to first.
Demsetz' Theory as a framework for the economics of open source was first used in 'Coase’s Penguin, or, Linux and The Nature of the Firm' by Yochai Benkler.
[1]https://plato.stanford.edu/entries/epistemology/
[2]https://en.wikipedia.org/wiki/An_Enquiry_Concerning_Human_Un...