On the upper-left corner of the Monastery, you see some random quotes.
I would like to share with you my (somehow vague) thoughts on some of them:
- XP is just a number... but of course people only realize that the moment they become Saints! It's called "enlightenment".
- Welcome to the Monastery - It's one of the best things about this community: people will receive you with open arms :-)
- Perl Monk, Perl Meditation. - Yep. 'F you're a monk, gotta meditate! Listen carefully and learn. I think that's part of the philosophy behind the Monastery.
- Think about Loose Coupling - My personal opinion is that this has to do with modularity, but I may be wrong, because only today I was told of the meaning of "Coupling" :-) And the first meaning I was told of apparently involves sex :-\ (but the link is safe, so don't bother opening it)
- There's more than one way to do things. - And the fact is that by doing something in a couple of ways (e.g., japh's), you get some more experience. You should follow this advice: experiment it another way (and she might like it, too).
- laziness, impatience, and hubris - Oh yes, I'm lazy, impatient, and... er... what's the word I'm looking for? :-) Anyway, I think it is true that these really are virtues of a programmer. Regarding laziness, an expression arises to mind: "If you have a boring/hard task to do, give it someone lazy; he will find an easier way to do it".
- Pathologically Eclectic Rubbish Lister - no comments :-)
- Perl Sensitive Sunglasses - The truth is: I now see the world through Perl. Am I wearing those glasses? :-)
- P is for Practical - Oh yes, baby! Practical! Oh yeah! :-D (we apologize for the interruption)
- go ahead... be a heretic - I'll take it as this is somehow related to the London Perl Mongers (search for "Heretic People" here) :-)
- Keep It Simple, Stupid - This reminds me of mjd's insults^W quotes O:-) the word "retardo" comes to mind, as well as the sentence "you are a stupid..." :-) I'm also reminded of when I was wondering why if ( scalar ($first .. $last) < $max ) {} didn't work, when a simple if ($last - $first < $max) {} would suffice (I hope I got the code right).
- more useful options - What is this related to? Perl command line switches? More regex switches? :-)
- good chemistry is complicated, and a little bit messy-LW ... you should see "bad" chemistry!
- Just another Perl shrine... as if there were many :-) The ones I use the most are this one and use.Perl.
- Syntactic Confectionary Delight - Yep, Perl really is a delight, true eye-candy :-) You can almost taste it :-)
- Your skill will accomplish what the force of many cannot - Here's a great aphorism: "If brute force fails, then you haven't used enough"... I'm not so sure of what to think of this :-)
- Perl: the Markov chain saw - I know about Perl being a chain saw (and we do are a fearsome army, with our chainsaws), but I really don't know what that has to do with Markov... jjohn's fault, perhaps?
I missed one :-) On purpose :-) I'll leave it to you to find out which and why :-)
Re: Random quotes in the top left corner
by mr_mischief (Monsignor) on Apr 26, 2005 at 16:23 UTC
|
The KISS principle has been around longer than Perl. It's a great thing for any programmer to remember, or any engineer, any web page designer, any cabinet maker, any essayist...
The whole point of Keep It Simple, Stupid is that many people who design and implement new things are in the bright to genius category, including very bright somewhere in between. It's a matter of pride and skill to be able to make things very complicated and still understand them. However, there are a several reasons not to make things complicated.
- Complicated things are harder for an outsider to understand and fix later.
- Complicated things are generally less robust and break easier.
- People working with complicated things tend to lose sight of the original intended purpose of that item, and all kinds of bells and whistles get added at the expense of the main functions.
- No matter how smart you are, the jobs of programmer, engineer, essayist, cabinet maker, et cetera are more or less about managing complexity in the first place. At some point of introducing additional complexity, even the smartest people can't hold enough of a project in their heads at once. Paragraphs, chapters, subroutines, modules, reusable parts, and templates (both the material working and programming kinds) are tools to help localize complexity -- that is, they raise the complexity a manageable amount in several places so the overal complexity can be reduced.
Almost anyone can screw together premade cabinets that have been disassembled if they have the directions and enough patience. It's the cabinet maker who takes a bunch of lumber, planes the cabinets, makes the right cuts, puts the wood on the router table with the right jigs, and sands the rough spots out. This is managing complexity by taking a bunch of raw materials and making parts that connect, then conencting the parts. Having premade screws in a package and glue in a bottle of course are helpful. We as programmers are lucky that often many of our parts are already made.
Almost anyone, likewise, can figure out a Hello World program if given a reference manual on a language. Fewer people can reason about a 100-line program with no formal flow control. Even fewer can reason about a 1000-line program with no formal flow control. Most people can understand a program with ten subroutines doing ten well-defined things each ten lines long. If those ten each call ten more well-defined subs, that's not much of a stretch either. Three 40-line subroutines of course can be as reasonable as ten ten-line ones, depending on the problem you're trying to solve. Loops, subroutines, modules, blocks, and a certain level of syntactic sugar are all helpful precisely because they let one focus on the steps to solve a problem at one moment and how to break down an individual step into substeps at another time.
There are of course many other tools to help make things less complex, but the best tool to manage complexity is a well-trained and/or insightful mind. Knowing where you can eliminate complexity and where it's safe to have a little more than usual takes training, practice, or a really good eye -- preferably all three.
It's probably the art and science of managing complexity that accounts for most of the huge differences among lines of working code per day produced by programmers using the same language. These differences are not usually measured in numbers of individual lines, but in multiples or even orders of magnitude.
| [reply] |
|
2. Complicated things are generally less robust and break easier.
An interesting counter-example is an ecosystem - more components and interactions equal more robustness.
| [reply] |
|
That is a great counterexample. Note two things about that, too:
The complexity in an ecosystem comes from nature and not from man. The complexity of an ecosystem is such an obstacle to our full understanding of it that only in the last few decades have we started to understand the damage done to the systems via the damage done to their parts.
So, it's a great counterexample to one rule, and a great reinforcing example to another.
| [reply] |
|
|
|
|
|
An interesting counter-example is an ecosystem - more components and interactions equal more robustness.
What's so robust about an "eco-system"? What functional elements of the "eco-system" are you claiming this robustness for?
If I've very carefully selectively bred, say, an ant colony to create tunnels in patterns that represent the solution set for a given computation, I've got a very fragile system, not a very robust one. I'd need massive amounts of parallelism to match the correctness of even a small microcomputer, in order to statistically correct for all the flaws in the individual ants.
Ecosystems are only robust in that it's reasonably hard to competely disrupt all biological processes in a given area, due to sheer numbers. But then again, it's even harder to destroy all geological processes, let alone radiation processes, due to an even bigger problem of scale.
And even when we examine ecosystems, we find that the small,simple organisms: like, bacteria, grass, and insects often tend to outlast the big, complicated ones (dodos, dinosaurs, and sabre tooth tigers).
K.I.S.S. is a good principle.
--
AC
| [reply] |
Re: Random quotes in the top left corner
by tilly (Archbishop) on Apr 27, 2005 at 02:51 UTC
|
Allow me to confirm that the loose coupling comment is about modularity. Two pieces of code are tightly coupled if there are complex interconnections between them. They are loosely coupled if they interact through well-defined interfaces that expose very little of the internals.
A large system built of loosely coupled pieces is generally going to be much more reliable, maintainable, etc than one which is built in a tightly coupled fashion. Therefore loose coupling is generally a good thing. Code Complete has lots more to say on this topic. | [reply] |
|
Exactly. After all, to make minor changes in tightly coupled systems, one often has to redesign much of it to get it all to work together again after that apparently minor change is made.
I'm even of the opinion that the performance benefits of tight coupling are mostly imaginary due to unforseen indirect consequences of tight coupling in large projects; when things need to be altered during development, sloppier fixes are encouraged by the difficulties created by tight coupling.
Of course, I'm far from the foremost expert in code modularity, and could well be out of my depth here.
print substr("Just another Perl hacker", 0, -2); |
|
- apotheon
CopyWrite Chad Perrin |
| [reply] |
|
I think that your conclusion, as appealing as it may be, is wrong.
The time when tighter coupling makes sense is when you are pushing the frontier of what is possible. In that situation attempting to enforce loose coupling pushes you to choose a way of modularizing before you understand the problem space well enough to pick a good modularization. Maintaining it also prevents you from using certain optimizations that you might come up with after you create your design.
This does not mean that people who are trying to accomplish the novel have free license to throw out the rule-book. To the contrary they are unlikely to successfully push those limits unless they try hard to make the complexities that they will encounter manageable. However they will also need to selectively violate normal principles just to make what they want to do possible.
However history shows that, when technology catches up to what they were trying to do, the people who created the integrated technology generally lose in the long run to latecomers with more modular technologies. Does this mean that they did something silly? Not at all! History suggests two other things as well. The first is that the recognition of the right way to modularize the problem is often only possible after someone has solved it badly, first. The second is that there is a lot of money to be made by being the first to be able to do something that people want to do.
For more on this, I highly recommend The Innovator's Solution. Be warned, it is a management book and not a technology book per se. However I think that what it has to say about which technologies are likely to replace others is useful for people who work with technology.
| [reply] |
|
|
|
Re: Random quotes in the top left corner
by Fletch (Bishop) on Apr 26, 2005 at 14:47 UTC
|
Here's a great aphorism: "If brute force fails, then you haven't used enough"... I'm not so sure of what to think of this :-)
Or there's also "If it jams, force it; if it breaks, you needed a new one anyhow."
| [reply] |
|
It also reminded me of something someone posted on slashdot recently:
"XML is like violence, if it doesn't solve your problem, just use more."
Strangely, the first thing this made me think about was regular expressions.
| [reply] |
|
You should thank Kuro5hin, as I shamelessly stole it off someone (forget who) from that site.
TBSDY
| [reply] |
Re: Random quotes in the top left corner
by merlyn (Sage) on Apr 26, 2005 at 14:40 UTC
|
| [reply] |
|
I keep forgetting about that.
/me so sorry O:-)
| [reply] |
Re: Random quotes in the top left corner
by prasadbabu (Prior) on Apr 26, 2005 at 14:46 UTC
|
Be Consistent!
Am i right?
I missed one :-) On purpose :-)
Purpose: my opinion
use strict; (be consistent, follow it strictly)
ummm... but very difficult.
| [reply] |
Re: Random quotes in the top left corner
by ktross (Deacon) on Apr 26, 2005 at 14:47 UTC
|
I can think of one that you missed, but I can't figure out why its signifigant, unless you think its ommission is ironic or something.
| [reply] |
Re: Random quotes in the top left corner
by theorbtwo (Prior) on Apr 26, 2005 at 15:19 UTC
|
Oh, pmdevs: patches welcome.
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply] |
|
|