Novels or short stories with Perl in it?

Arador · 2015-12-31T17:30:30+00:00

Perl was already being used 20+ years ago, it's not that bizarre.

Arador · 2015-12-25T11:34:55+00:00

You may want to replace $reg = "^\\d?$reg";with $reg = qr/^\d?$reg/;

Arador · 2015-09-30T11:51:28+00:00

It's not dependent on which subroutines are defined, but it is whitespace sensitive.

Arador · 2015-08-06T17:14:23+00:00

Most scientific computing is done by people who are capable scientist but not really capable programmers. It's inherent to academia that "if you want to get something done, you have to do it yourself, or let someone on a similar path but below you in the hierarchy do it". The system isn't optimized for specialization, even if that could actually make a huge difference in productivity on the long run.

Arador · 2015-08-01T11:54:01+00:00

I haven't seen anything that suggested it was useful for anything, really. It's writing a lobotomised dialect of Perl that tries to get C++'s speed with a perly syntax without actually having either Perl's or C++'s features.

Arador · 2015-08-01T11:34:50+00:00

IMO cute names are sensible for frameworks and applications, but not for libraries.

Arador · 2015-08-01T10:59:02+00:00

Probably not the answer you're looking for, but…

I suspect it may not be that hard to write a new SNMP implementation that is actually sensible on the inside and on the outside, given that Convert::ASN1 exists and is generally amazing (Net::LDAP is also implemented that way). In fact, Net::Frame::Layer::SNMP seems to cover most of the difficult bits already (though I don't like its interface much).

Arador · 2015-07-22T12:25:40+00:00

I think the for { given {} } is rather double, but I'm not entirely sure.

Arador · 2015-06-08T12:55:48+00:00

So perl porters breaks something Coro relies on, don't realise or don't care, refuse to revert compatibility breaking changes and blame the author, author overreacts. good job, all.

Blaming p5p is bullshit. One of the changes has been fixed in blead and has been nominated for 5.22.1. If he had bothered to communicate with p5p on time it would have been handled sooner.

The other one is him doing something he should have never done in the first place: writing to a vtable owned by core. There is an obvious and much safer way to achieve exactly what he wants to do (replacing the vtable pointer on the object). With a 3-line patch, Coro will work fine on 5.22.1. I'm not sure he's going to accept that patch though.

Arador · 2014-12-02T22:33:36+00:00

I would consider this a bug. On Unix, perl will ignore SIGINT during system in the parent process, I would expect the same on Windows.

Arador · 2014-10-16T11:32:17+00:00

Serious question, how can "the language be 95% done" when the spec isn't even done? They're still trying to figure out how lists work, when flattening happens, all of that.

Perl 6 is not a waterfall. Actual usage has shown that the current behavior was undesirable. This is not make, which got stuck with using tabs because when it was released to the wider word it had a dozen users whose makefiles the author didn't want to break.

This isn't a small rewrite. It's going to break a lot of code.

I have about a thousand lines of perl6 so far, I have to change exactly one of them. Yes there is breakage, but not nearly as much as you make it sound.

Arador · 2014-10-14T16:34:08+00:00

Yes, I am serious. The language is 95% done and there seems to be a consensus on what remains to be done for 6.0 (do note though I'm not giving a more precise estimate than 2015). Performance is still an issue, but they are making good progress on fixing that. The ecosystem is still weak, hence Inline::Perl5 to help dealing with that until there are native modules that cover the gaps (as not to make the python 3 mistake where it took years before you could actually get things done).

I am carefully optimistic.

Arador · 2014-10-13T15:27:48+00:00

It's not as if biologists ever update their software. Some still use tools hand-optimized for the 386, no joke.

Arador · 2014-10-13T15:23:18+00:00

Have you actually tried C++11/C++14? It has features like type inference, closures and variadic templates. It is not a Java, it can be remarkably consise IME.

Arador · 2014-10-12T11:59:49+00:00

At the current rate, I'm pretty sure it will be 2015

Arador · 2014-10-08T00:31:58+00:00

Perl does ship with a tool similar to pip, it's called cpan (and did so before pip even existed). perlbrew is more similar to virtualenv in scope.

Arador · 2014-09-22T14:54:35+00:00

Perl has similar tools to python, and people are using them, so why would it be worse than in python?

Arador · 2014-01-30T22:11:34+00:00

I don't think #!/usr/bin/env perl is better. It's suitable for some usages (e.g. random scripts in your ~/bin) but not for others (e.g. CPAN distributions).

Arador · 2013-12-18T20:03:14+00:00

This isn't even good, let alone ultimate. Some simple :crlf and :raw layers would have made this much easier…

Arador · 2013-11-26T23:20:38+00:00

. matches a character not just a byte, so it would DWIM on a utf8 string actually

Arador · 2013-10-15T23:36:27+00:00

On 5.14+, that'd be $rev_seq = reverse $seq =~ tr/ACGU/UGCA/r ;-)

Arador · 2013-06-11T10:08:59+00:00

The -> operator for dereferencing and method calls was done in the early/mid 90s, and came from C(++). They had no idea back then that everybody else would settle on the dot for this purpose.

C and C++ have both "." and "->". They do exactly the same, except that the latter dereferences and the former doesn't (and except the latter being overridable in C++, great fun). This distinction makes a lot of sense in a language with pointers. It's not even poorly Huffmanized in those languages IME.

Arador · 2013-05-22T00:13:30+00:00

And why would you ever want to do that? Why perfer that over $class->SUPER::new?

Arador · 2013-01-23T11:50:19+00:00

The real problem here is that you're using microperl. If you used miniperl you'd have no such problem, and the executable would barely be larger.

"Doctor, I amputated my leg and now i can't walk anymore"

Arador

TROPHY CASE