3 ms·

> complex solutions Puzzles aren't really about that. It's about making a model of a problem and finding solutions to it. Complex solutions are as bad in puzzl

by dmos62 7y ago

> complex solutions Puzzles aren't really about that. It's about making a model of a problem and finding solutions to it. Complex solutions are as bad in puzzles as in any other area. Not sure what you mean by "clever" (maybe "clever" as in unreadable code). Sometimes you come to an aha moment and realise that you can solve something in a trivial way, aka clever way, and that's a desirable event.

rubinelli 7y ago
A puzzle will more often than not have one right way to do it, unlike real engineering problems which are made of trade-offs, and that one way is unintuitive, otherwise it wouldn't be much of a puzzle at all.
- dmos62 7y ago
  A puzzle is just a packaged problem. I think it's hard to argue that certain puzzles are more prevalent than others. This weekend we were doing these puzzles where you have to align unique pieces into a specified shape. It's basically a bruteforce search. The creativity is expressed in how you reduce the search-space and how you memorize the alignments you've already tried. There's definitely more than one way to do it.
- Retric 7y ago
  Even when there is only one solution there is generally a vast array of possible approaches to solving it. A Rubik's Cube for example does not care about the intermediate states.
barrkel 7y ago
For sure. However most code doesn't require "aha moments"; it requires readable code with tests that cover edge cases, following the same pattern as similar code that does similar things. The worry around puzzle orientation is when someone e.g. takes advantage of an obscure feature or does something unusual for a performance gain at the cost of readibility or maintenance. I've seen several repeated instances of clever people writing complex code because they could, and spending too little time thinking about whether they should. There's a place for that kind of thinking. It's usually when non-functional requirements are limiting factors; minimizing memory, CPU time, network round trips, etc.
- nullspace 7y ago
  > It's usually when non-functional requirements are limiting factors; minimizing memory, CPU time, network round trips, etc. Unless you’re working on something trivially easy, isn’t this almost always the case? The puzzle does not actually show up as “high cpu utilization”, but seeing process stalling, string handling edge cases, weird packaging based problems or that one issue for that one customer happen on a weekly basis for my teams over the past decade of me programming professionally. Also, the best puzzle solvers or hackers almost always come up with the simplest solutions that solves problem and are literally the only people I’ve seen being able to take on the toughest bugs.
  - barrkel 7y ago
    I could put it another way. Some people who are comfortable with complexity don't actually come up with the simplest solutions, and instead come up with more complex solutions because they themselves find them relatively simple. It's a pattern I've seen in talented engineers with less experience. And on your question, I don't think it's the case. If it were, then there would be little excuse to use Ruby over Java, or Java over C++ / Rust / etc. In the same way as we pay a performance penalty in return for productivity when we use an expressive, high-level language, we pay a performance penalty for maintainable code with clear abstraction boundaries. Efficiencies, when they must be found, often come through vertical integration that burrows through abstraction layers. Ideally we build our architectures so that we can scale out rather than up, for both hardware (easy) but also the team (the much tighter constraint - aiming for fungibility and elasticity of labour). If we get to the size of a Google or FB, then we can worry about squeezing out more profit, but first comes growth, and that means product, which means features.
randcraw 7y ago
Agreed. Levy's "Hackers" is still the best book I know about the mindset that begets hacking and hackers. I can't recommend it highly enough. It opened the door to my first job in programming. The author seems to be bemoaning the lack of opportunities today to return to the halcyon days of yore. Mostly I agree. I was coding back in the early 80's, and the energy surrounding computers then was much more dynamic, open-ended, and seemingly limited only by one's imagination. Alas the rise of open source inevitably grew hobbyist computing into the panoply of richly ornamented computing tools we know so well today, from the Linux kernel to the GNU toolchain and far beyond. It was probably inevitable when millions of youngsters with copious free time can dive deep into the bowels of PC hardware using a wealth of S/W tools that the formation of a big complex (daunting) computing ecosphere was inevitable. And all that technical mass makes it much harder to perturb the universe and do something new and cool and share your hack with like-minded friends. As to the roots of hacking... solving a puzzle is where the adventure begins, but solving it elegantly, even optimally, is where it goes from there. The best hacks open doors to other hackerfolk, enabling them to go where nobody you know has gone before, and they make ever deeper dives into computing that much more compelling. AFAIK, this is true of all hackerfolk, be they white or black hatted, in S/W or H/W.

