...don't get mad for the question, but: anybody has any arguments for using Perl instead of, let's say Python, these days? (besides the "I already know it incredibly well" argument)
...cause the lack of an answer to such a question has only one conclusion: the language is dying, even if this is not already happening in a visible way!
(don't get me wrong, I'm not a Perl hater, and fyi, I think the world would be a much better place if Rasmus Lerdorf would have learned Perl and written a nice Perl web framework instead of inventing PHP :) )
...don't get mad for the question, but: anybody has any arguments for using Python instead of, let's say Ruby, these days? (besides the "I already know it incredibly well" argument)
...cause the lack of an answer to such a question has only one conclusion: the language is dying, even if this is not already happening in a visible way!
(don't get me wrong, I'm not a Python hater, and fyi, I think the world would be a much better place if David Heinemeier Hansson would have learned Python and written a nice Python web framework instead of inventing Rails :) )
The superb community is one of Python's biggest assets, especially when compared to the Ruby community.
The Python community is made up of some very smart and talented experts. Their emphasis is on developing high-quality software, and doing things properly. Egos are kept in check, and there are always many people willing to offer a helping hand to those who are new to Python.
The Ruby community is generally quite different. There is a much bigger emphasis on celebrity and ego, and being "trendy". The attitude toward software development is different, too, with much more emphasis on producing a lot of code quickly, even if it has security flaws or other serious problems. It's more about being seen and heard, rather than doing.
I'd put the Perl community somewhere in between the Python and Ruby communities. Back when it was more prominent, it had a more lively set of participants than we than we find in the Python community, but a much higher degree of technical aptitude than we find in the Ruby community.
I haven't read something so generalizing in a while. This is the technology-equivalent of saying that women are worse at programming than men because of their sex, or people that use Craftsmen hammers build better houses. Just because someone writes code in Ruby or Python does not assign them to one personality group and mean they are driven by similar motivations.
It sounds like you're talking about the most prolific speakers and code authors in each community who may in fact have their own personalities, but they don't define everyone who are simply using the best tool they can to accomplish their goals.
Perl improved much in this area. The main reason for that is probably the automatic tests that for every new release on CPAN are run on a wide array of systems. This kind of infrastructure plus emphasis on having tests in the libraries is where Perl is still ahead of other languages.
That and the fact that you browse the documentation on CPAN. PyPI (for example) is only an index of packages, the documentation needs to be hosted elsewhere.
First, yeah, I can't mention any modern environment without lots of good points -- and bad points. Most everyone agrees, except...
Second, this trolling attitude seems built in with the Python purity philosophy. It reminds me more of islamists and other religious fanatics than of anything else.
I get the joke, but there are thousands of people currently learning either Ruby or Python and tons of classes for them, it's incredibly easy to hire either a Python or a Ruby (or PHP or Javascript) programmer and so on... while Perl is slowly falling off the radar.
There are 100000 perl modules, all backed up by an extensive test suite. About jobs: knowing a popular language guarantees you a job, but it doesn't guarantee you a good job. Those shooting for a higher level can pick what language they want. Those looking for higher level programmers will find a much broader distribution of language preferences. Hence Twitter runs on Scala, Blekko runs on perl.
> Hence Twitter runs on Scala, Blekko runs on perl.
Those are hardly equivalent (aside from the obvious differences in prominence, scale and relative importance between Blekko and Twitter).
Scala shops attracts developers curious about new paradigms (FP / FP hybrid) whereas Perl shops tends to repel forward-looking developers who view it (accurately or not) as an ugly throwback to the year 2000.
Put plainly : Scala sells itself (to a certain crowd) whereas Perl needs to be be sold almost across the board. Scala is viewed as an up-and-comer, Perl as a has-been.
The GP argued why a tech choice is good, you answer by arguing the reality -- of the fud! That was quite funny.
Edit: OK, I was talking about the first part, CPAN. You only made claims about jobs (that there are no good Perl jobs being created, which duckduckgo by itself should have killed.)
The parent was making reference to the common notion that using outlier languages provides access to high quality talent. In certain cases this holds true, in others not. You will attract, on average, higher quality talent by using Clojure rather than Cobol.
EDIT (response to parent edit) : well, no. I never said there are "no good Perl jobs", just that Perl is not in and of itself a draw in the way that Scala / Clojure / Haskell might be. You could probably convince someone that there are cool opportunities in Fortran development, but very few are actively seeking them out.
That thing about Perl is probably being said since the past 12 years and the needle doesn't seem to have the least count distance with regards to that.
People are learning Python? Really? That was probably true in 2006-2009. Python is no longer the new hotness. Scala and Clojure may be.
The fact of the matter is Perl has a massive niche(Text processing, Unicode, CPAN, Regular expressions, Fast prototyping, TIMTOWDI, Ability to add new syntax rapidly[Moose, Devel::Declare etc], Automation, Testing culture, Documentation, Unix, Parsing, Getting things done real fast... I can go on.. but I will stop here), If you look at what Larry Wall has been saying over the years about Perl 6 in various talks you will note that he designed Perl to fill a niche which continues to be totally unoccupied till today's date. The only competitors Perl has in its design space are tools like sed and awk with a additional few Unix utilities thrown around. In other words Perl doesn't have any credible competition. What's more? Any language that is designed to replace Perl will largely look like Perl(Read: Ruby, Perl 6). And yes, Php and Ruby do have their niches.
Python doesn't have a niche. All Python has is- "Tab indent your code." And sorry to break the bad news to you. Merely forcing indentation on a bad programmer doesn't magically transform him to a good programmer. Rather it make the situation more worse. It gives him a free pass to sit amidst good programmers.
> a niche which continues to be totally unoccupied till today's date
Leaving all about Python aside, what exactly is that niche? I'm not being ironical or anything, I really want an answer to this question, that's why I started this piece of the discussion. Seeing that things like Metasploit, that I would have expected to be written in Perl, end up being coded in Ruby, makes me unable to see any "special niche".
(About what people are learning: indeed we programmers pursue the new hotness, but of people that just started learning how to code, I bet 80% of them are learning Python, Ruby or Javascript, and since this the language they will first learn, this is more likely to become and remain their "go to scripting language" - bar Javascript...).
my theory is that Python ended of being used so much in scientific computing because of what it lacked :) I mean weird stuff that put off "brilliant non-professional programmers" (ie. scientists, engineers and other domain experts that thought themselves how to code). All other languages have tons on these things: Ruby has blocks that make people write functionalish code, Perl has ...tons of weirdness. Python just looked clean and easy to learn and lacked "weird shit" :)
Python also has scientific libraries that don't have equivalents in other dynamic languages. I don't agree that Python is free of weirdness, though. Perl and Ruby just happen to have extra weirdness.
Ruby doesn't have great support for math, science or AI. There are projects out there trying to make the ecosystem better, but currently it trails Python.
For biology -- especially the genomics side -- Perl was absolutely dominant 10 years ago. It's been gradually edged out by other things (substantially Python and R) since then. Desire for better statistical tools may be a driver here, but it's interesting that it's led to a switch of languages rather than building more stats tools for Perl
I would say that Perl is still dominant in computational genomics. About a year ago I wrote some code to do some basic comparative analysis at the genome level alongside some more gene focused phylogeny efforts. Since the whole thing was quite simple it wasn't a problem to write the overall structure, but getting the bioinformatics Python libraries working was a pain. Even if the code tiself was Python the API was littered with various Perl and Bash idioms and there was a major bug in at least one of the tree building methods (had to patch it myself). Calls to subprocesses within the libraries (a heavy part of most bioinformatics work, where there are thousands of stand alone command line programs) would often fail without warning. The state of the art in this area is definitely behind Ruby and far behind Perl.
However, Python is still my main language and I am very happy with that. The numpy/scipy stack and everything building around that is incomparable to anything in Perl of Ruby. Also for the last month or so I have been doing work in the IPython notebook. It has really helped my productivity and documentation efforts. And it looks really cool.
That question can be turned around: Why should someone use Python (or Ruby) instead of Perl?
For someone who hasn't used any of those, I'd say give each of them a few hours and see which style suits you best. Of course, try to find modern examples to learn from. When it comes to Perl that means:
* Mojolicious [1] (or Dancer [2]) as the web framework
* DBIx::Class [3] as the ORM (maybe with some sugar [4])
* Moose [5] (or Mouse or Moo) as the object system
Python and Ruby both have garbage collectors and can deal with reference cycles. Perl only has reference counting, leading to programs that leak memory due to reference cycles and needing to hunt down where in the code you're creating them.
It's the only high-level language I know of that only has reference counting for memory management.
and because of that, it often runs much faster, as well. Having an interim choice between "full GC" and "malloc/free" is a nice option, in some cases. Particularly for small programs/scripts that churn through a lot of data (so long as you don't build a cyclic graph data structure while scanning)
> It's the only high-level language I know of that only has reference counting for memory management.
It's also the only high-level language I know of that can't really be parsed ("only Perl can parse Perl" they say).
It's a dead language really, you can also see this from the number of noisy evangelists vs. professional users nowdays (and that comes from someone who has used Perl almost exclusively for the past 10 years), if you couldn't see it from the diminishing quality of important modules on CPAN (e.g. I pulled my hair today over JSON::XS generating '-inf' from values on one side and crashing on the other side while trying to parse it).
So, I'm learning Go now and improving my JS skills.
"you can also see this from the number of noisy evangelists vs. professional users nowadays"
Actually, where I work, we use Perl almost exclusively. I don't know a single person who I would consider a "noisy evangelist" - we just quietly get stuff done.
Maybe the noisy evangelists are the only ones with enough confidence to publicly proclaim that they use Perl. The others lack confidence and don't publicly announce it because the general programming community responds with disdain / pity.
Nah I've never met anyone in the Perl community who seemed to care much about what other people thought about their language choice. Also most Perl developers I've met tend to be polygots so they're less likely to be the yelly "THIS IS THE ONE TRUE LANGUAGE" type.
There is a Steve Yeggie quote, though its not necessarily praise for Perl, which always pops to mind when people have a rant about Perl:
'As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl. Well almost.'
Even though the lack of a garbage collector is a factor, I doubt that it is the biggest reason.
I was bit quite nastily by the lack of garbage collection in Perl just a couple of months into using it.
However, perl proved itself as an invaluable tool for quickly trying out ideas, and I was loyal to it for at least 10 years. Perl just wasn't able to grow as strong as the alternatives did.
It's hard for me to give up my "perl on the command line" habit. As far as I could tell, Python has no equivalent of "perl -n -e ...", and Ruby is seldom installed on machines at work.
I think that Ruby would be a better choice for some of the scripts that come up here and there at work, but inertia keeps much of it in perl. When I've taken the effort to install something for scripting, it has usually been Scala or Groovy, so as to make use of application code within the scripting.
Text processing with interpolation, the dynamic type system, and regular expressions is insanely easy as they are integrated directly into the language. You don't have a lot match, compile, and match group type scaffolding in your code.
It's a very fun language to begin with. Which is not unimportant if you want to keep being motivated after three decades being a programmer. Peter Norvig described 7 features which made Lisp different. Perl shares 6 of them. Important features like first-class functions, dynamic access to the symbol table, and automatic storage management. (source "High Order Perl" by MJ Dominus).
well, putting aside things "dynamic access to the symbol table" or run-time ast manipulation types of black magic, first class functions and "automatic storage management" are available in both Python, Ruby (...yeah, you need to twist your mind towards thinking in blocks/procs as first class functions, which annoys the hell outta me, but doesn't seem to be a problem for others) and most other "dynamic" languages.
> anybody has any arguments for using Perl instead of, let's say Python, these days?
The Perl community is software's Maker subculture [1]. They have a "heck yeah, we'll give that a try" perspective lacking from other subcultures. The the larger software ecosystem ever lost this Maker/Perl worldview, it would be a huge lose.
Taking a step back: In some ways, I think languages get larger adopted because of their culture. Their technical implementation is just a manifestation of the culture. (And, I think this explains why LISP has never broken out. It isn't a language problem, it's a cultural problem).
CPAN ~ pypi ~ rubyforge. Ruby allows you to write decent one-liners too, though people don't like to use it this way.
the only argument I can extract from this is "Perl has a much nicer syntax for working with regexps", and I agree with this (and I hate it when other languages don't fully embrace regexps and treat them as first class citizens).
but that's the thing, not even the "reasons not to use it" are unique to Perl any longer: heck, if you want to write incomprehensible code for "job security" reasons, Ruby gives you enough rope to hang the whole neighborhood (and Python too has a "dark side", but fortunately most people don't know or want to learn about it)
work uses pypi every day, and I had to set up a caching proxy because mirrors are frequently unavailable. It was inconceivable coming from CPAN that the major package distribution network for a major language may be down.
I had to deal with the major third party, more or less essential, Ruby and RoR gems a few years ago. Rubyforge was a part of this constellation of essential third party gems. Dealing with gems was definitely dependency hell, with mixed up cross dependencies, which were dependent on certain versions of other gems, that were sometimes conflicting when there were a number of gems. Also, you would go to the main Ruby web pages and click links to documentation and the links would be broken - not some obscure, old documentation page to another old, obscure module, but from central help web pages to other pages of central importance.
I have used CPAN for many years and it is so much more rock solid and automagic. If a mirror is down it jumps to the next one without a beat.
The CPAN modules are great too. I was using XML:Simple recently, but the XML files got too big. So I looked around a little and started using XML:Twig, which works great. Then I needed to sort alphabetically words in a variety of languages. So I went with Sort:ArbBiLex which allows me to create my own sort dictionary and has suggested Western language dictionaries on the documentation page. And yes, it has a cmp call which allows for easy multi-column sorting. For whatever problem I have, it seems someone has already written a module for it, which I can get going with little effort.
OT but I think it's one of the reasons mandrake/mandriva never quite took off. There was never a great centralized repository network you could count no - I grew tired of using the PLF system to grab a list of mirrors, and having to update it all the time because participating mirrors were offline or defunct after a few weeks/months.
When programmers discuss Python on the web, this comes up again and again. I agree with you - it is a minus for me in terms of using Python. There are "solutions", there are people who say you get used to it, there are people who say it does not matter, yet it comes up again and again. I guess it does matter, to some of us at least.
I can open up a text editor and start writing C, or Java, or Perl, or PHP - all without that much thought on whitespace, indentation etc. I can later run indent -kr, or perltidy, or astyle and so forth and make the code I banged out look nice and tidy. Sometimes I feel like doing the nice indentation myself while coding, sometimes I do not and let the scripts do it. With Python "there is one way to do it" and you have to think about indentation while coding. It is annoying. It is like Java and exceptions, forcing me to put try/catch loops everywhere and messing up my scope - even for a little prototype program which will be run once and will never need to catch an exception. It is treating me like I am an idiot and forcing me to work in a regimented manner.
When I first learned Python, at one point I decided to put a do/while loop in my program. I was not able to discover how this was done in documentation. I go on IRC #python and am told Python has no do-while loops (which I later confirmed is true). I was told, and I am assuming the source knows more than me, that this is due to the indentation system. One screwy thing done as a result of another screwy thing.
There are a lot of nice things about Python. The code is clean and understandable. It sometimes allows you to do in 2-3 lines what might take 10 lines in another language. And so on. But some programmers feel certain aspects of it are drawbacks, and these things are not easily dismissable. If they were, they would not be brought up again and again.
Opinions on Python aside, I'd never hire somebody saying something like that at an interview, even about a language I don't like. You should really look past petty details when evaluating any tech and come up with actual arguments.
Really, why? You wouldn't hire someone that has some "language aesthetic preferences", although a bit different that the mainstream ones? He said "preventing me for ever liking Python" not "I'll never touch it because of this".
This is really the same as saying, "I won't work for company X because I don't think the brackets in the C++ code should be on the following line[1]!"
[1] E.g.:
int main() {
}
vs.
int main()
{
}
This is an apt analogy because most companies will have some sort of code style guide that you have to follow, which doesn't make "coding at company X where bracket placement is enforced" much different from "coding in Python where whitespace is enforced."
I've yet to come across someone that had a severe hatred of Python due to the significant whitespace that was a programmer I respected. The last person that I knew (who had a visceral hatred of Python whitespace) wrote Perl code like this:
sub func1 { shift->func2(shift)->func3(@_) }
or
sub func1 { grep { $_[0]->func2($_) } $_[0]->func3() }
Note: These are literally code samples with the function names changed.
I don't know any Perl programmers that would condone this sort of code. It's a maintenance nightmare, especially since these were not one-off instances. Seems to me that the people that have a hatred of Python's handling of whitespace don't like being 'constrained' by their language, and are probably happier with Ruby or Perl.
Actually, saying that you'll never like a given detail about a language is not the same as saying that you'll never work for company X because of that specific detail. It is not a logical conclusion, unless you are implying that for one to work for someone else you really need to like everything about the job at hand. I see no reason why you can't do something for money that you wouldn't do for your personal pleasure.
There are some problems with the whitespace in Python.
I wrote some code with lots of nameless functions as input parameters (think JavaScript style or Ruby blocks), which of course was an ugly pain to port to Python with no multi-line lambdas.
List comprehensions is another example -- a kludge coming from that the lack of multi instruction lambdas stop real map functions. (The fun part is that this necessity is touted as something good, instead of admitting that it is unnecessary complexity to learn.)
I've used both Perl and Python. When using Perl I use anonymous functions all the time. When writing Python, I don't. There are instances where in Perl I would use an anonymous function, but in Python I define a local function an pass the reference. Each language has it's own style.
If you're trying to fight the language's style, then you will obviously run into friction. I'm sure there are plenty of people coming from C/C++/Java that think that dynamically-typed languages are unusable because type can't be enforced at 'compile time.' Defining an anonymous function vs. a one-time use local function is mostly a matter of style/preference[1].
| which of course was an ugly pain to port to Python with
| no multi-line lambdas
There are two things you are describing here:
1) It was a pain to name all of these anonymous blocks.
2) The idea of naming the blocks is annoying / aesthetically displeasing to you.
#1 is just part of porting something between different languages. You would equally run into issues porting JS and/or Ruby code to Haskell, even with support to lambdas. #2 is just personal opinion / preference, even if it's one that shared by many.
| (The fun part is that this necessity is touted as
| something good, instead of admitting that it is
| unnecessary complexity to learn.
I could use the same argument to rail against statically-typed languages. "A type system is just unnecessary complexity to learn."
[1] I welcome examples of where anonymous functions are unable to be replaced by local functions passed by reference.
Uh... different paradigms. The scripting languages, which we are talking about here, are generally very similar.
>> I welcome examples of where anonymous functions are unable to be replaced by local functions passed by reference.
Where did I write "unable" -- did I disprove some Turing machine theorem and forget about it? :-)
In this specific case it was a declarative data structure with some data next to code. It was well suited to have a dozen or two short functions next to the data structures.
You could rethink the whole thing and do something different in Python to keep it readable. But among the normal languages (in the same paradigm), Python is the odd man out, just because of the lack of multi line lambdas.
(I also gave the example of bad influences on map, etc.)
| >>Ruby code to Haskell
|
| Uh... different paradigms. The scripting
| languages, which we are talking about here,
| are generally very similar.
Different languages are different, no matter how
many similarities that they have. You are going
to run into issues porting between languages.
Expecting anything else is setting yourself up for
disappointment.
C++ and ObjC are both 'C-based', so there should
be zero issues porting code between them, right?
French and Spanish are both Latin-based, so they
are practically the same language, right?
| >> I welcome examples of where anonymous
| >> functions are unable to be replaced by
| >> local functions passed by reference.
|
| Where did I write "unable" -- did I disprove
| some Turing machine theorem and forget about it?
| :-)
Poorly worded on my part.
| In this specific case it was a declarative
| data structure with some data next to code. It
| was well suited to have a dozen or two short
| functions next to the data structures.
|
| You could rethink the whole thing and do
| something different in Python to keep it
| readable. But among the normal languages (in
| the same paradigm), Python is the odd man out,
| just because of the lack of multi line lambdas.
1. The inclusion of multi-line lambdas in a
language is what makes it 'normal'? This just
seems more like a personal opinion than anything
objective. I could easily say that Ruby is the
odd-man out and Perl/Python are the 'normal'
languages, because of this:
a = 0
if a
puts "Evaluates to True"
end
Or Perl is the odd-man-out and Ruby/Python are the
'normal' languages because they have a GIL.
2. If keeping the data structure and functions
together was the best use-case, then maybe Python
wasn't the tool for the job. Just like I wouldn't
talk about how crappy Ruby is because it doesn't
have SciPy/NumPy.
>>The inclusion of multi-line lambdas in a language is what makes it 'normal'?
All the scripting languages are very, very similar (see data structures, etc).
In short, you don't argue against my point.
My point was that Python stops multi-line lambdas for some weird purity argument re white spaces (I haven't found any other motivation).
This hurts quite a few use cases (for a 2nd -- copy paste and automatic indentation of code is at least more complex, and so on) and makes it necessary to learn weird syntax (list comprehensions), which incidentally is touted as the next coming of Christ...
And the inability to admit a wart on Python is quite typical -- didn't Guido tell you guys to stop trolling recently, because you were getting bad reputation..?
>> Or Perl is the odd-man-out and Ruby/Python are the 'normal' languages because they have a GIL.
These three are all similar -- avoid threading. :-(
Not that it is relevant for my original point, either.
> These three are all similar -- avoid threading. :-(
Perl gets a bad rep on threading because it's threads don't map to what many people consider the strong points of threads, which is light weight processes. Perl fails spectacularly in that regard, but if you want multi-process programming with a standard, well understood set of primitives for IPC, it's really quite nice. That is, the 'threads' module isn't all that great by itself, but when paired with 'threads::shared', it's really quite nice (as long as you are pre-spawning workers or don't require quick thread spawning).
For example, I love how locks are scope based, which makes the following possible:
> There are some problems with the whitespace in Python.
> I wrote some code with lots of nameless functions as input parameters (think JavaScript style or Ruby blocks), which of course was an ugly pain to port to Python with no multi-line lambdas.
As nnq points out elsewhere in this thread, this doesn't have anything to do with significant whitespace. Python only allows you to have a single expression in the body of a lambda, and from what I've read the reason it stays this way is to discourage using a lambda as an argument to map, fold, filter & friends. The usual suggestion from Python programmers is to just use a locally defined, named function, which to be honest is often what I do anyway in languages like ML, because it's clearer.
And anyway, just because it was hard to port some code from language A to language B due to something different about B doesn't really seem like a valid knock against B.
My argument was that a lack of real anonymous functions (> 1 instruction) is a problem in some quite common and useful scenarios.
If you REALLY can give good references that show this is wrong, I'm very interested (like, I would guess, most Ruby users).
(It would also be interesting with a link to a PEP or something with, as you claim, arguments that map etc should be discouraged -- and that is why no multi line lambdas exists. For instance, how would the syntax look like??)
My argument was just that it has nothing to do with significant whitespace, which is what you were complaining about. Python could be changed to have non-significant whitespace but retain its crippled lambda.
You made specific claims (regarding map recommendations in Python and that white space has nothing to do with one instruction lambdas). I asked for references. I assume you have none?
Note that with significant white space a usable syntax for multi-instruction lambdas seems... non-trivial. It seems to me as an unusually stupid fan boy position. But a few well argued references, which you lack, would change my mind. I'm no troll.
Edit: I might also note that your reference nng is a low-Karma account that argues that a cometing open source language to his love child is dead -- typical language war troll. Is that your only reference?
I should rest all this rip, but I can't help it: reference to multi-line lambdas in languages with Python-like syntax: http://cobra-language.com/trac/cobra/wiki/AnonMethod, http://boo.codehaus.org/Closures (yep, you're right, having multiple closures on a single line with offsite-rule syntax is "non-trivial" and no one solved this yet, but even one per line would be enough to make map and fold bearable, and ftr, I want to punch Guido or whoever else has a saying in language's design for not "stealing" this and adopting it into Python - I think there was a PEP along the lines that got killed and burried, can't find it now).
You asked about multi-line lambdas in python and I gave you a valid Python syntax for multi-line anonymous functions. Here is PEP 202, which simply says list comprehensions are more concise than for loops and map/filter etc.
Considering the way Python people have been trolling most every Perl discussion for the last few years when I've been on HN, I feel like I'm in orbit compared to people in the mud...
I might also note that I got two non sequitur answers in a row, so a joke like that is imho not an extreme reaction. Hardly as sarcastic as you was over a joke, at least...
Edit: I might also note that this article (76 votes) is 5 places below another roughly equally old article (8 hours) with 13 votes. So it is probably flagged to Hell. I do feel classy, compared to some others.
At least in Haskell, I don't really care for the significant white space when it's re-factoring time. I don't see how it wouldn't become more of an issue for a traditional imperative language and their tendency for large blocks.
That doesn't make much sense to me. Let's say if I were interviewed at some place using Java, Python, C and Go, why shouldn't I state my personal language preferences?
For most things as an hiring manager I'm OK with people working with their favourite language on whatever project I assign them to (as long as it isn't too esoteric; OCaml is OK, but Haskell is probably pushing it a bit too far, for instance), except when they have to work on an existing code base, in which case I wouldn't want to hire someone hating it; they'd be miserable and the resulting code would be awful.
We'll talk about this Tuesday :) People usually have a very good reason to prefer the language they're more comfortable with, because it makes them more productive. Of course, it could be easy to dispell if some guy insists on writing only assembly, or C++, vs Python. I've known a guy who wrote whole Windows GUIs in assembly, it's pure madness.
There are many valid technical reasons to rather choose C than Python, Java than Perl, or PHP than Go, Erlang rather than C++ ...
But Perl vs Python vs Ruby? Hardly any difference, extremely similar dynamic languages. It's only a matter of personal taste at this point.
I used to think this was a drawback. Then I started using Python full time four years ago. Significant white space encourages readability, and readability (IMHO) encourages maintainability.
There are a numbers of things to dislike about Python; however, after you used the language for a while, you realize significant white space isn't one of them. It is like saying lisp's parentheses are ugly: sure, you might not like them, but they are a huge reason the language (and, really, the way of thinking about code) is so powerful.
Python significant white space is just like nudism. At first you think something essential is missing (clothes, curly braces), then you notice that it wasn't really needed at all, and everything becomes freer and simpler.
I agree, "language aesthetics" matters ...that's why I hate variable prefixing with "$", "%" or "@" :) (and out of all ideas PHP could have gotten out of Perl, it had to be this one, and in a laughable way that makes it useless as arrays also use "$") but I could understand Larry's reasoning that "things that are different should look different" and I wouldn't avoid the language just for this reason.
significant whitespace is not why you cannot write a lambda that contains a line-break. the problems are not really related. just ditch the difference between statements and expressions and allow multi-line expressions. true, then it will no longer be Python but a whole different language :)
I didn't say I hate Python, mind you; but I don't like its significant whitespace, like some don't like Lisp for its parentheses and Perl for its sigils.
I'm using Python from time to time, but I wouldn't spontaneously use it for my personal projects, I prefer Perl for that.
The only languages I really wouldn't want to work with is Java.
Try submitting either of our comments to a reputable publication. I doubt the editor will preserve our whitespace.
English has well-defined whitespace rules, as does nearly every programming language. Every programming language style guide I've ever read has talked about indentation, so you have to indent according to rules no matter which language you use.
Have you ever thought to yourself, "wow, there's no way I'll be able to finish this task on time because I have to indent according to Python's rules"? I'm guessing no.
> Try submitting either of our comments to a reputable publication. I doubt the editor will preserve our whitespace.
True, but it's because changing the whitespace doesn't break the prose. But in Python it certainly breaks the code.
> so you have to indent according to rules no matter which language you use.
Sort of. I've written any number of programs in languages that use braces as delimiters, but very lazily, then used a beautifier to fix things up at a keystroke.
I agree with your point that the source must eventually follow accepted formatting, but it's not true that I necessarily need to pay attention to that (as I do in Python).
Some of the better beautifiers even enforce optional style choices, like turning this:
function_name(variables)
{
Into this:
function_name(variables) {
Automatically.
The latter style has pretty much taken over since I started programming 40 years ago, to the degree that I've come to like it.
I emphasize I like Python and I find its advantages far outweigh the whitespace issue on my personal radar.
> Have you ever thought to yourself, "wow, there's no way I'll be able to finish this task on time because I have to indent according to Python's rules"? I'm guessing no.
You're right, but only because my editor automatically manages Python indentations in most cases, so I don't think about it any more.
The one caveat are Python source files that, from time to time and for various reasons, get infested with tabs. Then things get complicated as I try to get rid of the tabs without destroying the program's logic. IMHO tabs should be outlawed.
Mainly for the sake of completeness, I will mention: block scope. I program in Python a lot, and I like it, but it always boggles my mind when I remember that block "locals" are still visible after a block is closed. JS and PHP are (I believe) the same way about this. The Perl (and C) approach of "proper" block scope feels much less icky to me.
CPAN is probably the main one when i built a front end to authority labs api all of the heavy lifting (apart from the Callback handler) was done using perl modules
I use "visibly dying" for a technology that people are migrating away from - this usually generates things like blog posts titled "X is moving away from RoR because it's crap and rewriting their stack in new fangled scala framework".
But there are other ways something like a language can die in: no new projects get written in it, no new programmers learn it etc. ...this is a slow "death in silence and darkness" (think Pascal).
I see what you mean. And just a few years ago I would've agree that this applies to Perl. But then we got projects like Moose, Dancer, Mojolicious, the whole "Modern Perl" movement and a renewed focus on Perl 5 (very regular releases). I think a part of the community was waiting for Perl 6 and thus everything was a bit stagnant, but lately I don't get that feeling anymore.
It feels closer to Firefox, which is showing some renewed vigor lately, than to e.g. Tcl (sadly…).
This isn't really the only presentation/post about this. After all, it's not like Django and Rails receive the same amount of hype as they did in the beginning, so if you're just going by that, we probably all should switch entirely to Go and Node…
disclaimer: I really didn't intend to transform this into a discussion that's 70% about Python (I could have said Ruby or Javascript instead, the question was about Perl and the comparison was just an example). Right now I would downvote my own parent comment if I could, just to get higher the other comments that are actually relevant to Perl programmers.
I would recommend starting with MooseX::Declare instead of Moose if you are trying to upgrade your Perl, as Moose is great above standard Perl OO but doesn't go far enough by itself.
Previously I found that MoooseX::Method::Signatures was very slow, so I ended up selecting Method::Signatures::Simple.
Coupled together, you end up code that looks somewhere between Ruby and Java. It's not my first choice for a new project, but it's not a bad way to fixup an old but large codebase.
Wow.. I've been using Perl heavily for the last three years and he still managed to cram some amazingly useful stuff I didn't know into that short talk.
Well worth watching if you still equate "Perl code" with "line noise" :)
Anything you can build in Perl, you can also build in Ruby or Python (or hell, even PHP), so it seems rather pointless to argue any of these solutions are superior to another.
At the end of the day the choice is largely personal preference (or company requirement). Also, I know plenty of programmers who still earn a living writing Perl, so it's clearly not a dead language by any stretch of the imagination.
Personally, I would LOVE the chance to work on a Mojolicious project. IMHO that's the best web application framework today (in any language).
Perl unfortunately has a bad image vs its true reality.
I think Perl / Python are interchangeable as a language choice for web scale projects. If your biggest problem is whether to use Python vs Perl vs X, then I say good luck to you -- you should really have more important problems to worry about.
I'd never use ruby for a web scale project (as evidenced by the many services solely dedicated to scaling ruby on rails apps). PHP is not really a language.
Great talk! I've never posted before, but I'm inspired to today. Forgive me if my code is formatted terribly this post.
I used Perl back around 2000, like everybody else, to make CGIs. Then went away from it for a long time. But I've used Perl over the last year to create a large DMCA takedown system, the bulk of which is spidering and analyzing web pages for infringements. Torrent trackers, one-click file download sites, etc.
It's been a beautiful experience. The code runs quickly (for a scripting language), and CPAN is AMAZING. I feel Perl was the best choice for this project, and since I enjoy the language--and trust me, it's NOT line noise: these aren't little scripts, this package-based, documented, modular software development, the likes of which people normally associate with Java (for instance.
I have to say I disagree with one point in that talk. I don't think there are "too many" ways to do OO in Perl--and this sort of ties into his gripe about "@_" and slurping in subroutine arguments, which I think is pure joy. I'm not certain, but I think Larry Wall got this from Lisp. Please correct me if I'm wrong on my history there.
Anyway, in one package that I use as an object, I have this code:
#/ @param object $this an Offense::Analyzer
#/ @param string $event an EVENT_x constant value
#/ @param int $targetId a target id
#/ @param int $obvious TRUE for obvious offenses, or FALSE
#/ @param int $same TRUE for offenses found on the same target, or FALSE
#/ @return int the value for the given event, or undef
sub getEvent($$$$$) {
my ($this, $event, $targetId) = (shift, getEventFor(shift), shift);
my $obvious = getObviousKeyFor(shift);
my $same = getSameTargetKeyFor(shift);
return undef unless $this->hasTarget($targetId);
$this->{'data'}{$targetId}[$obvious][$same][$event];
}
And I supplement that code with the following convenience getters:
sub getIgnored($$$$) { shift->getEvent(EVENT_IGNORED, @_) }
sub getNotified($$$$) { shift->getEvent(EVENT_NOTIFIED, @_) }
sub getQueued($$$$) { shift->getEvent(EVENT_QUEUED, @_) }
sub getRemoved($$$$) { shift->getEvent(EVENT_REMOVED, @_) }
I love the convenience of being able to use the incoming arguments array in this manner. In fact, because you explicitly pass the object reference as the first argument to methods in Perl, I even have this:
#/ @param object an Offense::Analyzer
#/ @param string an EVENT_x constant value
#/ @param int a target id
#/ @return int the value for the given event
sub getEventTotal($$$) {
int(getEvent(@_, TRUE, TRUE)) +
int(getEvent(@_, TRUE, FALSE)) +
int(getEvent(@_, FALSE, TRUE)) +
int(getEvent(@_, FALSE, FALSE));
}
Those are not static method calls (so to speak--package sub calls), but are object method calls. I love that convenience.
Does your fluency need to be very high for this to seem like a good idea? Probably. And in this manner, Perl can never compete with Python. But I guess my argument is similar to the argument a lot of Lisp dialect programmers make: I'm an advanced user, I don't need to be babysat, I can take care of myself, and I'm ok with exploiting the expressiveness of the language.
Well, there is 'Moose' if you want to do OO Perl: http://moose.iinteractive.com/ Some folks I know swear by it. I just find Perl hard to read and not very intuitive. My perl loving friends, on the other hand, claim the opposite. I guess it depends on how your brain works and what you are used to.
You're right on both counts. I would never perldoc my private code...I already don't use it for installed modules. So that's a personal preference. The prototypes issue is spot on. They're ignored during compilation when dispatching isn't clear ($obj->method() ... which subclass?). Most of my subs aren't called that way, so I do get argument checking, which has saved my butt many times, so I just make a habit of always using prototypes. They've been useful for me: that's all I've got there. I could easily be wrong.
And that goes for my whole coding style. You could easily say it's wrong to use "@_" the way I do, which I feel is incredibly convenient. I'm not saying it's a best practice. Maybe it isn't. But for me, it presents no obstacle, and I feel the code is perfectly clear. In in fact, having to enumerate every single argument merely to pass them along, in the same order, to another sub...to me, that seems like a terrible idea. Some people prefer that verbosity (or clarity, if you like). I don't think it's necessary.
As I understand, it has been going on for as long as Python 3 -- which is starting to be used in a few places now. (The difference is that Perl 6 is really, really, really ambitious. Let's see if it ever gets production-ready.)
...cause the lack of an answer to such a question has only one conclusion: the language is dying, even if this is not already happening in a visible way!
(don't get me wrong, I'm not a Perl hater, and fyi, I think the world would be a much better place if Rasmus Lerdorf would have learned Perl and written a nice Perl web framework instead of inventing PHP :) )