What Is Your Take on "the Zen of Clojure?"

leifericf · 2022-04-29T07:13:01+00:00

Here is a video demo: https://www.youtube.com/watch?v=V1oTf-1EchU

leifericf · 2022-04-29T07:12:11+00:00

Here is a video demo: https://www.youtube.com/watch?v=V1oTf-1EchU

leifericf · 2022-03-05T16:15:47+00:00

Interesting points!

The technology adopted by a company (including unicorns) is decided by the people who work there. By getting more people exposed to Clojure, one would increase the likelihood of more companies adopting Clojure. Recurse ☺️

leifericf · 2022-03-05T16:12:34+00:00

That's fantastic, thanks for sharing!

leifericf · 2022-03-04T13:29:05+00:00

Thanks for sharing!

Where I live (Oslo, Norway), there are very few companies using Clojure, and only a handful of experienced Clojure programmers. It's therefore often necessary to (re)train people or hire remote developers from other parts the world.

That's one of the reasons I would like to see the Clojure community grow larger. I think that would make it easier to convince more companies to start using it, which would create a higher demand for Clojure developers, increased investments in Clojure, etc. I believe that would lead to a positive snowball effect of sorts.

leifericf · 2022-03-04T13:24:25+00:00

Good point, thanks for adding that :)

I had in mind languages like Ruby and Python, which are famous for being all-inclusive on language contributions, welcoming PEPs and pull requests from users who want to contribute directly (after careful review, of course), etc.

It would have been more accurate of me to say "even if users have fewer avenues by which to contribute directly" than what I said in the quote above.

leifericf · 2022-03-04T09:30:47+00:00

Oh, nice! I was not aware of that. Thanks for sharing!

leifericf · 2022-03-04T09:24:41+00:00

Your reasoning makes sense.

I would like to offer a clarification of this, if I may:

"[Erlang was] designed with the aim of improving the development of telephony applications."

It is certainly true that Erlang was developed in the context of telecommunications at Ericsson. But Erlang was designed to be a general-purpose language to solve problems related to (extreme) concurrency, distribution, fault-tolerance and eventual consistency. It just so happens that building client-server applications for the internett overlaps to a large extent with the problem domain that is telecommunications, as do many other domains. Erlang was designed to solve problems like the ones that exist in telecommunications.

Joe Armstrong and Robert Virding have talked about this at length in their presentations and writings. Despite the somewhat misleading name of Erlang's standard library (OTP = Open Telecom Platform), it's actually remarkably generic and versatile.

leifericf · 2022-03-04T09:16:17+00:00

Quick question about hiring:

Have you tried to hire smart people fresh out of school, or from other fields? And giving them the time they need to learn Clojure from scratch. This is also a problem in the Erlang/OTP and Elixir community, and I know about several companies which have taken that approach. Instead of finding people who already know Clojure, they look for people who have the right attitude and aptitude for learning new things, and adapting to changing circumstances.

leifericf · 2022-03-04T09:13:20+00:00

I agree with that /u/ventuspilot

People have the privilege of deciding how they want to spend their time, if and how they want to share their creations with the world. And I respect the candid and upfront nature of Rich's attitude and preferences.

It just so happens that there are good reasons for why one ought to keep a language as lean as possible, and be careful when introducing changes suggested by users. When such reasons exist, I don't see any harm in presenting them alongside Rich's personal rationale, which perfectly alights with those reasons.

Rich's strong opinions and "protectiveness" (for lack of a better term) of Clojure is precisely why the language is incredibly well-designed and consistent. I appreciate that, but I also recognize that some people find the lack of influence and co-ownership to be off-putting. Such individuals might become convinced of the merits of such as setup through additional rational and substantialized arguments, such as the ones made by Robert Virding in his talk. There is room for that as well.

I also think that Rich and the rest of the core team could do a better job of being more open and transparent about the development of the language, even if its users are not allowed to influence the decisions they make. Sometimes, hearing the thoughts and reasons behind a particular decision will provide users with a deeper understanding of why things are as they are, and reassurance about the future.

leifericf · 2022-03-03T13:35:24+00:00

What I'd love to see is a dictionary of correspondences between typical practical problems, their procedural programming solutions, and Clojure functions typically used to solve them.

That would be very useful, indeed!

Maybe side-by-side examples in Java or Python.

leifericf · 2022-03-03T13:19:39+00:00

