Hacker News Reader

Comment by vavooom | Hacker News Reader

Would people reccomend this as a way to cement an understanding of Python / OOP in general? I’m typically more geared towards data science style scripting use cases and want to explore more problem focused programming.

View on HN

I highly recommend it to explore new programming styles in general. As some others, I use it as an excuse to learn a new language each year.

While I think python is a really great language for advent of code, I'm not sure I'd recommend going for an OOP-heavy style. Although that might just be a matter of personal taste - I think OOP is a poor strategy for most problems.

Yup. Very much a chance to learn a new (for me) language. Looking to do Golang this year - brushing up on the basics of the language as we roll into a long turkey weekend.

I'm torn between Clojure (totally n00b) or Elixir (mostly to force myself to use it rather than defaulting to Python)

I'm something of an elixir zealot, but I have to say that Clojure has the most pleasurable syntax for this kind of thing out of any programming language.

Being an elixir zealot have you ever considered lisp flavored erlang? If so, what are your thoughts in comparing it to clojure?

https://lfe.io/

I actually have played around with it! I think Clojure feels a lot more polished, but it's also a lot more rigid, which I could definitely see someone disliking. LFE almost feels a little more like Common Lisp, although that's more to do with Erlang and the BEAM than any specific syntax choice. Plus, of course, you get to work with all that OTP goodness. If had to choose between LFE and Clojure as the only language I ever programmed in again, it would be a really hard tossup. Clojure might have a relatively larger community, but I don't want to give up the BEAM!

The reason LFE didn't do it for me was that Elixir is relatively painless syntax-wise, and has really nice high-level libraries like Phoenix and Ecto that simplify a lot of work. If I don't need the BEAM, than I'd rather have a more strictly functional language like Clojure, or something more low-level like Common Lisp. LFE doesn't occupy a niche in my personal ecosystem. That being said, I'd definitely give it another try sometime, and I'd recommend it to anyone else who wants to feel the power of the BEAM.

That's good to know. What is it about the AoC that makes it play into Clojure syntax so well?

Clojure is the most practically expressive language I've ever had the pleasure of working with. For some reason the example that immediately comes to mind is how you can use a collection as an accesser for itself, so ({:a 2 :b 3} :a) returns 2. Just a neat bit of syntactic sugar, but now if 'blacklist' is a set, you can just do (remove blacklist guests) to remove everything in blacklist from guests. There's a hundred little things like that which combine to make it a really fun and concise language to work with.

This year I'm going to try it with Babashka, the native Clojure scripting runtime. See how far it can take me.

Babashka is fast-starting but slow-running (compared to JVM Clojure). AOC puzzles typically contain a lot of loops so you will likely run into the slow-running-ness. But it shouldn't be much trouble to move to Clojure when you hit this.

Clojure is fun to try out. I tried it last year and had a lot of fun combining and finding the right function from its huge expressive vocabulary. It inspires you to treat code as data.

I've had a couple of Clojure books I've meant to work through over the past year. Where I'd get stuck is in the development workflow more so than in the language features or syntax. Clojure (and lisp-like languages in general) seem like my usual edit, save, run loop isn't the most effective way (especially if it's Clojure and the JVM needs to start each time if you run cold).

I can't possibly sing the praises of Cider loudly enough. Emacs is a hard sell, I get that, but Cider is such a nice way of working with Clojure.

I suppose Cider in Doom Emacs means I can keep using the vim keys I already know.

You can go one further - last year I tried to solve every problem in a different language!

I first heard of people doing this for codejam, and it works just as well for AoC

My 2c from the experience,

* I hated Go for this style of programming, but I could see it being good for some production-ready code

* Rust should be renamed to Rustcargo. Even for the most basic of tasks it seems like these two are welded together.

* I still really like Nim as a replacement for Python in my toolbox

> Rust should be renamed to Rustcargo

I much prefer RustCargo to C++BringYourOwnShittyBuildSystem! Cargo definitely one of the bright spots in Rust imho.

I like OOP approaches a fair bit, but only for relatively large, long-lived systems, especially when working with a team. E.g., the Domain-Driven Design approach can provide a ton of shared clarity.

For something like Advent of Code, though, I'd avoid it. It's just me and it's not for long; there's no need for me to be explicit about how I'm thinking about the problem.

I'd say AoC is more about problem solving and less about Python. The puzzles tend to be pretty good and I usually learn something from them. You could have a look at the previous edition to see if AoC is something you'd enjoy [0]. What I found informative was looking up other people's solutions on reddit and GitHub.

There is also Rosalind for more data oriented challenges [1].

0. https://adventofcode.com/2020

1. http://rosalind.info/problems/locations/

I just started rosalind after someone posted it on here last week. They're definitely focused on bioinformatics similar to euler being more math focused.

I haven't gotten too far, but the initial problems don't seem too hard in higher level languages. They are very good problems to get better at IO, string manipulation, and data wrangling in your language of choice though.

> I just started rosalind after someone posted it on here last week.

Same.

> I haven't gotten too far, but the initial problems don't seem too hard in higher level languages.

True. But the info boxes in the top are interesting and informative, those make it worth it to keep going.

> They are very good problems to get better at IO, string manipulation, and data wrangling in your language of choice though.

For me, it's also a way to peek into BioJulia and get some familiarity with it. (I don't mind "cheating" this way since this was my primary goal with the site anyway.) So far I'm pretty impressed by how fast it is!

