All,
Plato said that in the Republic. In other words, we don't tend to look for new solutions when what we already have works. We can use the principle to expand our current knowledge base. This meditation will take you through the explanation, cause, and a solution to an apparently common problem among Perl hackers.
Explanation
After assimilating enough information to do what needs to be done, many Perl hackers feel lost in what to learn next. I myself experienced this same problem originally as outlined in Road map woes. We feel such an affinity to the language, we want to continue expanding our knowlege even after being confident we can get the job done.
Cause
Perl is an amalgamation of many small versatile tools resulting in a language that easily solves many jobs. It was designed with the programmer in mind so that you could accomplish what you wanted without worrying about things like memory allocation, garbage collection, explicit conversion of strings to numbers, etc. With such a powerful language, you only need to know a little to do a lot. This is the crux of the problem since learning more is not necessary to accomplish what we need to do. Since we do not know what we do not know, it is often hard to come up with a project that will require learning new things.
Solution
Simply solve an old problem in a new way. You can accomplish this by systematically throwing out tools from the toolbox until you don't know how to solve it. On occassion you end up using an old tool in a new way, but this is just as beneficial. In fact, if there is an area you have not mastered, a useful variation on this method is limiting your toolbox to a single tool (solve X using only regular expressions).
It is important to note that the more experience you have, the more unlikely it is that you will find a better solution for the original problem. This is perfectly ok since what we set out to do in the first place was learn something new. You may also find that you have no practical use for what you have learned. That is ok too because it usually becomes a key that fits perfectly in a yet undiscovered lock. It is also ok to pursue ridiculous solutions since you never know what you may uncover in the process.
Feedback
I welcome any and all feedback. I know that some hackers prefer to be more practical in their approach to coding. I understand and respect that opinion. I freely admit it is not a good fit for everyone. Programming is not my primary vocation so I tend to run out of needs and have to invent my own. This method has helped me. I know it won't help everyone, but I hope it helps someone.
|
Re: Necessity is the mother of invention
by kvale (Monsignor) on Mar 09, 2005 at 20:43 UTC
|
People have been using constraints to spur creativity for a long time. A lot of beautiful poetry has been wrriten under the constraints of rhyme and meter. Perl poetry, too, has its own constraints.
Another type of necessity that spawns invention for me is solving other peoples' problems. The constraint is that their problem and possibly their approach as well should be respected; work within those boundaries to create an elegant solution. If no elegant solution presents itself under these constraints, well, that is a learning experience, too.
And so I have learned a lot about perl and algorithms from solving problems posed by SoPW.
| [reply] |
|
|
kvale++
I find it almost impossible to motivate myself to solving problems for which there is no real need. That's why I find SoPW's motivating. Someone out there has a real problem they are trying to solve.
The competition aspect of Golf and similar challenges sometimes grabs me, but give me a real problem any day.
Motivation was never a problem in the workplace, but as a hobbiest, finding the motivation to, for example, write a module for the sake of having a CPAN presence just doesn't get my creative juices flowing beyond the initial proof of concept.
I always had a similar problem with pure math. I (once upon a time) could handle most of abstract math (to the fairly low level I studied it) as well or better than my peers, but the idea of futzing around with stuff that barely one percent of the population could ever understand, never mind appreciate left me cold.
If it doesn't have an application that I perceive as having real world uses, I find very little motivation for pursuing it.
I have great admiration and awe for guys like Andrew Wiles, but quite how he managed to find the motivation to pursue his proof, especially in the knowledge that there are probably only 30 or 40 people in the entire world that will ever truely understand it, is quite beyond me.
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply] |
Re: Necessity is the mother of invention
by Anonymous Monk on Mar 09, 2005 at 21:36 UTC
|
Too many people try to do this at work. :-(
At work, please don't solve a solved problem in a new way; and if you do, **please** don't do it in production code unless you've got a very, very good reason.
I have to deal with this sort of thing all the time: people deciding to do "clever" things with Perl, then forgetting why they did them, or making things overcomplicated just to "try out" features that aren't needed. Code like that is hard to maintain! :-(
Don't artificially complicate an old solution, unless there are clear benefits to trying a new approach. Even then, refactor first, re-write later.
Even when dabbling on your own time, why not try to solve a new problem, instead? There are lots of projects that need doing: try doing something that hasn't been done, or adding a little feature to something that already exists.
There are certainly learning benefits to doing something that has been done before (for example, you can look to other implementations as a reference for what you should/should not have done, and compare results). However, there's also a certain joy that comes from doing something productive that other people can use and appreciate. I prefer the latter, if and when I can manage it.
--
Ytrew | [reply] |
|
|
Richard Feynamnn the Nobel prize-winning physicist had a great reason for solving old problems - it builds your confindence and your experience and then one day you find an interesting problem and solve it and discover that no one else had managed it before. There might not be a practical use for a seond solution, but there is a lot to be learned from getting there which cannot be gained from simply studying an existing solution. The point is the journey, not the destination ;)
| [reply] |
|
|
"Why not try to solve a new problem instead?
The simple reason is that, contrary to popular wisdom, the best time to fix something is when its not broken. If you already have something that works, its easy to test that your new solution does the same thing -- especially if your have tests for your existing solution.
And a comment on the title of this thread: I thought it was well estabished that the common case is the reverse: invention is the mother of necessity. That is, we don't realize that we can't live without something until we actually have it. It's why market analysts invariably fail to predict "the next big thing".
Dave.
Opinions my own; statements of fact may be in error.
| [reply] |
|
|
It's why market analysts invariably fail to predict "the next big thing".
I have a rather different view on why market analysts fail...mostly it's because they always ask 'wool-over-the-eyes' questions like "How would you feel if your [cellphone] was (or wasn't!) the smallest/lightest/coolest thing amongst your circle of friends?" rather than straight forward questions like "Would you pay a premium to have very cool, tinier mobile than your freinds?".
The fact that there is a practical limit to the usability of a yet smaller, phone seems lost on them. Have you ever tried, (or better yet, watched someone else) trying to use one of those really tiny mobiles in a noisy environment? I call it the "cool-cell DTs".
Listen, move down, speak, move up, listen, move down, repeat, move up, listen, move down, re-repeat "Could you repeat that?", move up (quickly), listen,.... :)
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply]
[d/l] |
Re: Necessity is the mother of invention
by DrManhattan (Chaplain) on Mar 09, 2005 at 21:43 UTC
|
I take the same approach to video games. If I get bored enough in UT2004, I'll run around trying to cap people with the shield gun. :)
| [reply] |
Re: Necessity is the mother of invention
by samizdat (Vicar) on Mar 10, 2005 at 14:26 UTC
|
Excellent meditation to grok, L~R. I tend to place "success" in a social organism in a context of "What behavior, if encouraged, leads to more individual success / satisfaction / survivability." Current learning theory uses a helical spiral as a metaphor, but I'd expand that to use a spring in resonant motion as a representation because it's also wise to back up and re-examine your basic assumptions. I cheer for Detonite as he digs around for all kinds of different things to chew on.
Your example of selectively enabling/disabling tools is a good one in that it provides an action framework on a very basic and incrementally useful level. I'd suggest also using huge leaps, i.e., reading up on Feynman's life and then learning to program a microcontroller in assembly language, and then reading something by David Friedman on economics in practice. Then come back to Perl with a whole new perspective. Life becomes more juicy when you make it big, IMHO.
The breadth of one's association nets is the key to both creativity and survivabilty in this non-deterministic, non-zero-sum world. | [reply] |
Re: Necessity is the mother of invention
by Anonymous Monk on Mar 10, 2005 at 15:29 UTC
|
Man, I often do this. I throw away for, while, blocks, subroutines, map, if, etc, and do all my flow control with
goto $var;
I also found that there's no need for arrays and hashes.
But what I don't understand is why my co-workers hate me. They used to complain Perl has to many constructs, and now that I've reduced the number of constructs I use, they're still unsatisfied. | [reply]
[d/l] |
Re: Necessity is the mother of invention
by kimanaw (Beadle) on Mar 11, 2005 at 04:30 UTC
|
1) Posit previous solutions into a new universe. My personal favorite is thoroughbred horse racing. Its fun, its challenging, and occasionally profitable.
2) Take old solutions and make them run faster with smaller footprint. All too often PH's just throw the same old solutions at problems wo/ thinking about the consequences. So dust off those old scripts, open the Camel 3E to chapter 24, section on "Efficiency", and start tweaking. You may be surprised at the performance to be squeezed out of even a small script.
3) Write a source filter. Its been my best learning experience thus far. Oh, and make sure it does something useful (Acme::Dubya may be a humorous effort, but of questionable value). If you have some domain-specific knowledge, you can probably invent a nice language to encapsulate/represent it...so write a source filter.
| [reply] |
Re: Necessity is the mother of invention
by johndageek (Hermit) on Mar 11, 2005 at 19:20 UTC
|
To keep life interesting, I practice being a generalist. People tend to avoid problems that are outside of their area of expertise, so the problems that cross lines are shunned by all sides. It is entertaining to meld various pieces of knowledge into a "new" solution. (Yes I hone my special areas of expertise - programming and data design) But there is a special thrill in delving into a new area of knowledge because there is potential to apply it in a new way.
It is also fun to take a specific problem/task and try to see how many different ways it can be solved, disregarding all constraints, then selecting the one(s) that can be modified to have no un-desired results.
Thanks for an interesting post!
| [reply] |
|
|
