galacticpony

I was interested to hear the argument up until "Ruby on Rails" showed up. If "Ruby on Rails" does what you need, that's great, but then I'd say you're barely programming anymore, just like writing HTML/CSS barely is programming.

If we just go down another level (where you would implement something like Ruby on Rails), the same question appears. Do we favor explicit logic over implicit relations? At that level, I'd say the rule of thumb that "explicit is better than implicit" pays off, because it's often not that much more code, and a lot of code builds on top.

...so preoccupied with whether or not they could, they didn’t stop to think if they should.

I was about to write the same comment. Since you beat me to it, I'll just point out that this guy really should put on a proper shirt.

data contained in an exe (or dll) is not necessarily in RAM at all time

If you read the article, you'll see that what Corral is right now (i.e. the supposed "next generation") is in fact being abandoned. It's a dead-end, at the very least.

I'm not doing your homework for you.

Many languages in use today don't even have a (first class) concept of unions or structures, at least not in the sense that you are talking about. If you're talking about about "bloat" those contexts, you might want to start somewhere else...

...maybe because JSON is one of the worst serialization "protocols" in common use?

If you ever need an argument for why "worse is better" actually rules the world of software, point to JSON and drop your mic.

>> The downside is then if you just get a message without knowing what it is about it's difficult to figure out.

You're saying that as if there was a clerk reading the message at the other end. If a computer program gets a message it doesn't "understand", it's not going to "figure it out" either way.

Worse, if you're a programmer that doesn't know the actual schema and you're trying to figure out what the schema might be just by looking at the data, you'll probably run into trouble.

You're being completely disingenuous here.

Nothing is competing with HTML on being what HTML is. Nothing is even close.

All text encodings in common use build on top of ANSI. The de-facto standard (now) is UTF-8 and there's no reason to change that.

