Fork me on GitHub

@orestis One place I worked at a long time ago had a still operational, but very old system, that they had been incrementally upgrading for ages. At one point, they decided to switch the old database from whatever to Oracle. The old database couldn’t distinguish between uppercase and lowercase, so everything was in uppercase for some reason. When they switched to Oracle, they had to make Oracle behave like this, because the frontend expected it. A year later, they switched the frontend to something else, and then they had to make it behave the same way, because the Oracle database expected it. Meaning, they were now at a point where both frontend and database could handle uppercase and lowercase strings just fine, but were constrained by a system that didn’t exist anymore.


I would start with a small proof-of-concept of Clojure on both backend and frontend to make sure you’re not imposing artificial constraints on yourselves.


Ideally, you would make the proof-of-concept such that it does some small piece of everything you currently do. For example, I recently made a proof-of-concept for a system that would parse article input files, do NLP on them, store them in Datomic, and seed the data from Datomic into search instances, using Datomic Cloud and Ions. It took about a month to do, and each step is about 10-20% complete vs. what I would consider a production version. I.e., it parses a subset of what an article file might look like. It does a subset of the NLP that should be done. It stores a subset of the results in Datomic, and the search instances are seeded with a subset of that.


With the entire chain of major components in place, it’s much, much easier to reason about what the scope of a production-ready system would be like.


Also there’s a risk that you end up having team of 5 where 2 does backend/Clojure and and 3 frontend/JS.. When you could have 5 full-stack devs eventually doing CLJ/CLJS.


Maybe I need to explain my thinking. IME ‘features’ tend to require both backend/frontend and it’s better to not have (small) team artificially divided between them. Having same language and tooling on both sides narrows the gap between and you’ll get more stuff done end-to-end, like @henrik just described.


Yeah, having to coordinate between two teams is really annoying. I’m the only one comfortable in both domains, alas.


(There’s also some culture issues here that we’re trying to navigate, as in, demonstrate that we are even able to do some minor rewrite in finite time...)


Yeah, attitudes are difficult to change. It’s important to get the team to buy in, whatever you decide.


At the same time, even artificial constraints sometimes make sense - to bound the scope and avoid pie-in-the-sky, magic solution thinking.


By artificial constraints, I mean constraints that has nothing to do with either the business or the problem domain.


It’s much easier to try say and build a GraphQL server, than trying to also figure out a unique snowflake of an architecture. Especially if the underlying domain isn’t that complicated...


One of the (in my opinion) huge wins with Clojure is that it clears away inconsequential gunk and allows you to focus on the problem domain. To leverage it, it might require breaking from some previous models.


For Clojure, I’m convinced 100%. It’s CLJS I’m on the fence for, perhaps because of my own unfamiliarity, but also from seeing the kind of issues people ask about on this Slack (mainly JS interop etc)


What’s familiar and at hand is automatically going to be easier, as we all know from Simple Made Easy. While it’s easier right now, it doesn’t really clarify the long-term business value of doing so vs. doing something else. This is largely why I made the proof-of-concept above, I needed to demonstrate the viability and show that it’s within reach.


Did you make it on your own or with a small team? Part of my mandate is that any proof of concept has to be made with a small team... that is not super familiar with Clojure. Hence my desire to limit the scope a little bit. Perhaps though we can start with a backend and then address front end if time allows.


No need to be afraid of JS interop. It works. There’s just some confusion because there’s more than one way to do it and some rough edges here and there.


@orestis In your situation, I would definitely do it as a group, or it would just serve to fracture the team. In my case, it was a pipe dream in the company, that people thought would take huge amounts of effort. I wanted to demonstrate that with the right tools, it’s well within reach.


I went for the smallest thing I could think of that demonstrated the business value.


It’s hard to advise exactly how to navigate your situation, because of the different circumstances. First thing must be to overcome the neophobia, if there is any. Some people are just afraid of new things, and I currently know of no way to overcome that except continued piecemeal exposure.


Love the neophobia term, I’ll steal it.


In our case it’s a mixture of Blub (ie I don’t see the value of using a language that compiles to JS, it’s still JS) and fear of wasting a year ending up nowhere, which has happened before and left everyone scarred. I’m new and don’t have this kind of (real) emotional baggage.


You’re stealing it from Robert Anton Wilson 😉 Don’t use it as an accusation directly to people though, no one likes to think that they are neophobic.


I’m Greek so I can claim I made it up on the spot :)

😄 4

Yeah, people are the hardest thing to navigate here.


It’s been a sobering experience coming from a mostly solo career.


Do you have the flexibility to make a learning event or a short project out of it?


I also know that when people are under pressure, they become more neophobic.


Stress makes us revert to the familiar.


If your team is under pressure from elsewhere, relieving that pressure should help, or they might not have the mental capacity to spare to take in something new.


Right, I should have mentioned - it is meant to be a learning event, but at the same time it has to be realistic enough to not be dismissible via hand waving.


Only way to find out is to try. 🙂


Alright, that’s good. If you can create a space where the normal day-to-day stuff doesn’t apply fully, it’s easier. That’s part of the point of having retreats in a different location rather than on-site.


Ooh, I was thinking of doing this outside the office in some kind of mob programming fashion. Also good point about stress in general.


Thanks for all the input! I have to get back to breakfast or I’ll risk an episode :)

👍 4

What is a good way to show your co-workers the power of Clojure? I am not a consultant. I was thinking of building the system we have (Parts of it) in Clojure and show them.


Currently working in a Java-stack.


Brown bag maybe? We used to arrange those at previous place where I was working. They were quite successful. I had one where I live-coded something simple in Clojure to demonstrate the power of REPL.


I was contemplating building some internal tool in Clojure — would bring some value to the business while not being critical/unreplaceable, and I could hopefully also demonstrate how concise/simple the code was.


At my last job I inherited the task of managing our localization/translation process, so I wrote a Clojure app that would read/parse our localization files, store each entry in a SQL database, allow in-place edits and version control, export to Excel spreadsheets to send to the translators, re-import the translated results, and generate updated localization files. It started out being a tool for me to use to make my job easier, but my boss found out about it and everybody ended up using it. (It was a Java-only shop otherwise.)


I was always trying to find ways to sneak Clojure into my day job 😉


Well, it's official. Neutron stars contain flying spaghetti monsters

😂 4