Live data from Hacker News

Why Did I Choose Perl When Building Crowdtilt?

dsog.info

101–110 of 143 posts

Re: Why Did I Choose Perl When Building Crowdtilt?

#101
post #77

Earlier quoted context omitted.

In python the readability come as a natural idiom, it is part of their zen! Superficial readability, perhaps. Neither PEP 8 nor PEP 20 get into interesting questions about maintainability like: * How long should individual compilation units be? * How do I factor my code? * What metaphors do I use to name components? * How do I know when to break apart components? * How do I know when to merge components? * How do I w…

You need good developers to tackle those interesting questions. There is no answer, because you can only rely on rule of thumb and you must know when to break the rule of thumb. PEP 8, on the other hand, is to get these good developers to agree on the less interesting things, such that they can use it as a stepping stone to the more interesting ones. PEP 8 requires strict compliance, because if different developer ig…

I agree, but nothing in Python the language addresses any of my questions. Those concerns are so far beyond the language level that the language is irrelevant.

Re: Why Did I Choose Perl When Building Crowdtilt?

#102
I'm writing to beginner programmers. Please, please don't use Perl.

Use Ruby and/or Python. Other competing scripting might be good (like lua) but I haven't used them. I do know however Ruby and Python are better.

see https://sites.google.com/site/steveyegge2/ancient-languages-...

90% still holds true. This guy knows more than 99% of the Perl advocates on this thread (he's also smarter than me). Do another search on other famous programmers (like Rob Pike) and almost always you'll find negative comments about Perl. There a reason companies like google use Python and universities (like MIT) teach in Python.

For crying out loud Perl has pointers in it. Perl doesn't do basic parameter checking in functions. Perl doesn't come with a decent repl. The Perl repl doesn't work with readlines. Perl doesn't do sane type checking. print "abc" + 1; prints 1. It isn't a syntax error (like in Ruby or Python). Do some basic google searching. wantarray is one of most horrible things I've seen a programming language thats unique to Perl. You how know generally side effects are bad in functions? Well, I don't want to get into it... but just google it.

Perl has a weird cult culture to it. There are a few smart people who are really into it but it isn't because of the languages merits. This is well described by one of perl most famous developers: http://www.perl.com/pub/2000/12/advocacy.html No one with a OPEN mind who isn't lazy wouldn't move onto Python or Ruby.

Remember too at the end of the day it is how good or bad code theoretically is. Is what you see out in the wild. What you work with. The chances are you won't be looking at chromatic's code. Perl code is about the ugliest, most unreadable code you'll find on average. I recently saw something Brain D Foy (a Perl expert) acknowledging this. The average code is what counts.

Anyhow those are my 2 cents. I have to go to sleep.

Re: Why Did I Choose Perl When Building Crowdtilt?

#103

Earlier quoted context omitted.

Hiring people willing to work in Perl isn't that tough. Hiring experienced Perl developers with experience solving specific issues is tougher. Hiring a experienced Perl hacker that's fully embraced something front-end development using Extreme Programming is going to be virtually impossible in your local area. I'm a recruiter w/ first hand experience trying recruit for many languages, and I find Perl-based posotions…

Part of the problem is that people like me tend to prefer to work remotely, work on contract, and get paid more than $35 an hour.

As long as you get the job done, we don't care where you are. I don't think many companies care anymore. Or maybe they still do.

Re: Why Did I Choose Perl When Building Crowdtilt?

#104
post #71

Earlier quoted context omitted.

umm, verbosity? package Point; use Moose; # automatically turns on strict and warnings has 'x' => (is => 'rw', isa => 'Int'); has 'y' => (is => 'rw', isa => 'Int'); sub clear { my $self = shift; $self->$_(0) for qw/x y/} 1;

Verbosity. class Point { has Int $.x is rw; has Int $.y is rw; method clear() { $.x = 0; $.y = 0; } } :)

Looks like a noble attempt to remove perl5 and ruby pain in the arse points simultaneously. Wonder if it will ever come to anything ...?

Re: Why Did I Choose Perl When Building Crowdtilt?

#105
post #42

Earlier quoted context omitted.

I agree. It is a misconception that Perl is "dying". It powers a lot of the web. It had a bad rep a few years ago due to cryptic-looking codes that were written as a throw away code and somehow spread all over the web :). I was one of the skeptical developers at some point, but then I got hooked :). Modern Perl changes the old rep alltogether. I encourage people to write well architected, maintainable, extensible cod…

Regardless of the structure of modern usage its syntax is still very noisy for the reader. It seems the majority prefer the cleaner syntax that doesn't use punctuation to define the type of access a la BASIC.

