3 ms·
Fortran is entirely modern. Last standard is what, 2008? And any compiler will just eat any previous version without complaint. You can take a huge swath of '77
by RogerL 11y ago
Fortran is entirely modern. Last standard is what, 2008? And any compiler will just eat any previous version without complaint. You can take a huge swath of '77 code, put some 2003 and 2008 in there, and it will all just compile.
Python? Good luck. Every frigging month (practically) it's a breaking change. You have to work furiously just to keep your infrastructure working, or purposefully draw a line in the sand (2.7!).
I run Fortran every day (via NumPy and other packages), and some of us are investigating just switching to it for some projects (we need the math speed, and all the C++ matrix libraries involve compromises of one form or another). There's no reason I and my peers wont be doing the same in 50 years. It works, its fast, its debugged, and it is easy to use things like Python 5000 (by then over 70% of people will have made the transition from 2.7 to the 3.x version!!!) to do all the glue work that Fortran is not optimized to do.
Fortran codes ain't ever going to be a liability[1]. Python 2.7 on the other hand...
[1] because of being Fortran. Poor coding style was endemic in Fortran77, and that can be crippling, but to a large extent that is language agnostic. I acknowledge the required short variable names of 77 doesn't help, but people would not comment what the variables mean, and that is the real problem (IMO). Poor structure is another problem (masses of gotos). Yes, 77 doesn't make your life easy there, but discipline is possible. We can quibble about all this; my point is the 'modern' languages are going to be old quite soon, and we will face real porting problems then. Move 20,000,000 lines of JS and Python? Good luck.... Get a Python 2.4 code base working with 3.9? Ah, hmm, well .....
But Fortran? We build it and run it every day, easy peasy.
- icebraining 11y agoPython? Good luck. Every frigging month (practically) it's a breaking change. You have to work furiously just to keep your infrastructure working, or purposefully draw a line in the sand (2.7!). What? There was exactly one breaking point, from Python 2 to Python 3. Which "monthly breaking changes" are you talking about?
- anthony_d 11y agoI'm not a Python developer but what I've seen and find frustrating is the slow migration of libraries to Python 3. Some projects have switched to 3 and some are sticking with 2 for now. Some applications are using 2 because they have dependencies using 2, but as those dependencies switch applications have to deal with combining Python 2 and Python 3 dependencies. I know each issue is easy in isolation, but we're talking about old 25M line codebases here. If such things exist in Python it can be a maintenance problem. I'm in favor of languages making breaking changes occasionally but there is something to be said for languages like Java or Fortran that are intended to keep compatibility forever.
- fluidcruft 11y agoProbably not the language itself, but the quivering mass of libraries with moving APIs and bolted-on design fads. Numerics is numerics--functions, matrices, linear algebra and indexing isn't going to change any time soon. That Fortran gets bashed and Lisp is worshiped seems quite incongruous.
- paulhauggis 11y ago"There was exactly one breaking point, from Python 2 to Python 3" One breaking point? The majority of the libraries that I use don't even work properly in Python 3. The standard Mysql library for instance, which is used in the majority of ORMs (including SQLalchemy) isn't included in Python 3, which means you need to make major changes/try to use a different library. The case of many standard libraries were changed, breaking lots of code. Example: ConfigParser to configparser. Even simple things like print 'test' is now print('test') These are only a few examples. There are lots of other major changes that break 2.X code. I have been using Python 2.X for all of my projects and wanted so badly to change to 3.x for my new projects. However, because of all incompatibilities, I can't. I don't think I'm alone on this either. Python 3.X still isn't being used by the majority of developers.
- kragen 11y agoPosting this censored comment for the good of the community; it seems entirely reasonable, although a bit overwrought. "Gurer jnf rknpgyl bar oernxvat cbvag, sebz Clguba 2 gb Clguba 3" Bar oernxvat cbvag? Gur znwbevgl bs gur yvoenevrf gung V hfr qba'g rira jbex cebcreyl va Clguba 3. Gur fgnaqneq Zlfdy yvoenel sbe vafgnapr, juvpu vf hfrq va gur znwbevgl bs BEZf (vapyhqvat FDYnypurzl) vfa'g vapyhqrq va Clguba 3, juvpu zrnaf lbh arrq gb znxr znwbe punatrf/gel gb hfr n qvssrerag yvoenel. Gur pnfr bs znal fgnaqneq yvoenevrf jrer punatrq, oernxvat ybgf bs pbqr. Rknzcyr: PbasvtCnefre gb pbasvtcnefre. Rira fvzcyr guvatf yvxr cevag 'grfg' vf abj cevag('grfg') Gurfr ner bayl n srj rknzcyrf. Gurer ner ybgf bs bgure znwbe punatrf gung oernx 2.K pbqr. V unir orra hfvat Clguba 2.K sbe nyy bs zl cebwrpgf naq jnagrq fb onqyl gb punatr gb 3.k sbe zl arj cebwrpgf. Ubjrire, orpnhfr bs nyy vapbzcngvovyvgvrf, V pna'g. V qba'g guvax V'z nybar ba guvf rvgure. Clguba 3.K fgvyy vfa'g orvat hfrq ol gur znwbevgl bs qrirybcref.
- smanzer 11y ago(we need the math speed, and all the C++ matrix libraries involve compromises of one form or another). Are you using lots of really tiny matrices? I would think pretty much all the libraries could just be linked with a good BLAS distro and then it would not matter what language that you use. Personally, I'm a big fan of the Armadillo C++ library.