by dmos62 7y ago

rubinelli 7y ago

A puzzle will more often than not have one right way to do it, unlike real engineering problems which are made of trade-offs, and that one way is unintuitive, otherwise it wouldn't be much of a puzzle at all.

dmos62 7y ago
A puzzle is just a packaged problem. I think it's hard to argue that certain puzzles are more prevalent than others. This weekend we were doing these puzzles where you have to align unique pieces into a specified shape. It's basically a bruteforce search. The creativity is expressed in how you reduce the search-space and how you memorize the alignments you've already tried. There's definitely more than one way to do it.
Retric 7y ago
Even when there is only one solution there is generally a vast array of possible approaches to solving it. A Rubik's Cube for example does not care about the intermediate states.

barrkel 7y ago

For sure. However most code doesn't require "aha moments"; it requires readable code with tests that cover edge cases, following the same pattern as similar code that does similar things. The worry around puzzle orientation is when someone e.g. takes advantage of an obscure feature or does something unusual for a performance gain at the cost of readibility or maintenance. I've seen several repeated instances of clever people writing complex code because they could, and spending too little time thinking about whether they should. There's a place for that kind of thinking. It's usually when non-functional requirements are limiting factors; minimizing memory, CPU time, network round trips, etc.

nullspace 7y ago
> It's usually when non-functional requirements are limiting factors; minimizing memory, CPU time, network round trips, etc. Unless you’re working on something trivially easy, isn’t this almost always the case? The puzzle does not actually show up as “high cpu utilization”, but seeing process stalling, string handling edge cases, weird packaging based problems or that one issue for that one customer happen on a weekly basis for my teams over the past decade of me programming professionally. Also, the best puzzle solvers or hackers almost always come up with the simplest solutions that solves problem and are literally the only people I’ve seen being able to take on the toughest bugs.
- barrkel 7y ago
  I could put it another way. Some people who are comfortable with complexity don't actually come up with the simplest solutions, and instead come up with more complex solutions because they themselves find them relatively simple. It's a pattern I've seen in talented engineers with less experience. And on your question, I don't think it's the case. If it were, then there would be little excuse to use Ruby over Java, or Java over C++ / Rust / etc. In the same way as we pay a performance penalty in return for productivity when we use an expressive, high-level language, we pay a performance penalty for maintainable code with clear abstraction boundaries. Efficiencies, when they must be found, often come through vertical integration that burrows through abstraction layers. Ideally we build our architectures so that we can scale out rather than up, for both hardware (easy) but also the team (the much tighter constraint - aiming for fungibility and elasticity of labour). If we get to the size of a Google or FB, then we can worry about squeezing out more profit, but first comes growth, and that means product, which means features.

randcraw 7y ago

Agreed. Levy's "Hackers" is still the best book I know about the mindset that begets hacking and hackers. I can't recommend it highly enough. It opened the door to my first job in programming. The author seems to be bemoaning the lack of opportunities today to return to the halcyon days of yore. Mostly I agree. I was coding back in the early 80's, and the energy surrounding computers then was much more dynamic, open-ended, and seemingly limited only by one's imagination. Alas the rise of open source inevitably grew hobbyist computing into the panoply of richly ornamented computing tools we know so well today, from the Linux kernel to the GNU toolchain and far beyond. It was probably inevitable when millions of youngsters with copious free time can dive deep into the bowels of PC hardware using a wealth of S/W tools that the formation of a big complex (daunting) computing ecosphere was inevitable. And all that technical mass makes it much harder to perturb the universe and do something new and cool and share your hack with like-minded friends. As to the roots of hacking... solving a puzzle is where the adventure begins, but solving it elegantly, even optimally, is where it goes from there. The best hacks open doors to other hackerfolk, enabling them to go where nobody you know has gone before, and they make ever deeper dives into computing that much more compelling. AFAIK, this is true of all hackerfolk, be they white or black hatted, in S/W or H/W.