4 ms·
Before i switched to Python as my general purpose language, i used to be a bit of a Perl fanatic. I've still to come across a language that lets you get your i
by 3amOpsGuy 14y ago
Before i switched to Python as my general purpose language, i used to be a bit of a Perl fanatic.
I've still to come across a language that lets you get your ideas down as quickly. It's full of fantastic time savers, e.g. the for(<>) construct and the format output functionality cover a bunch of common use cases in minimal keystrokes (let me pipe in some data, analyse it, then spit it out in a clean report).
It can hurt readability but for small one offs, it often doesn't matter.
- ryporter 14y agoI'm in a similar boat. I've largely switched to Python as my scripting language (except for one-liners), but I'll still defend Perl against those who dismiss it out of hand. After using it an Amazon, I've seen firsthand how productive one can be with the language; and, if you're careful (following, e.g., the guidelines in "Perl Best Practices" by Conway) it's very possible to write maintainable code as well.
- gvalkov 14y agoI hear you on the one-liners issue. Python is unhelpful when it gets to that - there are no -n, -p, -l switches or special variables like there are in Perl and Ruby. It's a shame really, since all the building blocks needed to implement a useful mode for writing one-liners are there. In fact, I have a work in progress module that tries to address this issue: https://github.com/gvalkov/python-oneliner https://github.com/gvalkov/python-oneliner
- slurgfest 14y agoThis is an interesting idea, but if you need an extremely terse DSL which doesn't look anything like Python and has to be learned anew, why not just use Perl directly? Maybe for environments where you can't install Perl?
- gvalkov 14y agoThanks. My approach is actually pretty minimal. Just a read-print-loop (-n, -p), a few local variables (equivalents of $_, $~, $. etc) and a shorthand import syntax to take away some of the verbosity. There are other projects, such as pyp[1], that are more ambitious, but put you through a learning process. By all means, everybody should use what they are comfortable with. Ruby and Perl allow you to write extremely terse and awesome one-liners, the likes of which will never be possible in Python. But if the first solution that pops into your head is a Python one, why not use that? [1] http://code.google.com/p/pyp/ http://code.google.com/p/pyp/
- dalke 14y agoHave you looked at APL or its derivatives like J and K? For certain types of work, and with experience, it's very terse and expressive.
- 3amOpsGuy 14y agoJ, now there's a language! The C source is written in a J like style: a wall of ascii punctuation interspersed with single char identifiers. It looks like a fantastically expressive language, but i fear the learning curve would be too steep for my time invested to pay off - others would have to spend the same time to learn it as well, negating any code sharing / reuse in my org (we don't use J).
- brcrth 14y agoSo why you moved to Python?
- 3amOpsGuy 14y agoGood question. I found others i had to share code with weren't as interested as me about writing maintainable perl code - i got really fed up with a patch work of "write only" perl scripts performing useful functions in prod. From DB maintenance tasks to general housekeeping, to work-arounds for prod app issues that never got prioritised for strategic fixes. I found in practice python code produced by most others was easier maintained: it seemed to more or less force people to write more readable and therefore, maintainable code. I also viewed the fact that Python was one of the premier languages across so many problem domains (Systems, DB, GUI, Web, Large data, GPU, etc.) as being a sure fire payoff for any time invested in it. In environments this size it's not any one persons actions dictate what becomes the status quo: different groups will have different agendas and therefore priorities and views. I guess i was lucky that everyone else was either willing to give Python a go, or was easily convinced. FWIW over the past few years it's proven to be a good choice for us. There are still O'Reilly books float about, esp between the newcomers but there's no zealous "where's my camel book!" shouts anymore.
- chromatic 14y ago* ... it seemed to more or less force people to write more readable and therefore, maintainable code.* What do you mean by "readable" and how does Python seem to enforce that?
- 3amOpsGuy 14y agoSo one of perl's nicest features is it just plain, flat gets out of your way. If you want to write something some way, go ahead, perl will allow you. This is great - you can cook something up in 5 lines that would take 15+ in Python and 50+ in C++. It also means that it's really tempting for some to abuse this ability, even for code which will be long lived.
- anonymous 14y agoI'm actually the reverse. I went to perl from python. I usually use it for system scripting and what I like about it is that it replaces bash nicely without removing the power of specialized syntax. I find it much easier to type open("program -args |") than to construct a subprocess object in python and manually extract lines from its output. On the other hand, python is pretty handy for larger programs, more than a few screens of dense perl syntax starts getting hard on the eyes.
- ajross 14y agoMy experience is almost exactly the opposite. Whenever I'm writing in Python I can't escape the feeling that the code is simply fragile due to missing language features. Obviously this starts with all the regex initializations (often quite distant in source from where they are applied) which make regular expressions in python just a huge mess. Perl's autovification allows me to build a data structure at parse time with code that is trivially verifiable. Python forces me to sprinkle the code with a thousand tests for whether or not the field is initialized yet, or write extra code to define things like defaultdict instances (with syntax that I always have to look up, and which in my experience most python programmers don't understand). Not to mention that if I want to use an OO syntax for that data structure I have to write extra code defining a class for it (and inevitably be yelled at by the pythonista security branch for all the __whatnot__ methods I forgot to define). Python's comprehension/generator syntax is nice, though, and doesn't have a clean analog in perl. One thing it does do well is chaining up "filter" operations on aggregate data structures in a clean way. And that has value and is worth emulating. But honestly most of the rest of the language is junk compared to perl or ruby.
- hercynium 14y agoFor list comprehensions and a different style of generator, look at https://metacpan.org/module/List::Gen https://metacpan.org/module/List::Gen And then there are a pile of modules that implement python-style generators, some using https://metacpan.org/module/Coro https://metacpan.org/module/Coro (co-routines implemented as threads), some using crazy hacks: https://metacpan.org/module/Compile::Generators https://metacpan.org/module/Compile::Generators https://metacpan.org/module/Coro::Generator https://metacpan.org/module/Coro::Generator https://metacpan.org/module/Attribute::Generator https://metacpan.org/module/Attribute::Generator
- ajross 14y agoYeah, honestly though those fail the "clean" test for me. What I really meant isn't the computational capabilities of python generators but the way the mesh nicely with the way builtins like "in" or "all()" or "any()" work on plain old data. Reasoning about them, in general, isn't any harder than reasoning about a dict or list in the common case, and that's a feature missing from the perl equivalents which try to do it in a library. I'd feel comfortable throwing a comprehension into code intended to be maintained by a novice. I'd never inflict any of that junk on the poor maintainer.