When you write a regex for something for the first time, you can't get it right. When you write it for the tenth time, you get it almost right at the first try; and when you write it for the hundredth time, you get it right without even thinking.

Besides programming at the university for my thesis and for money on my side jobs, I also registered at sites like Rosalind.info or HackerRank and programmed for fun in my spare time.

I was lucky to meet several people that were far better than me, and I learned a lot from them. And I'm still learning.

Good luck!

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

If I may also add to my previous questions:
What do you respond to people that tell you " Ah Perl is so much deprecated nowadays, you MUST program in Python instead!!"
Would you advise someone to be expert in Perl or average in both Perl and Python for example?
The way I see it, I would definitely feel satisfied with myself if I could become a very good Perl programmer, instead of putting this effort into learning another, quite similar programming language.

If someone were to say you must write code in X (for any X), then I would immediately suspect them of not understanding computers.

That's like saying shoes are deprecated, you must commute to work using only a Tesla. Which specific language you use is less important than having the logic skills and knowledge that underlie everything.

For the car analogy, your language of choice can range from a pair of shoes to a bike, car, or stunt plane. They're all more and less useful in different situations, but can usually get you from point A to point B without excessive fuss. Logic and at least knowing of the existence of algorithms you can look up are like a sense of direction and the skill to read a map (and even the basic wisdom to keep control of your vehicle instead of watching a movie while the cruise control is set)

So, the analogy was fun and got away a bit, but IMO, the important point is less what language you know, but the breadth of math you know enough of to look up, and the logical patterns of thought to allow you to map your task into a series of solved problems.

Does that simplify down to "get a CS background"? Perhaps, but just from being around here for so long, it sounds like you've soaked up a some of it by osmosis.

As someone who dropped out of high school (did go back and graduate though) and never went to college or university, and who now deciphers large corporation and government business processes and converts them into code logic (in Python), I'd say if you like Perl, go with Perl.

Python is a decent language, but to be honest, it feels more 'childish' in many ways. Sure, you can get a coding job in Python anywhere, with the 5 million other out-of-school kids. You can do the same with any hot language. Perl, however, while it is in decline, is becoming very lucrative (because of corporations wanting to keep their legacy codebase running).

Again... learn what you feel good with. Perl is a very good start, as if you know Perl, you can transition reasonably well into other languages (I want to say C/C++, Java and, well, Python). I think I find jQuery/Javascript to be easier to grasp as well with my Perl experience.

Do what feels right. Python is easy to grasp with enough Perl experience (you'll need to understand Object Oriented Programming), but looking back, I don't think it could be the other way around as easily.

I also find the Perl community to be much kinder to one another. Sure, there are fights and bitching, but it's handled appropriately for the most part, as many Perl hackers have been around for a very long time.

There's also the CPAN. I don't believe there's another language that exists that has such a cohesive, consolidated grouping of all the published modules in a single, easy to access location.

I am self-taught ..., so I was not taught programming in a "proper" way.

My first advice is stop worrying about "Computer Science" and "proper way". If you have the desire -- you are asking -- and some level of aptitude -- you'll probably know if you do -- and the time to program regularly, you're already more 3/4s of the way there.

Some of the best programmers I've encountered are entirely self-taught, and some (actually most) of the worst had CS degrees. That's not to say that CS courses always produce bad programmers by any stretch of the imagination; just that most self-taught programmers only progress because they have some aptitude, otherwise they fall by the wayside; the same is not true for CS grads who memorise enough stuff to pass exams without ever having acquired any level of intuition or aptitude.

As for the difference between practice and experience; it's all down to whether what you are doing results in something useful. Purely academic practice exercises are rarely complex enough to produce anything useful; so they tend to require the use of well-known algorithms, in isolation, and in a clearly identifiable and straight forward way. The problem comes when trying to recognise the use of those algorithms when they are a small part of a larger project and need to integrate with the other parts of the code base.

The best thing about this place is that it that it provides a ready supply -- less so these days than previously, but so far, still enough to keep me coming back -- of interesting and diverse problems to force you to think about things in different ways. And there are still enough people posting replies to to get several different takes on possible solutions. And if you come up with something, it just might do someone else a good turn too.

despite my high level here at perlmonks I just pass the basic usage of Perl. I've studied medieval history and never gone beyond trigonometry in math. Now Perl is my best friend for my sysadmin job. I've a little codebase running since 2004 (?) that speed up a lot my daily work and monitoring tasks. My code base is objectively horrible and given to me the possibilty to rewrite it i'd do in a very different way.. But my little codebase get the job done.

During these years Perl has become my only sane interaction with the machine: i've produced many standalone applications i'm proud of and a lot of one-shot little programs to get the life simpler.

Another personal example: i get interested with the Pascal's triangle (well i call it Tartaglia's triangle..). I wrote a little piece of code to produce the triangle, i read other intersting solutions and i'v also understood many but i've not learn how to get the rigth intuition to produce the triangle with a oneliner like:

