Fortran.io – a Fortran Web Framework
fortran.io
fortran.io
It had been scheduled for merge into the LLVM monorepo 2 days ago, but has been delayed pending some additional architecture review.
Install numpy, it will pull in Fortran stuff.
Scipy is a different story.
The need for a fortran compiler was a big part of the original rationale for the divide of numpy and scipy when they replaced numeric. Numpy was meant to be the lighweight/core version of things, and scipy was the full-fledged environment. (I think numpy was even scipy-min, or scipy-core, or something along those lines for a bit.) A key differentiator for what when into numpy vs scipy was whether or not it needed a fortran compiler. That's still true today -- numpy explicitly doesn't depend on anything fortran related, and anything that uses it is optional.
(I'm not authortative on any of this, I'm just someone who's been doing scientific computing in python (and fortran) since the numeric days.)
On a different note, modern fortran (e.g. F90 and above) is actually a really nice scientific software language. It's _still_ really hard to beat, and modern fortran is pretty maintainable and easy to read in addition to being performant. I've dealt with highly optimized fortran codebases and highly optimized C codebases for the same scientific tasks. The fortran ones were usually a lot easier to read, more maintainable, and were still faster. Fortran is not really a general purpose language, but if you're doing lots of number crunching on large arrays, it's damned nice.
I was amazed how much more complex things were when moving to C++ (as opposed to C or C written in cpp files which you’ll find in academia and some books).
Of course, that ease is a hazard when all the modern (i.e. fun) sci-eng software development is in C++.
Do not grow complacent in school, ye numerical methods researchers! Write your stuff in C++. The job market awaits.
Could you elaborate a bit on this? I think I know what you mean, but I'd like to hear more if you don't mind.
Not such a big deal if you are a pure-researcher in, say, CFD, and not such a big deal in a national lab, where the big codebase may be FORTRAN anyway (caps to denote old school code bases). But it really limits your mobility not to be "C++ first". Lastly, if you land a job at a big numerical analysis company, you may be looking after legacy products forever if you are "just a Fortran person".
Well, this is obviously anecdotal. Sorry to state such bald opinions. But it's what I've seen, and really would have been helpful to know as I was going through school. I wrote a lot of Fortran and Python. It's left me playing catch up and it could have been avoided with comparative ease compared to my time budget now.
I'd also give a quiet nod to trying to get familiar with modern dev-ops tooling. E.g. docker, kubernetes, and interacting with at least some forms of cloud storage. Get used to the idea that a bucket is not actually a directory, it's a hierarchy of prefixes and learn how to use that. Think of a dockerfile as learning how to write a makefile. It's worth learning the basics of, and it's not hard for simple things. HPC work has traditionally been a lot of fairly custom clusters (Condor, anyone?) or problems that are best solved with a lot of RAM on one machine. However, things are moving towards commodity solutions (i.e. "the cloud") or at the very least, common software layers. You don't need to understand the the ins and outs of managing a kubernetes cluster, but it's helpful to have used kubectl to spin up and debug a pod or two at some point.
However, I will say that there seem to be more Python-based jobs than C++ or Fortran jobs in the industry-based scientific computing world these days. Perhaps less so for fluid dynamics or finite element methods or other "simulation on a grid" problems, but there are a lot of python codebases out there in industry right now. I think it's very important to be comfortable working in higher level languages as well, and python is kinda becoming the lingua franca of a lot of sub-fields. For better or worse (I'm in the "better" camp), a lot of users are going to want a python library for what you're writing. It's best if you're used to "thinking in python" and can design a pythonic api.
I guess my fear was that all Python jobs (that I'll find) are going to be "machine learning" -- but really that would just mean data munging to feed Tensor Flow (or similar lib) and post process. Total snooze fest unless "post process" means something more like design generation/variation/optimization - and we are back to the api.
However, in order to support all existing C programs I believe they still can't make the same level of optimization as Fortran does. It'd be nice to see this gap merged, in fact.
C++ can actually do better with some numeric code since commonly used libraries perform expression optimization at compile-time using Eigen for example.
I don't know if Fortran would be considered dead by the "no longer adapting" definition, but that it's still in use isn't proof it's alive.
That said, I only write in modern Fortran when I use Fortran. The newer features make it much easier to write complex data structures, in particular.
In regard to Fortran, things are changing too. There's even a Fortran 2018 standard, which is fairly close to Fortran 2008, but would be almost unrecognizable to people who learned Fortran 77 or earlier.
All of these are directly descended from Latin in exactly the same way that today's English is descended from 1900s English, just over a longer period.
Latin is certainly a dead language, even though it has living descendants.
The reasons for considering English circa 1000 and English circa 2020 to be "different stages of the same language" but Latin and French to be "different languages" are an arbitrary cultural distinction not rooted in science. The English of Beowulf is just as different from the modern variety as French is from Latin. And at every point from the introduction of Latin into France thousands of years ago until the present day, everybody could communicate perfectly easily with their own grandparents, and thought they were speaking the same language.
(Tangent -- certainly not all languages are descended from a hypothetical Proto-World, since we have examples of brand new languages forming: any creole languages, or Nicaraguan Sign Language. Whether most of the major language families are descended from a Proto-World is very much an open question, and probably one that will never be answered, since even if say, English and Navajo are genetically related, they diverged so long before we had written records that no trace remains.)
In any case, there's a meaningful difference between a language gradually changing over hundreds of years such that the newer varieties are quite different from the old ones, and a language truly dying, because it has exactly one remaining native speaker, and that person dies.
It's a question that linguists (who are scientists) strive to answer in ways that are useful to studying, reasoning about, and explaining language. It's not much different than the species problem in biology. Everyone knows that speciation happens gradually, but scientists still propose ways of defining and explaining speciation to aid in scientific inquiry. The labels and dividing lines themselves are not empirically observed, of course, but that doesn't mean they're unscientific or outside the purview of scientific inquiry.
I would be very surprised if such a thing exists.
Sure they are, although a debate wouldn't be contained in one paper written collaboratively by debating authors, as you seem to imagine -- it would play out over a series of papers, each of which cites previous papers and claims they're wrong.
For example, Timm 1989[1] argues that modern Breton is a VSO language, disputing the claims of Varin 1979[2], who claims it is SVO, which in turn disputes the traditional understanding that it is indeed VSO.
Or the famous paper of Haspelmath 2011[3] citing many other authors' proposed approaches to word segmentation and arguing that they're all wrong (i.e., that "word" is not a meaningfully defined concept in linguistics).
Where are the papers that you claim exist about the lines between languages? If this is really something mainstream linguists care about, you should be able to give examples in non-fringe journals.
I just checked the citations on the Wikipedia article for Middle English like you suggested, and found zero papers about whether Middle English should be considered "the same language" as modern English. Can you tell me which ones specifically you mean?
[1]: Timm, L. (1989). "Word Order in 20th Century Breton". Natural Language & Linguistic Theory, Vol. 7, No. 3, Special Celtic Issue, pp. 361-378 (https://sci-hub.tw/10.2307/4047723)
[2]: Varin, A. (1979). "VSO and SVO Order in Breton". Archivum Linguisticum 10, pp. 83-101
[3]: Haspelmath, M. (2011). The indeterminacy of word segmentation and the nature of morphology and syntax. Folia Linguistica, 45(1). (https://sci-hub.tw/https://doi.org/10.1515/flin.2011.002)
The weaker (and more reasonable) claim is that learning Latin improves your ability to recognize words and (very basic) structures in its descendants.
http://ancientgraffiti.org/about/ is an excellent resource specifically for Herculaneum and Pompeii, but it also links to broader collections to which the project has contributed.
There are interesting aspects of graffiti throughout the Roman Empire. Children (or exceptionally short adults) practised writing on walls; some taller people's graffiti showed not just literacy but familiarity with Virgil and even decent command of Greek and other second languages. Conversely, numerous graffiti are supporting evidence for partial Latin literacy among speakers of other languages, even among celtic-language informal epigraphers in the west and northwest in the first decades CE. It seems likely that these influences "accented" day-to-day Latin, perhaps comparably to https://en.wikipedia.org/wiki/Singlish .
A couple of centuries later and one could see a clear split between the classical register and early Vulgar Latin. Appendix Probi is interesting, and some examples are listed at https://en.wikipedia.org/wiki/Vulgar_Latin#Evidence_of_chang... which also draws some comparisons with Romance languages. (cf. https://en.wikipedia.org/wiki/Appendix_Probi )
Anyway, my point is that it's an error to say that Latin "stopped changing". Other languages have changed similar amounts: modern Americans can't understand Beowulf, modern Greeks can't understand Homer, and modern Chinese people can't understand Confucious, but nobody would claim that English or Greek or Chinese died and stopped changing. The fact that people call Latin, but not English, a "dead language" is purely due to the fact that the different stages of English all happen to be called "English".
In an alternate world where Latin was exactly the same as it was in the past, and Italian is exactly the same as it is now, but Latin had never spread outside of Italy, I suspect that we would today call Latin "Old Italian" (or perhaps we would call Italian "Modern Latin"), and nobody would be having this discussion, despite the scientific/linguistic facts being identical to what they are in our reality.
I don't think this is the case: the language that Beowulf is written in is normally referred to as Old English. Chaucer is Middle English. Shakespeare is Early Modern English. William Makepeace Thackeray is Victorian English.
IMO, it's reasonable to assert that each of these are "dead" in some meaningful way: even Early Modern and Victorian English, despite their intelligibility, are simply not spoken by any group of current-day English speakers.
That said, Latin was certainly considered a dead language before Vatican II.
Ecce?! Hui?! Vah?!
Generally, it is recommended that you create a prepared statement entirely from static SQL string(s) (no user input) and then bind parameters into it, such that there is no possibility for any user input to be parsed as SQL:
This is quite frankly nonsense. You have released the software to the wider world it is your responsibility to make sure it is decent. Just because you have released it for free doesn't suddenly mean you can avoid criticism.
SQL injection is such a basic thing to check there is really no excuse.
The default https://fortran.io/ not so much.
EDIT: for a modern, relatively new and highly-used scientific codebase that uses Fortran90 exclusively, see PFLOTRAN: https://bitbucket.org/pflotran/pflotran/src/master/
https://arstechnica.com/science/2014/05/scientific-computing...
Raku (perl6).
You want to make a new array, where each cell in A is added to the same cell in B. So you are going to do a loop over 2 variables, right?
in FORTRAN the code is...
C = A + B
in Julia the code is C = A .+ B
Fortran gets its performance from prohibition of aliasing, which is something that C++ admits as per the standard. One could enable the same performance boosts with a non standard compiler flag, but this breaks a lot of codebases, including the Linux kernel AFAIK.
Aliasing is a pox upon the world. There's a lot of work gone into stuff like UBSan for C++. I think aliasing should be added to stuff that it checks for. Dunno how much overhead that would be though.
But more generic array slicing with strides seems to get nasty in Eigen. For example if
v2 = v(1:2:20)
Map<RowVectorXf,0,InnerStride<2> > v2(v.data(), v.size()/2);
https://eigen.tuxfamily.org/dox/group__TutorialReshapeSlicin...
Different shape for array assignment at (1) on dimension 1
Which suggests that the biggest source of horror would be that most code you'll come across was written by a non-programmer who is intelligent enough to translate an extremely complicated and niche problem domain into very clever and completely un-idiomatic code, who likely was unable to read their own library mere months after graduating because most PhDs don't fully understand their own thesis within months after graduating.
Balderdash. Claptrap. Codswallop. Poppycock. What if you want to revisit it to make it run on parallel processors? Optimize it for a new CUDA architecture or caching scheme? A new instruction set that handles sparse matrices better? Code lives forever, at every level.
Either way, it's not that much horror: http://www.netlib.org/lapack/lapack-3.1.1/html/dgemm.f.html
It's also quite safe for non-programmers. Those non-programmers write complex algorithms, but the code itself is not "clever and completely un-idiomatic". Most often, it is quite naive, just a series of formulas one after the other. You will find very long subroutines, bad names, some obvious inefficiencies, and maybe some spaghetti, but nothing to be afraid of.
BTW, the 'non-programmer' you seem to not think much of probably used an RPN calculator. Food for thought.
If what I wrote lead to that as your main take-away, then I apologize for expressing myself badly, because nothing could be further from the truth! I studied physics myself at one point, and base this on conversations with friends who (unlike me) didn't drop out. Specifically, those who were asked by their professor to update old libraries during their PhD thesis.
Funicular railway:
https://www.youtube.com/watch?v=GO9J7NsM0Ck
Cog railway:
Amusingly, a short while ago I HN-commented on the eruption of Vesuvius that destroyed Pompeii and nearby settlements. Vesuvius also destroyed the funicular that the song advertised, in a later eruption.
Fortran has moved on, even if you professor hasn't.
I know of 4 major languages created in the 1950's: Lisp, Algol, Fortran, and Cobol. Lisp and Algol were brilliantly designed, years ahead of their time, and have inspired nearly every programming language since then. Fortran and Cobol not only look like evolutionary dead ends in hindsight, but they weren't pleasant to use even when they were popular.
There's a reason we still see Lisp posts on HN almost every day, and very rarely Fortran posts.
Although, I don't guess it's any worse than wanting to use your client-side scripting language for your server, or you database query language.
I think some of its infamy is unjustified.
"The March of Progress
> * 1956: Fortran I:
> PRINT 1, X
> 1 FORMAT (F10.2)
* 1980: C
printf("%10.2f", x);
* 1988: C++
cout << setw(10) << setprecision(2) << showpoint << x;
* 1996: Java
java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance(); formatter.setMinimumFractionDigits(2); formatter.setMaximumFractionDigits(2); String s = formatter.format(x); for (int i = s.length(); i < 10; i++) System.out.print(' '); System.out.print(s);
* 2004: Java
System.out.printf("%10.2f", x);
* 2008: Scala and Groovy
printf("%10.2f", x)
"
The reference and the details (2012):
I don't know how to solve this problem. printf doesn't cut it. It simply can't specify an exact number of characters.
%06.*g
I believe this will always find an answer, and the one with the largest number of significant digits.
For example:
void format(double val, int width, char* buf) {
for (int w = width; w > 0; w--) {
int count = sprintf(buf, "%06.*g", w, val);
if (count == width) return;
}
}
Note that you can't represent negative values equal or below -1e-100 since those take 7 characters.
Whether you'd want to is another question rntirely. Might make for a fun weekend project. :)
[1] https://www.microfocus.com/en-us/products/visual-cobol/overv...
The attention to detail in this video is amazing (e.g., MS-DOS window on Mac), and very funny.
http://www.fastplaz.com/ https://github.com/risoflora/brookframework
Devil’s advocate for not writing FORTRAN off completely at first sight.
Apple used to run ad campaigns about how Macs were immune to viruses and therefore highly secure. Turns out enough people just weren't using Mac, and viruses started popping up once it went mainstream.
Captive audience.
> A modern Fortran development environment for Microsoft Windows, Apple macOS, and GNU/Linux systems.
It was quite interesting to read the list of available features [2].
PS: I am sure this is meant as a parody to make fun of other frameworks.
Love the idea.
Peasants. FORTRAN-77 is the real Fortran.
I love it
COBOL-ON-COGS is hilarious though.
To my mindset, this brings us closer.
GOD = ASSEMBLER .AND. FORTRAN .GT. NODE.JSAnd of course "unholy" is itself a metaphor for something which should not be allowed.
What? That's where you lost me.
There's even a CUDA compiler.
As I understand it, lack of pointers makes it possible for fortran compilers to parallelize code quite well.
And after writing a significant amount of fortran 90 code I didn't even know the feature existed...
You could probably even add another zero (almost two) to this
Typically, simulations that I run in MATLAB, Python or R, take 100 to 500 times longer than the equivalents that I write in Fortran. I am sure you can achieve a similar performance with C as well. But the development cost in C is much higher for numerical computing than in Fortran, given Fortran's native array-based syntax, parallelism features, optimization hints to the compiler, and the new high-level string and memory manipulation tools that it has.
That said, every language has its usage and place in the world of programming. In my case, all of the post-processing analyses of my Fortran/C simulation results are done in either Python or MATLAB, and sometimes in R. They complement each other rather than being rivals to each other.
Like some many-angled Lovecraftian horror, it spites reality, sanity and common sense merely by existing.
I don't know Fortran, so I won't use this. But as a dedicated ruby enthusiast, I won't be throwing stones either ;)