3 ms·

Very nice; I haven't used it, but I gather that Fortran-80 was severely lacking in string handling. That said, I feel compelled to point out that one shouldn't

Very nice; I haven't used it, but I gather that Fortran-80 was severely lacking in string handling. That said, I feel compelled to point out that one shouldn't judge Fortran as a whole by the need for a library like this in a 40 year old version of the language. I'm still learning the language, so I can't speak with a lot of authority, but it seems to me that, while Fortran is never going to be my favorite language for text munging, its string handling has come a long, long way between then and the Fortran 2018 standard.

Bostonian 5y ago
There was no Fortran 80 standard. There was Fortran IV aka Fortran 66, Fortran 77, Fortran 90, and following, most recently Fortran 2018.
- mumblemumble 5y ago
  There wasn't a Fortran-80 standard, but there was a Fortran-80. Kind of like how there isn't a C# 2005 standard. That's a specific dialect of C# associated with a commercial compiler. The closest standard is the C# 4th edition ISO standard, which covers a subset of C# 2005's features. But it's still OK to refer to C# 2005 as a thing. I think that this is a useful distinction to make in Fortran-land. I haven't used any of these old Fortran compilers, but my understanding is that they were all significantly different and more-or-less mutually incompatible. The Fortran standard had a minimal standard library, so things like what functions you had available for string manipulation depended more on the compiler you used.
  - adrian_b 5y ago
    Yes, FORTRAN-80 was a Microsoft product, belonging to a suite of compilers and interpreters (e.g. COBOL-80, BASIC-80, etc.) for the operating system CP/M and for CPUs compatible with Intel 8080, e.g. Zilog Z80. These were the main Microsoft products before its involvement with MS-DOS. I have used FORTRAN-80 quite a lot, before being able to use an IBM PC compatible computer. An 8080 or Z80 was able to do only about 100 (@ 2 MHz) to 200 (@ 4 MHz) double-precision floating-point operations per second. When I was able to use for the first-time a PC/AT with an 80386DX @ 25 MHz with coprocessor, which could do 100 thousand such operations per second, I recompiled an older FORTRAN-80 program and its run time dropped from 1 hour on CP/M to a few seconds on the PC/AT. Obviously I was very impressed.
  - DaiPlusPlus 5y ago
    > Kind of like how there isn't a C# 2005 standard Er... no. There is: it's just that C# stopped being published as an ISO Standard after version 2.0, and MS stopped publishing C# as an ECMA Standard a few years ago, but the C# language still has specifications and those specifications have version numbers - and those version numbers are used as compiler flags: `csc /langversion:7.3`, for example. > But it's still OK to refer to C# 2005 as a thing. "C# 2005" was C# 2.0, the last version with an ISO spec. Currently we're on C# 9.0 in .NET 6. C# language spec versions and .NET releases are tied together as new language features have dependencies on BCL features (e.g. C# 8.0's `foreach-await` requires `IAsyncEnumerable` which was added in .NET Core 3: https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/november/csharp-iterating-with-async-enumerables-in-csharp-8 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/... That said, the C# language does enjoy relatively good evolution and progress that's almost as rapid as Swift's, and unlike, say, Java, which feels to me like it's progressing at half the speed of C#.

Bostonian 5y ago

There was no Fortran 80 standard. There was Fortran IV aka Fortran 66, Fortran 77, Fortran 90, and following, most recently Fortran 2018.

mumblemumble 5y ago
There wasn't a Fortran-80 standard, but there was a Fortran-80. Kind of like how there isn't a C# 2005 standard. That's a specific dialect of C# associated with a commercial compiler. The closest standard is the C# 4th edition ISO standard, which covers a subset of C# 2005's features. But it's still OK to refer to C# 2005 as a thing. I think that this is a useful distinction to make in Fortran-land. I haven't used any of these old Fortran compilers, but my understanding is that they were all significantly different and more-or-less mutually incompatible. The Fortran standard had a minimal standard library, so things like what functions you had available for string manipulation depended more on the compiler you used.
- adrian_b 5y ago
  Yes, FORTRAN-80 was a Microsoft product, belonging to a suite of compilers and interpreters (e.g. COBOL-80, BASIC-80, etc.) for the operating system CP/M and for CPUs compatible with Intel 8080, e.g. Zilog Z80. These were the main Microsoft products before its involvement with MS-DOS. I have used FORTRAN-80 quite a lot, before being able to use an IBM PC compatible computer. An 8080 or Z80 was able to do only about 100 (@ 2 MHz) to 200 (@ 4 MHz) double-precision floating-point operations per second. When I was able to use for the first-time a PC/AT with an 80386DX @ 25 MHz with coprocessor, which could do 100 thousand such operations per second, I recompiled an older FORTRAN-80 program and its run time dropped from 1 hour on CP/M to a few seconds on the PC/AT. Obviously I was very impressed.
- DaiPlusPlus 5y ago
  > Kind of like how there isn't a C# 2005 standard Er... no. There is: it's just that C# stopped being published as an ISO Standard after version 2.0, and MS stopped publishing C# as an ECMA Standard a few years ago, but the C# language still has specifications and those specifications have version numbers - and those version numbers are used as compiler flags: `csc /langversion:7.3`, for example. > But it's still OK to refer to C# 2005 as a thing. "C# 2005" was C# 2.0, the last version with an ISO spec. Currently we're on C# 9.0 in .NET 6. C# language spec versions and .NET releases are tied together as new language features have dependencies on BCL features (e.g. C# 8.0's `foreach-await` requires `IAsyncEnumerable` which was added in .NET Core 3: https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/november/csharp-iterating-with-async-enumerables-in-csharp-8 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/... That said, the C# language does enjoy relatively good evolution and progress that's almost as rapid as Swift's, and unlike, say, Java, which feels to me like it's progressing at half the speed of C#.