evdev

This is correct. The ActiveX is very, very real.

The whole area is heavily, heavily reactionary and slow moving. They're on embedded XP because that's the closest they can get given the software platforms they're dependent on.

You're right that locked down embedded industrial (Linux) PCs are the best option, but your control platform has to run on them...

This, from a former coworker, might give you a good sense of the state of things:

https://www.youtube.com/watch?v=tPWKJR6IVfA

Agree that this is a more interesting comparison than AMQP.

From my perspective, problems with facebook:

1) Anti-privacy, megalomaniacal nature of network.

2) Social cost of having removed the normal ways we moderate each other's behavior. E.g. when someone is a narcissistic bore, you talk to them less and less at the barbecues and eventually events start happening they're not invited to. Facebook takes the people most willing to ignore social boundaries and customs and puts them center stage.

3) Opportunity costs of not having mechanisms to form more naturally-moderated social groups, but with a wider pool of potential people than are in your physical social graph. This has always been the dream of the social internet.

4) "Fake news", specifically the moral hazard of providing an environment that plays to the "worst" tendencies of media consumption. This is obviously dependent on our values, and how patronizing we're willing to be. But the hazard is a real issue especially when your network attracts people under one pretense--hang out with your friends/kids/grandkids--and then has this non-advertised effect of sticking you in a media echo chamber. This unlike when people choose to go out and fight their echo chamber in a way that's fairly important.

5) Like 3) but now for "good" media consumption, or a Healthy Democratic Civil Discourse, or whatever. I'm glib because this is on the razor's edge of smuggling in whatever values we daydream about imposing on the world.

A lot of us can come up with the David-and-Goliath dream of a distributed network, but I think it's interesting that this is probably neutral-at-best for 4), which is the issue du jour. One could easily see things getting worse and articles being published with the thesis that people need to be de-balkanized for the sake of civic discourse.

Also, the REAL contrarian take here is that things are close to optimal. People are succeeding at 3) and by extension 2), just in niche special interest groups that aren't salient to us in the steady state. The "problem" is that many of us lack the conviction or self-direction to quit media behaviors we don't like. Meanwhile 4) and 5) are really about the bankruptcy of modern ideologies, etc. etc.

When I first saw this, the concept of "rejected energy" from the pink boxes seemed to need some explanation. From the outside view, nothing is "wasted"--there's just the cost and benefit. You compare alternate sources and alternate uses this way. Losses don't really mean anything unless they are comparative, and the only thing that matters is the ultimate value of the work, not what you would get if you ran a science experiment to figure out the joules.

Even the losses in electrical transmission don't really mean anything unless compared to an alternative, which will have its own losses, and which can't really be compared kWh but instead relative cost.

Someone can correct me if I'm off-base.

FYI I found this a great article otherwise.

Summarize.

What I've found matters in this area is the mismatch in locality between elements in read batches and elements in write batches. It'd be nice if the emerging DBs that deal with these issues put at least a gloss on the information model and write -> read lifecycle they're targeting.

Otherwise, a lot of these "actually you need X for time series!" are just talking past each other because "time series" means any number of actual patterns.

There's a weird, undefined use of "nihilism" threaded through this piece.

I laughed out loud at that paragraph.

To be clear: obviously the assertion itself might be true but is very possible to deny. To make matters worse, the support for the idea is basically that services that charge the end user nothing have destroyed the revenues of services that had the ability to ransom themselves for money. Whether that's good or bad to the broader public is... complicated.

The point isn't to learn it as if it's something you'll have to recreate--it's to understand that "advanced" language features are built on top of the "fundamental" structural model and are not magic. You need some understanding of how programming languages are built in order to keep languages and libraries honest. Otherwise learning about type/object systems becomes learning all the pitfalls and incidental complexities caused by the design as if they're benefits and not costs.

Yes, I think it's very reasonable to use a scripted dynamically typed language to learn control flow to start with. We tend to forget that the basics of loops and mutation are a hurdle for many people.

I think there's a tension between two imperatives in teaching new programmers:

1) Learning must be applied learning. Give people problems to solve and they will come to you for data structures and algorithms, O notation, etc. If they don't, they should do something else

2) A lot of what's out there in programming languages are cargo cults, and newbies need to be prepared for this. For instance, virtual function inheritance isn't a thing. It's a weird call chain pipeline system glued into your vtable, which C++/Java teaching also won't bother to tell you exists. Make people start from assembly, graduate to C, then write their OWN vtable, so it's demystified. Now you've reduced the ability of software designers to piss on your leg and tell you it's raining.

So ideally I'd want students (at first) to be doing something either close to the machine or in the functional model. As they say though, the imperative of 1) means getting people to actually produce something, which is easier in Python.

match { case v: java.util.Date => }

This still works without case class extractors and is useful. That's what I mean by matching and binding.

Extracting/destructuring in the match statement can sometimes be more trouble than it's worth. It's definitely brittle to changes in the case classes. Then there's the question of the (difficult to reason about?) cost of the abstraction.

IMO the hierarchy of need for this goes:

1 - case classes / value classes / data classes, whatever you want to call them.

2 - match-and-bind syntax

...

11? - fancy pattern matching

This maybe says more about how much I pay attention to what's upstream in Java, but I found the fact that this is just a hypothetical proposal, in April of 2017, strangely shocking. I guess I figured it had to be on the docket for a future java version already.

Does anyone know of analogous work re: the size/# of IO buffers? It seems like a similar problem.

It was a track runner with three parallel tracks, "bombs" and "coins" approached you, making sounds either in front of you, to your left and right. Your job was to avoid bombs and get coins.

Pretty simple "action" game for the visually impaired. The joke is that we spent an absurd portion of the time on the visualization. The justification was that it would also have appeal for the sighted.

In my college software engineering course we built a game for the blind. It had full 3D graphics.

I always felt a pang of guilt that we were walking away from the project when the class was over, since some of the kids did like it.

Just a note to people who are encountering this for the first time: adopting SBT, deciding it was a mistake, and going back to Maven is also a common narrative.

"Build/Package/Release logic is complicated, and deserves sophisticated tools and abstractions just as much as the code it builds."

This seems correct until you realize that the #1 priority for your build system is to not be spending time screwing around with your build system. The benefits of using Maven to stay with the herd ends up dominating any benefits power you get to come up with clever build mechanisms. Then, yes, maybe you have an ugly shell script you have to run in your CI--but for all the crappiness of that, it's still composed on top of the thing that you basically never touch.

I've heard first hand from one big marquee Scala company (you could get it in a couple guesses) that this was basically why they were going to move away from SBT. That was years ago, so do with that what you will.

As a Scala guy on a Scala team, I'd think this would be most immediately useful on smaller fill-the-gaps sub-projects where we have to integrate with native code.