antris

I have no idea if Apple should buy Peloton or not, I was just objecting to your reasoning. It's completely normal to get acquired by another company and keep on working on the existing products as is, that's all I'm saying.

Why not? If Apple buys Peloton, they also get all their staff and offices. The existing staff can continue working on their existing products just as before, while transitioning to Apple, no?

> Where do you draw the line?

When the abstraction can be considered 100% leak-proof in practical terms. Also, if you have alternative tools when you encounter a case where "X" doesn't fit, you do not need to learn about "X" as long as you have "Y".

But when a solution is presented as "this must always be used", the solution should have been around for a long time with a track record of never breaking. If that's where the abstraction is, it's usually solid enough to not go any deeper.

In my experience, most developers don't talk about "magic" as if it's the same thing as "abstraction". "Magic" usually means an abstraction that leaks under non-trivial conditions.

> If they shut you down on the App Store, you're done. Your iOS app is worthless on any other platform.

> I shit you not, I've personally had apps rejected by the review board because they didn't like the screenshots. Those were screenshots of the app itself.

My experience sending applications to the app store was certainly frustrating as a first-comer as the App Store has numerous rules about the screenshots, descriptions, naming etc. that you have to follow.

However, every time the app got rejected, the reviewer sent clear feedback on which rules the submissions were violating and how to fix those issues. After that, you could send your app for another review. Calling that "shutting you down" is slightly harsh in my ear. We fixed the problems they had with our submission and then we got approved.

Can you give us examples of cases where the police are running out of legal options in their use of force?

Wouldn't duplicated textures get de-duplicated by any halfway-decent compression algorithm though? I'd assume the game is sent over the wire compressed

"Picture to QR code converter"?

I must be missing something... What does this have to do with photo realism?

Highly structured and rule driven practices are key to all safety. Hospitals, military, airlines all depend on a rigid set of safety instructions that are followed without exceptions.

Same goes for explosives. Many governments around the world set various different rules around storage of explosives, and the Beirut port explosion was a result of ignoring pretty much all of them. It's an example of what happens when the government isn't there to do its job.

Cheapest option is to not buy a car and or go by public transport or a bike.

And the reason why gasoline cars are as affordable as they are now is that the carbon tax is not here and cars are heavily subsidized in general. Carbon tax isn't even really a tax, it's more akin to removing a subsidy (you cannot pollute for free anymore and make someone else pay the costs)

Back of the napkin calculation is not a source. Economy is a bit more complex.

edit: Imagine being downvoted for asking for a legitimate source on HN. Because rejecting UBI by making a simple multiplication is a sufficient explanation instead of researching all the secondary effects that a UBI would bring. Yeah, we've solved it there, I guess! Economists should go find some real jobs /s

Quite bold statements there without linking to any sources. "I won’t pretend to be an expert" Yeah, you definitely shouldn't.

Also, you are missing the target on the parent comments argument. The carbon tax wouldn't affect the poor as much because the UBI is there to compensate for it, that's kind of the whole point. There's nothing about being poor that forces you to emit more carbon when compared to other people, as far as I know.

If the self driving cars are significantly safer than human drivers, it's a bit hard to argue that self driving cars should be banned.

TDD and unit tests aren't exactly the same thing. Also, not doing TDD doesn't mean that there's no automated testing. I prefer to write my code and then do a few end-to-end automated tests for the most important parts of the code to serve as a backup in case some change in the code causes massive failures. But TDD is overall tedious for (usually) little benefit when compared to a few well selected end-to-end tests. And unit testing is even less benefit for even more work, unless you are doing something very very specific.

If the code is that bad, unit tests aren't going to help you. Messy spaghetti code with massive structural issues will break every unit test every time you change anything in the code, in ways that make no sense and provide you with little useful information. You will fix things faster if you just let the tests fail, fix the code and then rewrite the tests. Which makes the unit tests useless.

Also, have you ever seen a project where the code is a mess but the unit tests are perfect? Even if somehow you could write unit tests that would cover for super bad code (which you can't), it is extremely unlikely that your unit tests would be that amazing.

> IMO the only systems where this “type system eliminates most tests” philosophy seriously works are the ones that don’t do anything other than pass data between components without doing anything beyond calling some serialization methods.

Which is what 90% of programmers on this website are essentially doing. And for the remaining 10% there is likely a better suited, different programming language or type system available. Even if there isn't unit tests would still be very niche and the general case would be that by default you shouldn't be unit testing.

You are correct, however that's a niche use case that would warrant using a non-conventional type system. Conventional type systems are mostly for just dumping a bunch of strings and integers to and from a database and formatting them neatly.

Additionally, even if you know the use cases, often I find it more productive to form the code of the application one use case at a time. This allows greater focus on the task at hand. People cannot effectively multi-task so breaking focus into different use cases at the same time is slower and causes more mistakes than just coding one use case at a time.

I would argue that having a robust type system and some (not too many) end-to-end tests for your software makes unit testing almost completely useless overhead.

You'd be still trusting the compiler. However many layers of checks you do, there's always something you need to trust.

If you go down that road, you can make this argument infinitely. Even if you verify your builds, you cannot know if the software you are using to check the build isn't compromised. Or if you check the software you use to check the build, you have to check the software doing that check and so on.

Nothing makes software automatically super-crazy-secure. Absolute security doesn't exist.

A huge part of the knowledge I had to acquire in the early years of my development career is now useless or even harmful... Anyone remember clear: left; ? :D

It is very rare to have to support Internet Explorer anymore for new applications. Most software that requires IE support is legacy enterprise stuff. Microsoft has been promoting Edge for 5 years already over IE.

How do you know a website is pure HTML? The developers will tell you about it.

If there's Javascript on the site, then surely the JS code goes over the wire too?

If we are talking about preservation, we would most likely want to be able to preserve everything made using Flash, rather than pick people who used Flash "correctly" and preserve only their work.

Not a data scientist myself, but plenty of data scientists in a consultancy company that I used to work in said that they have to implement variants of a limited set of models over and over again, because they couldn't reuse code and infrastructure. The project contracts demanded that all IP created by the consultant is the property of the client. This even caused some of the data scientists to lose motivation, because the job wasn't challenging to them intellectually as it involved setting up the same stuff again and again. Very rarely would their actual expertise be needed in the job.

I am not sure if this particular service solves the problem for them in any way, but to my ear it sounds like there is a need for code and infrastructure reuse in the data scientists domain that is ripe for innovation.

Not everyone wants to be an admin to their infrastructure. Real existing services like Heroku and Squarespace exist as useful services because even though you might know how to design and build a website from scratch, sometimes you just need something done quickly without too much worrying about details of the system that do not matter for your project at this point. I really don't see how this wouldn't apply to AI projects as well.

I could make a much better site coding my own website from scratch and setting up servers myself, but for some projects I wouldn't even think about it that way, because using Heroku or Squarespace I can save a LOT of time and get the results I need much quicker.

How's "Pepsi's mistake cost innocent lives by an exploding grenade"? Technically correct, but sounds even more horrendous and catastrophic, while technically 100% correct. If your argument is that the title is trying to be click-baity they could've probably done a lot worse even while staying with the strict facts. I really don't think the author meant to clickbait.

I wonder if there's some kind of software that takes an advantage of an AI to teach non-beginner players Go. E.g. you could play against the bot and then the AI would translate your mistakes into what you can improve upon.