> The energy-driven reduction of entropy is easy to demonstrate in simple laboratory experiments, but more to the point, stars, biological populations, organisms, and societies are all systems in which energy is routinely harnessed to generate orderly structures that have lower entropy than the constituents from which they were built. There is nothing physically inevitable about increasing entropy in any of these systems.

is so straightforwardly incorrect that it frankly just should not have been published.

In a competence culture, you try to understand your sphere very, very well, including not only the current facts of the matter but how those facts might change under different circumstances. Then you try to understand enough of spheres of people around you that you can bracket what will affect you, and how you will affect them. It's implicitly understood that the functioning of the entire enterprise comes from people doing this.

In anti-competence culture, the functioning of the entire enterprise is mysterious and located somewhere else where it's not your problem. You only know as much about what you're doing as you need to barely keep going. You try to know as little about what's going on with others as possible, and if there is any interaction between you, you try to minimize and even resist it, in the hopes that you will have to change as little as possible or changes will be discovered to be unnecessary or deemed to be too expensive.

You want to stay in the cultures of competence. What the article is describing is just how much of the other kind is out there.

This is not an "extra" claim on top of conservation laws/fundamental symmetries.

> Reductionism can be understood as a combination of (1) the claim that the intelligibility of the universe depends on the unity of scientific theories

It's strange and frankly likely just projection to say that it's the reductionists that claim the universe must be a certain way in order for it to be intelligible.

> Despite its limited usefulness as a guide to scientific practice, reductionism is a powerful cultural idea. We might call it the Lego-block conception of reality: only the Lego blocks are real, so ‘fundamental’ science involves identifying what the blocks are and how they interact, while ‘applied’ science involves discovering the right combination or permutation of blocks that accounts for the phenomenon in question.

The question of realism is separate than reductionism of fundamental law, and it's not a good sign to (deliberately?) confuse them. EDIT: Just to be clear to people skimming this stuff, I can hold two theories: a) your dog is real, b) your dog is not real, only quarks are real. We can debate this for as long as we'd like, but what I am not necessarily saying is that your dog's dogness corresponds to some suspension or modification of fundamental physics.

> that parts and wholes have ‘equal’ ontological priority, with the wholes constraining the parts just as much as the parts constrain the wholes.

Again, if ontology means "realism" this is a confusion, if it means the way things work, it's simply wrong or completely unsupported.

Kafka creates the abstraction of a persistently stored, offset-indexed log of events. You read all events in a topic. Kafka can be used to distribute messages in the way AMQP is used, but is more likely to be the centerpiece of an architecture for your entire system where system state is pushed forward/transformed by deterministically processing the event logs.

You can say, well that wouldn't work! But now the idea is that the structure of this model feudal society is justified by reasons like "people won't follow someone if they don't have a gold hat and a scary sword" and not by any process that led to selecting the particular feudal lord.

The trick comes in when we switch without acknowledgement to describing the system for the distribution of wealth and status.

This kind of "meritocracy" is more like if we held an arm-wrestling tournament, declared the victor to be our new feudal lord, the next 6 runners up to be knights, and everyone else to be peasants. Our position in this new society was based on "merit", but that can't necessarily justify the difference between nobles and serfs.

We could even re-run the tournament every year. We could make sure no child gets extra time in the weight-room because of her noble parents. We could decide that arm-wrestling is stupid and brutish and so, in a glorious revolution, switch to speed chess. None of it would address the question of justice.

I find the "Liskov Substitution Principle" is an awkward way of pointing at the idea that your usage of subtyping should not render the type variance in your system nonsensical.

For a while I've assumed that OOP as in C++/Java essentially formalized modular programming in C. In other words, that people were already writing programs whose state was divided into functional areas, with some functions serving as the interfaces between the modules. With a class-based system you can rigidly formalize this; and then OOP as we use the term essentially just reinterprets this formalization as actually creating the architectural paradigm that had already evolved as programs grew.

(This is NOT meant as the one way to sum up the whole world of things identified as or related to "object-oriented programming".)

But I wasn't around at the time...

This cart-before-the-horse is so pervasive in social sciences, and developing sciences like neuroscience, that it's understandable one would ask why history can't get in on the action.

The glib invocation of phlogiston theory is telling. The essence of phlogiston theory is not wrong!

