Hacker News Reader

Comment by LeifCarrotson | Hacker News Reader

Can you help out a reader who does not know any Perl?

I tried it in the REPL and found that "Illegal division" can't locate method "illegal" in package "division", so presumably that gets ignored, same with method "by" in package "zero", and that "at /tmp" is the simplest version of the string that produces the error message, which apparently is more severe than the missing package warnings and terminates the program?

I'd guess the / is the operator for division, and the "tmp" is getting initialized as a variable and coerced into an integer? But "/tmp" doesn't do it, and "/tmp/" does something with regex, so I'm not sure why the parser would split it there.

View on HN

The footnote is originally referenced here:

    Figure 6 represents the string “gggijgziifiiffif”, which by pure
    coincidence happens to accurately represent the authors’ verbal reaction
    upon learning that “unquoted strings” were a feature intentionally
    included in the Perl language.⁵

So, the hint is that this has to do with the "unquoted strings" feature (aka "bare words"[1]).

See the sibling comment about the actual parse — "at" and "tmp" are seen as strings.

The strings get coerced into numbers due to being used with the numeric "/" operator (that's normal Perl behavor). Since the strings can't be parsed as numbers, they become "0". So, you get division by 0.

[1] https://perlmaven.com/barewords-in-perl

Non Perl user here: why do people love Perl but hate JS? I imagine Perl had a lot more thought put into it (than JS's 10 days), but this kind of implicit conversion sounds like exactly the kind of thing that bites me in the ass constantly in JS land.

(Actually, implicit unquoted strings sound so nightmarish it's comical, but let's do one question at a time...)

I used to think the solution was static typing, but then I found none of the same infuriating bugs in Python, which has dynamic but strong typing, forcing you to be explicit about type conversions.

Edit: I think I've hit the nesting limit, so please reply to parent comment and I will find it.

When using Perl you should `use strict; use warnings;` and you have something approaching a real language with a lot fewer warts, in which said quine is not a valid program. It isn't the default because Perl people have an obsession about not breaking backwards compatibility.

I think the people that love perl love its expressiveness. It has a little bit of functional programming here, and a system for making an object-oriented language, and all of these handy tools and you choose which ones you need or find most readable. I've heard Ruby called a better Perl, and - as someone whose day job is largely those two things - that's completely fair.

Many moons ago, I made a case for making strict mode the default in Perl. We settled on the current backwards compatibility compromise, which is that breaking changes are hidden behind a minimum version toggle:

Eg. putting "use v5.14.0;" or similar on top of your file (or compilation unit/scope) will indeed turn on strict mode for you, along with adding a number of features as well.

At the time, also auto-toggling warnings was considered unacceptable because technically, using the warnings pragma anywhere had some edge case action at a distance. This has been remedied in some later release after I wasn't involved in the language development anymore, and from some more recent version, warnings are also part of the standard import.

I imagine you (TheDauthi) already know that, though.

Javascript has a Much larger user community. You get much different behavior and discussion when the community's enormous, it's one of the most used computer languages anywhere, and it's available on almost every device with no additional software. Partial example, StackOverflow question counts (measure of community volume and topic need). 2,529,945 questions on JS. [1] Perl? 68,116. [2] (as of 4/30 when linked)

Possible effects: People that must use Javascript, but don't want to (only choice, only framework). People that use Javascript because it's hyped or hot, not because of personal interest. Larger volume of talk, so more opportunities for griping. Much larger perception of griping (blogs, HN links, news. You almost have to work to find the Perl griping locations). The talk tends to more work issues (stuck on project, annoyed at issue), and not discussing a language you write with because you enjoy the features.

[1] https://stackoverflow.com/questions/tagged/javascript

[2] https://stackoverflow.com/questions/tagged/perl

Former Perl language contributor here. A sibling comment to this already pointed out that you must use strict mode with Perl to retain your well being.

The two languages certainly both have their terrible warts. I think in the implicit conversion gotchas, JS is actually markedly worse. Perl has polymorphic values, but somewhat typed (for its basic types) operators (eg "eq" for strings, "==" for integers). JS has both implicit value type conversions and overloaded operators. That leads to an unholy level of indeterministic mess.

I think developer experience was bad all round "back in the day". Eg PHP didn't have stack traces, query parameters were automatically set as variables (and quotes escaped with backslashes... Depending on your sysadmin's config...) Compilers would produce broken binaries instead of erroring. By comparison, most people learning JS since Web 2.0 have experience with friendlier languages.

> The strings get coerced into numbers due to being used with the numeric "/" operator (that's normal Perl behavor). Since the strings can't be parsed as numbers, they become "0".

Huh, that's an odd failure of Perl's normal ethic of doing things that appear to make sense in context. A number should be 0 by default in additive contexts and 1 by default in multiplicative contexts.

PHP had this too in earlier versions. so if you missed an import that defined constants, the constants would just evaluate as their names. People liked to use this particularly for associative array indexes like $array[userid] instead of $array['userid']. Naturally a terrible idea because the inverse is also true in regards to constants, defining a constant named "userid" would then change the meaning of the program

Easiest way is to Deparse it:

    $ perl -MO=Deparse tp.pl 
    'division'->Illegal('zero'->by('at' / 'tmp' / 'quine' . 'line'->pl(1)));
    tp.pl syntax OK

So I believe this is what causes it (note that "at" and "tmp" and such are "barewords"):

    $ perl -e 'at / tmp'
    Illegal division by zero at -e line 1.

It might be when you run Perl with no qualifier you get a recent version of Perl which turns on strict warnings for you, and (rightly) warns about undefined words instead of quietly trying to evaluate them anyway.

But yes, it converts the strings to integers and divides them, as shown in the sibling comment.

By default, even on a recent perl it'll act like you're on a really old perl and run just fine.

With warnings, it runs, but tells you about all of the mistakes you made. With strict, it doesn't run.

Reply on news.ycombinator.com