6 ms·

Stockholm Syndrome implies that Perl is bad, no? I disagree. Just as it allows you to write horrible stuff, you can just as well get your shit together and do

by roeme 13y ago

Stockholm Syndrome implies that Perl is bad, no? I disagree. Just as it allows you to write horrible stuff, you can just as well get your shit together and do it maintainable, robust and nice to the eye :) And as the author states, you (almost) always have an choice to run other languages, where perl runs. Not really a hostage situation, methinks. Edit: Not that I particularly like Perl, but neither do I hate it. I think it's somewhat bad reputation stems more from the fact, as described above, that it forces you less to do things nicely and is very accessible to the, let's say, less experiences programmers - so a lot of quickly cobbled together stuff flies around.

lazyjones 13y ago
> it allows you to write horrible stuff, you can just as well get your shit together and do it maintainable Many years of programming practice and SE theory have taught some of us that discipline is not the main concern of most programmers and the higher a level you require of it, the more you will be disappointed. Which means that you tend to get more maintainable results from languages which either require very little discipline to produce good code or those that strictly enforce discipline (e.g. Go). Sadly, even the code on CPAN (which was built to withstand some scrutiny apparently, or why else would anyone release it to the public) is often so badly written that I wouldn't want to debug or maintain it. > And as the author states, you (almost) always have an choice to run other languages, where perl runs. Not really a hostage situation, methinks. In practice you're more likely to find old, hard to maintain Perl code bases that noone is able or wants to rewrite in another language, if you get hired to program in Perl. If there was a realistic choice to use another language, it was likely made already years ago.
- AdrianRossouw 13y ago
  I fell off my chair when I installed R for the first time, and I discovered that I needed a FORTRAN interpreter. Apparently the math libraries written in fortran back in the day have become such a foundational part of analytics, that nobody really wants to re-implement them.
  - baldfat 13y ago
    FORTRAN is an amazing language for some very specific jobs and is still a great tool for a specific job. It's fast does scientific and numerical calculations incredibly fast. I haven't touched Fortran in 20 years though :) I loved me Pascal except the semi-colon key broke on my keyboards.
  - alephnil 13y ago
    That is not really the reason. The reason is mainly BLAS, that implements some of the most commonly used linear algebra operations (matrix multiplication, matrix solvers, singular value decompositions etc). This is implemented in optimized versions for almost every CPU available. BLAS is written in FORTRAN, but it is not true that it has not been reimplemented. In fact CPU vendors frequently reimplement it tailor made for their CPU. On the other hand, the API is not something that is subject to change. A lot of software expect this to be stable, like Matlab, R, Octave, Numpy, and a lot of others.
  - steveklabnik 13y ago
    My vague understanding is that Fortran can actually be faster than C in certain numerical calculations because the language doesn't make the same kinds of guarantees. And therefore, Fortran will live forever.
    - chromatic 13y ago
      Fortran disallows pointer aliasing and it has some language intrinsics which operate on arrays as a whole, so the compiler can emit processor-specific SIMD instructions. I'm sure that a very clever programmer could use restrict and inline assembly in C to get similar benefits, but you know as well as I do that having the language make these guarantees for you is helpful.
  - Solarsail 13y ago
    Picking a(n extremely small) nit (with a fine tooth comb): Fortran compiler. There are no Fortran interpreters in existence, anywhere, that I've been able to find. For FORTRAN 70, Fortran 90, or any other versions. If someone manages to find an interpreter and proves me wrong, I'd love to hear about it.
- BugBrother 13y ago
  I posted this the last time I saw you making ~ the same point https://news.ycombinator.com/item?id=7316490 https://news.ycombinator.com/item?id=7316490 (And yeah, 10+ years old Perl code bases might be less than pretty... The environment evolves quickly, for good and bad.)