(What you can do is remove unnecessary coupling, but you're doing that anyway...)

First, look at what happens to the system from the outside, say a web request that leads to a web response. In between, information is gathered from other areas (databases, program logic) and combined with the request data. There are also possibly other effects generated (writes to database state, messages to other users, etc.).

Now take all of those “effects”--the web response, but also the database updates, logs, messages, etc.--and look at each of them as a tree (going left to right, with the root, the result, on the right) where different kinds of information were combined and transformations were performed in order to get the result.

We’re being conceptual here, so imagine we’re not simplifying or squashing things together--the tree can be big and complicated. Also temporarily ignore any ideas you may have that there’s a difference between information coming from the “user” area versus the “admin” area versus the “domain object #1” area. In this world, those stores of information only exist to the extent they enable the flow that produces our results.

Now notice that there are many different requests and many different effects and responses. Thankfully, some number of the inputs are shared and reusable. Further, entire spans of nodes are in common (an event type) or entire subtrees are in common (a subsystem). These are your data streams and your modules. You didn’t add them in because you felt like there had to be a “user service” or an “object #1 service”--those commonalities factored out (to the extent they did) of the requirements of the data flows.

Often, there isn’t an “object #1” at all--that was a presumption used to put stakes down so you had somewhere to start. And our systems that are made of up of things like “object #1 service” and “object #2 service” very frequently end up with problems of the form: “we can’t do that because object #1s don’t know about [aspect of object #2s]! Everyone knows that! We need a whole new sub-system!”. In the data-driven world the question is always the same: what data do you need to combine in order to get your result?

This isn’t to say all modules we usually come up with will turn out to be false ones (especially since a lot of the time we’re basing our architectures on past experience). For instance, that there is some kind of “user” management system is probably made inevitable by the common paths user-related data take to enter the system.

Now for the reverse argument: imagine you have a system that was done with the sort of modeling where there is an “object #1 service” that must get info from the “user service” and work with the “object #2 service” through the “object set mediator service”. You’re tracing through all the code that goes into formulating a response to requests, from start to finish, but someone has played a trick on you: they’ve put one of those censoring black bars over deployment artifacts, package names, and class names. The punchline is that your architecture inevitably is one of the trees described above--it’s just a question of how badly things are distorted because someone presumed the system comes from the behavior of “object #1”s and “object #2”s and not the other way around.

In other words, the appropriate way to describe your system would not be (subscribable) relationships between a set of components that describe your presumptive view of a division of responsibilities. (This is the non-event driven way of doing things, but with the arrows reversed.)

Instead, you track external input types, put them into a particular stream of events, transform those events to database updates or more events, etc. Your entire system is this graph of event streams and transformations.

These streams may cut across what you thought were the different responsibilities, and you will have either saved yourself headaches or removed a fatal flaw in your design.

If you're thinking about doing work in this area, don't just reverse the arrows in your component design!

For example, this:

This observation which they refer to as the “hard problem of content” or the “covariance-is-not-content principle” is that systems acting on covariance information, while acting on information, do not constitute content-bearing systems, because to bear content is to embody claims about how things stand, when in fact they merely embody capacities to affect the world.

is just complete nonsense, and to extract the charitable reading I put in quotes above, you have to read closely for paragraph after paragrah to see that what's going on is the word "content" is reserved to mean "things brain-like things do in a brain-like way to other brain-like things in a context built for brain-like things."

Again, okay! But: it's wildly misleading to frame this as being about mathematical logic or the metaphysics of symbols, syntax and semantics.

Comments URL: https://news.ycombinator.com/item?id=20947539

Points: 2

# Comments: 0

Yes, this article is pretty much misleading end to end, and not taking into account the cost of heating is the keystone.

Everyone who thinks about this issue should stop cherry-picking some particular consumption good you think should be curtailed.

One, it's anti-humanistic, you'll end up getting slammed for telling (poorer) people from hotter areas to suck it up, and contra the article, you'll deserve it.

Two, analytically it seems to confuse even people who should know better. You have to take the whole system into account.

Directly pricing the externalities of carbon emissions solves both of these.

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

I think it boils down very simply: the intra-group dynamics can't be opaque to whatever mechanism regulates the group. Hence making the group dynamics unknown to the instructor but not providing group members some other mechanism does not work.

Letting students punish/fire each other would just open up lots of other ways of things being unfair that would need their own mitigations. (In the real world this takes the form, very imperfectly, of a boss' incentive alignment and employee exit.)

I think the only reasonable answer is to not make individual contribution opaque to the instructor. Git/etc (for code and documentation) may be your friend here.