4 ms·

> But let’s be straight, that’s like 1% of all of the developers out there — the rest of them are just lurking and coding with their language of choice and bein

by mkl95 4y ago

> But let’s be straight, that’s like 1% of all of the developers out there — the rest of them are just lurking and coding with their language of choice and being content with it. Be it Fortran, COBOL, Perl, or PHP. Assuming all developers who are using something like COBOL or Perl are content with it is hilarious. It doesn't really get much worse than something like COBOL or Perl in terms of ergonomics and ease of use.

biztos 4y ago
As a once and, who knows, maybe future Perl dev I find it a weird choice of grouping, no disrespect to Fortran, but I also think there are probably quite a few mature Perl codebases tended by mature Perl programmers who have their ergonomics and ease of use very dialed-in. Whether you would enjoy it is a different question, but my impression from years of doing Perl is that the most committed hackers tuned their environments and organized their projects just so, and would laugh at anybody else’s idea of “ergonomics.”
dan-robertson 4y ago
Php had pretty good docs online. COBOL presumably has good docs (though I think it’s a bad example and not used much). Perl used to have a thriving online community so it seems pretty conceivable to me that people could like the language. And CPAN still exists and is full of reasonably practical packages for doing lots of reasonable things, as well as packages like marpa which don’t really have equivalents outside of Perl.
msla 4y ago
I like Perl for small codebases heavily focused on manipulating text. It has first-class support for regular expressions, which means you can make them more readable in addition to doing more things with them more conveniently, and it largely stays out of my way. COBOL, on the other hand, is a domain-specific language for a domain most people here have no experience with: Software involving fixed-format input and fixed-point numerical calculations. It would be amazing if some language integrated a clear way to describe modern, recursively-defined input formats with the same degree of language support COBOL has for its data definition language. Go is still too verbose, sadly. Fortran suffers from FORTRAN, by which I mean if you mention Fortran to people they think of 1960s-era mainframe software with no string support, column-oriented fixed formatting, and GOTO use by people who'd never even heard of Dijkstra. Modern Fortran is not like that; sadly, much like Lisp, they never changed the name, so old ideas linger. (This is also true of Cobol.)

by mkl95 4y ago

biztos 4y ago

As a once and, who knows, maybe future Perl dev I find it a weird choice of grouping, no disrespect to Fortran, but I also think there are probably quite a few mature Perl codebases tended by mature Perl programmers who have their ergonomics and ease of use very dialed-in. Whether you would enjoy it is a different question, but my impression from years of doing Perl is that the most committed hackers tuned their environments and organized their projects just so, and would laugh at anybody else’s idea of “ergonomics.”

dan-robertson 4y ago

Php had pretty good docs online. COBOL presumably has good docs (though I think it’s a bad example and not used much). Perl used to have a thriving online community so it seems pretty conceivable to me that people could like the language. And CPAN still exists and is full of reasonably practical packages for doing lots of reasonable things, as well as packages like marpa which don’t really have equivalents outside of Perl.

msla 4y ago

I like Perl for small codebases heavily focused on manipulating text. It has first-class support for regular expressions, which means you can make them more readable in addition to doing more things with them more conveniently, and it largely stays out of my way. COBOL, on the other hand, is a domain-specific language for a domain most people here have no experience with: Software involving fixed-format input and fixed-point numerical calculations. It would be amazing if some language integrated a clear way to describe modern, recursively-defined input formats with the same degree of language support COBOL has for its data definition language. Go is still too verbose, sadly. Fortran suffers from FORTRAN, by which I mean if you mention Fortran to people they think of 1960s-era mainframe software with no string support, column-oriented fixed formatting, and GOTO use by people who'd never even heard of Dijkstra. Modern Fortran is not like that; sadly, much like Lisp, they never changed the name, so old ideas linger. (This is also true of Cobol.)