- roeme 13y ago
  > In practice you're more likely to find old, hard to maintain Perl code bases that noone is able or wants to rewrite in another language, if you get hired to program in Perl. If there was a realistic choice to use another language, it was likely made already years ago. Having worked in several corporations now I have to respectfully disagree. My experience is that either the code base was scheduled to be retired (but we all know how that usually turns out: the app is used for at least 3x(abs($retiredate - $now)) + $rand ), nobody could be bothered to keep the system current, or there was always something more important to do (which overlaps a bit with the second point). Come to think of it, I really can't come up with a situation where you can't replace perl with a reasonable amount of work? But then again, I'm not active in the perl field.

by roeme 13y ago

lazyjones 13y ago

> it allows you to write horrible stuff, you can just as well get your shit together and do it maintainable Many years of programming practice and SE theory have taught some of us that discipline is not the main concern of most programmers and the higher a level you require of it, the more you will be disappointed. Which means that you tend to get more maintainable results from languages which either require very little discipline to produce good code or those that strictly enforce discipline (e.g. Go). Sadly, even the code on CPAN (which was built to withstand some scrutiny apparently, or why else would anyone release it to the public) is often so badly written that I wouldn't want to debug or maintain it. > And as the author states, you (almost) always have an choice to run other languages, where perl runs. Not really a hostage situation, methinks. In practice you're more likely to find old, hard to maintain Perl code bases that noone is able or wants to rewrite in another language, if you get hired to program in Perl. If there was a realistic choice to use another language, it was likely made already years ago.

AdrianRossouw 13y ago
I fell off my chair when I installed R for the first time, and I discovered that I needed a FORTRAN interpreter. Apparently the math libraries written in fortran back in the day have become such a foundational part of analytics, that nobody really wants to re-implement them.
- baldfat 13y ago
  FORTRAN is an amazing language for some very specific jobs and is still a great tool for a specific job. It's fast does scientific and numerical calculations incredibly fast. I haven't touched Fortran in 20 years though :) I loved me Pascal except the semi-colon key broke on my keyboards.
- alephnil 13y ago
  That is not really the reason. The reason is mainly BLAS, that implements some of the most commonly used linear algebra operations (matrix multiplication, matrix solvers, singular value decompositions etc). This is implemented in optimized versions for almost every CPU available. BLAS is written in FORTRAN, but it is not true that it has not been reimplemented. In fact CPU vendors frequently reimplement it tailor made for their CPU. On the other hand, the API is not something that is subject to change. A lot of software expect this to be stable, like Matlab, R, Octave, Numpy, and a lot of others.
- steveklabnik 13y ago
  My vague understanding is that Fortran can actually be faster than C in certain numerical calculations because the language doesn't make the same kinds of guarantees. And therefore, Fortran will live forever.
  - chromatic 13y ago
    Fortran disallows pointer aliasing and it has some language intrinsics which operate on arrays as a whole, so the compiler can emit processor-specific SIMD instructions. I'm sure that a very clever programmer could use restrict and inline assembly in C to get similar benefits, but you know as well as I do that having the language make these guarantees for you is helpful.
- Solarsail 13y ago
  Picking a(n extremely small) nit (with a fine tooth comb): Fortran compiler. There are no Fortran interpreters in existence, anywhere, that I've been able to find. For FORTRAN 70, Fortran 90, or any other versions. If someone manages to find an interpreter and proves me wrong, I'd love to hear about it.
BugBrother 13y ago
I posted this the last time I saw you making ~ the same point https://news.ycombinator.com/item?id=7316490 https://news.ycombinator.com/item?id=7316490 (And yeah, 10+ years old Perl code bases might be less than pretty... The environment evolves quickly, for good and bad.)
roeme 13y ago
> In practice you're more likely to find old, hard to maintain Perl code bases that noone is able or wants to rewrite in another language, if you get hired to program in Perl. If there was a realistic choice to use another language, it was likely made already years ago. Having worked in several corporations now I have to respectfully disagree. My experience is that either the code base was scheduled to be retired (but we all know how that usually turns out: the app is used for at least 3x(abs($retiredate - $now)) + $rand ), nobody could be bothered to keep the system current, or there was always something more important to do (which overlaps a bit with the second point). Come to think of it, I really can't come up with a situation where you can't replace perl with a reasonable amount of work? But then again, I'm not active in the perl field.