It might look noisy - but it is just easier to parse in your head when you know what is a variable and what is a function or a keyword. I have came to believe that much of the 'Perl is ugly' notion comes from the fact that the $ character does not have nice typefaces (http://perlalchemy.blogspot.com/2011/01/is-responsible-for-u...).

Re: Why Did I Choose Perl When Building Crowdtilt?

#106

Earlier quoted context omitted.

+1 It is so hard to know that @ means array and % means a hash (key/value pair) haha.

It's not that hard to know the types of the variables you created without punctuation in the identifiers, either.

Well, it's not just the type of the variable but also how you're treating it - world's most concise cast...

Also, it means one doesn't have to dodge keywords in naming their variables. Doesn't count for a lot but is nice.

Re: Why Did I Choose Perl When Building Crowdtilt?

#107
post #78
post #74

Earlier quoted context omitted.

Off the top of my head -- a serious sql parser and the whole TAP test ecosystem. After a while I stopped checking cpan for what I needed, since I just got angry. Another difference: In the Perl world, you can find and have dependency trees with dozens to hundreds of modules installed from cpan -- and you expect it to work, particularly since the module tests by default are run at install. (It is a bit painful with to…

I think there are many cases where packages may not be in one language repo, but in another. However, Python does have a lot of testing packages available that do a swell job. Also, the JUnit test-report format these days tends to be what I see a lot of. http://wiki.python.org/moin/PythonTestingToolsTaxonomy Also, as far as SQL, and even Object Relational Mappers goes, there's SQL Alchemy. You can verify they are pre…

SQL Alchemy doesn't have an SQL parser, which I asked for.

See http://search.cpan.org/~rehsack/SQL-Statement/

It contains a parser and evaluates SQL expressions on lots of data sources(!).

The testing tools on Perl use a common infrastructure and can work with each others in a plugin fashion.

Re: Why Did I Choose Perl When Building Crowdtilt?

#108
post #102

I'm writing to beginner programmers. Please, please don't use Perl. Use Ruby and/or Python. Other competing scripting might be good (like lua) but I haven't used them. I do know however Ruby and Python are better. see https://sites.google.com/site/steveyegge2/ancient-languages-... 90% still holds true. This guy knows more than 99% of the Perl advocates on this thread (he's also smarter than me). Do another search on…

Your post gets a number of things wrong about Perl.

> For crying out loud Perl has pointers in it.

It does? Do you mean references? You'll need to use reference syntax when using nested data structures, but this is the same syntax that you'll find in Python and Ruby - you could think of those languages as using references by default instead of having array or list types.

> Perl doesn't do basic parameter checking in functions.

This is true - you'll need to deconstruct `@_` yourself. It is a shame. There is Params::Validate and Method::Signatures to fix this.

> Perl doesn't come with a decent repl.

Yeah, this is annoying. Get Devel::REPL and use that.

> Perl doesn't do sane type checking. print "abc" + 1; prints 1. It isn't a syntax error (like in Ruby or Python).

This throws a lot of people off, when they expect it to work like Python or Ruby and it doesn't. "abc" and 1 are actually the same type - scalars. A scalar can be a number or a string behind the scenes, and they're automatically converted, so you can just read data from a file and not have to worry about that. You want to use the dot operator, `print "abc" . 1;`, which prints "abc1" (which is what I think you want).

In those languages, it throws a type error, not a syntax error, which is an important distinction. Intergalactic law states that you're not allowed to complain about Perl if you don't know this.

> wantarray is one of most horrible things I've seen a programming language

Having list flattening means you can dump all kinds of data into a function and not have to worry about where it came from. Recently I wrote the line of code `highlight qr/regex/, @colours, @more_colours`, where I just dumped values from arrays into the function and didn't have to worry about destructuring them. If I wanted to pass the arrays, I'd put a backslash before them. It's sort of the opposite of Ruby's unary * operator.

Perl has warts just like any other language. Its warts are just more infamous (because Perl is used so much, a lot of people are having to maintain old codebases) and more visible (Perl has a culture of using the CPAN to fix things with the language (MooseX, Modern::Perl) whereas other languages' users tend to just put up with it).

I disagree that the average code is what counts. When I helped out on a Python cause, the lecturer barely knew Python, and taught it as though it were C (the students learned while loops first, then for loops, and never actually learned about generators. Yeah, I know). The code they wrote was definitely below-average. But not once did they turn to the Internet to see what proper Python code was like - they just followed the course, and did what it told them. If you learn Perl from a book, the amount of sub-par Perl code in the wild isn't going to affect you. Or, to put it another way: how can someone else make my language a worse one merely by writing in it?

I do agree that Perl is a bad choice for your first language: the choices it gives you and the amount it leaves up to you could get confusing when you're trying to learn it by yourself. Perl is a language for when you're a better programmer, and you've learnt to code at a higher level.

Re: Why Did I Choose Perl When Building Crowdtilt?

#109

Earlier quoted context omitted.

Yes, the sigils can make Perl code look noisy, especially as Perl uses curly braces and semicolons too. However, they do have a couple of nice benefits: firstly, they make variable interpolation easier (and less noisy!) than in other languages like Ruby and Python. Secondly, sigils make it easy to see what kind of data you are dealing with, obviating the need to scroll through your program to the variable declaration…

The sigils make variable interpolation easier only in the most generic case "interpolate $me". Anything more sophisticated requires a temporary variable.

I am not especially enamored of variable interpolation, but for those that are, Perl 6 does a much cleaner job than Perl 5 imo.

Re: Why Did I Choose Perl When Building Crowdtilt?

#110
post #42

Earlier quoted context omitted.

Regardless of the structure of modern usage its syntax is still very noisy for the reader. It seems the majority prefer the cleaner syntax that doesn't use punctuation to define the type of access a la BASIC.

Yes, the sigils can make Perl code look noisy, especially as Perl uses curly braces and semicolons too. However, they do have a couple of nice benefits: firstly, they make variable interpolation easier (and less noisy!) than in other languages like Ruby and Python. Secondly, sigils make it easy to see what kind of data you are dealing with, obviating the need to scroll through your program to the variable declaration…

Huh? That will tell you wether foo is a hash or not, but not what kind of things it contains. So, as soon as you subscript you $foo or @foo or €foo, you are lost again.

A good IDE would be of much more help (and strong typing makes writing such an IDE way easier, but that is a different issue)

Post reply on HN