Hacker News new | ask | show | jobs
by anonymoushn 1762 days ago
Not using design patterns seems like pure upside.

I don't think it's reasonable to use a library for most things one implements in competitive programming, because the work of getting your problem instance in and out of the library is probably greater than the work of writing the solution yourself, in code length and in runtime. As an example, the only time I ever needed to use A* was on a state space that was larger than the main memory of any computer on Earth. I don't expect that I can download a library that does A* on abstract state spaces not fully present in RAM for me, but I can just bash out my own A* that's fused with the definition of the state space. Maybe this is so easy to do partially because I did a bunch of programming contests in which I wrote BFSes that were fused with the definitions of graphs.
2 comments
dmurray 1761 days ago
> I don't expect that I can download a library that does A* on abstract state spaces not fully present in RAM for me

I'm sure this does exist! A functional library where you pass in, not a pointer to the set of all nodes, but some functions to get the node with the current lowest distance and to update the distance of a node.

Not saying it was the right thing for your use case, but don't rule it out. Even in languages that aren't strongly FP - eg it happens a lot in Go due to the lack of generics, and if you squint, the C++ STL is kind of like this.

link
alerighi 1762 days ago
It's not. Because then someone else has to maintain the code you written, and if he cannot see any common pattern in your code he will make 10x the effort to understand the code, that means wasting time and thus loosing money for the company.
link
anonymoushn 1762 days ago
Is this about the design patterns or the A*? Design patterns are a mix of techniques to pay complexity make code extensible that usually will not ever be extended and workarounds for the deficiencies of a specific family of languages. An example I posted about previously is that you could spend hundreds of lines across a dozen files implementing double dispatch, or you could use dramatically less if you aren't implementing it in terms of a language-provided dynamic-dispatch-on-the-first-argument-only primitive.

It is nice to write code that can be understood by the next reader. To explain what our invariants are and what we are up to, we have comments.

link