plesner

If what you're saying is true then it's easy to provide evidence: just find a case where a company has been successfully sued for not minimizing their taxes sufficiently. I've never heard of such a case and I can't imagine how it could exist and not be mentioned every time a company receives criticism for evading taxes.

It's a common misapprehension but it's just not correct. There is no such thing as a fiduciary duty to minimize taxes. See https://en.wikipedia.org/wiki/Fiduciary#Fiduciary_duties_und....

Incorporating old rancid stock is obviously bad. But besides that -- how bad is this if people don't actually care? The danger of saturated fats is being increasingly questioned[1] and evidence for the health benefits of antioxidants is scarce[2]. If it's just a matter of taste and people like the taste just fine then how bad is this really compared to other cost-cutting measures companies use?

[1]: https://www.theguardian.com/society/2016/apr/07/the-sugar-co...

[2]: https://en.wikipedia.org/wiki/Antioxidant#Relation_to_diet

This looks really impressive. I'm curious what the story is around propagating errors through chains of futures. Traditionally future libraries don't pay much attention to that which can make debugging excruciating, which it doesn't have to be. But then rust does errors differently so maybe it's less of an issue there?

About the naming though, I was a little disappointed. Out of future, deferred, and promise, "promise" is the better term. The two others imply that something will happen later which is misleading because it's fine to have promises stick around long after they're fulfilled.

> L1. There are gaps out there.

I had a similar experience. At one point I decided that I wanted to understand, step by step, how Ada Lovelace's Bernoulli program works[1]. There was a few steps that didn't seem right to me but I was sure if there were any bugs in there they would be well-known and mentioned somewhere I could find. This being one of the most iconic and historically significant programs ever written. Indeed I found more than one person claiming that the program was known to be correct.

It took a long time before I could believe that it wasn't just me not getting it, there were indeed a few things out of place and apparently there was just no mention of it anywhere on the web or in any of the research into the analytical engine I could get my hands on.

[1]: http://h14s.p5r.org/2012/12/bernoulli.html

These things keep happening in Denmark but the thing is, very few people actually care here. Avoiding mistakes of this caliber isn't rocket science but it does take a little effort and awareness and as long as nobody cares there is no motivation to make that effort.

In that sense this is just giving people what they're asking for. They're not asking for security so they're not getting it.

It's possible that it's more a theoretical than a practical problem, I would hope so. But it does seem to me like fundamentally a problematic property of a type system that having more accurate types can break your program. It's the static type equivalent of breaking the Liskov substitution principle.

In their list of risks there's one missing: it makes changing the return type of a method to a subclass a subtly breaking change. Say some api defines a method,

Collection<String> getNames() { ... }

and in your code you do

var names = getNames(); if (...) names = Collections.emptySet();

Now, if the api later changes getNames() to be

List<String> getNames() { ... }

your code breaks. That's one of the advantages of only allowing this on final variables (besides reusing an existing keyword): it means this can't happen. Of course you already have a problem if the class has subclasses but I would argue that this is more subtle and problematic.

No question, we're quickly moving away from physical Kroner. There's also political and especially business pressure to get rid of them. However, it's not true that they're obsolete or somehow similar to new yen.

I think it's a point worth emphasizing because going cashless is a huge decision, especially the way we're moving towards in Denmark. There's a discussion to be had around it and if we just accept that it's inevitable or has already happened then that kills that discussion before it's even taken place.

That's just not true. People pay by cash all the time in Denmark. I happened to read this in line at a Danish supermarket and people were paying with cash as much as with cards while I was paying attention.

You're making it sound like you're disagreeing with me but it sounds like we're in complete agreement on the main point: it's not impossible to create a cPython JIT. It's a choice whether to do it or not. (And by the way, creating a JIT is a piece of engineering, it's not black magic). It's fair enough if people think that would be the wrong choice, I might even agree actually, but if the cPython developers say, time and time again, that python is inherently unsuitable to be JITted then that's wrong and it prevents that discussion from taking place.

Sure there were C-based extensions for JavaScript, that's how it integrates with the DOM. It makes it a little trickier but not a whole lot.

By "bold" I'm also referring to your use of the words "freaking" and "ridiculous".

1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't "we can't make a JIT for python" rather than "nobody can make one"? Because that's how it turned out with JS.

2. If given the choice, do you think the community would turn down a JIT to avoid making the reference implementation more complex? To whose benefit is that requirement? I've never heard people complain about other languages that they didn't have an easy-to-read reference implementation.

3. I've not heard this reported as a problem in practice for languages that have a JIT. It's usually toy programs where the JIT overhead is significant and they're so small and short-running that neither slowdown or extra memory is usually an issue.

