I understand you about the implied contract. I think it's more complex than that. People were making videos before the promise of ad revenue, and they were better videos. If people go away who make videos for money - which will never happen - it would be an improvement overall. If ad blockers do win, YT could edit their ads into the videos themselves making an ad blocker's job harder. YTers who want money could make their own independent deals with advertisers, as some do today. And YT can always charge money - as they do right now with premium. But if YT did that for all tiers, they couldn't dominate and they'd have competitors spring up. They know that. They also know if they ever asked anyone whether they agree to watch ads, most would say No. The prevalence of Ad blockers are proof that people don't want to watch the ads. But, as you point out, we do accept the free content. The thing is the world would likely be better if YT would charge everyone for access. Judging from video quality these days a lot of YTers could be doing something more productive than what they're doing now - I mean in an objective sense, better for economic health. But the real reason for these $0 tech services is to stifle competition and prevent the market from working. And that works to everyone's detriment. Basic economics doesn't function without prices.
I agree with this. There was no meeting of the minds, no contract. But, the terms in the Google account probably include something about the terms for viewing youtube videos.
No, piracy is defined as stealing a vendor's exclusivity by making copies and putting them up on a web site. Ad blocking is not the same as making copies and distributing.
You might as well argue that covering your ears during a TV advertisement is piracy. That's a strange definition of the word if I ever saw one.
Judging by the response to the parent come back, evidently TSMC deserves the high prices it will be charging. Why?
It's unrealistic to expect just anyone to start up a new fab. But if not one person among billions will start up a new fab it points to intrinsic difficulty or unpleasantness or lack of prestige in the task. A correctively high price has all kinds of advantages for the society.
I haven't seen any argument that difficult tasks shouldn't be priced high. Only name calling.
> I was daunted by making the jump to C, then c++ and python. Only over time did I overcome the nerves and move on with Java, [...]
It sounds as if you did skip C++ and moved to Java instead. If so you serendipedously avoided the one language that's likely to cause problems. C++ doesn't work like the rest of the languages on your list, and it really is as full of land mines as people say - even though, with a good process, evidently it can be managed.
> A new language / style / technology / whatever very often will leave us less competent.
This may be a big factor in rejecting unfamiliar languages. Over time the brain trains itself to grok a specific syntax, and understanding becomes partly automatic: we look at a Java program and our brain injects meaning into our consciousness. If we then look at APL or Lisp, however, that training on Java doesn't apply and the automatic injection doesn't function. We're left having to read the symbols directly, and it's unsettling not having the auto-assist. It makes us feel we "can't" understand the language, when it would likely take a couple weeks of immersion to change that impression.
I too appreciate detail-free programs, and I wonder at the value of including all the typedecls and pointer markings, and lifetime markings, and mutability markings interleaved with the logic. Some people I guess believe that the details are "part of the program" and they aid understanding. Do you buy that?
I find that sometimes typedecls aid understanding, but they get in the way if they're the least bit complicated. I'm better off reading the program. I never had problems understanding Lisp programs for some reason.
> [...] show people posts from the people they follow or that the people they follow liked.
Yes, this is a good system. It'll work particularly well at filtering spam because people largely agree what it is. One thing that will happen with your system is people will separate into cliques. But that's not the end of the world. Has anyone implemented Anthony's idea of using followees' likes to rank posts?
I never did any real programming in APL, but I studied it over about 2 months. When you get used to the symbols, reading spelled-out words feels like reading in slow motion, or being stuck in molasses.
Most (not all) APL code I've seen uses very short names, often one letter names, for function names. And APL programmers are famous for cataloging "idiom" which are short phrases for common subroutines. In other words, it's best practice to repeat 3- or 4- symbol phrases instead of defining a subroutine.
Of course, there's nothing about an array language that requires using symbols; but for some reason most do.
I saw a video where a mechanic replaced a pack on his Model S with a 100Wh pack. There were some minor issues of fit, which he had all figured out. There was a connector change and some sheet steel around the edges that needed changing out to make it physically fit. The procedure was to keep a table under the vehicle, lower the vehicle so that the pack rested on the table, remove the last retaining bolts on the bottom, and lift the car back up. Reverse for install except he had to align it first. He estimated it would take 2 hours total. This car was designed for fast pack exchange. The coolant connections were self connecting and disconnecting.
Then came the software. The amount of complexity and jargon and issues and roadblocks that come out of nowhere is extraordinary. You have to dive several layers deep in a menu system to do step 1, then get hung up on opening a "gateway", then dive down the same menu to do step 2 of a 2-step process. He had another problem that kept him busy but what impressed me is the amount of time and complexity to do the simplest things. He wasn't performing many steps, but just getting to the step required rebooting, waiting, pressing the brake pedal to see when it was time to move the right turn signal stalk, didn't work, go back, do something else for 10 minutes, try again, it seemed endless.
German automotive companies have historically been terrible at software. Just because Tesla hasn't simplified or integrated their various software components yet, doesn't mean others can't do it nicer. But any company that doesn't value software like the Americans do is going to have a real tough time with the EV software problem.
If Google has failed so far to resolve mem safety issues in their decades old giant code base, then I'd rather hear standardization ideas from someone who succeeded. If G succeeded at resolving those issues, then that's a concrete positive example for the rest of industry to consider following. They ought to lead by example.
It seems like decades-old giant code bases are precisely the ones hardest to migrate to memory safety. That's where coercion and enforcement is needed most. You and I don't need to be told to start a new project in not-C++ do we? Nearly every trained programmer has been brainwashed (in a good way) with formal methods, type systems, bounds checking, and security concerns. Now those same people who champion this stuff say it isn't enough, and therefore we need to do more of the same but with coercion. That's a failure to understand the problem.
The article in question is published on Google's blog. Has Google resolved memory safety issues in its C++ code base? Did G port their code base to Rust or some other memsafe language? What's preventing them from doing that by themselves?
What's preventing Microsoft, or Apple, or the coagulate Linux kernel team, or any other kernel team, from adopting memsafe technology or practice by themselves for themselves?
The last thing we need are what are evidently incompetent organizations that can't take care of their own products making standards, or useless academics making standards to try to force other people to follow rules because they know better than everyone else.
If the team that designed and implemented KeyKos, or that designed Erlang, were pushing for standardized definitions or levels of memory safety, it would be less ridiculous.
At the same time, consciousness of security issues and memory safety has been growing quickly, and memory safety in programming languages has literally exploded in importance. It's treated in every new PL I've seen.
Putting pressure on big companies to fix their awful products is fine. No pressure needs to be applied to the rest of the industry, because it's already outpacing all of the producing entities that are calling for standards.