Learning Perl is easy, yes.. it is easy...

After posting my last meditation (here) I have realised
one important thing... programming is not, and will not
ever be language bound... the problem is in ...

(drum rolls, etc)

Data analysis...

I am willing to pose the following: ANYBODY can program,
the problem lies in analysing the data you are presented with.

ANYTHING can be done, as long as you know what you want to do...

You can learn Perl, you can learn any language for as much
as I care, BUT ... you will never be able to `program`
(a verb that I never really understood)
UNLESS you are able to bring your huge program back to
loads (and yes, it can be loads, and loads) of easy
problems to solve ...

Once you are be able to solve the problem you have, in the
core of the language you know (ANY Language, I am sure that
I could write ANY program I have ever posed to perlmonks
in assember (ANY processor, just like loads of you), just
give me the specs...) ... THEN you are `programming` ...
But yet... you are not a saint, you are just someone who
knows how to treat data, change data, interpret data...
Analyse data...

There! ... I pose to you... there are no `Great`programmers`,
just great data analysts...

I rest my case .. but ... I believe in what I just said...
Closing remark: TIMTOWTDI

p.s. I have had some beers.. it REALLY is the point I`m
stating here, not the spelling/language... *grin* ... It`s
almost data analysis :)


print "profeth still\n" if /bird|devil/;

Replies are listed 'Best First'.
Re: do you know Perl ?, or do you know ?
by cacharbe (Curate) on Mar 27, 2002 at 20:26 UTC
    I would take this a step further and suggest that it is all algorithm analysis. Not so much analyzing the data, but knowing what to do with it - Knowing how to solve the problem.

    Take, for instance, a recent example from my "SpareTime" file. I watched some family members play a game of boggle and thought, "Hmmm, I bet I could write code to solve an arbitrary sized board, and do it using both recursion and without."

    The hardest part was analyzing how you actually solve it (match words of minimum length to a known dictionary(s) given certain path and adjacency restrictions). Once I realized how it was done, the code came out in an afternoon. It was really a matter of analysis. The data (in this case a 6x6 board of random letters) was not as important as the structure and method.

    HOWEVER, if I didn't know how to use lists, recursion and references, didn't understand how to streamline my code and optimize, I'm pretty sure some of my first 8x8 attempts would still be running on one of my servers somewhere.

    I'm going to have to agree with Steve Lohr on this one, when he observed that, apparently, knowing how to code leads one to better problem solving, and vice-versa. They are partners in this game. I don't really think one goes without the other. Strong problem solvers make strong coders, and weak, weak IMHO. I think a certain level of problem solving and technique can be learned, but I think it's one of those quirks, either you have it or you don't.

    "There are a certain percentage of undergraduates - perhaps two percent or so - who have the mental quirks that make them good at computer programming. They are good, and it just flows out of themů.The two percent are the only ones who are really going to make these machines do amazing things. I wish it weren't so, but that's the way it has always been."
    Donald Knuth - Stanford University</right>


Re: do you know Perl ?, or do you know ?
by snafu (Chaplain) on Mar 27, 2002 at 20:08 UTC
    I like your thoughts and agree with a good portion of your comments. However, I wonder about this statement:

    quote: <quote>There! I pose to you; there are no Great `programmers`, just great data analysts</quote>

    Just because a person can analyze does not mean that person can program efficiently. To me, a great programmer is one who can take what s/he analyzes, flows it efficiently, and codes it following all of the rules that good coders use ie K.I.S.S., readability, efficiency, etc.

    So, in my opinion there is a very big difference between a "programmer" and a "great programmer".

    If we were arguing symantecs I could do the whole definition thing of "analyst" vs "programmer" but that would be pointless as it is very clear where you are going with this topic within the realms of the job description, if you will, of a programmer.

    So, yes, analyzing is most important but a programmer is one who can code what s/he analyzes and a great programmer is one who does it as I stated above.

    _ _ _ _ _ _ _ _ _ _
    - Jim
    Insert clever comment here...

      This reminds me of the quote from Kent Beck (who in anyone's book is a great programmer): "I'm not a great programmer, I'm just a good programmer with great habits."

      M-x auto-bs-mode

Re: do you know Perl ?, or do you know ?
by dreadpiratepeter (Priest) on Mar 27, 2002 at 20:51 UTC
    Data analysis, I think, implies the wrong connotation. I'd prefer to use the term problem solving. Programming is a series of problem solving challenges. Languages and algorithms are just tools that the programmer uses to problem solve.
    A book can teach you about lists and trees and hashes, but only experience will teach you what are the appropriate tools to use for a given problem. Perl has the advantage and disadvantage of being a very prowerful, flexible and robust tool. It can be used well or very badly. I've seen perl code that will turn you white. But then again I've seen perl code so beautiful it wil make you cry.
    I'm usually the fastest coder and best architect on a job. Why? Am I smarter than the rest of the coders? Probably not. But I have been coding for over 20 years now. More importantly, I have been coding a lot of different things for those years; databases, GUIs, web pages, compilers, palm, reporting, etc. The reason I code faster than my peers is that I have a really big toolkit and the knowledge to use it. Chance are that I've solved the problem, or a similar problem, before. Probably more than once.
    Solving the same problem multiple times allows you to refine your approach to it; to learn from you past mistakes. The tenth shopping cart app comes out a lot better and cleaner than the first.
    Programming is a craft. Not art, not science. If it were art than the results could never be objectively determined. If it were science we would have written a program to do it long ago. It is more like cabinetry or blacksmithing. It requires the discipline and rigor of the scientist and the inspiration and passion of the artist. Qute frankly, if you don't love programming, love it enough that you would do it without pay, then you will probably never be a great coder. But, if you are unwilling to apply structure and rigor and scientific method to your coding then you will never be a great coder either.
    Well, I am good at rambling on and bad at concluding so I will just shut up now.

    "I am Jack's utter lack of disbelief"
Re: do you know Perl ?, or do you know ?
by derby (Abbot) on Mar 27, 2002 at 20:26 UTC

    ++. All problem solving rest on analysis, all analysis rests on logic. The differences are only vocabulary, syntax and experience.


    update: and to quote ESR who's quoting Fred Brooks

    Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.

    That fits nicely with ChOas notion that data analysis is key.

      nice sum up!
Re: do you know Perl ?, or do you know ?
by mrbbking (Hermit) on Mar 27, 2002 at 21:43 UTC
    I've seen this described as the difference between a Programmer and a Developer.

    The Developer can take the real world problem, break it down into pieces (steps, objects, whatever...) and then build those pieces.

    The Programmer can write code that executes according to instructions to complete a well-defined task.

    The Programmer builds the pieces. The Developer determines which pieces should be built.

    Sun is one place that buys into this distinction. At Sun, getting a 'Sun Certified Java Programmer' certification is (can be) a step on the road to getting a 'Sun Certified Java Developer'.

Re: do you know Perl ?, or do you know ?
by sevensven (Pilgrim) on Mar 27, 2002 at 22:18 UTC

    ANYTHING can be done, as long as you know what you want to do..

    Those are great news. Then I suppose you can write a perl program that looks at the source of any other given perl program and tells if that program ever ends ?

    If you do, don't bother telling me that, just go cash your Turing award and your Hilbert and Godel Honor Badges.

    -- sevensven or nana korobi, ya oki
Re: do you know Perl ?, or do you know ?
by tmiklas (Hermit) on Mar 27, 2002 at 20:52 UTC
    True, true...

    IMHO you can always improve your coding skills (coding = writing workin code), but then you are just the programmer.

    IMHO *great programmer* is someone who knows exactly what s/he want to do and understands the way the solution follows... and as a last virtue i'd mention his/her coding skills.
    As for me it's some kind of genius - to trully understand the WHOLE big problem, split it into small tasks and write an efficient code, that makes me feel the magic when i look at it :-)

    Greetz, Tom.
Re: do you know Perl ?, or do you know ?
by cjf (Parson) on Mar 28, 2002 at 05:27 UTC
    I am willing to pose the following: ANYBODY can program, the problem lies in analysing the data you are presented with.

    I'll agree with you on the first point, pretty much anybody can learn to program. Too often programmers try to make what their doing look way more complex than it is. This is seen in just about every other profession as well, and doesn't do any good in those professions either. When properly broken down into their smaller components, all tasks are quite simple.

    As for the problem being in analyzing the data, well, pretty much anyone can do that too. As with programming, some people are better than others due to more experience, higher natural ability, being more interested in it, and so on. Analyzing data is part of programming, and if there are great data analysts, then there are also great programmers.

Re: do you know Perl ?, or do you know ?
by gav^ (Curate) on Mar 27, 2002 at 21:34 UTC
    Learning something is easy. Being good at something is another matter.


Re: do you know Perl ?, or do you know ?
by Silicon Cactus (Scribe) on Mar 27, 2002 at 20:11 UTC

    I would have to disagree. There are indeed great programmers. Many are mathematicians or logicians. They discover new algorythms. I would say they are rather great programmers.

      I never said there was no such thing as great programmers. I just said that there is a difference between great programmers and just programmers. And just because a person is a great mathematician or a great logician does *not* mean they are great programmers. I don't think you or anyone has actually seen every mathematician's or every logician's or even every professor's code so I'd say that for you to say that every scholar is a great programmer is premature. You simply cannot back that with facts.

      My point was that there *is* indeed a such thing as a person being a great programmer. I would also say that I think a programmer is both an analyst AND a coder but not all analysts are programmers in the coding sense.

      _ _ _ _ _ _ _ _ _ _
      - Jim
      Insert clever comment here...

        I think that the order of the posts confused you Jim. My post was in response to ChOas, please check the thread again? :)
Re: do you know Perl ?, or do you know ?
by Biker (Priest) on Mar 27, 2002 at 20:50 UTC

    Which is why one shouldn't study Object Oriented Programming until one have studied Object Oriented Design.

    A good Object Oriented Programmer masters the language he's using to implement the design. But a programmer who cannot start with an existing problem and apply a good design before applying an ever so sofisticated program code is (IMNSHO) only half a programmer.

    Everything went worng, just as foreseen.