Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Perl Renaissance

lanyrd.com

Post reply on HN
Print view View original

71–80 of 130 posts

Re: The Perl Renaissance

#71

Post by fosap »

PommeDeTerre wrote: post #43
autarch wrote: post #13

Earlier quoted context omitted.

...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 m…

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 di…

According to your logic Chicken Scheme is the language of the future. They have a small, but great community.

I like it, but I have given up hopes that one day it will become mainstream.

Re: The Perl Renaissance

#72

Post by wschroed »

nnq wrote: post #2

...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 muc…

Tail recursion. ;) Bioinformatics.

I am currently looking for a couple software developers (https://news.ycombinator.com/item?id=5203736) for positions where Perl is the dominantly used language.

Re: The Perl Renaissance

#73

Post by Roboprog »

ShiningRay wrote: post #30

I'm always looking forward to Perl6, waiting for its stable version, for 10 years.

I think perl 5.10 and beyond kind of preempted perl 6.

Alas, perl 6 in some ways isn't even perl. Perl 6 is cool, but Larry should have made a new name for his next hobby :-)

Re: The Perl Renaissance

#74

Post by Roboprog »

anonymous wrote: post #32
eCa wrote: post #17

Earlier quoted context omitted.

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]…

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)

Re: The Perl Renaissance

#75

Post by spacemanaki »

berntb wrote: post #70
pyre wrote: post #44

Earlier quoted context omitted.

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…

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 tout…

> 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.

Re: The Perl Renaissance

#76

Post by yxhuvud »

Ologn wrote: post #50
falsedan wrote: post #20

Earlier quoted context omitted.

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…

Bundler helps a lot though when it comes to managing the gem dependency hell.

Re: The Perl Renaissance

#77

Post by Roboprog »

eCa wrote: post #17
nnq wrote: post #2

...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 muc…

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]…

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.

Re: The Perl Renaissance

#79

Post by gfodor »

PommeDeTerre wrote: post #43
autarch wrote: post #13

Earlier quoted context omitted.

...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 m…

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 di…

*citation needed

Re: The Perl Renaissance

#80

Post by berntb »

spacemanaki wrote: post #75
berntb wrote: post #70

Earlier quoted context omitted.

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 tout…

> 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…

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??)

Post reply on HN