Hacker Newsnew | past | comments | ask | show | jobs | submit | jabl's commentslogin

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?

Yes, Unabomber was a total psychopath. Thoreau and Emerson never killed anyone.

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.


A wealth tax is just a warning shot to your wealthy neighbors, if they can afford to flee, they'll flee.

If you're planning a peasant revolt you should really consider going all-in, bloody revolution, you give the kulaks less time & space to plan for contingencies.


They said millionaires would flee when Massachusetts implemented an income tax surcharge. The amount collected from that tax was in fact more than expected.

If the wealthy in California were willing to give up quality of life to save an amount that's not very meaningful to them, they'd have already moved to Texas. Or North Dakota. Or even Washington, which is an actual small-government state without a personal income tax.


People really want to push wealth taxes to the point of confusing income and wealth taxes, and assuming the willingness to accept an income tax surcharge equates to a willingness to accept a wealth tax, when we have lots of data showing that whenever you tax capital that is mobile (e.g., not real estate) then you get less taxes than you expected as well as capital flight.

It's annoying to list your income, but people do it because the disclosure is limited to one year, and more importantly they can control their income, particularly whatever income is earned in a given state. Only realized income is taxed. But a wealth tax involves questions of valuation - of taxing unrealized gains -- that are in many ways arbitrary and subject to abuse, and a level of disclosure and state control that makes many people feel uncomfortable due to the massive expansion of state power it requires.

I don't know why people are so stubborn about this. Next up, they will argue that because people accepted a higher sales tax, they will accept a higher wealth tax, too. After all, you let the state mandate childhood vaccines, so you should be OK with the state mandating your diet, right? Anyways, we'll see how things work in out in California. The state already has massive deficit problems, so let's see how this addresses their fiscal problems.


Conveniently an article just dropped studying the effects of a new wealth tax in Norway. As usual with these sorts of taxes there were a lot of threats that all the high net worth individuals would emigrate to Switzerland or wherever. In reality, it turned out that threat was mostly hot air and bluster. (And of course, you can combine a wealth tax with some kind of exit tax for those that want to take their ball and go play somewhere else.)

https://www.nber.org/system/files/working_papers/w35854/w358...

But yes, you're certainly right that taxing unrealized gains is difficult for many types of wealth. But e.g. property taxes are often already based on some estimation of the market value of said property anyway, so no change there. And similarly publicly traded stocks and such have a clear market value. For other types of wealth, sure there are difficulties, but usually it's possible to do it in some way, be it by estimating the worth somehow or then delaying the tax until the thing is sold or the owner dies etc.


A study from norway? As broadly applicable as studying Saudi.

Yes, in Norway, an oil state with very little mobile capital. Basically what I said about immobile versus mobile capital.

And I guess we will just pretend that Hollande's wealth tax experiment never happened, when 60,000 millionaires left, the state lost $200 Billion in capital, and the wealth tax cost the state twice as much revenue as was generated by the tax. That was for a country, France, whose wealth was not in the ground.


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.


I thought the main advantage had always been the row/column-major order of arrays:

https://en.wikipedia.org/wiki/Row-_and_column-major_order

In short, people solving numerical problems want to write like M[i,j] where i is iterated through on the innermost loop and j is iterated through on the outermost loop... and if the language works in sympathy with them and gets good cache-coherence, that's great, but if the language works against them and would make them write M[j,i] to get the same performance, they don't like it, so they keep writing M[i,j] and let the slowness be the other language's problem.


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.)


Uh... C does have multidimensional arrays. Writing "int a[5][10]" allocates the same contiguous storage as "int b[50]", and accessing a[3][7] will access the integer at ((char *)a) + 3*sizeof(int[10]) + 7*sizeof(int), which would be the same offset as b[37].

It has to be row-oriented because the language allows you to take the address of each intermediate dimension, e.g. int *c = &a[3] gets you a pointer to the equivalent offset of b[30], and legally you can access c[0] through to c[9]. Accessing c[10] would be equivalent to a[4][0] and compilers will let you do it, but I think it's officially undefined behaviour?


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

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?


Also wasting valuable mass... of heavy elements. Transfuse it and possibly even use it as an energy source, or bury it, and let's be done.


So you are 100% confident that a few centuries from now there will be no safe way to dispose of nuclear waste by shooting it into space? Well, maybe you have a time machine, but I don't, so I still think it's a fine idea that we can determine the practicality of later. The point remains that we don't need to solve for millions of years.


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.


Even getting it from storage pools in reactors to storage facilities overland has risk.


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?


Apart from the climate crisis, the other huge systemic environmental crisis hitting us is biodiversity and habitat loss. Which is largely driven by land use changes thanks to agriculture. Using large tracts of farmland to convert fuels, fertilizer etc. into biofuels at barely break-even in energy terms isn't defensible in cases where electrification is an alternative.


Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: