The Path to Mastery (2000) | Hacker News Reader

The Path to Mastery (2000)

perlmonks.org

58 pointsbtilly5 comments

I like an article about mastery that doesn't talk exclusively about 10,000 hours. The idea of nailing a subject's fundamentals is import. Similar to the story, I did some of my best academic work in the subjects that I knew the least about because I had to question everything.

I found the same thing to apply in UNIX. The folks who opened all the doors and learned all the details (beyond what class asked) were the ones who could later write 2 or 3 line scripts to solve most any problem.

The discussion here is where the gold is.

interesting to see the tie in between good proofs and good programs. I've never done much with perl, but I've heard that one can achieve a very high degree of concision.

I would say that Perl is roughly on par with other scripting language in terms of how concise it is. The downside is that it is more idiosyncratic, the upside is that it has better libraries. Perl has been good to me, personally, but I'm not about to try to tell a Ruby or Python developer that they have an overwhelming need to switch.

However the advice about knowing your tools applies to proofs, programming, cooking, mechanical engineering...

I used to work a lot with Perl 5, maintaining a 20000 LOC program. Nowadays I work a lot with Ruby. Compared to Perl I much prefer Ruby. Ruby has most of Perl's powerful constructs but it's much easier to write maintainable software in Ruby. Perl allows me to do things about as quick as Ruby, but thanks to many language... features... your programs turn into a mess quickly until you're being very strict to yourself.

A few things in Perl that really don't help:

- Variables don't have to be declared and are global unless specified otherwise. You can 'use strict' to turn off this "feature".

- Strange syntax for working nested structures. Basically nested structures are a hack because Perl <= 4 didn't support them. Hashtables only support scalar values so to put an array in a hashtable you need to store a reference. Dereferencing has rather strange syntax if you're not used to it; even if you're used to it it's still easy to get confused. @{$foo{bar}->baz}...

- OOP feels like a hack because, as you guessed it, earlier Perl versions didn't support it. You have modules; this works as expected. Classes are implemented on top of modules: to instantiate an object, you make a hash, array or scalar value, and "bless" it with a package name, which is like assigning a type to the thing. The thing that was blessed is your instance, and you store your instance variables in it. You then return a reference to that thing and that is your object. The whole syntax is nuts.

- Even function arguments feel like a hack. That's because there is no syntax for them. Every function has an arguments array, called @_. That's not a smiley, that's the actual variable. To get your arguments, you have to extract them from @_, so every function would start off like: my ($arg1, $arg2, $arg3) = @_;

- Threads... oh you mean usable threads? Forget about it. Threads in Perl do not share state by default. You have to explicitly mark variables as 'shared'. If your app is well-architected (not relying a lot on global variables), this isn't much of a problem, but unfortunately Perl also copies all AST nodes upon thread creation. If you have a moderately sized program, like mine (eats 25 MB of RAM) then it 5 years ago it took 15 seconds to create a thread while Perl is making a copy of all the AST nodes. Yikes.

Perl works great as a sed replacement, but for anything larger than, say, 50 lines I would recommend Ruby over Perl. Like Perl, Ruby has builtin regex support.

Reply on news.ycombinator.com