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

51–60 of 67 posts

Re: Structuring Clojure applications

#51

Post by thelazydogsback »

cultofmetatron wrote: post #41
jwhitlark wrote: post #27

Earlier quoted context omitted.

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.

> your tools will neither doom you nor ensure success. This holds true as long as you're not buidling your startup on something truly outlandish like brainfuck or piet

> Of the two billion-plus exits

That's a lot of exits :)

Re: Structuring Clojure applications

#52

Post by jimbokun »

yogthos wrote: post #38
jimbokun wrote: post #26

Earlier quoted context omitted.

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.

Seems like that would be a good approach for a Clojure shop.

Re: Structuring Clojure applications

#53

Post by yoyohello13 »

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 love lisp in general as well, but I think lisps will always tend toward an unmaintainable mess unless the people working with it are very disciplined. With the REPL based workflow and macros, lisp encourages a very 'hack on it until it works' development workflow. Which feels awesome but doesn't lend itself to building maintainable solutions.

Re: Structuring Clojure applications

#55

Post by yogthos »

jimbokun wrote: post #52
yogthos wrote: post #38

Earlier quoted context omitted.

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.

Seems like that would be a good approach for a Clojure shop.

Honestly, code reviews and pairing are a good idea in any shop. These things significantly improve code quality and ensures that more people know what the code is doing.

Re: Structuring Clojure applications

#56

Post by [deleted] »

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'…

[deleted]

Re: Structuring Clojure applications

#57

Post by [deleted] »

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'…

[deleted]

Re: Structuring Clojure applications

#58

Post by samsquire »

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 worked on 3 Clojure projects professionally.

For background I'm a devops and software engineer and I'm comfortable with Javascript, Java, Python and C.

I am implementing my own multithreaded programming language and I have a switch based interpreter and a compiler that codegens for it.

I think other people's Clojure code is unreadable.

Clojure code resembles the author's mental model of the problem being solved. Which is often very different to how I model the problem to be solved.

It's not the complexity of Clojure codebases that I have trouble with, it's the syntax and the approaches to the problems being solved.

I would use LISP for AST generation and codegen but not for direct programming.

Re: Structuring Clojure applications

#59

Post by yogthos »

rmuslimov wrote: post #42

This is very informative and beginner friendly write up which came be used as strategy for organizing apps in Clojure. I personally have something very similar which Redis storage used as persistent storage for storing jobs and tasks within workflow are potentially executed on diff hosts. I would recommend to extending this topic and share your thoughts about component/mount like abstraction to the code. For example…

Glad to hear this was helpful, and regarding managing stuff like credentials, I like the pattern of initializing the client up front using component, mount. Then passing the client in the resource map.

The advantage over simply passing credentials is that the initializer for the client can validate itself when it loads. If you just pass the credentials and assemble the client when you try to send the message then if some variables weren't set correctly you only find out when you try to use the client at as opposed to when application starts.

Post reply on HN