Fortran is strongly typed python is not. If you want that big an integer declare one that big to assign it. If you want it in the stack ( for your print example) then compile with a larger default int. Fortran does abstract the int size away from the hw. It is just strongly typed.
I did not say that I WANT Fortran to adopt that particular trait from Python.
I would say that being strongly typed is one way that Fortran is a lower level language than Python, and more similar to Julia. I would say that strong typing and especially overflows mean that users contend with a lower-level detail of how numbers are represented in computers.
I have heard several people say that C is a high-level language. After all, it clearly abstracts a lot of the hardware too. But I think that defining thing such that almost every language in the world is lumped into the same category of “equally high level” makes the terminology useless. A Fortran or Julia user needs to think more about how computers work internally than a Python user, and less than a C user. Strong typing, type promotion, garbage collection, object orientation, arrays, etc. are all language features that add or remove levels of abstraction.
I agree that python and pretty much any interpreted language is higher level than a compiled language. Generally, I did not mean to imply you were saying something about a feature that should be adopted just pointing out that the overflow example that you gave means that the program is in error, as it’s been pointed out elsewhere if you have an overflow error, you made an error in your program and should have typed the variable larger or better avoid generation of numbers approaching infinity, which usually is a recipe for losing precision.
Your comment:
“ I would say that strong typing and especially overflows mean that users contend with a lower-level detail of how numbers are represented in computers.”
Is incorrect and others have tried to explain that Fortran types do not map to the hw representation. In fact, you can have higher precision types or types with more digits than are implemented in the CPU registers . So it’s actually quite the opposite: the Fortran types allow you to not think about the local types on the CPU. You can specify what you want in the language is required to implement it. So again, it’s just a consequence of strong typing for code speed.
I think you are conflating strong typing, with “low level or less abstraction“the two are not exclusive. You can have strong typing, and abstractions that allow more easy implementation of patterns. If by high level, you mainly mean, auto conversion of different classes or types in your code, that is as you pointed out, very inefficient for speed, but can be implemented on a case by case basis more efficiently in the type language. But this is getting into the semantic weeds. Use the tool you’re comfortable with that does the job. If speed is a priority, then look at transcoders, and other methods to speed up python or consider strongly type languages instead at least for the slowest parts.
To your original point. I use both Python and Fortran I find that the fortranformat module in python is very useful for interacting with output from fortran programs, given how the Fortran format operator is so much more complex and advanced than the c one I agree the best way is to add to stdlib to convert c format strings to Fortran at least a subset. there is an old Fortran stdlib ticket for this:
That you have probably seen. You could ping that and even start to contribute some simple start.
even in python itself the print statement and the methods of formatting output have changed/been extended multiple times, and in the case of print not even backwards compatible. Suggesting that there is no best answer even in Python. I suspect some version of python 3 formatting even in limited support would be of more interest.
Python floating point computations do overflow.
Strong/weak typing has really nothing to do with low/high level, it’s just a design choice. Some langages (e.g. Ada) are even more strict than Fortran about typing, conversions, etc, and they are not lower level.
In Fortran (and even in C) you don’t necessarily have to. You need to think more about how computers work as soon as you are seeking performances.
1 Like
I really dislike the C syntax even though I’ve had to suffer it for decades at work. Every time I see it I have to trawl through some other bit of code and to find out what it’s supposed to output. As for the *printf procedures, even the seriously experienced programmers get the buffer size wrong partly because of the whole null-terminated string fiasco.
I do like the C++ manipulators - they’re simple to use and not riddled with arcane syntax, could they be added to stdlib?
1 Like