Hacker News new | ask | show | jobs
by stormcrowsx 3558 days ago
Really not a property of Go. Any codebase can be hard to follow if the designer wants it to be. It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code.
1 comments

> It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code.

That's one way to look at it. The other is that they embedded more syntax which makes the learning curve longer, but yields more more efficient writing and reading of code once you've fully internalized that syntax. The big mistake, IMO, was that they also made the language easily usable to get something done before you've fully internalized those rules, which leads to subtly wrong or weird programs that just work most of the time.

Perl is fundamentally different than most languages in how it uses context, but you can get away with not really understanding that at all by just learning a few rules-of-thumb. This, predictably, results in frustration in the writer, as they run up against what look like rough edges and weird idiosyncrasies in the language but are often just places where they've never actually learned how Perl really works.

That's not to say Perl doesn't have actual rough points and problems (what language doesn't after almost 30 years?), but contrary to popular belief, Perl is actually highly designed, and usually conforms to a few core principles (even it those principles are not what many other languages emphasize).

It's worth keeping in mind that Perl, like its predecessors sed and awk, was intended among other things to be useful and convenient as an embedded language in shell scripts.