perl -e "while((@_=(1,map$_[$_-1]+$_[$_],1..@_))<=$ARGV[0]){print qq(@_\n)}"

By the other hand my lack of math geniality has not stopped me to produce a full program i'm still proud of: TkTartaglia's triangle. Doing so i had fun and I lern a lot about how using different tools.

That's the point: Perl is a tool.

Programming Perl can be a tecnique (τέχνη is the best word), a craft or even an art.

What you can do, as i do, is to practice the tool and learn from others to use the tool in the appropriate way, possibly in the best way. Perlmonks.org as you already know is a wonderful place to learn how others approach a problem.

For example I never done a multithread program, but i followed the matter over the years (my restyled homenode has bunch of links about..) and know i know what tecniques i have to follow, what code i can borrow, which pattern i must follow in the case i want to do paralell programming.

That said intuition cannot be teach.

You can practice appropriate methods to get particular jobs done, learn which idioms are preferred and why and your knoweledge baggage will become richer and richer, adding possibilities to your own intuitions

L*

An accountant writes:

Much the same way as one learns anything else. Read, practice, discuss. The thing Perl has above any other language in my experience is its community. I don't know (& can't be bothered to Google) if there's a Perl Mongers group in Athens, but if there isn't, try founding one. You may not be able to help your fellow mongers technically, but if you put some work into the organisation, it will be clear that you are not a freeloader and will get lots of help. At least, that was my experience in another country in the days before Perl was invented.

You know how to research things and evaluate sources (or bloody well ought to if you have or are working to a PhD - yes, I have one of those too). Apply the same techniques to computing sources. You found this site. What do you think of it? My evaluation is that it's very good on technical matters, pretty amusing when it tries to be (polls & some of the CB, for example) and occasionally allows itself to become a forum for flame wars. I try to learn from the first, laugh at the second and ignore (possibly downvoting) the third. But it might not suit you. There are other sites, some language specific, some (Stack Overflow is possibly the biggest) polyglot.

Then write. You have your BioPerl needs for your PhD, but if that stops providing you with a cause to write code, find something else that interests you and write code for it. Write documentation, too. It's fine to document someone else's work. I am convinced that no-one (certainly including me) documents their own code well. So take some of the code you've had trouble understanding and write better docs for it and publish them. If you want something to start on where you can be certain you won't be flamed, my one CPAN module is http://search.cpan.org/~davies/XML-Lenient/lib/XML/Lenient.pm, and you can be as brutal about those docs as you like without causing offence.

As well as writing, talk. Attend things like the London Perl Workshop (London Perl Workshop 2016). When you feel you have something to say, say it, even if that's just giving a 5 minute "lightning" talk.

Read and listen to the feedback you get from these activities, but with your PhD evaluator switched on. Some of the feedback will be nonsense and some of it personal taste.

As someone said, I think quoted in Peters & Waterman's "In search of excellence", "the first hundred years are the hardest".

I can't end without a reference to "teach yourself programming in 10 years": http://norvig.com/21-days.html.

Regards,

John Davies

How did you become good in programming? I mean, if I take myself for example, I am self-taught (I come from Biology background and need to code for my Phd in bioinformatics), so I was not taught programming in a "proper" way.

Yeah .. my only two computer science courses were in FORTRAN (WATFIV/S, specifically) and COBOL during the '76/'77 academic year at Waterloo. After that it was whatever I learned whatever I needed to get the job done, with an occasional visit to K&R's excellent Guide to C Programming, and then learning on the job.

My degree in engineering helps -- learn whatever you need to, in order to get the job done -- that rule has served me well throughout my career.

• Perl? Didn't exist when I graduated in 1982. I picked it up in the late 90's when I used awk for a while, loved it, but found it limiting.
• Linux? Had a couple of false starts setting up SuSE Linux in the late 90's, and just didn't know enough to keep going.
• SQL? Knew enough in the late 90's to land a contract where I was learning it on the job. It's based on set theory, but then it gets complicated. And there are different dialects.

Really, it comes down to practice. I applied for a remote job about a year ago, and took the full week to do their 'Write us some code' example. Yes, I was out of practice. I plan to revisit that exercise to see how I could do it better.

Finally, like anything else, you need to be continually learning. I got an idea for a module yesterday, and went home to spend a few hours bashing up a prototype, which led me to a dark corner of Perl I'd never seen before (Symbol and qualify_to_ref). Fascinating. You need to always be stretching yourself.

PS Welcome to the Monastery! Becoming a member here has helped my Perl immensely, and I believe I've helped a few others.

Many thanks to all of you who posted here, I am now more enthusiastic about "sticking" to Perl for some more time, since, for me at least, it "gets the job done" and very efficiently!

Reading and participating in this forum has contributed greatly to what skill I have. I learned my first programming language by looking at code and wondering, what does that do? I have learned a great deal here in a very similar way.

The examples here are superior to any textbook: for the most part these are questions about real coding situations, and the solutions come from a cadre whose depth of experience you couldn't afford to hire.

This sort of question comes up regularly, so I keep a list of similar questions.

