Perhaps the reason is to prevent anything from spying on the clipboard. Keyloggers are likely prevented by Secure Keyboard Entry. In contrast, websites cannot spy on clipbaord, so there is not real reason to prevent paste on websites.
Historically i believe Fortran language had stronger assumptions that variables arent aliases for the same memory. This means that the compiler can be more aggressive (than e.g. C) in terms of the generated code as it doesnt have to behave correctly if e.g. memory for unrelated arrays overlap. See https://en.wikipedia.org/wiki/Pointer_aliasing
I am not sure if this performance advantage is still the case as the wikipedia page on pointer aliasing notes that C99 added a "restrict" keyword so that the C programmer can tell the C compiler where similar strong assumptions can hold.
Because for example Fortran has multi dimensional arrays as first class entities. C does not. Yes you can get the same speed in C - yes you can do the same things in C but you can do them with simpler code easier to reason about code in Fortran.
You say you can get matrix libraries for C++. And you're right, you can. But with Fortran, you can get (for example) functions that will solve Hermitian matrices, which run faster than solving regular matrices. Or special routines for sparse matrices, which run faster and use less memory. Or...
And you could write every one of those in C++. But the Fortran ones have 30 years of debugging and optimization on them. They're solid. You can't get that by writing your equivalent in C++.
Because Fortran was purpose-built for manipulating array-based data while C++ is a general-purpose programming language. That means Fortran is optimized for this problem domain starting at the _grammar of the language_ while C++ can provide at best access to a locally optimized set of libraries. Those libraries might be quite good, but the comparative experience is still like trying to drive a Phillips-head screw using a flat-head screwdriver.
No, because computer scientists are too lazy to create modern domain specific languages that are powerful enough for practitioners to put to effective use. :-)
Numpy, Scipy and a lot of other numerical libraries use Fortran for the underlying operations along with C. Because Fortran is just faster for such operations and will continue to be. Numba is still very much alpha. Julia is still immature for production (Good language from what I hear but still very much in development).
Don't know if C++ can ever be as fast as Fortran because all fortran compilers are optimized for the architecture on which they run. (Best fortran compiler for intel cpus is by intel). As for ViennaCL I don't know much about GPU programming and its performance. Never done it. (My only exp is with Cython and Scipy stuff)
Intel also has C/C++ compilers which probably share optimizers and backend code generators with their Fortran compiler and shouldn't be worse. Ditto for 3rd party commercial vendors like PGI.
And, BTW, I have seen a case where PGI vastly outperformed GCC on the same code. So compilers matter.
Both Julia and Python use Fortran code under the hood to speed up matrix multiplication. Julia comes with OpenBLAS which is partially written in Fortran, and the following page of SciPy documentation indicates that a Fortran compiler is required for some NumPy modules:
"To build any extension modules for Python, you’ll need a C compiler. Various NumPy modules use FORTRAN 77 libraries, so you’ll also need a FORTRAN 77 compiler installed."
I would also say that no one in the scientific world should be writing ASM for their programs. Does that mean I'm also telling them not to use any compiled language? No.
That aside, you haven't explained why you think the languages you listed are better suited for scientists than Fortran. What are your issues with modern Fortran?
Modern library availability, larger pool of programmers, better compiler technologies, more features that apply to modern hardware, cleaner code, and better documentation are all present on my languages. They are not present on FORTRAN.
All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination. And all are worse performance-wise.
Julia is regarded as the modern replacement for Fortran, but it isn't quite there yet.
The major problem with Fortran is that there is (sadly) nearly no documentation on modern idioms, and occasionally you have to dive in legacy code, which can be... scary, to say the least. Otherwise, it was upgraded really well, without losing performance.
> All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination.
There is some C++ code that is very bad out there but most C++ code maintained by normal people is passable. When I use it I use it as C with references.
> And all are worse performance-wise.
You are incorrect just by the facts of the situation [0][1][2]. This lie has stuck around so lazy people can pat themselves on the back for being lazy. "Yay we did it! We found the best language every! We don't need to learn anything new or update anything!".
The truth is a modern C/C++ compiler like GCC or clang/LLVM can generate far more efficient code than Intel's FORTAN compiler. Not only that but you have access to more performance and scalability libraries when you're not using the programming language equivalent of Latin. You're never going to get out of the MPI ditch that scientists have dug for themselves in a museum piece like FORTRAN. There will be no good abstractions, no well planned libraries, no in language support for newer hardware.
FORTRAN is going to be stuck in the 70s and 90s.
Languages like C++, Python's libraries, Julia, and other languages (like D/Go/etc) are going to evolve as industry needs them to. As we start being able to use less and less of the our computers abilities compilers, optimizers, and libraries are going to allow us to easily pick up the slack. You can already see this things like ViennaCL. GPUs, FPGAs and other tools are coming. MPI and FORTRAN can't be the only tool in your toolbox and if you're lying to yourself and burying your head in the sand in an attempt to pretend you can then good luck to you. You're wasting your budget, the taxpayer's money, and everyone's time on the supercomputer's queue because you don't want to try something new.
But it's fine. Who cares really. FORTRAN is the only language a scientist will ever need. I mean it is the fastest (even if it isn't) and it has the best compilers (even if they aren't the best and we waste thousands and thousands of dollars of taxpayer money to get them) and we know it and that's all that matters. Who cares about broader impact, portability, and future proofing.
This is a huge topic in applying ML in physics and chemistry where we already have a lot of prior detailed knwoledge about the systems we want to describe and it would be silly not to build it into the ML models.
People now try to use ML anywhere and everywhere so it's wild west a little. Three examples: [1] uses a standard neural net to represent a many-body wave function, with all the machinery of quantum mechanics on top of that, and reinforcement learning to find the true ground state. [2] uses a handcrafted neural net, which by construction already takes advantage of a lot of prior knowledge, to directly predict molecular energies. [3] uses a simple kernel ridge regression coupled with a sophisticated handcrafted scheme to automatically construct a good basis (set of features) for a given input, to predict molecular energies.
In all these cases, the ML itself is not the target problem, but only a tool, and most effort goes into figuring out where exactly to use ML as a part of a larger problem, and how to encode prior knowledge, either via feature construction or neural net handcrafting.
I ended up writing a simple distributed build system (https://github.com/azag0/caf, undocumented) that abstracts this away. (I use it at a couple of clusters with different batch systems). You define tasks as directories with some input files and a command, which get hashed and define a unique identity. The build system then helps with distributing these tasks to other machines, execution, and collection of processed tasks.
Ultimately though, I rely on some common environment (such as a particular binary existing in PATH) that lives outside the build system and would need to be recreated by whoever who would like to reproduce the calculations. I never looked into abstracting that away with something like Docker.
(I plan to document the build system once it's at least roughly stable and I finish my Phd.)
I am a scientist who sometimes publishes data sets with academic papers and this looks super useful both as a tool and as a potential publishing best practice. Currently doing away with HDF5 and figshare. One necessary future for academia would be to be able to assign a DOI to a given version of data. Is it feasible for quilt to have such a feature?
We'd love to include DOIs for each version of datasets. I think it's feasible for us to do that, but we haven't scoped out how hard or expensive that will be. In the meantime, if you have a way of creating DOIs from URLs, creating a package version will give you a permanent URL for a version of a dataset. If you have a recommendation for how to implement DOI creation, please let us know. Thanks!
[disclaimer, work for digital science but not figshare]
Figshare currently has versioned dois, so you can refer to a specific release, and the API will let you download each one. I might put some small tooling around this as I release data there myself.
To add on the feature requests, for academia having trust that the data will survive the company going away is something important to me.
As does any regulation. That does not mean the regulation is bad. I wouldn't regulate this issue with specific rules, just put a cost on waste. Each company would need to deal with the product waste in an environmetally safe way. If they can essentially recycle the replaced products into new ones, then I have no problem with that. But if it ends up as waste, then there should be a price on that. I wonder how much would this motivate companies to make repairable products.
RoHS is a limit on toxic chemical concentrations in materials used for electrical equipment to limit environmental and public exposure to a few egregiously toxic compounds (i.e., the solder in a radio can have a maximum of 1000 ppm of lead, but no more). You're probably thinking of the Waste Electrical and Electronic Equipment Directive which is the one that set recycling goals for electronic waste.
Same for me when I was moving to Linux; missing a music player as good as foobar2000 kept me from changing for quite some time. In the end I settled with Clementine which is pretty good, but my music listening actually decreased quite a bit because of the change, strange as it may sound.
Not nearly as customizable as Foobar, but in case you're wondering if there's something better than iTunes, then Swinsian is a fantastic alternative macOS music player: http://swinsian.com/