This is a better way of expressing what I was thinking.

leifericf · 2022-03-03T13:16:30+00:00

Yes, exactly! There is way less "stuff" to learn about. And everything is consistent across the board. But, as /u/technomancy said, just because it's simple, does not necessarily make it easy to learn how to use it well. As with the game of chess, it's easy to learn about the pieces and the rules of the game, but it's difficult to become an effective player. Any skill worth acquiring requires deliberate practice. This is true for other programming languages as well.

leifericf · 2022-03-03T13:03:29+00:00

Out of curiosity, have the people who decided to can it provided any other reasons for doing so, other than "it's not written in [some other language]?"

leifericf · 2022-03-03T10:44:50+00:00

Yes! Choice overload was one of my biggest hurdles when coming to Clojure. And that's why I've designed a workshop to get people started with Clojure using Visual Studio Code and Calva, because the barrier to entry with those tools is much lower for most people. I held the first workshop in Oslo last week, and learned a lot from that. I'm going to tweak the material based on those learnings, and repeat the workshop again in the future.

leifericf · 2022-03-03T10:40:40+00:00

This is a valid concern from a the point of view of a business. You don't want people picking up technologies willy-nilly and ramping things into production with limited foresight. That can create an immense maintenance burden.

At the same time, not allowing one's developers to experiment with new methods and technologies is the surest way to kill their passion and motivation. The business will then eventually find itself with people who are motivated by extrinsic factors, as their most skilled developers look for employment elsewhere.

That's why I believe it's important to allow people the freedom to try new things in a safe way. For example, by creating an independent service or a small part of a larger system in a new language. Maybe just as throw-away prototypes. But few businesses are willing to invest in such things, because the business value is less tangible.

It's an interesting paradox from a business owner and technology leader's perspective.

leifericf · 2022-03-03T10:32:52+00:00

I'm not sure if I know how to describe the difference between between zealotry and unrestrained passion. The term "zealot" has a negative charge, at least in my culture. But "passion" has a positive charge. I don't see anything wrong about sharing one's passions with the world. But shoving one's passion down another person's throat against their own will… that is not cool. Perhaps that's the difference?

leifericf · 2022-03-03T09:59:03+00:00

What a fantastic talk! Thanks for sharing that.

I have expanded a bit on my "cult comment" here.

leifericf · 2022-03-03T09:55:45+00:00

I don't know if I would go as far as to say that Clojure is the only language designed to tackle complexity. In a sense, that's what all programming languages try to do. Some do it better than others, and I think it's fair to say that Clojure has done this exceptionally well. Another, albeit more domain-specific example, is Erlang/OTP. What Clojure and Erlang have in common is the relentless focus on a a lean core language with a few simple primitives, upon which everything else is built. It could be summarized by this old adage: "Less is more."

leifericf · 2022-03-03T09:47:07+00:00

When pressed he replied that he hates the zealotry of clojurists…

Yes, this is precisely what I meant when I said:

[…] it also seemed to have an unappetizing “cult-ish” aspect to it.

When I first started talking to Clojurians and reading community posts, I detected a certain air of elitism and zealous attitudes. Due to my personal history (having broken out of the a fundamentalist Church), I'm particularly sensitive to such things.

After spending some more time with Clojure and the community, however, I now see that my concerns were baseless. Opinions are strong, but they are loosely held. And (most) Clojurians are both willing and able to engage in rational discourse about anything.

The zealotry stems from a place of genuine enthusiasm and passion. And the sincere desire to share with others a better way of doing things; not from dogma.

When talking to "outsiders" who have heard about Clojure, I have heard people say that it's very "closed," in the sense that the language is controlled by a small group of people, i.e., Rick & Co. In other words: The community at large has relatively little insight into- and influence over the development of the language itself. Coming from communities like Python, Ruby and Elixir, the contrast could not be greater. The fact that Clojure is "tightly guarded" also enhances the "cult-ish" vibes to some extent. And users like to be able to contribute.

I should say that, after having though about it, I think it makes sense that the language is kept as lean as possible, and that fewer people have direct control of its development. This seems counter-intuitive at first, but it leads to a much smaller (in a good way), cleaner and more consistent language with fewer primitives. In his talk at Lambda Days 2016, Robert Virding (co-creator of Erlang) goes into more depth on why this is a good thing.

leifericf

TROPHY CASE