fjh

I'm a bit baffled by this comment, so much so that I find it difficult to believe we've read the same article. I don't see any indication in the article that the author ever submitted any work to SciAm, let alone that he's sore about not being published. None of the examples he cites have anything to do with climate denialism, nor is he defending any pseudo-scientific conspiracy theories. How is any of this responding to the article you're commenting on?

Yes, it's a curious coincidence that the people writing this report, surely in good faith, just happened to pick March 2020 as the point of comparison.

the default would be to just build housing without any regard to affordability.

Luckily, that would still lead to affordable housing, because "just build housing" is what actually makes housing affordable.

That's obviously not the distinction between the parties here. The second one intends (or at least has a policy to) do something about it, but just not by raising the existing CO2 tax.

Do they, though? I don't know how familiar you are with the German political parties, but the concern about climate change is mostly empty marketing on all sides. We should stop running coal electricity plants, but somehow turning off all nuclear plants immediately is more important. We should stop subsidising driving to work, but that would be regressive etc. Most parties are making noises about climate change being bad, but they're all pretty unwilling to accept any trade-offs involved in doing something about it.

I'm saying if you want something effective do be done, look at what the parties are actually proposing to do, not how concerned they're expressing to be in their election flyers.

As an example, 2 parties could both say No to a higher Co2-tax, but one of them does so because they claim climate change is a hoax, while the other one has a problem with it not being progressive enough, thus hitting poorer people harder than rich people.

But as a voter who is in favour of a higher CO2 tax, why would you care about that distinction? If there's one party who thinks climate change doesn't exist and one who believes in climate change but is unwilling to do anything about it, the only difference between the parties is in their rhetoric. I'd argue that voting based on actual policy proposals a benefit, not a drawback of this approach.

