4 ms·
Clojure typically doesn't attract the kind of developers who want to work on "boring" things So there is an imbalance there On one hand I'm kind of happy ther
by slifin 4y ago
Clojure typically doesn't attract the kind of developers who want to work on "boring" things
So there is an imbalance there
On one hand I'm kind of happy there's no one true way in Clojure to do web dev, because as I think Rich said, it's not a solved problem
So if we couple too heavily to one opinion on web dev then it's going to fail us as a community on a big scale and be hard to move away from
Sets of libraries are typically easier to swap out
In reality I think most Clojure businesses end up on reagent or and reframe and they are the defacto ways of doing web dev
For "solved" problems like stripe calls it would be nice if we had more people working on maintaining libraries but as a Clojurian myself I know I wouldn't do that myself so I only have me and people like me to blame
- janetacarr 4y agoI agree. Boring is tough to work on. I thought about touching on this in the article. Re-frame and reagent have become the default for Clojurescript development, but I have no idea how.
- seancorfield 4y agoCould you elaborate on that? I don't do ClojureScript, but I've dabbled with it on and off since 2013 (I've been doing Clojure in production for over eleven years). When I first started looking at ClojureScript, Om was "the thing" and Reagent was the new kid. I built a prototype at work with Om and then rebuilt it with Reagent and found the latter much more pleasant and idiomatic to work with. Last year, I dipped back into ClojureScript and built some simple projects with re-frame and I really liked it. I can definitely see why re-frame has become so popular.
- capableweb 4y ago> Clojure typically doesn't attract the kind of developers who want to work on "boring" things I'm quite the opposite. I love Clojure, just because it is "boring". Maybe not "boring" as in well-known, but "boring" as in the core language and it's runtime doesn't change and is stable, like really stable. I've upgraded projects using "ancient" Clojure versions (released +5 years ago) and not having to almost do any changes, as both the language, the runtime and most libraries are so stable over time. It simply just works. If people want to introduce breaking changes, they tend to prefer to create entirely new libraries instead.
- int_19h 4y agoI'm kinda amazed that 5 years ago is considered "ancient" these days, and stability over such a short time interval is considered remarkable.
- keithasaurus 4y ago> Clojure typically doesn't attract the kind of developers who want to work on "boring" things I kind of have the opposite opinion. I worked on a large Clojure codebase for several years. There was so much effort put into building tooling and libraries in Clojure because the ecosystem isn't huge, (and some of its bigger pieces are just a misadventure, ie spec). It was really frustrating to me because I felt like we were spending 50% of our time writing inferior versions of code that Python, Ruby, or even JavaScript already had as libraries. I'd have preferred that time to be spent on interesting things like business concerns. Of course, you can use java interop, but it's much more natural in Scala and Kotlin.
- huahaiy 4y agoCare to mention a few examples of missing libraries that you spent 50% of time writing on the job? I can hardly recall a case where I could not find a Clojure libraries for. The only exception would be wrappers for proprietary APIs, such as Stripe.
- keithasaurus 4y agoI have a little trouble remembering all the details, and I'm not sure I can speak to where things are now. Maybe it's more helpful to mention where I thought we got off-the-rails with building our own stuff? - unit tests with ephemeral dbs - db migrations - ORM library Many of these things exist in Java and in retrospect, were probably the way to go. One other pain point was that Clojure libraries would stop being updated, lag too far behind the java libs, or lack features. I remember this being the case with Google Cloud and AWS, and I think Elastic Search. I remember a number of times just completely swapping out the Clojure wrapper lib for the java lib.
- huahaiy 4y agoMost of these things do have Clojure libraries. For example: - unit tests with ephemeral dbs: we use com.opentable.components/otj-pg-embedded for postgres. - db migrations: there are Migratus and many others, we also just use flyway in app startup shell script Some are not relevant if you write proper Clojure. - ORM library: I am not sure you need these in Clojure. Clojure is data-oriented, not object-oriented, so you don't need to map data to objects. Clojure is good at transforming data. Just keep data as data. I don't recall us spent too much effort in building Clojure libraries of our own for something missing. For my over a decade of Clojure career, I only built two Clojure libraries of my own. Both were not missing, just that I didn't like the existing ones. One is a Clojure data diff library (Editscript), and another is a database (Datalevin). In general, if one cannot find a Clojure library (very rare), we tend to use Java interop. As mentioned repeatedly, Clojure is a hosted language and we embrace the platform.
- thom 4y agoI don’t understand this at all. Clojure’s all over the place in banks and fintech startups and they’re all boring as hell. People don’t spend a lot of time on random proprietary wrappers because they don’t provide a lot of leverage, not because they’re ‘boring’.
- eternalban 4y agoThis is the second appearance of "boring" in this thread. There is also "boring" libraries. Somewhere someone should-be/is writing a thesis on the psychology of programming and programming languages.