Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Structuring Clojure applications

yogthos.net

Post reply on HN
Print view View original

21–30 of 67 posts

Re: Structuring Clojure applications

#21

Post by lairv »

twawaaay wrote: post #13

I love Clojure and also Common Lisp (basically, Lisp in general). But I also observed every single corporate Clojure project I had any connection with to fail spectacularly. Typically as a complete unmaintainable mess. Some as unmaintainable mess that is very slow and unreliable. My theory is that this is result of no guardrails on how to structure your application. Clojure to be productive must be used by people who…

That goes against the "Beating the average" lesson [0] but I guess this thing is already 20 years old, I wonder if it's still relevant now

[0] http://www.paulgraham.com/avg.html

Re: Structuring Clojure applications

#22

Post by twawaaay »

mattgreenrocks wrote: post #19
twawaaay wrote: post #13

I love Clojure and also Common Lisp (basically, Lisp in general). But I also observed every single corporate Clojure project I had any connection with to fail spectacularly. Typically as a complete unmaintainable mess. Some as unmaintainable mess that is very slow and unreliable. My theory is that this is result of no guardrails on how to structure your application. Clojure to be productive must be used by people who…

> When it comes to Java you get hordes of devs still producing passable results. The structure is largely imposed by the frameworks (mostly by Spring/Spring Boot) and available help, literature...I would say, if you have a normal-ish project, care about productivity but don't have really stellar and mature developers -- skip Clojure. Regardless of whether I agree, I'm struck by this thinking as a sad commentary on th…

Faced with decision overload, most people get more productive where most of the decisions are made for them by somebody else.

If you had to consciously make every single decision about everything you do you would die. That's where habits and patterns come to reduce the number of decisions you have to make to a reasonable level.

Most software development projects really are the same as a lot of other projects. You get API services that basically shuttle data between database and web interface, you get frontends which basically shuttle data between APIs and UI, etc. There is no need to invent everything for every project you do, it is much more productive to just focus on things that are specific to your project and adopt the rest from either your experience or some ready made guidebook.

It is not necessarily a lack of trust. It is just that when I hear some development manager to start on a journey of reinventing everything for a pretty mundane backend project it immediately suggests to me a lack of common sense or prioritising personal goals over good of the project.

Re: Structuring Clojure applications

#23

Post by haolez »

austinbirch wrote: post #12
haolez wrote: post #6

I'm an experienced developer and I'm getting the feeling that advanced languages are getting less relevant for most applications, since you usually just need a little glue code to glue together mainstream solutions or managed services. I don't need the power of Clojure to connect SQS to Lambda with some extra custom logic. But Clojure does look amazing :)

I can see why Clojure is seen that way ("advanced", "powerful"), but a big piece of it’s design is Rich Hickey’s view that "we can make the same software we're making today with dramatically simpler stuff." Learning Clojure has made working in other languages much harder for me - pretty much all of my Clojure programming is functions plus transforming data structures (mostly maps). So few concepts to keep in your hea…

Why not use ClojureScript and transpile it to TypeScript/JavaScript? That's part of my point. It's usually not worth it.

Re: Structuring Clojure applications

#24

Post by twawaaay »

lairv wrote: post #21
twawaaay wrote: post #13

I love Clojure and also Common Lisp (basically, Lisp in general). But I also observed every single corporate Clojure project I had any connection with to fail spectacularly. Typically as a complete unmaintainable mess. Some as unmaintainable mess that is very slow and unreliable. My theory is that this is result of no guardrails on how to structure your application. Clojure to be productive must be used by people who…

That goes against the "Beating the average" lesson [0] but I guess this thing is already 20 years old, I wonder if it's still relevant now [0] http://www.paulgraham.com/avg.html

There exists no single tool that is best for everything.

Also, not every company can hire best developers (even though most claims so).

Imagine you are project manager for project X which is pretty mundane backend with pretty mundane API and you are given a deadline to develop it.

Will you:

a) try to find absolute best developers on the market and then use absolutely most powerful language (Lisp) to get it done?

b) try to find some developers that are available and use technology that is adequate enough that they can work with not shooting their feet off?

Take into account that you might not be able to hire best developers and even if you do, they might quickly leave not being satisfied with the mundane job you gave them.

Re: Structuring Clojure applications

#25

Post by yogthos »

twawaaay wrote: post #13

