I shudder to think what that is made from.

You've said, "There are only two kinds of languages: the ones people complain about and the ones nobody uses." Why does this tend to happen?

Glad I wasn't the only one who thought of that one.

there are no bad languages, just bad programmers.

There are, however, languages that make it far easier to write code that is less readable and harder to maintain. As a specific example, compare Fortran 77 with Fortran 90. I can write the latter without any need for numerical statement labels. I can write a straightforward "DO WHILE" loop in Fortran 90, while in Fortran 77, I'd have to use the dreaded GOTO to get the same effect. Aside from basic stuff like that, I can write formulas in Fortran 90 with whole arrays, which can really help readability. In short, it is far easier to write clear code in Fortran 90 than in Fortran 77.

Do they seriously think that if those models were written in C, Java or Perl they would have been magnitudes better?

Heck, yes! For one thing, in any of those languages, separation of code and data -- something which spreadsheets actively discourage -- would be much easier.

FORTRAN was *NOT* designed to support multidimensional arrays from the beginning. That only came in Fortran 90.

Not true. Multidimensional array were around at least as far back as Fortran 77. Now what is new in Fortran 90 are the ways to manipulate those arrays. In Fortran 77, one could do arithmetic on elements of arrays but not on arrays as a whole, so, for example, adding two arrays in Fortran 77 required DO loops. In Fortran 90, though, one can add arrays A and B with the expression "A + B".

Boost's multi_array is useful, but it's not really aimed at numeric calculations. That's more the territory of Boost's uBlas, and even then, there are competing libraries like MTL4 or Eigen that may have better performance for that purpose.

Actually, I think of the Russian occupation of Crimea as more analogous to the German occupation of the Sudetenland. The pretext for Germany occupying the Sudetenland was the presence of the ethnic Germans there, while for Russia, the pretext was the presence of ethnic Russians.

There's also the matter that OpenSSL and OpenSSH are different animals. OpenSSH is audited, much as OpenBSD is itself.

Repeating as fact something that Politifact had rated as "Lie of the Year" for 2009 does not help your credibility.

There are a few catches with MacPorts, though:

1) Installing and updating ports usually requires compilation. There generally aren't ready-to-download binary packages. For a single package, this may not be a big deal, unless it drags in a bunch of other packages that also have to be compiled.

2) If one upgrades OS X, the MacPorts maintainers recommend deleting and reinstalling MacPorts for the new version of OS X. I'm not sure this is always necessary, but I've preferred not to risk it.

3) A given version of MacPorts targets certain OS X versions, and there's a lag time between when the latest release of OS X comes out and when a version of MacPorts comes out that targets that release.

There's also Fink, which shares problem #3 with MacPorts. It's supposed to have binary packages available, but when I tried it recently, that didn't work out, and it acted much like MacPorts, that is, downloading source and compiling it.

Feminism, in just about all its various forms, is about relationships among human beings, especially where those relationships concern women and girls. Programming, on the other hand, is about human-machine relationships, in particular about how humans -- who tend to think in very fuzzy ways -- can control and manipulate computing devices that "think" in very exacting ways are are very good at doing what they are told rather than what we want them to do. Feminism is certainly relevant to how programmers interact with one another, but not so much with the programming itself.