This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (69)
- # babashka (21)
- # beginners (246)
- # calva (49)
- # chlorine-clover (19)
- # circleci (3)
- # clj-kondo (38)
- # clj-new (5)
- # cljsrn (1)
- # clojure (52)
- # clojure-australia (2)
- # clojure-europe (41)
- # clojure-nl (5)
- # clojure-spec (4)
- # clojure-taiwan (2)
- # clojure-uk (28)
- # clojurescript (12)
- # crux (8)
- # cryogen (6)
- # cursive (6)
- # datahike (3)
- # fulcro (2)
- # garden (1)
- # graalvm (3)
- # hoplon (48)
- # jackdaw (6)
- # jobs (3)
- # kaocha (6)
- # malli (3)
- # off-topic (51)
- # rdf (1)
- # reagent (40)
- # reitit (32)
- # remote-jobs (1)
- # reveal (24)
- # shadow-cljs (21)
- # startup-in-a-month (5)
screencast of ztellman's solution to day 17: https://www.youtube.com/watch?v=lU3awBr5C7E
a somewhat cruel reaction to Robert Martin's: https://www.youtube.com/watch?v=umKbM5SwLq4
I’m probably extra harsh on BM because he repeatedly gives terrible advice as if it were handed down from on high.
Uncle Bob makes me think of someone who learny programming 30 years ago, and still programs like its 30 years ago
im not an expert, but as a clojure beginner, i really liked lambda islands daily aoc videos
UB has a lot of blog posts like these: https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html should they be taken with a grain of salt? I don't want to quote him in my paper, when the "scene" thinks he is not always on the best of paths
Still makes me happy that he likes it, because it bodes well that if someone could convince Uncle Bob that it’s nice.. then it’s possible to convince just about anyone 😅. Also since he does garner attention it did give some attention to Clojure in general which I always appreciate
Uncle Bob has a lot of firm opinions based on a mix between experience and the dogmatic belief that programmers are engineers that should be held to similar rigorous standards, which makes him prefer ideas like Test Driven Development. His vocality and personality make him seem a little confrontational/adversarial to those who prefer to keep discussion open, and so that’s what I believe causes the main pushback against him. Personally I’d probably use him if I could use him to demonstrate that a diverse group of people (including him) agree on a topic. Also I’m ending this rant here because it’s a bit off-topic for the channel.
That sounds like something he would say about anyone else. I’m personally not confident enough to assert any advice is good or bad (or terrible in this case).
I can say I’m not very convinced by his ideas to be honest, and that I don’t believe they’re the great advice for most people and cases. But that depends more on context than what he’s saying outright.
It has little to do with “his vocality and personality,” (which, as you say, are grating).
C# ? I would have thought Uncle Bob was known for Java / C++ more than C#. I must've missed his C# period
I’ve seen him sic his followers on my friends because he didn’t like a decision that he knew absolutely nothing about.
to be fair, it's easy to spend an indefinite length of time in an AoC challenge if you miss the key insight. that says little about the soundness (or otherwise) of his methodology
I just had a blind spot on the insight on a few of them and ended up going down all sort of wrong rabbit holes
Yeah, my initial statement had nothing to do w/ the problem. I didn’t do it. I just glanced at Zach’s solution.
personally I find it nuts to use TDD for AoC challenges unless you want to get specific practice on that or show it off, but I doubt that accounts for the time overhead
I haven't seen this screencast by Uncle Bob, but I bet it's failing to realize that an infinite space calls for a sparse representation
I can image that for some days I will take maybe multiple days because im a beginnner in clojure
I've seen people in this channel struggle with that, then come out with brilliant solutions in other challenges
@roelof, 'im the same. BUt its good to solve the problem and then come here / youtube to see other good clojure developers solution. You can learn a lot of useful functions that I find I often end up implementing myself because I didn't know they existed
in some other challenge everyone seemed to get immediately that a mutable linked list was called for. I took forever to come up with a solution that run in 30+ minutes by just failing to think of that
FWIW, I agree that sparse storage is best, but immutable state is a must. I used maps since vectors puke on negative idxs. Also generate move increments for any sized dim. with math.combinatorics/selections is a real time saver. Finally, the key for speed is to only use neighbours to scan for next state, use ‘iterate to produce states et voilà. I spent time to write a rendering module to go through each cycle against the sample diagrams. It took 2 days but was a lot of fun. For me by far the hardest was fay 13 so far, currently on day 18. Cheers!
yes, I don't know how one would solve 13 without knowing about the Chinese Remainder theorem
Uncle Bob has an interesting video on day 13 with a simple and fast solution, which positions the cursor on the current bus Id, then skipping (next id number of items) ’til the next one lines up and so on.
@roelof in the context of this challenge, sparse representation means that you only represent the cells that are active, not the whole space (which is impossible, since it's infinite) nor a "box" around the active cells
I'm study CS at uni and we were asked to use Test Driven Development wherever possible because it is safe and secure and the code writes itself when you have the tests. Why is that bad in clojure? I always feel bad becuase I skip making tests
The problem isn’t that TDD is bad in clojure. The problem is that it doesn’t do those things. It doesn’t make anything safe, secure, and the code doesn’t “write itself.”
There are upsides to TDD Proper (i.e. test first). There are upsides to having a test suite.
But things like, “safety” or “security” are the result of a lot of decisions, and the test suite is way down the list of important things.
It’s not necessarily bad, it’s a strategy that has it’s tradeoffs. In the case of advent of code.. maintainability is not something that is strongly valued and which is what TDD is supposed to give you in return for writing more code (for testing).
Question's probably good fit for #testing 🙂 (Can one cross-post in slack? I don't see it)
In clojure in general tests and specs are used quite a bit, but REPL driven development or Data Driven Development are more common, for various possible reasons.
@roelof, without having read all messages since you asked about lamdaisland (aka @plexus) , for all I can tell, that is showing super-duper idiomatic Clojure coding, and coding habits you can take inspiration from with great benefits. The only thing I disagree with is that he is not using Calva. 😃
thanks, I saw also a teacher whch making and explained this but he does it totally a other way then plexus
There is no One True Way, so might be perfectly valid both of them. But when I see Arne code I just want to be that good, all the time. I’m virtually drooling.
> I'm study CS at uni and we were asked to use Test Driven Development wherever possible because it is safe and secure and the code writes itself when you have the tests. Why is that bad in clojure? I always feel bad becuase I skip making tests The test-first TDD approach does a lot of stuff, and one of them is creating short feedback loops between writing small pieces of code and running it to see if it works the way you think it does, which you don't otherwise have in a lot of languages. Clojure already has a built in, ubiquitous mechanism for that same thing: the REPL. So that benefit falls off a bit in Clojure. Not doing TDD doesn't imply you shouldn't have tests at all though, there are lots of other benefits of having a test suite. More generally where I see TDD fall down in practice is when it's used to try to 'discover' an algorithm. Bob's AoC videos I think have lots of good examples of this. Another is the infamous Ron Jeffries attempt to write a Sudoku solver. In cases like that it's much more effective just to think about the problem for a while, maybe with a pen and paper. TDD is too rigid/mechanistic.