I've had some experience in programming in early "pedagogical" languages. Typically the environment that surrounds them is terrible.
The compiler is slow and buggy, and to top it off, the languages might look good on a whiteboard, they tend to have fundamental flaws (oversights really) that make them painful to program in. Kernighan has a fairly famous essay enumerating a big long list of such flaws.

Contrast this with a "real" language rather than a pedagogical language, which has had its environment optimized and its corners rounded until it works well for industry, and has glaring flaws fixed and is more or less feature complete.

I guess I'm not arguing against any particular language so much as arguing against a novel language invented specifically for pedagogical purposes by someone with no industry experience and then push that onto students before it has had a good 10-20 years of industrial exercise and development. The result is students who find programming painful and hate programming.

Programming the early versions of C wasn't great either. Things like function prototyping made a big difference. C++ has had its fair number of changes over the years too. And how long has python been around, and even python has had some annoying corners rounded in the last two years.

I haven't looked at Racket, I don't know how well honed it is, sounds like it is old enough to maybe be mature in this sense, but really, how many lines of real applications have been written in it for it to be mature? Python certainly is plenty mature. But please don't push your invented novel unrefined pedagogical language on new students. Maybe in the 90's there were not a lot of good options, but today there's plenty.

As other commenters have said, the point is not learning the language, but learning the methods and algorithms, so the language really shouldn't matter. So what's wrong with doing that in python?

If you're going to do a painful language for pedagogical purposes, use C or assembly. Don't invent a new painful language.

Tell me when I can plug a reasonably sized stack of these into an LED and have it on forever.

Any security company who thinks a good security model is to tell the accidental publisher of API keys to stop publishing them rather than fix the idiot who gave them to the publisher needs to have its reputation ruined. This is not a security model.

Github should extract all the API keys and put them on a web page with the heading "If your API key is in this list, you need to invalidate it and change it."

The robust discussion I think actually was very productive, in that it will result in less crashy code that is a lot simpler by removing unnecessary functionality.

The slashdot summary mischaracterizes and possibly misquotes Linus's comments. He didn't say that inode numbers are obsolete, he said they are irrelevant for VIRTUAL filesystems (like /proc ) , and at some point it was (half jokingly) suggested just setting all file inode numbers to 0.

He then went on to say we don't care if it breaks tar, because using tar on a virtual filesystem is stupid and it should break. Not in so many words, he basically said if you find a use case that is sane then it is worth making them unique.