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

41–50 of 67 posts

Re: Structuring Clojure applications

#41

Post by cultofmetatron »

jwhitlark wrote: post #27
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.

> 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

Re: Structuring Clojure applications

#42

Post by rmuslimov »

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 notify-sender should have credentials to connect to the services. How they are delivered? as input to the :handle-action method or as as component/mount. Interesting to learn about your approach here.

Thanks for sharing!

Re: Structuring Clojure applications

#43

Post by mtrimpe »

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…

The same applies to most Scala projects from the early days. It attracted many developers who just wanted to have a go at writing their own custom half-baked versions of their favorite parts of category theory for a simple line-of-business CRUD app.

I think both eventually found their niche and now have plenty of developers that stuck around write appropriate code in it. But when they were shiny and new they indeed both created their fair share of failures.

Re: Structuring Clojure applications

#44

Post by silver-arrow »

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 initially had the same thoughts as you when I got on my first Clojure project. Previously, I used strongly typed languages with "approved" frameworks. Developed in Java for over 20 years before getting put on a Clojure project.

It because apparent over time that the lack of types and the other features provided by Clojure resulted in much smaller and simpler codebases compared to those previous languages and frameworks that I toiled in for so many years.

It has really highlighted to me the value of simplicity for better productivity and maintainability. I wouldn't even want a framework to build web apps using something like HTMX for example. Clojure handles HTMX in almost magical ways with a simple library or two such as hiccup.

Recently, I was doing some work on a Java / Spring project and was dismayed with the proliferation of classes and packages; really the complexity of it all. And remember, I am solid with Java experience, so it is a result of those types of languages and architectures IMO.

Re: Structuring Clojure applications

#45

Post by twawaaay »

jb1991 wrote: post #32
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…

Lack of types -- yeah, I forgot to mention it.

Another is -- lack of good IDE support (which is connected to lack of strong typing). In something like Java you can always understand what is the thing under your cursor.

But an experienced developer knows how to deal with these problems. Lack of strong types means you have to be building clean, well specified interfaces. Lack of strong typing in language does not mean you don't have types in your program -- it just means that it is now on you to make sure it is easy to figure out what is the exact specification of piece of data at any point in the program.

I also found that spec rarely helps. One of the major points of something like Clojure is to be able to create general purpose functions that can do useful operations on very wide range of data and then use those functions to compose your program. Spec really hinders your possibilities here.

> 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%.

It is the curse of Lisp. It is the most powerful language that can exist and yet it will never be mainstream because it requires a whole other level of development mastery to really get the productivity benefits.

I personally use Clojure for my rapid prototyping which is to say -- "as long as I am sure nobody else will ever need to work on it with me".

I did a very efficient algorithmic trading framework proof of concept in Common Lisp and it was a joy to work with. But then when it came to actually productionising it I was forced to rewrite it in Java at the cost to performance and heaps of boilerplate code.

Re: Structuring Clojure applications

#46

Post by twawaaay »

silver-arrow wrote: post #44
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 initially had the same thoughts as you when I got on my first Clojure project. Previously, I used strongly typed languages with "approved" frameworks. Developed in Java for over 20 years before getting put on a Clojure project. It because apparent over time that the lack of types and the other features provided by Clojure resulted in much smaller and simpler codebases compared to those previous languages and framew…

> It because apparent over time that the lack of types and the other features provided by Clojure resulted in much smaller and simpler codebases compared to those previous languages and frameworks

Totally agree. My very initial motivation that caused me to get interested in Clojure was my study of various API clients generated I think by Swagger Editor? All clients were littered with generated boilerplate -- except for the Clojure one which looked clean and exactly as you would imagine some intelligent programmer writing it. As I already had experience with Common Lisp I immediately understood what is happening here.

> Recently, I was doing some work on a Java / Spring project and was dismayed with the proliferation of classes and packages; really the complexity of it all. And remember, I am solid with Java experience, so it is a result of those types of languages and architectures IMO.

I also have over 20 years of experience with Java and I also share your experience.

Recently I have started mixing OOP with functional and FRP. For example, most of my code is now FRP (ReactiveX/Reactor) and for some strange reason Java is superbly suited to it. It is not a panaceum but I found that I can frequently write what would normally be large features even in minutes.

Re: Structuring Clojure applications

#47

Post by jeremyjh »

cultofmetatron wrote: post #40
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 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 la…

Elixir doesn't have the same problem of everyone building their own framework each time they build an application, though. Almost every web project uses Phoenix and inherits a whole series of tools and practices that less experienced devs would never think of until it is too late. Every database project uses Ecto with its well-typed schemas and changeset validations etc. Clojure has equivalent things but you have to not only find them, but first find the need for them.

Re: Structuring Clojure applications

#48

Post by joshlemer »

austinbirch wrote: post #29
haolez wrote: post #23

Earlier quoted context omitted.

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…

When I was looking into ClojureScript I was kind of concerned at the complexity of writing applications in ReFrame which seems to be what most of the community is using. I've developed apps in this kind of event-emitting/event handler style before in JavaScript and found it quickly got quite out of hand. For my next app I will want to go with something like React-Query that in a sort of declarative way handles all your data fetching for you, and lets you decouple your components from the getting ahold of the data they depend on. I also searched far and wide for some kind of framework/library that supports SSR+CSR like Next.js but I don't think there's anything ready yet except maybe https://github.com/pitch-io/uix.

Re: Structuring Clojure applications

#50

Post by thelazydogsback »

jwhitlark wrote: post #27
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.

> Of the two billion-plus exits That's a lot of exits :)
Post reply on HN