IP really does move all the data around the entire internet (that's kind of in the name right there!).

Yes, there are variations, extensions and incompatibilities, but these things are not being re-invented all the time, exactly because these things are ubiquitous standards.

The manpower behind Linux is superior. Not sure if it's the "vast majority", but for many business cases following the GPL(v2) rules simply is not a problem.

Both the PS4 and the Nintendo Switch run on FreeBSD, by the way.

Some people care about privacy. Most probably may even care about it to some degree, but not to the degree where they sacrifice their convenience for it.

Again, the media has done its best to scandalize the very real privacy concerns with companies like Google and Facebook. Did it hurt their success with the unwashed masses?

If privacy was really such a big deal, why would Uber write that blog post in the first place? Sure, enough people complained online to get it pulled, but that's not representative.

To wake people up, we'd need a real "story" here, like somebody getting fired over googling something relatively innocent.

Finally, if advertisers really try to disguise targeting, they're doing a terrible job at it. Just try turning adblock off for a moment to see for yourself. Yes, even the common folk thinks targeting is creepy, but at the end of the day they don't care that much.

Yes, it is. Fair points, good luck!

> What other game dev tools can a user on a Chromebook use? Or an Android device?

Well, you're kinda making a point for me there. Why would a game developer use a Chromebook or an Android device?

The second point applies more or less to an Electron app, too.

Like you said, this is all theoretical. You can reach "the whole world" with the right browser. At that point, you might as well ship an Electron app.

But that's not even the point of my question. What I actually meant is: Where is the benefit for the user? I wouldn't want to use applications in-browser, unless there's some real value in that. For everything else, I strongly prefer a "native" application.

This isn't a new problem. We "know" the common people don't care because all attempts at scandalizing this in the media, for years, have not found much resonance.

...even for a team of one developer!

Look, I understand how one might like HTML imports. Once you've gone down the rabbit hole of Web technology, all the fancy experimental features make it look like HTML/CSS are now adequate. They're not. It's a trap.

The real answer is writing Javascript (or something that compiles to Javascript). Always has been, always will be. Don't trust the web consortium to specify things that maybe browser vendors will implement. Do it yourself now, thank yourself later.

There are web applications that are way more demanding than this, that have run on more platforms for a while and that don't need any of these questionable experimental features.

I could understand if you said you need WebGL or WebAudio or some other hardware/OS interface. You don't need HTML imports.

> Those of us that do understand the technology have a duty to help the people without that knowledge and experience.

No, we don't. The fact that the "common people" don't value privacy enough led to this whole situation. Those that do value privacy, can pay for it with their money (or their time to learn).

Can't you just... program that stuff yourself? By relying on such "cutting-edge" features, you get all the drawbacks of web technology with none of the reach.

Does anybody ever actually want to do serious work "in the browser"?

I can think of many drawbacks. Where's the benefit?

Second Line:

"However, in practice, the short seller is required to post margin or collateral to cover losses, and inability to do so in a timely way would cause its broker or counterparty to liquidate the position."

That's exactly what the Bitcoin exchange will do, as well. Since the exchange actually holds the assets (i.e. bitcoin and dollars), it can also determine whether such liquidation is backed by orders.

What you're talking about is a "naked short", which is of course very risky. No Bitcoin exchange allows for this. In fact, most exchanges don't allow for shorts or any sort of leverage.

While what you're saying may be true in some context, it doesn't apply here.

You're cleary not familiar with the context at hand. You don't know how exchanges like Bitfinex operate, what the terms of use are, etc.

Everything you said so far is just wrong in context.

Not if you simultaneously BUY ON THE OTHER MARKET.

Jesus.

You also can't lose money beyond what you put in (on the exchanges that allow for this), your position just gets terminated.

What does that have to do with anything? You don't understand the point.

You go short on one market, while simultaneously going long on the other market. That's how you profit (arbitrage).

How so? This is a rather a case where a law is being followed to the letter to an objectively worse individual outcome.

It's highly questionable that having 20,000 free videos removed from public access is the intention behind the law. More likely, it's an unwelcome side-effect.

Why should the law not allow an exception for free content? Why should the law put the burden squarely on the provider? The tradeoff isn't in having "everyone" participate or not, it's in who pays the bill.

I'm making a general statement, not specific to UC Berkeley. Even if you don't consider UCB a business, most of its income does not actually come from taxes and its spending isn't going to be all that different from a private university. Clearly, their decision here was not to spend, but to delete instead. That was the economical thing to do.

You're also missing the point completely. Whether a business wants to do something depends on whether it is expected to be profitable. If the laws make it unprofitable, then it doesn't want to do it.

You're posing a false dilemma with "it's more important that those persons be allowed to participate in society than it is for a business to make money". If society wants participation, society should pay for it, not just business. It's just really easy for the government to use people with disabilities, because opposing such legislation is unpopular.

Who decides what's reasonable, anyway? If you're a small business, building some ramp can easily break your budget. If you're McDonalds, it make no difference. Are you going to treat both companies equally? If so, you're sponsoring big corporate.

This is ass-backwards. If a business has to spend extra time and effort to fulfill some regulation to provide a free service, it's just not gonna happen. Everybody loses.

Even if it wasn't a free service, if the regulations make the venture unprofitable, it won't happen. Same for taxes, etc.

If the legislators want "standards", they had better pay for it out of the tax payers pockets, instead of shifting the burden to business, where it doesn't belong.

> Yes, it has since at least 2010 (and probably earlier).

See my reply to whitequark_, this seems to be loop-specific.

> The Vec classes can be used as Point structs.

Oh, sure. Which one though? How do I abstract this, again?

> So pad it out to 4 fields, using homogeneous coordinates.

In other words, "do something else than what I originally did" and "potentially leave 25% throughput on the table".

I think you're trying to pull a fast one on me.

> That's not making a lot of assumptions about your compiler. The x87 floating point stack, for example, has been obsolete for a long time.

Did you even read beyond the first paragraphs? There's five compiler-specific flags you'll have to get right for any of this to work.

Again, there's no free lunch...

> I disagree. Let's look at actual examples. "Almost certainly" suboptimal abstractions are not what we've seen in Rust, for example, which leans on abstractions heavily.

Could you just scroll up for a moment? We are talking about this because someone wrote the "abstract" version of squaring a number and some optimization didn't kick in, resulting in significantly degraded performance. And that's a trivial example! In a real codebase, you'll have to carefully audit compiler output to see if it does the right thing, potentially requiring you to rewrite code. For Rust, you also have the blessing that there is only one compiler...