LWN: Comments on "GNU Toolchain Update: September 2008"

FORTRAN!

jengelh — Wed, 08 Oct 2008 00:36:16 +0000

>There are no type checks for external procedures

And I am exactly barfing about that!

FORTRAN!

asamardzic — Sat, 04 Oct 2008 07:11:04 +0000

I may be able to live with the fact that offsets start at 1.

Use whatever start index you like - start index 1 is just the default, here is an array with indices ranging from -5 to 5:

real, dimension(-5:5) :: foo

I'd say this capability is actually big advantage over C-like array handling, where indices have to start with 0. As for default of 1 as start index, one should have in mind that Fortran came before other languages, so 0 as start index is actually convention that came later.

I might be able to get used to the odd indent rules.

Don't know what you mean here: from Fortran 90 onwards, the code could be written in free form, and there are no particular indent rules - the editor (well, emacs at least) is usually indenting the code for you, and the structure of the Fortran code written this way looks pretty much alike as the code written in any contemporary language.

But I as hell am so not amused by it (pgf90) not having a fucking type checking system.

There are no type checks for external procedures, you'd have to put this subroutine into the module in order to have types checked:

module baz
  implicit none
contains
  subroutine foo(bar)
    implicit none
    integer :: bar
    write (*,*) bar
  end subroutine foo
end module baz

program main
  use baz
  implicit none
  integer, dimension(12) :: bong
  call foo(bong)
end program main

FORTRAN!

jengelh — Fri, 03 Oct 2008 16:28:21 +0000

For science: dumbed down. I may be able to live with the fact that offsets start at 1. I might be able to get used to the odd indent rules. But I as hell am so not amused by it (pgf90) not having a fucking type checking system. Pass an array of integers in where a single integer is expected and all things will go crazy (also segfaults will be seen less often even), and I wish you a pleasant time debugging that. Because whenever the scientist gets it wrong, I engineer am getting called to have it figured out.

I don't claim correctness, but this is the idea:
subroutine foo (bar) integer bar ... end subroutine main (etc) integer bong, dimension(12) ... foo(bong) end

FORTRAN!

donbarry — Fri, 03 Oct 2008 13:09:30 +0000

Also APL and J. Sadly, J only exists as "freeware" (i.e., *not* free software). I am always saddened that scientific computations didn't follow the APL/J route, giving us only a fraction of the array primitives that we'd otherwise have in bastardized scientific array languages like IDL and Matlab.

FORTRAN!

flewellyn — Thu, 02 Oct 2008 12:20:40 +0000

Assuming that there is one! It's likely that the optimal machine-language representation would differ depending on the number and size of the inputs, number of iterations/recursions, etc. In such cases, assuming a sufficiently smart compiler, you'd still have to either settle for a "sub-optimal" general case, or else recompile for every run.

FORTRAN!

eru — Thu, 02 Oct 2008 05:49:28 +0000

I can believe that a state-of-the-art Common List compiler might generate as fast code as Fortran (after you have completely decorated the Lisp code with type declarations that you normally don't use with Lisp, and which make the code less readable), but how could it be faster than code from a state-of-the-art Fortran compiler? Shouldn't both converge on the same optimal machine-language representation of the algorithm?

FORTRAN!

flewellyn — Thu, 02 Oct 2008 00:33:12 +0000

show me another programing language with built in handling of complex numbers and equations containing them

Common Lisp. And in terms of performance, some CL compilers (CMUCL, for instance) can outperform Fortran at such tasks, using the same algorithms.

FORTRAN!

njs — Wed, 01 Oct 2008 23:26:02 +0000

> show me another programing language with built in handling of complex numbers and equations containing them

Well, C, actually. (Not actually standardized until C99, but gcc has supported them forever.) But that's nit-picking.

another programing language with built in handling of complex numbers

mejd — Wed, 01 Oct 2008 22:23:12 +0000

python!

with no libraries imported

>>> (-1+0j)**.5
(6.1230317691118863e-17+1j)

the standard library cmath has all the useful transcendentals

FORTRAN!

rahvin — Wed, 01 Oct 2008 19:19:20 +0000

Anyone that's used Fortran knows why that's true. The language was designed specifically for the needs of scientists. IMO it's far easier to pick up, understand and use for those trained in engineering and science because it's structure is aligned with classical equation notation much more than any of the popular languages (and yes, it's features outside pure computation such as strings blows but show me another programing language with built in handling of complex numbers and equations containing them). It's Numeric capabilities are the reason it's still around and being used daily.

FORTRAN!

asamardzic — Wed, 01 Oct 2008 17:39:13 +0000

I guess it depends on what you're doing these days - I, for one, can assure you that for doing numerics Fortran (it's not spelled FORTRAN any more, btw) rocks just as much as ever.

FORTRAN!

felixfix — Wed, 01 Oct 2008 17:15:10 +0000

Wow, haven't seen FORTRAN (or is it spelt Fortran nowadays?) in ages. Learned it eons ago, back when we had no water, had to smash our own hydrogen and oxygen atoms together to make it, and don't ask about snow.

I like it in those examples, a nice clean language there. But it was a bit of a shock. My brain took a few seconds to wonder what modern language had the look of FORTRAN and was I so out of the loop that I hadn't been keeping track of new languages ...

GNU Toolchain Update: September 2008

moxfyre — Wed, 01 Oct 2008 16:06:28 +0000

A "series of blogs"? Is that anything like a series of tubes? Sorry, just poking a little fun... I think you mean a "series of blog posts"? ;-)