jabl

Oh, absolutely. Music might be a shit career unless you happen to be in the top 0.01%, but it's a fantastic hobby. Being able to play or sing something yourself is immensely satisfying (maybe not so satisfying to your neighbors, but I digress).

I've been wondering if we're going to end up with some kind of backlash against all the autotuning, 'gridification' as this article explains, etc etc., and AI slop as well as deepfakes filling up the interwebs. You can't know what's real anymore. So people will start preferring live performances. Not only live music, but, say, theater/musicals/opera instead of going to the movies, and so forth?

Not saying this as some kind of general "anti-AI" argument or anything. I'm not advocating for the Butlerian Jihad. I find AI a very useful tool, and I used it at work pretty much every day. But for art, which in a sense is a celebration of human creativity, something gets lost if we use AI to generate it, doesn't it?

In defense of the analog simple life I suppose it's possible to be a hermit without sending out mail bombs to people you believe have not seen the light?

Capability-based security might be the bees knees, but how would one retrofit it into an existing kernel without breaking backwards compatibility?

COMMON, ENTRY, and EQUIVALENCE are certainly frowned upon in modern Fortran style, as the language has gotten less error prone ways of accomplishing the problems those features ostensibly solved. But they still exist in the language for backwards compatibility.

To this day some Fortran compilers put large local variables into static storage rather than the stack. Because many old Fortran programs were written with the assumption that all procedure variables were statically allocated, and thus having huge arrays as local variables wasn't an issue.

This kind of code then easily breaks by overflowing the stack if the compiler allocates them there.

But this then doesn't work that well if the procedure is called recursively, or concurrently from multiple threads.

Making this even worse, in a recent Fortran standard (2008?) this was reversed such that procedures must be explicitly marked with NON_RECURSIVE in order to allow the compiler to allocate variables statically. Undoubtedly the right decision given the increasing prevalence of threads as well as recursive algorithms, but a gotcha for compiling old dusty deck code.

I remember helping a research group port some old Fortran code they had to a more modern environment and compiler. Turning on array bounds checking made the program crash pretty quickly. "There can't be a problem with the code as we've published papers with it". Umm, sorry sunshine, that's not how it works.

That is true, but on the other hand if you had to pay a hefty yearly property or wealth tax you might not be able to afford it in the sense that your wealth is bound up in the house.

The counter is of course that when you buy a house you should make sure you have enough income and/or liquid wealth so that you can pay the taxes. And if not, move to a smaller house. Of course, opponents of such taxation will then roll out all kinds of grannies living in mansions on meager pensions. Then again, is it fair that this prices out younger people from the property market?

As difficult as they are, I do think we'll need some form of wealth taxation in order to put a brake on spiraling inequality. Yes, call me a fan of Piketty if you want.

Nah, that is mostly about keeping the ordering in mind when iterating (e.g. do you iterate first over innermost or outermost index?). And there are algorithms such as (naive) matrix multiplication where the correct order for one matrix is the wrong for the other one, so plus ca change.

But speaking of arrays, one definitive advantage of Fortran is that it has built-in multidimensional arrays in the language. Which is very nice when writing code that needs them. In C many people resort to the Fischer-Price My First Multidimensional Array implementation where they allocate each row separately, which is of course horrible. (In C++ you can use libraries like Eigen or Armadillo which use expression templates and operator overloading to have sensible multidimensional array support even if it isn't built-in.)

There are several reasons why Fortran historically has been faster. Many of these are because Fortran is less strict about what the compiler can do so allows optimizations that wouldn't be allowed in C. Such as:

- Procedure arguments are not allowed to alias. Similar to restrict pointers in C99+. This is often critical to allow loops to be vectorized, but the onus is on the programmer to ensure no aliasing or else you get UB.

- Unspecified evaluation order for expressions. E.g. C requires that "a+b+c+d" be evaluated as "((a+b)+c)+d)" and with floating point it can't do it another way due to rounding. Fortran can do e.g. "(a+b) + (c+d)" where each subterm can be computed in parallel, but again at the cost of slightly different results due to rounding behavior for floats.

- Old school Fortran lacked pointers which led programmers to program algorithms using arrays rather than fancier data structures, which cpu's love.

In principle there's nothing preventing a competent C or C++ programmer can reach Fortran level performance. In practice, might be difficult.

Of course, nowadays performance is much about designing for cache hierarchies (see e.g. "Data Oriented Design") where Fortran doesn't have a built-in advantage.

The Royal Navy indeed won many battles "that mattered". Saying that Chesapeake is the only one is just ridiculously ahistorical.

Of course, I can't predict the future. So sure, if we in the future have some magical Star Trek technology that would make space travel entirely safe and ordinary, sure. Won't happen with anything like chemical fuels though, thanks to the tyranny of the rocket equation. And if we have such magical Star Trek technology, surely we'd also have the technology to transmute the waste into safer elements that don't present a long-term radiological hazard (that we in principle know how to do already today, it's just prohibitively expensive for little benefit)?

In the meantime, while waiting for the magical Star Trek future to arrive, I'd much prefer if we'd store the waste we have and continue to generate in a safe and responsible manner. Which, whether we do reprocessing or not, would involve deep geological disposal. If we later come up with a significantly better idea and for some reason have a motivation for doing something, sure, then we can dig it up again and shoot it into space, transmute it, or whatever the idea at that time is.

What I'm saying is that with anything like current day rocket technology, disposing of nuclear waste by shooting it into space is just a laughably insane idea.

Massively larger than the risk getting it from the storage pools to the space launch facility, to the extent it cancels out the definitely non-zero risk of the rocket launch failing?

This is getting very off topic, but this "let's dispose of nuclear waste by shooting it into space" is such an insane idea. In which universe is the risk associated with a frickin space launch lower than a deep underground geological repository?