4. Not everything that runs on cPython runs on PyPy so that's not a choice I'm necessarily able to make.

I'm not saying there aren't reasons to not have a JIT in cPython. But it's a choice not a natural law. And it's not ridiculous to suggest that they could make a different choice if they wanted, as JS eventually did.

> If you see only print, you are missing the point.

The top thing, sometimes the only thing, that makes my scripts written for 2 not work in 3 is the change to print. Adding a print function is fine, I'm all on board with that; removing the statement though seems like pain for no reason. Bringing that up is not missing the point, it's hitting the nail right on the head.

> Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons.

That's a bold statement. Can you elaborate on what those reasons are?

I agree that Denmark tends to dance to the US's tune but not as spinelessly as you make it sound. If what you're saying was true wouldn't there be US missile on Greenland?

Here's a video of him leading a search quality meeting in 2012: https://www.youtube.com/watch?v=JtRJXnXgE-A.

Why would that be illegal? There is nothing illegal about having other priorities than maximizing shareholder value. See https://en.wikipedia.org/wiki/Fiduciary#Fiduciary_duties_und....

Caveat emptor. The license only gives you permission to use the code, not any patents covering it. So while you can read the code, to use it you need to either get a separate patent license or convince yourself that MS holds no patents on the code. I'm not going to do a patent search, nor do I want to know, but I would be surprised if they haven't patented aggressively.

Not my comment but I think of it in exactly the same terms. You abstract the details of the company away and reduce it to some key numbers, the company viewed at a high level of abstraction.

The company gets to abstract away information that might cast them in a bad light, like bad working conditions, environmental impact, bad financials, etc., and maybe lets them screw over investors. But what makes it really "evil" (thought I don't think evil is a helpful concept to invoke) is that it can also help investors by giving them plausible deniability, they can invest without being bothered by unpalatable "implementation details". It can be used to make it easier to externalize the cost of doing business for both company and investors, to the detriment of the public.

Not necessarily what the original comment meant but it's why I think of it in those terms.

Really like the idea. Unfortunately name might work against them in Scandinavia and other places where kloak means sewer (it has the same origin as "cloaca" in English).

No you're totally right, it's not a pyramid scheme. I still don't think it's a Ponzi scheme though because I don't think a sticker and return postage constitutes an investment. It's just a normal, if unsustainable, trade.

For now. It would be totally consistent with how Ponzi schemes work in real life to start with something legit that turns out to not be sustainable, and then turning it into something fraudulent. Say once people have started sending in stickers they should choose to offer a service where they hang on to your stickers to save you the trouble of mailing back and forth, and doubling your holding every 10 days. Then a sticker would be an investment and it would be a Ponzi scheme.

I can only hope they'll do something like that. It'd be totally in the spirit of Ponzi.

Wouldn't that be a pyramid scheme?

Nit, but: it's not actually a Ponzi scheme. What made Ponzi's scheme a Ponzi scheme was not the postal coupons. It was pretending that investors were making huge profits to make them keep their money invested, and paying them with each other's money. At that point the coupons was just an alibi.

Of course I don't know ponzi.es' long-term plan, maybe they'll start taking investment and promising huge returns. That'd be pretty funny. Though I don't know if you can legally run a Ponzi scheme, even an ironic one.

Apple is not an abstract concept, it's run by people. I'm curious why, in your opinion, those people's decisions on behalf of apple should not be subject to moral judgement?

He's right, this post isn't about gloating. It's a story a manager tells himself to justify screwing over his employees. He says that's what he's doing: "I have an engineer working for me who makes $75k, who is absolutely critical to our company". But it's okay because the employee should just swindle him right back, that's what he did right? And if he doesn't then it's kind of his own fault that I'm underpaying him right? Right?

You're not the underdog. You're the guy screwing over the underdogs. If that makes you feel bad then that's good, it should. Maybe that's a voice you should listen to?

Isn't it the case though that the population is pretty supportive of the government, including its religious policies? Iranian elections aren't exactly free but polls suggest that free elections would give basically the same results.

(See for instance http://www.worldpublicopinion.org/pipa/articles/brmiddleeast...)

That's exactly why I ask.

It feels like languages often struggle with compatibility issues down the road because they assume that they're making all the right decisions from day one. Since you guys are aware that getting this stuff right takes many attempts maybe it would factor in the design process of a new Rust feature that it might eventually be replaced? I can understand if it isn't though, it's another constraint on problems that are already very hard.

I wonder how many of the features in Rust that have changed were designed with that possibility in mind? And if not, whether it would have made any difference if they had been?

Alternative title: the true danger of conflating regular expressions and backtracking pattern matchers. I wonder if it would be possible to reintroduce that distinction.