Since many of you seem to like 100%-functional, al...

# advent-of-code

[gnu]

Since many of you seem to like 100%-functional, all-in-one-solutions: I have really a hard time understanding those 20-to-30-line-functions with deeply nested lambdas without the help of an IDE. I have to keep track of a whole stack of receivers and inferred data types ... most of the time, I get lost half way through it.

I'm a TDD-developer, leaning more to the clean-coders-approach with very small, easy-to-understand functions and well defined in- and out-data-types. After creating a test first (which is a template for this contest), I write a really crappy imperative solution to get the correct answer fast. After that, during the refactoring phase, I do all the extractions and renamings, finally converting everything to functional.

What do you think, is this a bit over-engineered for these kind of contests?

[ephemient]

up to you and your goals for Advent of Code

[gnu]

Since I don't get up early enough to actually compete in the contest, I'm trying to understand the solution of others, integrating their ideas into my own solutions and by that, hopefully becoming a better developer myself.

[ephemient]

Eric Wastl has said his purpose for Advent of Code is for people to learn, and it sounds like that is the case for you, so it's all good 👍

[Jakub Gwóźdź]

@gnu it is exactly how I do the puzzles as well. And I do believe it is great exercise.

[Vitali Plagov]

I do the same - first cheap-dirt solution with a lot of local vars and printlns to get the correct result. Once I have the validated result - make a unit-test and start refactoring.

[PoisonedYouth]

For me it's pure learning of what is possible to solve the task. I try to get a solution which ist understandable for me

[elizarov]

You can check out my solutions. I code AoC for speed, so they are all as straightforward as I can get them. Not the great examples of concision and stdlib usage but they get the job done. https://github.com/elizarov/AdventOfCode2021

[gnu]

Thanks, Roman! I find it interesting, that almost all of the actual speed-coders tend towards a much more imperative style. In the end, it seems to be the "natural way" to think about tasks and implement solutions ...

[elizarov]

It’s not all imperative. There is a lot of useful FP on small scale (maps, filters, etc). But large-scale state manipulation is faster to write in imperative style and the resulting code is actually easier to understand.

[gnu]

Thank god, Kotlin is a multi-paradigm language :-)

[ephemient]

I'm not a speed coder but I have made it into the global leaderboard a few times, and my initial solutions are all functional - because I'm solving everything in Haskell first, before translating or re-implementing in Kotlin, Python, and Rust. I find it an interesting exercise to explore exactly what is or isn't expressible in each language

[Nir]

I kind of like to use a mix of styles; broadly I think I agree with what Roman said. A lot of small scale transformations are very clear with more FP approach, and you also get to keep a lot of local data immutable which is very nice.

[Nir]

But often for speed and clarity you can't beat declaring a mutable data structure and updating it; that has a clarity of its own if there aren't too many of them in one function, I think. Today's is a perfect example of that I think.

[elizarov]

It has to do with the way the business problems are typically stated. They are usually stated in imperative way as “do this”, “then do that”, “repeat this step so many times”, etc. However, each step is often declarative like “find minimum of”, etc. And that is the most natural way to write it in code. The closer your code to the original problem description, the easier it is to understand. Ultimately, that’s the very mission of Kotlin as a language — to make the translation of the problem statements you have into the code you write as direct as possible.