Contrary to other responses, you can certainly use OOP programming to solve these problems, and I think that is a better way to do it. You wouldn't write 100 line blocks of dense algorithms in prod code, why do it here? Thinking about breaking things into objects makes a lot of the problems easier to solve in my opinion.

That said, I don't think it's great for really getting in depth understanding of any language in particular - you'll only use a limited subset of language features for these problems.

Python, sure, but not OOP. Most solutions will not be very large and there's really no need for OOP (ever) but particularly not for something like this.

Don't hate on poor old OOP :( It's a good way to take that step from scripting to software engineering. Sure it can get out of hand with AbstractSingletonProxyFactoryBean's but so can other paradigms.

I mean...it forces you to plan and organize your code, if that's what you mean. But I also think it encourages you to do it in a way such that the organization becomes more important (and oftentimes, more complicated) than the problem you're solving, and I'd contend that's kind of a bad way to take that step, especially for people not otherwise experienced enough to know how to avoid that complexity.

You can apply OOP principles to even the simplest problems. Search for “fizzbuzz enterprise edition” to get some ideas.

I think most problems would be solved elegantly with a pseudo-functional approach in Python, so AoC wouldn't be the best for OOP.

Make an API client, a GUI or game if you want to use OO in Python canonically.

Maybe they could be, but that doesn't mean they have to be. My intcode computer was written using OOP.

AoC won't teach you anything about OOP.

The problems are designed to be solved in Python with less than 100 lines of code, by taking advantage of Python's extensive library of data structures and algorithms.

quite strongly disagree with this. You can solve the problems with fewer than 100 lines of code, but you can certainly also take it as an opportunity to flesh your programs out in OOP style. In general, programming is about what you want to do and learn, and the problems aren't designed for any specific paradigm. A lot of people have taken Advent of Code as an opportunity to not lean on any external libraries for example.

There's numerous problems from board or combat game simulations, to mazes and the intcode computers that lend themselves to be approached in OOP style. The context OP is coming from is data science scripting, it's fine to start with small examples.

I did AoC2020 with C++ and did it in a enterprise, over-the-top, well-structured way. E.g. need to find two items whose prices sum up to 123? Implement a multidimensional knapsack just in case you need it later (spoiler: I did need it). If you take the time, and don't bother with the leaderboard, you might find AoC to be a really fun and engaging way to explore new concepts and solutions.

Yes, this is the way I do it as well. There were quite a few cases where I went all in with an apparently overengineered solution, and then I could use the code directly for the second problem with almost no changes.

I don't go for being the fastest or anything, I just want to do everything in a way that I like. Last year I did everything on the same day it got out; I plan to do the same this one, unless there is a particularly bullshitty problem that puts me off.

A couple of years ago I decided to learn Kotlin by doing AoC puzzles. It was a really good way to get comfortable with the basic syntax and data structures of the language.

Doubtful unless you do it in a way that facilitates that understanding. it could be like a year or two ago where you build up a computer from the ground up and do things with it where it would be more oop but a lot of the times they are self contained and don't require that much structure.

if you do it deliberately it's a good way to learn a new language.

Advent of Code is generally to small to help with OOP practice. It will help get you familiar with Python though.

OOP's toolset is useful for abstracting over interchangeable parts, which is the sort of thing that doesn't really come up a lot in Advent of Code problems. AoC is lots of fun, and Python is a great language to do it in, but I don't think it's a good place for OOP.

I usually use AoC with some specific goals or limitation in mind to teach myself. The problems will not require OOP, but if you force yourself to solve each problem using OOP...

Last year I did typescript and tried to really focus in on the type system.

it can be a great way to learn a language and to explore other programming paradigms.

Reply on news.ycombinator.com