On Tue, 2012-01-17 at 23:10 +0100, Dennis Haupt wrote: > Am 17.01.2012 22:46, schrieb James Reeves: > > On 17 January 2012 20:46, Dennis Haupt <d.haup...@googlemail.com> wrote: > >> i've noticed this since i started to work as a programmer 10 years ago. > >> programmers in general are supposed to be good at finding simple > >> solutions, but my experience is: they are not. on the contrary, many > >> suffer from their individual tunnel visions without being aware of it. > >> to a hammer, everything looks like a nail. > > > > To borrow from Stuart Halloway: simplicity ain't easy. > > > > The example solutions you provide from non-programmers seem > > straightforward, but that's because they're instructions designed to > > be followed by a human being, who can infer and reason, rather than a > > programming language that is constructed around the idea of precise > > commands. > > > > For instance, "you just make pairs" hides a considerable amount of > > depth. How do you make pairs? You might select one number, then look > > for another number that is identical, but how do you ensure you don't > > pick the same number? > > > > Or what about "count how often a number is in the list". Again, it > > seems a simple thing to do, but only if you're giving instructions to > > a human. In programming there are many additional questions, like > > where to store the numbers whilst you're counting them. Do you go > > through the whole list for each number, or do you go through the list > > once and keep a tally? If you keep a tally, which data structure > > should be used to implement this? > > in the end, the program must work down to the lowest level and there > cannot be unanswered questions. but take a look at the 3 solutions given > until now. in 2 cases, all i read is "do this, then that, i don't care > how". in the third, a hashset was picked. but it didn't have to be one. > any non-map-collection type would have worked here. > > > > > It's often a lot easier to find a complex solution to a problem than a > > simple one. Simple solutions are hard work to find. > > i'd say they require different strategies to find
On a completely different approach, have you seen Polya's book "How to solve it"? Tim Daly -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
