To me Perl was just Weird, to no particular end. Not the kind of mind expanding Haskell/Prolog/Lisp weirdness that opens up new possibilities. It just does roughly the same things as every other language, but everything is done slightly differently due to evolving out of the primordial soup of bourne shell and AWK filtered through Larry Wall's brain.
Perl and Python were similarly powerful and useful languages, but I could learn and start producing useful code in Python after reading an hour long tutorial. Perl took an order of magnitude longer, and remained more awkward to use just due to the Weirdness. There was a momentum building in the early 2000s toward competitors like Python and Ruby that were seen as less crufty and more modern.
Perl's developers seemed to agree, since they cooked up their own competitor to Perl, an entirely different language confusingly called Perl 6. The coexistence of Perl 5 and 6 made the Python 3 transition look like a cakewalk -- at least it would have save for Perl 6's almost entire failure to exist for over a decade after its inception. It produced lots of constantly churning specs and blog posts about register based virtual machines with native support for continuations or whatever, but no implementation of a language that anyone felt comfortable using for any real development. Meanwhile people kept using the ossifying Perl 5 for existing applications, and gradually transitioning away as they were replaced.
Also PHP overtook it for the "just FTP a script to $5 shared hosting and make a webapp" use case.
Wasn't Intel trying to do something similar in Itanium i.e. use software to translate code into VLIW instructions to exploit many parallel execution units? Only they wanted the C++ compiler to do it rather than a dynamic recompiler? At least some people in Intel thought that was a good idea.
I wonder if the x86 teams at Intel people were similarly baffled by that.
Maybe that's true for this project (implementing pointer chasing list interpreter directly in hardware), but it's much less clear to me why it would be true of the much more commonly remembered examples of "lisp machines" like symbolics, TI, etc.
You can write a function in go or rust, then write code in assembly to call it with any old nonsense. It is no different. The whole point of static typing is that it happens at compile time, not runtime.
I haven't written any ruby for over a decade and a half, when ruby 2.x was still on the horizon. But I do know the source of "eigenclass". It was first jokingly used in an odd instructional programming book / web comic / experimental art piece by "why the lucky stiff" who was briefly prominent in ruby-land then erased himself from the internet. It's funny that it has now become an established term of art for Ruby people.
In my experience there are two mistakes people sometimes make that leads to the fisheye lens look. The first, as parent mentioned, when calculating the ray directions you should linearly sample a line rather than interpolating view angles. Second, when doing per-column perspective division, you should divide by dot product of the forward vector and the difference between the ray intersection and the camera location. Often if someone is making the first mistake they are also making the second.
Following this will give you the normal pinhole camera 3d projection that we all expect to see from a 3D game.
Rule of thumb I found as a beginner in 3D graphics: any time polar coordinates seem like the obvious solution, there's usually a better way.