I love Clojure and also Common Lisp (basically, Lisp in general). But I also observed every single corporate Clojure project I had any connection with to fail spectacularly. Typically as a complete unmaintainable mess. Some as unmaintainable mess that is very slow and unreliable. My theory is that this is result of no guardrails on how to structure your application. Clojure to be productive must be used by people who…

I've had the opposite experience myself. At my last job we switched from Java to Clojure and found that similar types of projects were much faster to develop and easier to maintain. My team also hired a lot of coop students and junior devs that we trained up.

I find the mistake people often make is to get clever with Clojure. Using macros when regular functions would do is a good example of that. It is absolutely possible to write impenetrable Clojure if you start doing weird things just because you can.

However, I find the beauty of Clojure is precisely in the fact that you can write simple and direct code that solves the problem in a clean way without the need to get clever.

My biggest advice for structuring maintainable Clojure projects is to keep things simple, and to break things up into small components that can be reasoned about independently.

Re: Structuring Clojure applications

#26

Post by jimbokun »

lairv wrote: post #21
twawaaay wrote: post #13

I love Clojure and also Common Lisp (basically, Lisp in general). But I also observed every single corporate Clojure project I had any connection with to fail spectacularly. Typically as a complete unmaintainable mess. Some as unmaintainable mess that is very slow and unreliable. My theory is that this is result of no guardrails on how to structure your application. Clojure to be productive must be used by people who…

That goes against the "Beating the average" lesson [0] but I guess this thing is already 20 years old, I wonder if it's still relevant now [0] http://www.paulgraham.com/avg.html

Doesn’t beating the average require above average developers according to that article?

Re: Structuring Clojure applications

#27

Post by jwhitlark »

twawaaay wrote: post #13

I love Clojure and also Common Lisp (basically, Lisp in general). But I also observed every single corporate Clojure project I had any connection with to fail spectacularly. Typically as a complete unmaintainable mess. Some as unmaintainable mess that is very slow and unreliable. My theory is that this is result of no guardrails on how to structure your application. Clojure to be productive must be used by people who…

Of the two billion-plus exits I've been (peripherally) a part of, the most recent one was Clojure, and the one 10 years ago was Python. I've also seen several Clojure projects and one Scala project fail. With very rare exception, your tools will neither doom you nor ensure success.

It all comes down to execution, in the end.

Re: Structuring Clojure applications

#29

Post by austinbirch »

haolez wrote: post #23
austinbirch wrote: post #12

Earlier quoted context omitted.

I can see why Clojure is seen that way ("advanced", "powerful"), but a big piece of it’s design is Rich Hickey’s view that "we can make the same software we're making today with dramatically simpler stuff." Learning Clojure has made working in other languages much harder for me - pretty much all of my Clojure programming is functions plus transforming data structures (mostly maps). So few concepts to keep in your hea…

Why not use ClojureScript and transpile it to TypeScript/JavaScript? That's part of my point. It's usually not worth it.

Yeah, I can see that. Not disagreeing really.

I found ClojureScript worth it a few years ago. I’ve written two frontend apps (desktop-style interactive single-page applications meant for longer sessions) of reasonable size in ClojureScript. There’s a lot of non-glue code there (in fact mostly non-glue code, given the interactivity and statefulness of the applications).

Very little language and library churn has made maintaining them very straightforward really, and I won’t be rewriting them any time soon. Being able to use DataScript nearly made the choice worth it on it’s own!

The reason I’m mostly using TypeScript these days (for new things & backend code) is that it’s just too helpful for typing the data structures and reducing the "how many things do I have to keep in my head" burden. My TypeScript (like my ClojureScript) is mostly just functions and data structures (avoiding classes, inheritance, etc), and I avoid using any of the more complicated TypeScript features as much as possible.

It’s kind of heretical, but if Clojure had a well-adopted gradual structural type system (essentially what TypeScript has done for JavaScript) then I would find it hard to not pick Clojure for most things.

Re: Structuring Clojure applications

#30

Post by beders »

twawaaay wrote: post #13

I love Clojure and also Common Lisp (basically, Lisp in general). But I also observed every single corporate Clojure project I had any connection with to fail spectacularly. Typically as a complete unmaintainable mess. Some as unmaintainable mess that is very slow and unreliable. My theory is that this is result of no guardrails on how to structure your application. Clojure to be productive must be used by people who…

Maybe it is you :)

But I understand where you are coming from. Understanding an existing clojure code base is exploratory in nature. You'll REPL into it and run the functions you have difficulties with.

This is a very different activity than chasing object references and hunting down method calls.

Post reply on HN