Live data from Hacker News

Clojure: The Documentary, official trailer [video]

youtube.com

61–70 of 94 posts

Re: Clojure: The Documentary, official trailer [video]

#61

Earlier quoted context omitted.

I think it actually is a pretty big problem. "Once you absorb the ideas of Clojure" takes months or years to fully get. Composing libraries yourself, like your comment says, requires that they are "well-picked". Stitching together separate libraries is really time consuming and a distraction from the project you're trying to build. It also results in pointless thrashing within a team as everyone has become personally…

Have you seen this? https://www.infoq.com/presentations/Simple-Made-Easy/

Yep

Re: Clojure: The Documentary, official trailer [video]

#63

Earlier quoted context omitted.

Which in reality isn't a problem, once you absorb the ideas of Clojure and try to apply them when using Clojure. Composition of well picked libraries beat batteries-included frameworks for most use cases, both short term and long term, at least in 99% of the cases I'm writing Clojure/Script code.

I think it actually is a pretty big problem. "Once you absorb the ideas of Clojure" takes months or years to fully get. Composing libraries yourself, like your comment says, requires that they are "well-picked". Stitching together separate libraries is really time consuming and a distraction from the project you're trying to build. It also results in pointless thrashing within a team as everyone has become personally…

> By the time a beginner learning Clojure has researched and put together their web stack and got it all hooked up and is ready to start, the Django developer already shipped their project last quarter, iterated on it a few times, and is on to the next thing.

Yes, but this is intentional. Django developers are optimizing for "easy" which makes it fast to spin up project after project, Clojure developers are optimizing for "simple" which means way longer time to get the project of the ground, to nail all the design before things start to actually be put together, which makes it easier and faster to iterate on the same codebase after years of working on.

Ask the Django developer how easy it is for them to add features after a project they've done that approach with for N years, then compare it to a Clojure codebase, and you'll notice the difference.

Sure, I guess this is "downplaying" and "denying", personally I see people who disagree with me as people who disagree with me, that's fine, I thought that was why we were sharing our opinions in this forum in the first place. But anyways, if you're very deep into "frameworks are clearly superior in every case", that we disagree probably matters less. Best wishes regardless!

Re: Clojure: The Documentary, official trailer [video]

#64

Earlier quoted context omitted.

> Clojure style discourages building DSLs does it really? https://github.com/simongray/clojure-dsl-resources

I think you're talking past each other. "DSLs" can both mean "Using the language's variant of 'arrays' to build a DSL via specific shapes" like hiccup in Clojure does, and also "A mini-language inside of a program for a specific use case" like Cucumber is its own language for acceptance testing, but it's "built in in Ruby" in reality. Clojure favors the "DSLs made out of shapes" rather than "DSLs that don't look/work…

no, not really. when people talk about DSLs in context of lisps, they usually still mean staying in the domain of s-expressions.

Re: Clojure: The Documentary, official trailer [video]

#65

Earlier quoted context omitted.

I think you're talking past each other. "DSLs" can both mean "Using the language's variant of 'arrays' to build a DSL via specific shapes" like hiccup in Clojure does, and also "A mini-language inside of a program for a specific use case" like Cucumber is its own language for acceptance testing, but it's "built in in Ruby" in reality. Clojure favors the "DSLs made out of shapes" rather than "DSLs that don't look/work…

no, not really. when people talk about DSLs in context of lisps, they usually still mean staying in the domain of s-expressions.

Yes, maybe that's the sort of DSL you're talking about, the other person mentioned "Clojure style discourages building DSLs" which I'm fairly sure to be about the other DSL and is also true, hence the whole "you're talking/reading past each other".

Re: Clojure: The Documentary, official trailer [video]

#66

Earlier quoted context omitted.

clojure itself is a joy to use, on the web or outside of it BUT it doesn't have the equivalent of rails, mostly because lispers are an opinionated bunch and can't come together to agree on how web development should be done the frameworks that do exist are more of a collections of libraries with some plumbing to connect the dots

Yes, huge selling point in favor of Clojure!

it really isn't, unless your goal is to scare away the casuals.

Re: Clojure: The Documentary, official trailer [video]

#67
post #13

Earlier quoted context omitted.

Rich's talks have been the apex of my programming career. I didn't like sitting in front of a computer to the extent needed to make a living from it, so I moved on to another industry. And maybe I wasn't smart enough to become competent in Clojure. But I'm thankful for the eureka moments that Rich offered me. He's such a beautiful mind.

Would love to know what industry you ended up in. Daydreaming about working with my hands out and about one day lol.

I'm pivoting to mental health. But the trades are quite appealing too!

Re: Clojure: The Documentary, official trailer [video]

#68

Earlier quoted context omitted.

There are still Clojure remote positions. Thankfully, I have used Clojure professionally long enough that my core ability shouldn't atrophy too much now that we have moved away from it at my current position. I am looking forward to Jank actually.

Why did you move from it if I may ask?

There were multiple reasons at our company -- my particular team, all skilled Clojurists, decided to default to python last year for a variety of reasons including both AI code generation suitability and AI model utilization in our code bases; the latter is of high relevance for our particular work. While I find Clojure to be among the best languages for interacting with LLMs via API, it is awkward for interacting with local models directly. Of all on the team, I was probably most open to a polyglot approach.

Re: Clojure: The Documentary, official trailer [video]

#69

Earlier quoted context omitted.

I think it actually is a pretty big problem. "Once you absorb the ideas of Clojure" takes months or years to fully get. Composing libraries yourself, like your comment says, requires that they are "well-picked". Stitching together separate libraries is really time consuming and a distraction from the project you're trying to build. It also results in pointless thrashing within a team as everyone has become personally…

> By the time a beginner learning Clojure has researched and put together their web stack and got it all hooked up and is ready to start, the Django developer already shipped their project last quarter, iterated on it a few times, and is on to the next thing. Yes, but this is intentional. Django developers are optimizing for "easy" which makes it fast to spin up project after project, Clojure developers are optimizin…

Rich's Simple Made Easy talk is really interesting and insightful and I still love it but I think now the distinction is brought out too often almost reflexively, and used as a crutch. Yes "simple" and "easy" are not the same thing, but nor are they opposites. Just because something is "not easy" doesn't mean it's "simple".

I think there are lots of well maintained Django projects. In fact, if I do a search on AI and on google for what one web stack probably has the lowest overall total cost of ownership including maintenance years down the line, Django usually is what comes up, without even specifically searching for/mentioning it.

> if you're very deep into "frameworks are clearly superior in every case"

This is a mischaracterization of what I have said, and is more like the extreme position that Clojure devs seem to take. The original commenter said that Clojure is wonderful, but it's too bad that [for the people who want it,] there isn't the option of a well maintained, all-in-one, batteries included framework. You deny that this is a problem, saying that actually a well-chosen set of libraries are superior (I guess in every case, because if not then it actually would be a problem sometimes).

Re: Clojure: The Documentary, official trailer [video]

#70
post #49

Earlier quoted context omitted.

https://janet-lang.org is already Clojure without the JVM

I feel like calling Janet "A Clojure" is doing both a disservice. It's more like a "Clojure-like but smaller on purpose" programming language, and it's also (self-described) for "exploratory programming, scripting, and fun side projects" rather than Clojure's intended target audience. Nothing wrong with that, having different target audiences makes sense and is probably preferable, but Janet is more than just "Clojur…

Yes, clojure-like is good
Post reply on HN