4 ms·

I remember stumbling into that perl codegen years ago and just being horrified. I haven't done any OpenSSL internal work in years and recently I tried to find

I remember stumbling into that perl codegen years ago and just being horrified. I haven't done any OpenSSL internal work in years and recently I tried to find it and couldn't. I thought maybe it was just a vivid nightmare.

saurik 5y ago
In what way was using Perl horrifying? Is it that they weren't using whatever flavor-of-the-week stylish language everyone now thinks is "cool", like some ridiculous node.js stack in Typescript? If they were using Python--which FWIW is extremely common in the build script space--would you have been any less "horrified"? :/
- ajsnigrutin 5y ago
  Considering the age of openssl, using perl was a smart choice... Everything else would have been rewritten atleast three times by now... even porting from python 2.x->3.x takes a lot of effort... ...and perl? Just works!
  - _hyn3 5y ago
    > even porting from python 2.x->3.x takes a lot of effort... > ...and perl? Just works! Agreed! And, if anything, you might be understating it. We went through a Python 2 -> 3 migration recently and it required a massive effort across the entire company; ultimately, we decided to shelve it and port most of our code to Go; this effort has been ongoing to this day. This choice to not offer backwards compatibility left a very, very bad taste in our mouths, and we'll probably never go back to Python. It's astonishing that the PSF just decided that probably trillions of lines of working, production-quality code at companies around the world would need to be re-written. Perhaps it's "their" code, so it's their prerogative, but Go's backwards-compatibility pledge was a huge factor in our decision to move toward it. For those of us on the team who are old enough (honestly) to know Perl (as much as anyone can?), well, there are still some very large companies that have massive Perl codebases and they seem to be happy with them.
    - ajsnigrutin 5y ago
      Yep. I wouldn't care if the did what perl did... create Perl6, which is technically perl, but otherwise a totally new language, and keep supporting perl 5, but they decided to drop python 2 support totally. Combine that with distro maintainers seeing that, and "overnight" removing all the python2 software available (some even without suitable replacements) and totally removing python2 support, makes it a pain in the ass to develop anything and then fearing what will python 4 bring, and when will that happen. And as I said... perl code, just works.
- wbl 5y ago
  It's horrifying because it solves a problem most projects solve by using one assembler and having it as a build dependency. It makes reading the code hard and analyzing it tougher. The header files are their own horror.
geofft 5y ago
It's called "perlasm." First Google hit finds it, if you happen to want to see it again :) (Though it's not header files, so I wonder if 'wbl was thinking of something else.)
- wbl 5y ago
  They added it in 3.0.0. The headers go through perl now as well as the assembler.

saurik 5y ago

In what way was using Perl horrifying? Is it that they weren't using whatever flavor-of-the-week stylish language everyone now thinks is "cool", like some ridiculous node.js stack in Typescript? If they were using Python--which FWIW is extremely common in the build script space--would you have been any less "horrified"? :/

ajsnigrutin 5y ago
Considering the age of openssl, using perl was a smart choice... Everything else would have been rewritten atleast three times by now... even porting from python 2.x->3.x takes a lot of effort... ...and perl? Just works!
- _hyn3 5y ago
  > even porting from python 2.x->3.x takes a lot of effort... > ...and perl? Just works! Agreed! And, if anything, you might be understating it. We went through a Python 2 -> 3 migration recently and it required a massive effort across the entire company; ultimately, we decided to shelve it and port most of our code to Go; this effort has been ongoing to this day. This choice to not offer backwards compatibility left a very, very bad taste in our mouths, and we'll probably never go back to Python. It's astonishing that the PSF just decided that probably trillions of lines of working, production-quality code at companies around the world would need to be re-written. Perhaps it's "their" code, so it's their prerogative, but Go's backwards-compatibility pledge was a huge factor in our decision to move toward it. For those of us on the team who are old enough (honestly) to know Perl (as much as anyone can?), well, there are still some very large companies that have massive Perl codebases and they seem to be happy with them.
  - ajsnigrutin 5y ago
    Yep. I wouldn't care if the did what perl did... create Perl6, which is technically perl, but otherwise a totally new language, and keep supporting perl 5, but they decided to drop python 2 support totally. Combine that with distro maintainers seeing that, and "overnight" removing all the python2 software available (some even without suitable replacements) and totally removing python2 support, makes it a pain in the ass to develop anything and then fearing what will python 4 bring, and when will that happen. And as I said... perl code, just works.
wbl 5y ago
It's horrifying because it solves a problem most projects solve by using one assembler and having it as a build dependency. It makes reading the code hard and analyzing it tougher. The header files are their own horror.

geofft 5y ago

It's called "perlasm." First Google hit finds it, if you happen to want to see it again :) (Though it's not header files, so I wonder if 'wbl was thinking of something else.)

wbl 5y ago
They added it in 3.0.0. The headers go through perl now as well as the assembler.