The grandparent didn't say nothing bad happened at the protest, they said that Trump's comments were taken out of context, which is completely true. Read the thing in context (here: https://www.politifact.com/article/2019/apr/26/context-trump...) and it's clear that he's not defending white supremacists or anything of that sort.

Corporal punishment, hopefully.

Facebook famously has dual-class shares that give Mark Zuckerberg a majority of the votes. The shareholders can't make him do anything he doesn't want to do.

Why would languages without tail recursion optimisation perform worse when all languages use the naive implementation? It's not tail recursive, so it shouldn't make a difference, right?

Some particular names used in the examples were introduced by Python. For example the `enumerate` function or `zip`. I haven't seen those names used in programming languages older than Python, I know I might wrong.

All the ML dialects that I know have a zip function and ML pre-dates Python by about 20 years. This is particularly relevant since Rust is clearly strongly influenced by ML.

The fact that those are functional I think is not particularly relevant. It's like someone seeing a comparison of Java and Go and saying that those are just the principles of imperative programming, or object oriented programming.

The comparison feels right, but I think it would certainly be odd if somebody explained loops in Go as "a Java idiom".

People can't discriminate on properties that the person they are doing business with can't pick or change [...] but can discriminate on properties that the person in question did choose or could change

Religious beliefs seem to fall squarely in the latter category (at least to the extent that political views do). Are you really comfortable with people discriminating on that basis?

You're right, of course. I blame low blood sugar.

every 5th german is named lars

That is completely untrue. Lars isn't exactly a rare name in Germany, but I'd be surprised if it was even one of the 20 most common first names. It's definitely nowhere near 1/5th of the population.

match also lets you destructure values, which is useful when you're dealing with enums. It also doesn't have C's fall-through behaviour.

Edit: match doesn't insist on a default clause, it enforces exhaustiveness. Which can be achieved by having a default clause, but quite often you just have an explicit branch for every possible case.

House is basically a modern interpretation of Sherlock Holmes, with the same unpleasant personality. Which seems to contradict the idea that jerk protagonists are a new phenomenon.

Don't worry about it. This was back in December, so there is no point digging it up now. I just needed to vent.

When I applied, the interview process went like this:

1st phone interview (screening) -> 2nd phone interview (technical) -> [crickets]

I get it, we are all busy, but I think sending a "No, thanks" email to applicants who have spent time on your interviews isn't asking too much.

"The fucking article's author"

While I appreciate the sentiment of settling debates with data, you have to actually measure the right things. That statistic that says that only 2% of bugs would be prevented by static types? That's based on the assumption that everything that would be a type error in a statically typed language manifests as an exception in Python. But that's obviously not even close to being true. The really annoying bugs that type systems prevent are far more insidious than that. For example Python will happily let you use the greater-than operator on an int and a function. So if you accidentally write `f < 10` instead of `f() < 10`, you will not get a type error, but your program will have a bug that manifests in your program logic going wrong and leading to wrong results somewhere down the line.

I've analysed all bug tickets for a Python system at a previous job for several months, tracking how many of our bugs would have been prevented by a Haskell-style type system. This isn't very scientific either, but for my sample it was somewhere between 70%-90% depending on your interpretation. I'm not saying this generalises to all projects, but I can definitely say that the 2%-number is hilariously wrong.

Rust pulls some really nice trick, but cannot match Haskell.

I'm not convinced that's true. Rust is even stricter than Haskell in many respects (first example that comes to mind is incomplete pattern matches, which is a compiler error in rust) and strictness also avoids some run-time errors. I've managed to produce infinite loops in Haskell by accidentally defining recursive values more than once.

I've used mio and I also have nothing but praise for it, but it is a fairly thin abstraction over epoll/kqueue. That's certainly useful, but it's not nearly as nice or easy to use as the green threads that haskell gives you.

(That being said, I think 'woeful' is a pretty strong word to describe the situation. Sure, Haskell is nicer in that regard, but most other languages aren't.)

I'm interested in writing some random things in Rust, but very much not interested in _re_writing Rust code in newer Rust. This probably means it's still too early for me, if the standard library is expected to expand soon after 1.0.

Why would you have to rewrite code because of an expanding std lib?

Germany doesn't have nuclear weapons.

Haskell could be wonderful. Never tried it. Will someday. Until then, I'd love some sort of competition where a Haskell programmer and myself are given a task, like "write a script to X," where X is some real-world relevant task and not an academic puzzle, and see who finishes it first. It would be illuminating, since I'd give myself about a 30% chance of finishing first, but it would reveal what I'm lacking.

I think one of Haskell's biggest marketing problems is that its strong points (strong static types + separation of side effects) aren't all that important in scripts (or any program that's small enough to fit in someone's head in its entirety), which makes it difficult to convince people of its merits in reasonably-sized examples.

What Haskell gives you are good, solid abstraction boundaries that you cannot accidentally break, and the ability to refactor code with a high degree of confidence that it's still going to work fine afterwards.

Neither of those are particularly helpful for any program that you might write in a competion, but both are incredibly important in day-to-day software development.

The Techempower benchmarks are using the old version of GHC, 7.6

7.4, last time I checked.

I'd agree that the line in this case seems to be quite arbitrary but I'd respectfully suggest that it's not fair to say individuals whom eat meat having not given it much thought.

It's fair to say that giving this issue much thought strongly correlates with thinking that eating animals is immoral. But thinking it's immoral doesn't necessarily imply you are a vegetarian. I can't find the statistics right now, but there was a study that compared philosophers' position on eating meat to the general population's and found that philosophers (particularly ethicists) usually thought eating meat was wrong, even though their rate of vegetarianism didn't really reflect that.

transmute is marked as unsafe, so it can only be used in unsafe blocks or functions.

iPhone notifications, as far as I know.

References, please? And not mathematical references; programming references.

ML has had tuples several decades before Python existed.

Many of the better European universities teach FP languages in their introductory courses. Off the top of my head, Oxford and Edinburgh use Haskell and Cambridge teaches Ocaml.