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

31–40 of 67 posts

Re: Structuring Clojure applications

#31

Post by slifin »

bcrosby95 wrote: post #17
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…

In general I find Clojure's "power" to be its simplicity. As you mention, if you're building websites/services, I think the biggest "problem" with Clojure is the community hasn't rallied behind any particular framework. I'm reminded a bit of companies. The point of a large, successful company is to slow its employees down enough so they don't kill the goose that laid the golden egg. The point of a startup is to find…

I can't remember where but Rich Hickey at one point said himself web development isn't a solved problem

If you agree web development isn't a solved problem, do you want to couple your entire language to a massive framework that is committed to solving an un-solved problem in the general sense using technique X that presumably will need to be replaced Y years down the line? Or not work in situation Z

Personally I don't want that for Clojure, instead I see lots of different approaches in Clojure (and some outside) that could be the next big thing:

- https://www.hyperfiddle.net/

- https://github.com/whamtet/ctmx

- https://github.com/leonoel/missionary

- Unison

Ultimately I want to go long on my programming language and short on "the one true framework" until we have a one size fits all approach for solving the general problem of web development, until then give me low coupling libraries that I can mix and match

And that's exactly what Clojure is doing right now, maybe in the end it will be something like chatgpt just mix and matching the approaches for you but for now I'm personally not looking for a framework to be the only way to use Clojure

Re: Structuring Clojure applications

#32

Post by jb1991 »

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 worked on a large Clojure app for a small company for a few years and it eventually died for similar reasons as you describe. Then, I was hired to work for a startup also developing a large Clojure app, and I must say, it was a very challenging onboarding. The main problem is that "anything goes" in a language like Clojure, which can be great or devastating. My personal take is that the lack of types makes it very hard to understand a large codebase you are exposed to for the first time, unless, as you say, it is structured in a way that was very clear and strict from the outset. Trying to trace the ideas through a large Clojure codebase can become extremely difficult when all they are is a bunch of functions with untyped parameters. Liberal use of spec can help to some degree (though that is also a challenge to enforce, much like optional typing in some languages) but it doesn't change this fundamental paradigm of the language, and I've seen more businesses sunset Clojure than move to it. It's a shame, really, since the language is vastly more flexible and powerful than most, but it goes to show that there are some things that have, in the wild, outsized influence on productivity for the 80%.

Re: Structuring Clojure applications

#33

Post by fulafel »

dig1 wrote: post #11

I am not fond of the multimethods because they can easily tangle the code and give you a false sense of scalability. For example, in a blog post, "handle-action" is nicely decoupled with 3 different actions, but let's imagine how that will look after someone adds 20 new actions. Good luck debugging that. Also, I saw numerous cases where people will copy/paste multimethod arguments without knowing what they are used f…

Multimethods also have some problems vs reloading that need working around.

Re: Structuring Clojure applications

#34

Post by riwsky »

slifin wrote: post #31
bcrosby95 wrote: post #17

Earlier quoted context omitted.

In general I find Clojure's "power" to be its simplicity. As you mention, if you're building websites/services, I think the biggest "problem" with Clojure is the community hasn't rallied behind any particular framework. I'm reminded a bit of companies. The point of a large, successful company is to slow its employees down enough so they don't kill the goose that laid the golden egg. The point of a startup is to find…

I can't remember where but Rich Hickey at one point said himself web development isn't a solved problem If you agree web development isn't a solved problem, do you want to couple your entire language to a massive framework that is committed to solving an un-solved problem in the general sense using technique X that presumably will need to be replaced Y years down the line? Or not work in situation Z Personally I don'…

Frameworks being imperfect doesn’t mean devs can do better without them. The libraries a-la-carte approach makes it very easy to mess up cross-cutting concerns like security, a fact the clojure community has known for a while now: https://m.youtube.com/watch?v=CBL59w7fXw4

Re: Structuring Clojure applications

#35

Post by turtledragonfly »

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…

> sad commentary on the state of our industry

Honestly, I find myself structuring my own code to be dummy-proof and paint-by-numbers, even when I am the only user of it (:

I don't see it as a bad thing, necessarily; sometimes you want to "bake in" structure and conventions in various places so you can use your creative energy elsewhere.

Though I do take your point that this is not necessarily (or at all) communicated to junior devs, who are sometimes plopped into a little artificial coding cage and discouraged from reaching outside of it.

Depends on your perspective and intentions, I suppose.

Re: Structuring Clojure applications

#36

Post by yogthos »

beders wrote: post #28

This approach is not simple. It complects a business process state with multi-methods. Don't do it. Model state where it belongs: in a database.

This approach is perfectly compatible with modelling state in the database. The problem this addresses is the data flow, which is a completely separate problem from managing the state itself.

Re: Structuring Clojure applications

#37

Post by mullr »

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 had the opposite experience. I worked for a company with a bunch of Clojure projects, written by people of varying levels of experience. I had to do some cross-cutting changes and feared the worst. But when I actually got down to it, everything more or less made sense.

Why did this happen?

- We had small common framework that everybody used, at the very highest level (think application lifecycle management). That imposed some amount of consistency at the most basic run-the-program stage.

- The devs communicated openly, a lot, so there was some general consensus on what to do, and what not to do.

- The team at large was very suspicious of introducing new macros. You could do it, but you'd better have a really good reason.

- When I went to make the changes, I didn't have to worry about spooky-action-at-a-distance kinds of consequences anywhere NEAR as much as I do in other languages. Being strict with your state management, as Clojure strongly encourages, REALLY pays off here.

The actual problems I had were entirely related to the overall build system, the fractured nature of the source control, and figuring out who was responsible for what code once we were 3 reorgs deep. The code itself was remarkably resilient to all this nonsense.

Re: Structuring Clojure applications

#38

Post by yogthos »

jimbokun wrote: post #26
lairv wrote: post #21

Earlier quoted context omitted.

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?

My experience is that you need a few developers who know how to use the technology effectively, and who are willing to mentor junior developers. Doing things like pair programming and code reviews goes a long way here.

Re: Structuring Clojure applications

#39

Post by agumonkey »

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…

Interesting take. How much of these architectural problems came from

    - process / workflow (everybody goes on hacking a topic for weeks and then integrate ?)
    - team size (I can foresee how clojure would make large team a problem, but small teams happier)

Re: Structuring Clojure applications

#40

Post by cultofmetatron »

bcrosby95 wrote: post #17
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…

In general I find Clojure's "power" to be its simplicity. As you mention, if you're building websites/services, I think the biggest "problem" with Clojure is the community hasn't rallied behind any particular framework. I'm reminded a bit of companies. The point of a large, successful company is to slow its employees down enough so they don't kill the goose that laid the golden egg. The point of a startup is to find…

I built my startup on elixir.

Once you get past the syntax, a lot of the day to day thinking about how to model your solution in the context of the system is similar. to the point that I'd say elixir is Clojure with a ruby like syntax. elixir has let bindings but they are implicit and blend into the language. you don't really think about them. At the same time, you have all teh standard fare of a functional enough language without all the type ceremony.

Id say its more convenient to work with elixir day to day. Less tracking of parenthesis and the code naturally comes out looking more uniform. There is the price that macros are harder to write in elixir. That is not to say its difficult but lisps in general make writing a macro so damn easy that anything else feels difficult in comparison. I think its a good compromise. Its just difficult enough to make avoid creating macros until you REALLY need them.

Post reply on HN