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