|
in reply to Worst thing you ever made with Perl
You hadn't learned about strict back then and did not know why symbolic
references are evil. Or even that they are called symbolic references.
It is using lots of globals, maybe even shared throughout multiple
modules. Because you didn't realise the importance of style, not
everything is indented correctly and the style is inconsistent at
best. No external database is used, everything is serialized and stored
as strings. If there was a database at all, then it used a table per
record because you didn't bother to learn about databases.
Sorry to disappoint you, but I never did program that way. Not in Perl,
nor in any other language. When I was taught programming, more than 10
years before I learned Perl, the importance of lexical variables, style,
indentation, etc, was stressed from day 1. I had programmed in Perl for
quite a while before I even considered using symbolic references. Or local
for that matter. That's why I'm always baffled if newbies happily use,
or want to use, symbolic references. Most mainstream languages don't
use them, so where do they get it from? It's buried deep enough in the
documentation. Are there beginners courses that promote their use? I
certainly never discussed symbolic references or 'local' in beginners
courses that I taught.
Abigail
|
Re: Re: Worst thing you ever made with Perl
by Limbic~Region (Chancellor) on Sep 28, 2003 at 16:47 UTC
|
Abigail,
I think by describing your personal experience, you have shed light on the answer. You had formal training in "proper" coding technique and style. Personally, I was self-taught BASIC. I used goto at every point I realized my design was flawed and it would require me re-working to make it right. My variable names started with $a, $b, .. $z where I would then start with $aa, $ab (if I was consistent at all). I would write a map of what the variables were on a sheet of paper and promptly throw it away as soon as the program was running.
Sure the docs are there. Sure there are plenty of forums that will direct you on the right path to go. The vast majority of people are not interested in why or how. They want instant gratification. "I don't care if it isn't the right way to do it - it works".
Some people never drop this mentality. They stay perpetual newbies. Some people change. I hope that I am one of those people - though I still have never had any formal training in proper "programming".
Cheers - L~R
| [reply] |
Re: Re: Worst thing you ever made with Perl
by castaway (Parson) on Sep 28, 2003 at 16:58 UTC
|
I have to agree with Abigail-II - I started out teaching myself, from example BASIC programs on the Acorn Electron (out of user magazines), but I don't think I coded too badly in spite of that.. Later I learned formally and didnt need to change much of my style that I remember. I should find some of my early BASIC to try and prove/disprove that :)
Anyway, only started Perl mid-2002, and had been programming a while before that (must be 15 yrs now), so my original perl wasn't that bad in terms of indenting, modularizing etc. (And I still don't use strict, but I don't consider that a bad thing :)
*wonders where those early BASIC tapes might be.. good job the ole Electorn still works.. :)*
C. | [reply] |
Re: Re: Worst thing you ever made with Perl
by trs80 (Priest) on Sep 28, 2003 at 18:28 UTC
|
I am glad you are strict enough with yourself to follow your formal training. However for the many people out there I imagine it is hard to stick with The Right Way(tm) to do it when faced with time-line pressures or simply laziness. While the benefits of doing it The Right Way(tm) far out weigh the initial time invested that doesn't make it any easier to stick to it. Adopting a mind set of
"How will this effect me X days from now?"
"When I revisit this code in X (days|weeks|years) will I remember that I was thinking?"
"Will someone else find this to be The Right Way(tm) and if so why?"
then we can help ourselves to improve. For those of us that aren't blessed with strictness we can only hope that over time we stay commited to refining our process until our actions follow The Right Way(tm) without being forced.
| [reply] |
|
|
However for the many people out there I imagine it is hard to stick with The Right Way(tm) to do it when faced with time-line pressures or simply laziness. While the benefits of doing it The Right Way(tm) far out weigh the initial time invested that doesn't make it any easier to stick to it.
I fail to see how deviating from "the right way" would mean
you program faster. Does it really save time not to do proper indentation? (If you set ':set ai' in vi, most of
the work is done for you anyway). Do you save significant
time not using properly scoped variables? Saving time using
symbolic references is something I find hard to believe.
I'm not taking any future consideration into account, I'm
talking about programming right now, with a 5 pm deadline.
Abigail
| [reply] |
|
|
Good practices that take more time:
- Writing tests. Either after the code, or doing TDD.
- Proper modularization of code. It's faster to just throw together procedural code than create a new module.
- Documentation. Everything from proper comments to user docs takes time to write.
- Quality assurance of third-party modules. Grabbing something off cpan and assuming it works is a lot faster (short-term) than testing it.
Those are what immediately come to mind. There are plenty more. As for your points: indentation takes no time so no excuses there but many times global variables can speed things up development (think instead of passing args and returning values from subs) this is however a very tricky process and rarely (but still sometimes) the best approach.
| [reply] |
|
|
The Right Way(tm) elements are far more then just indenting , improperly scoped varibales, etc.
Elements central to the ideas behind my original point are:
- The initial time it takes to learn what The Right Way(tm) is
- Remembering and applying The Right Way(tm)
- Fully understanding concepts and the ramifications of not doing it The Right Way(tm), before you move the knowledge from the mind (private space) to the physical (public space)
This goes beyond programming and extends into any discipline. However, the shared realtiy of life is that the above does not work because if we all remained inactive until we comprehended then we would remain inactive. We must crawl, walk, run.
| [reply] |
Re: Re: Worst thing you ever made with Perl
by Juerd (Abbot) on Sep 28, 2003 at 17:02 UTC
|
Are there beginners courses that promote their use?
Yes.
Anyway, I guess I didn't realise some people got good training :)
Juerd
# { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
| [reply] |
|
|
