Clojurians Log v2
off-topic
I think that as long as you can actually update all the data in one transaction, you can do that. even having two atoms, in a multithreaded context you could run into inconsistencies
the idea is that the atom would generally hold incidental, ephermeral, and generally less important state
Is it schadenfreude to giggle when people run into massive porblams with scala? https://mungingdata.com/scala/maintenance-nightmare-upgrade/
(from hacker news front page)
Scala seems like a fun language to play with, but I can very easily imagine the minefields that would spontaneously generate once you started mixing different dev teams and coding styles with Scala's free-for-all mix of functional and imperative programming.
It'd be a great language for an introductory comp sci course, IMO
You have yet to see the mess determined individuals can produce with Clojure 🙂
@sova That echoes our experience with Scala at work a decade ago. We started with Scala 2.7 I think and the migration to 2.8 was an absolute nightmare: almost every single milestone (prerelease) build broke backward compatibility and/or binary compatibility so you had to wait until your entire stack was available, compiled for a new milestone build, and then update every single library, tool, and application code all at the same time. We only had a small Scala codebase and it was dreadful. And 2.9 was “better” but it was still bad and we just gave up at that point — we switched to Clojure.
And with Clojure we’ve been able to upgrade libraries and the core pretty much as and when we wanted and had almost zero breaking changes in a decade. We’ve run Alpha builds of Clojure in production ever since 2011 and almost never had an issue (by a stroke of luck, our release cycle overlapped with Clojure 1.5.0 so we just happened to go from the last RC straight to 1.5.1 so we missed the production-critical bug in 1.5.0).
Some of the Clojure libs we depend on haven’t been updated for years and still work just fine, despite being written and tested against much older versions of Clojure, and on the flip side of that we already have Clojure 1.11.0-alpha1 in dev and QA.
No I don’t 🙂
OTOH working in Clojure has repeatedly let me go back to code I wrote 6+ months ago, and even though I don’t recognize a single paren of it, I can still figure out what it’s trying to do. I can’t say the same for Java, PHP, Perl, VB, C#, C++, etc.
I'm pretty sure that any programming language lets you create a mess, unless it is a toy language that is so restrictive it doesn't let you do useful things.
but I'm also pretty sure that some languages/ecosystems positively encourage varying styles of implementation that make it more difficult to reuse code across those styles, e.g. C++ seems to have so many bells and whistles, that everyone using it in production picks a subset they allow in their code base, but that subset can vary across projects.
It's one thing I really really like about Clojure. I admire it's slow and steady pace (although, I do sometimes wish for a bit more...). I dabbled in Scala many moons ago. I still have cold sweats.
@manutter51 you sir get a gold star. i 100% agree that i can return to clojure code after having offloaded it from brain rather entirely and still make sense of it with relative swiftness and ease. other languages, unless i went HAM with the commenting, it's gonna be a bloodbath. i tell younger coders to "stay kind to your future self" and "be kind to your future self" and if they are not using clojure to comment heavily 😉
@andy.fingerhut have you seen the beautiful list of banned c++ functions at github (for code used internally at the company) ?
(in making Github itself, if that was confusing / not clear)
😄
Coming from the Python ecosystem, I still get a bit nervous every time I see a library was last updated 5 years or more ago. Can't say that it has ever turned out to be an issue in Clojure land, though. It's truly amazing how well Clojure code ages.
Yo that's right! We were wondering what to do to mark "finished" projects on github
If a Python lib hasn't been updated in something like 2 years, it's probably broken
right? in many other languages, unmaintained means it needs some love... in clojureland it's actually likely that it's done xD
more than likely
Gotta find that image again. Of Clojure codebase graphic over time
Ah yes, A History of Clojure
If you had to guess from 20 feet away which image was the clojure codebase commits over time... which would you choose?
oof those graphs are so potent
Our Scala experience was 2009-2011 and you can see the churn there. Looks like 2012 was even worse 👀
By comparison, we started switching over to Clojure early in 2011 and the only “large” shift on that graph happened in 2010 (1.2? maybe the start of the 1.3 cycle?).
Must have been 1.2. That came out in August 2010 and introduced protocols as the flagship feature…
"US Constitution vs. Charter of any communist nation" : P
@sova I had not, but looking at it, it is quite short and mostly seems to include things within the standard C library that are known to be common sources of buffer overrun bugs in C programs, too.
I'm pretty sure when I last worked at Cisco on a big C code base, they had lint tools that flagged occurrences of most or all of that short list.
That has little implication on the differences between the number of bells and whistles that the C and C++ languages have relative to each other.
You can easily return to Clojure you wrote. I have had the misfortune of inheriting a relatively old code base which was written under pressure by people who were sometimes new to the language. Two years and I still find surprises and horrors
The single-dev or small team story for Clojure is excellent, a larger context requires an iron will and a certain degree of tyranny if I'm being honest
Maybe tyranny is too harsh a term, but you need good standards and keep to them
Is there a language where that’s not the case, though? Sincere question — the largest team I’ve ever worked in had three developers, I think.
I’ve seen reports indicating that larger teams is where Clojure’s lack of static types really starts hurting. I can imagine how that might be, but I’m also curious about whether there’s a way to solve that without using another language.
I guess the rigidity of static type systems and interfaces, while a big bummer, allows you to at least create clear boundaries between things which can't be broken. With Clojure, and dynamic languages in general you're freer to make a mess. Also Clojure is very unopinionated when it comes to code and project structure
I think a way to ameliorate the static typing issue may be a CI check that every function is spec-ed, try to finagle your way around that one
Nothing replaces communication between developers on a common project. Static types, while they can provide some level of protection for some kinds of mistakes, can also become a form of "developer molasses" between teams, and/or finding workarounds to jam new information into existing spots in funky ways that aren't what you would do if you were writing the code from scratch, e.g. pass two 16-bit integers in a 32-bit integer.
> I think a way to ameliorate the static typing issue may be a CI check that every function is spec-ed, try to finagle your way around that one For me a good place to draw the line is APIs. APIs should be spec-ed, implementations need not This way one gets 80% of the benefit with 20% of the effort