Fork me on GitHub
#adventofcode
<
2021-01-18
>
euccastro04:01:35

screencast of ztellman's solution to day 17: https://www.youtube.com/watch?v=lU3awBr5C7E

euccastro04:01:46

a somewhat cruel reaction to Robert Martin's: https://www.youtube.com/watch?v=umKbM5SwLq4

potetm05:01:00

wtf how did it possibly take 2 hrs & 160 lines of code?

potetm05:01:33

idk, I haven’t done it, but glancing at Zach’s solution, the difference is stark

potetm05:01:25

I’m probably extra harsh on BM because he repeatedly gives terrible advice as if it were handed down from on high.

3
👍 6
potetm05:01:32

(And, remarkably, people believe him.)

Christian09:01:21

Took me a while to get from Robert to Bob as in RM to BM.

6
Stuart12:01:32

Uncle Bob makes me think of someone who learny programming 30 years ago, and still programs like its 30 years ago

Stuart12:01:43

i dont understand his popularity

roelof12:01:46

What do your experts think of the videos of lamda island?

Stuart12:01:18

im not an expert, but as a clojure beginner, i really liked lambda islands daily aoc videos

Stuart12:01:52

i learnt some neat things from them

roelof12:01:00

I also but I do not know if I learned then good idiomatic clojure code

roelof12:01:10

but I l like his explanations

Christian12:01:18

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

Mno13:01:05

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

Mno13:01:42

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.

potetm14:01:31

He gives terrible advice.

Mno16:01:49

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

Mno16:01:24

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.

potetm14:01:43

And his adherents pretend like it’s The Good Advice.

potetm14:01:25

It has little to do with “his vocality and personality,” (which, as you say, are grating).

roelof14:01:25

it that the same uncle Bob from c# ?

potetm14:01:42

pretty sure there’s only one 🙂

Stuart14:01:46

C# ? I would have thought Uncle Bob was known for Java / C++ more than C#. I must've missed his C# period

potetm14:01:09

Not to mention the fact that he also happens to be a total jerk.

roelof14:01:32

no idea. nver met him

potetm14:01:50

I’ve seen him sic his followers on my friends because he didn’t like a decision that he knew absolutely nothing about.

Mno16:01:12

That’s unfortunate, I see why you dislike the guy then.

potetm14:01:34

All because of his personal crusade against “SJWs.”

roelof14:01:02

and what are sjws ??

Stuart14:01:16

"Social Justice Warriors"

Stuart14:01:43

I think he got cancelled from a conference after a controversal twitter post.

euccastro14:01:52

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

9
Stuart14:01:04

yeah, some of the challenges this year took me a good few hours!

Stuart14:01:36

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

potetm14:01:02

Yeah, my initial statement had nothing to do w/ the problem. I didn’t do it. I just glanced at Zach’s solution.

euccastro14:01:04

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

potetm14:01:41

So it was more, “Dude A took 20min. wtf took 2 hrs?”

potetm14:01:07

Didn’t mean to say everybody should take 20min.

euccastro14:01:41

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

euccastro14:01:53

something that Zach jumped to immediately

roelof15:01:11

I can image that for some days I will take maybe multiple days because im a beginnner in clojure

euccastro15:01:54

I've seen people in this channel struggle with that, then come out with brilliant solutions in other challenges

Stuart15:01:15

@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

roelof15:01:26

I hear now things I never heard before like sparse represantation

euccastro15:01:28

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

kingcode04:01:31

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!

euccastro13:01:23

yes, I don't know how one would solve 13 without knowing about the Chinese Remainder theorem

kingcode21:01:52

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.

thanks2 3
euccastro00:02:17

I'll check it out, thanks!

euccastro15:01:42

@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

roelof15:01:20

oke thanks

Christian16:01:12

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

potetm17:01:16

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

potetm17:01:11

There are upsides to TDD Proper (i.e. test first). There are upsides to having a test suite.

potetm17:01:49

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.

Mno16:01:12

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

Max Deineko16:01:35

Question's probably good fit for #testing 🙂 (Can one cross-post in slack? I don't see it)

Mno16:01:55

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.

Mno16:01:23

Good shout Max!

potetm17:01:16

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

pez17:01:13

@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. 😃

👍 6
😂 6
roelof17:01:50

thanks, I saw also a teacher whch making and explained this but he does it totally a other way then plexus

pez17:01:12

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.

🤤 3
roelof17:01:40

I can image, I tried to follow him and I cannot all the time

roelof17:01:00

I saw one videoo where he uses bit-map things

Joe19:01:48

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

☝️ 9