Eyas

I'll have to check out Heaps. But you're totally right that the "Unity way" of using the editor isn't how a lot of us would naturally gravitate to creating a game. I learned to like it, though (I think).

For me, I realized that wanting to "keep it all in code" is a learned habit, and part of why I learned it is because the tooling when everything in code is just so much better. I can navigate references, etc., count on compiler errors runtime errors, etc. But none of this fundamentally required me to keep it all in code _if_ the tooling allows it. With ~2020 it feels like the tooling is getting to that point.

It's not just about "developer interoperability" vs "program interoprability". Implementing Java APIs means that entire libraries can run.

Sure you might not be able to take a legacy SWING Windows Java app and run it on android, but you can run entire libraries in your android app. It absolutely _is_ about interoperability in both cases. Perhaps to varying degrees

You can blame users for expecting AI to solve everything, but that doesn't mean we give Engineers and Researchers free reign to package, publish, and distribute AI software that falls short of its promise (and introduces dangerous patterns along the way).

That's uncomfortably close to Eurocentric claims of superiority that point to their colonization and exploitation of other countries in the eighteenth, nineteenth, and twentieth century.

I don't necessarily buy it. A pacifist civilization might be "dominated" by a violent civilization, but they might still choose death over becoming violent themselves.

I'm surprised no one here mentioned backwards compatibility as the likely ultimate reason Microsoft hasn't fixed this by default yet.

As others have mentioned, the "fix" of turning off auto-formatting is already available. But many here are wondering my Microsoft hasn't fixed the default.

I assume it's for the same reason Microsoft Excel purposely claims the date 1900-02-29 is valid, to be compatible with Lotus-1-2-3. I assume many legacy spreadsheets would break unpredictably if interpreting values as dates by default changed.

Right. The key innovation of the internet was the invention of TCP/IP for the purpose of inter-network communication. See https://en.wikipedia.org/wiki/Internet_protocol_suite#Early_...

Isn't documenting the failures the important first steps? When people seem to deny that these failures exist, deny their frequency, deny how horrific some of those failures are, etc.

Is there an okay percentage of brutality by police?

When a failure in the system happens, it needs to be magnified, studied, dissected, and the system must evolve to make sure it doesn't happen again. This is how we have safer nuclear plants, airplanes, etc. And in human systems too: coal miners and people on oil rigs have adopted new protocols to help their workers be more safe. The police is not immune. One act of brutality must be documented, post-mortemed, debugged, and mitigated.

They have a vented design which is very similar to transparency mode.

I wouldn't say a generation behind compared to AirPods, but they're definitely a class below AirPod Pros.

So the comment is really about the size of these libraries?

This is more of an artifact of companies that produced them, which use large monorepos, than the ecosystem itself.

That said, you can pick and choose which part of boost you use, just as you can pick and choose which part of Abseil/Folly you use.

I think that's the key point, the scale in which this starts happening is the sizes of the Googles and Facebooks of the world (in C++: Abseil and Folly) but also in Java (at Google: Guava), JavaScript (at Google: closure, Angular/Polymer/Lit/and many others).

So people extrapolating from a ~100 person company or a ~1000 person company using JS might as well think it's about the language, but it's really about the size, I think.

Look at Google and the Closure standard library for an example of a company writing a lot of JS that ended up writing it's own "standard library"-like thing.

Not really reimplementing, Kafka is a great example of a technology you can structure a DOA around.

> Would the data-access layer not them become the development bottleneck in such scenarios, meaning that it doesn't scale as well as SOA?

In terms of development, no, the data layer code grows sublinearly with the with the size/breadth of the schema/data. The data access layer is not much more than a database (plus usually, to enable event-driven programming, some semblance of subscriptions/notifications when data in your query changes). But it's fairly generalizable, and doesn't depend on the size of the team or schema using it.

> Is O(N^2) really that big of a problem? It seems like the problem can be reduced to something simpler: developers cannot easily understand which services communicate with one another. If that is the case, would a visualization tool be sufficient?

It really depends on how complex the system is. At some point, a visualization stops being helpful. There's obviously room to simplify a SOA dependency graph to look reasonable, and many do this successfully. But DOA is another interesting option in the toolkit: turn the problem on its head and say: maybe there's no graph at all.

Same schema, and the service doing the query doesn't need to worry about which tables to union. (Problem with union all is that it reintroduces addressability and a form of direct component interaction)

But sure, you can probably implement that with views etc. also.

I didn't cover it in the article, but the key to get interactivity would be to switch to a datastore layer that supports subscribable queries.

I'm aware of Esper[1] which tries to do this. And maybe/arguably Firebase (?)

[1]: http://www.espertech.com/esper/

Yeah, totally. The way I've seen this work is that a single service will "own" a record, so you never are running into a multi-writer situation for a given record.

While this seems closer to SOA, the key difference here is that single Type or Table can still have multiple produces (of non-overlapping records). In a trading system, you'd have producers of RFQs from makretplace A, B, C, etc. but for each single row in that table, the same service "owns" it. So you still get the benefits of not caring about the DAG/callgraph or knowing about the individual service that calls you.

Locking might be hard if you're doing some transactional change. Those become harder to do. But the half good news is that shifting to an "Event-based" programming mindset might mean you run into less of these.

But yeah, there's a whole new set of drawbacks.

While it's true that SOA generally began by breaking up services into separate binaries while usually keeping one centralized database, a lot of the specific principles of DOA are a _response_ to the distribution/fragmentation of state seen in SOA and micrservices in the mid 2000s.

DOA is often implemented taking advantage of event-driven programming, pubsub, and message passing, which as generalized practices were not as prominent when SOA began, imo.

I gather most people on HN don't like Medium. For those who find its reading style easier, a mirror link is available here [1].

[1]: https://medium.com/p/unexpected-lessons-from-100-test-covera...

Not really https://github.com/microsoft/TypeScript/issues/9235

Though with tuples, etc. being defined, maybe it's worth re-examining.

My bad. The recommendation at Google is to use publishReplay + refCount precisely for that reason, but surprisingly there's so little public documentation on e.g. the publishReplay rxjs operator, that I decided to go with what was ultimately more prevalent online.

Probably worth fixing that though, and creating those resources out there.

Right-- I don't disagree. But I do think 'Observable' is precise here: some streams are lazy, some streams involve pull rather than push, but if someone says "Stream" as a datatype, you don't necessarily know what they mean.

But sure enough, if all we care about is a "collection of observed values, asynchronously" 'Stream' and 'Observable' fit the bill in all(most?) implementations.

They're not quite the same thing. Here's a post that goes over some of the differences:

https://medium.com/@rakia/promise-vs-observable-vs-stream-16...

The big difference is the pull-vs-push scheme, making Observables lazy-by-default, and just subscribed vs unsubscribed to.

Observable is a theoretical concept in reactive programming, popularized by ReactiveX author Eric Meijer.

It's gained quite a bit of popularity because ReactiveX is heavily used in Java frontends and JavaScript (Angular especially).

Definitely a cool area for exploration. I'm not aware of JSON Schema generators from RDFS either.

It should be possible to model the basics (nested structure, repeated structure, defining the "domain" and "range" of a value).

Schema.org definitions however have no conception of "required" values[], however, so some of the cool form validation we see in some of these tools might not apply here.

  [*] _Consumers_ of Schema.org JSON-LD or microdata, however, might define their own data requirements. E.g. Google has some concept of required fields, which you can see when using the Structured Data Testing Tool.