2 ms·
Good thought - the thing is, once it's over a certain size, I don't think that it continues with the same ratio. Once it's beyond the difference between a one-
by deckiedan 13y ago
Good thought - the thing is, once it's over a certain size, I don't think that it continues with the same ratio.
Once it's beyond the difference between a one-line regexp/fork-to-shell/reverese combo type thing that perl is so great at, most of the code becomes your actual business logic, and logic code I feel ends up being similar lengths in perl, ruby, python, and other similar languages.
Python has more boilerplate to get at regexps, or calling external programs and doing stuff with the output, say - but it's explicit. Perl has a lot more built in, and hidden behind non-alpha syntax.
Both are great languages, and both have their place. I much prefer python, but also find perl a very versatile and useful tool.
- Mithaldu 13y agoDue to Perl lending itself to easily creating DSLs, i often find it to be much more concise even with bigger programs, when porting from python to Perl. (And then i end up making the difference in line count by actually writing documentation.)
- kamaal 13y ago>>Once it's beyond the difference between a one-line regexp/fork-to-shell/reverese combo type thing that perl is so great at That's just the very start, the very beginning of what Perl is good at. Read this book called "Higher Order Perl" by Mark Jason Dominus. You will see why 60000 line Python program actually becomes a 3000 line Perl program. >>most of the code becomes your actual business logic, and logic code I feel ends up being similar lengths No, You must take a serious look at Perl. Please read the book I mentioned. Some languages do make it very easy to write short, powerful, clear succinct code. More importantly you need to work in situations where Perl can show its magic. I've written scripts in a week alone which were easily 6 month Java projects.
- gjm11 13y ago"Higher Order Perl" is a very good book. I do not believe that any substantial fraction of the things it shows would take anywhere near 20x as many lines of code in Python as in Perl; certainly none of the examples I just looked at would. Could you please (1) give a couple of concrete examples that don't involve regular expressions (yes, Perl is very good with hairy REs; no, very few 3000 line programs consist mostly of REs) and (2) indicate your level of expertise in Python? Thanks!
- deleted 13y ago[deleted]
- Mithaldu 13y agoNot a 20x example, but file handling is one that stems from the implementation of Python's garbage collection. Python does not guarantee garbage collection at scope end. Thus you need code like this: def controlled_execution(callback): set things up try: do something finally: tear things down Or alternatively, slightly obtuse incantations like this: class controlled_execution: def __enter__(self): set things up return thing def __exit__(self, type, value, traceback): tear things down with controlled_execution() as thing: some code Perl makes this much easier by guaranteeing garbage collection of objects that have left scope, even if the scope is left via die() and caught with eval(). If an object leaves scope, its DESTROY method is called immediately, and after that the object is dismantled. Thus objects can carry their teardown around in their class definition (which can be easily modified by overriding or wrapping the method in a new class), and user's need to do nothing whatsoever to ensure the teardown being executed. Thus, file opening and using code for example can look as simple as this and contain zero gotchas and no "you need to understand this to actually know what it does": sub do_a_thing { my $file = io->file(".bashrc"); print $file->slurp; }
- lloeki 13y agoHonest questions since my perl-fu is weak. Since python's file class already implements the with protocol, I don't see how sub do_a_thing { my $file = io->file(".bashrc"); print $file->slurp; } is different from def do_a_thing: with open(".bashrc") as f: print(f.read()) Conversely I don't see how > Thus objects can carry their teardown around in their class definition (which can be easily modified by overriding or wrapping the method in a new class) is any different from implementing the with protocol in the class, which is strictly speaking "carry their teardown around in their class definition"
- Mithaldu 13y ago
- deckiedan 13y agoThanks for the heads up about HOP, I'll certainly try to read it. It's been a few years since I did any serious perl. :-)