Like many of the other replies my main advice is to practice. Unlike some of the other replies I think there can be great advantage into dipping into a University level Computer Science course. If you have the opportunity of attending a few selected papers that deal with subjects like data structures and algorithms you can pick up a few tools that you will use directly or for guidance often. It doesn't matter that the course uses a language other than Perl, most of that information translates well across languages and Perl is pretty good a being what you need it to be.

A lot of those tools and techniques you can pick up just by looking at the vast quantity of code around this site and by asking questions about it. But you will miss the overarching principles that let you use techniques in many different ways. A good computer science course will teach you the philosophy as well as the practice.

In 30+/-years at $work(EE doing realtime software), I found that if I got the data structures correct, the code usually flowed. If not, things got messy fast. Also, read all the code you can from acknowledged Perl experts(for me in the early days this was reading the Data General RDOS and AOS operating system code).

Domain knowledge is as important as Perl knowledge(You want to control a power system give me a call, develop a website not your man).

James

There's never enough time to do it right, but always enough time to do it over...

> I found that if I got the data structures correct, the code usually flowed. If not, things got messy fast.

This reminds me of some famous quotes from Fred Brooks, Rob Pike, Eric S. Raymond, and Linus Torvalds:

The programmer at wit's end for lack of space can often do best by disentangling himself from his code, rearing back, and contemplating his data. Representation is the essence of programming.

-- from The Mythical Man Month by Fred Brooks

Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

-- Rob Pike

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.

-- Eric S. Raymond

I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

-- Linus Torvalds

A few classic performance quotes:

Don't diddle code to make it faster -- find a better algorithm.

-- The Elements of Programming Style

Don’t Optimize Code -- Benchmark It.

-- from Ten Essential Development Practices by Damian Conway

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

-- Donald Knuth

Perl Data Structure References

• perldsc - Perl Data Structures Cookbook
• perlreftut - Perl References Tutorial
• perlref - Perl References
• perldata - Perl Data Types
• perllol - Arrays of arrays in Perl
• perlobj - Perl objects
• Storable - Persistence for Perl Data Structures
• YAML - YAML Ain't Markup Language
• JSON - JSON (JavaScript Object Notation) encoder/decoder
• JSON::MaybeXS - Use Cpanel::JSON::XS with a fallback to JSON::XS and JSON::PP
• TOML - Parser for Tom's Obvious, Minimal Language
• TOML Spec (github)
• Sereal - Fast, compact, powerful binary (de-)serialization
• SerealX::Store - Sereal based persistence for Perl data structures
• Config::Any - Load configuration from different file formats, transparently
• Config::Tiny - Read/Write .ini style files with as little code as possible
• Config::INI - simple .ini-file format
• SQLite (wikipedia)
• DBI and one of the many DBD::* modules
• DBD::SQLite
• feature - note that Perl 5.34+ allows you to disable old Perl 4 multidimensional array emulation via the 'multidimensional' feature
• perl 5.36 delta - ... and that use v5.36; disables multidimensional array emulation
• Data::Dumper - stringified perl data structures, suitable for both printing and eval
• Data::Dump - Pretty printing of data structures
• App::FatPacker
• Re: How to make distribution for simple script with CPAN dependencies? by 1nickt (2024)
• Re: access object values by kcott (2023) - displaying/debugging Perl data structures and references
• Re: Why can't some of my modules do log output to a file? by haukex (2022) - example of turning on Data::Dumper's Useqq option
• Memory efficient way to deal with really large arrays? by sectokia (2020)
• Re: Memory efficient way to deal with really large arrays? by Tux (2020) - Perl benchmarked faster than every database tried (SQLite, Pg, mysql, MariaDB)
• Multidimensional arrays by Bod (2023) - asking for advice on which Perl data structure to use
• Re^2: A good way to input data into a script w/o an SQL database by ObiPanda (2023) - asking about code vs data in a script
• How can I send a "transposed slice" of an array of hashes and by extension an array of arrays, or hash of hashes to a subroutine by ObiPanda (2023) - ... continued
• Storable for user preferences by Bod (2023)
• Re: Storable for user preferences by afoken (2023)
• Modules as configuration files by Discipulus (2015)
• Preserve the order in JSON by user786 (2015)

Build and Test Automation References

• Perl CPAN test metadata by me (2010)
• Data-driven Programming: fun with Perl, JSON, YAML, XML... by me (2015)

Database References

• Database References
• EAV (wikipedia)

See Also

• List Utils References

Updated: added "Perl Data Structure References" section. Added a few classic performance quotes.

Another advantage of a formal course is breadth of coverage. Learning only what you need to know at any given moment can provide a nice deep dive into that particular topic with the motivation that comes from being able to immediately apply it. For example, I know next to nothing about frameworks and CGI, because I've never had to learn it. I'd bet most Perl courses would cover them because that's a large part of what Perl is used for. Just not by me.

But God demonstrates His own love toward us, in that while we were yet sinners, Christ died for us. Romans 5:8 (NASB)

---