Chabsff

If you read Asimov's short stories and novels, you'll find that the point being made over and over again is that despite them sounding ironclad at first, the laws are naïve, futile, fraught with unexpected ambiguity, and ultimately cause more trouble than they solve.

People have this idea that Asimov envisioned a world where robotics was based on the rules, but it's the opposite really. He was claiming that there is no such thing as absolute rules once intelligence starts getting involved, and that nuance and grey areas are inevitable. The three laws were never more than a straw man to be taken down, and it's really weird to me whenever anyone uses them as some kind of north star wrt/ to AI ethics.

So in that sense, the comparison is definitely apt :)

Expecting an exported document to behave as close as possible as the hosted version is not exactly unreasonable in general.

Why do you think OP isn't refering to mmap()? Its behavior is pretty much what they describe, and a common way it's used.

To address the unit test stuff: I'm not saying that type systems replace unit tests. I'm saying that unit testing in dynamically typed languages is fundamentally deficient. Or in other words: unit tests are made more reliable by type systems.

Unit tests can only check outputs for the inputs that are provided during testing. Leaving the input unbounded means that they can only provide guarantees for code that conforms to the tested subset of inputs.

I may be able to test that `foo(3) == 4` and foo("foo") == "bar", but since I can't guarantee that `foo({})`, or literally anything else, will never be called, there will always be holes in the safety net they provide. This is something type systems directly address.

> And so if you feel your type system is going to make your refactors safe, well, good luck to you and the poor people who have to use your code.

safer. It makes them safer, not automatically safe.

100% agreed on all points. But even in these languages, writing generics remains greatly facilitated by the use of type inference, which is all I'm saying.

> Is there anyone making that claim? Apart from straw-men?

For every intent and purpose, the person I'm replying to is, with an equivalent level of straw-man-ness, which is why I phrased it this way.

> So if you claim your type system is going to keep your refactoring safe, I'd say that I'm not the one being delusional.

No, I'm claiming that there are entire categories of bugs that are protected this way, not that it provides universal safety.

> And of course unit tests also tend to, in practice, catch the errors that are caught by types. If you check that a value is equal to 10 rather than 9, you've also implicitly checked that it is not of type PinkElephant.

It provides that if and only if the code invoking the tested function is called with arguments using the same semantics as the ones exercised in the tests, which is impossible to enforce in a dynamic language. I'd even go so far as saying that it is axiomatically impossible for unit testing to be a truly reliable tool in such languages because of the lack of precondition enforcement.

And I would contend that anyone claiming "I am capable of taking everything about the code I am tasked to change into consideration" is delusional when it comes to non-trivial projects, including single-dev endeavors.

As far as serialization IDLs and API conventions go, they have the very special constraint of having to provide both forward and backwards compatibility across multiple applications, making them a very poor universal example.

Well... It is true of everything in that blog post.

But I am wiling to have my mind changed. I would be really interested in seeing a study that failed to find a benefit of type systems for refactoring tasks in large projects. The example I posted in my initial comment seems pretty open-and-shut to me, so I'm curious.

Admittedly, that was a bit hyperbolic on my part.

What I meant to convey is that the matter is settled enough from my point of view that there needs to be a very strong case being made for me to be willing to engage in that conversation.

Thanks for pointing this out, I've amended the comment to clarify a bit.

I'm arguing that the studies linked in that blog post are fundamentally flawed because they only take into account first-pass development, and fail to take long-term maintainability into consideration. And this is silly because that's where the main value of type systems reside.

> This paper presents an empirical study with 49 subjects that studies the impact of a static type system for the development of a parser over 27 hours working time.

"Types lead to fewer bugs when making changes to long-lived codebases" is not up for much of a debate in my opinion. Preventing regressions is arguably a lot more important than writing a correct first pass, which is what you are evaluating when looking at non-evolving code.

Concretely-speaking, an example of a bug being preventd by a typing system: Removing a field from an object in a large vanilla JavaScript project is inherently a minefield that has caused many bugs in the past, whereas the same alteration in a full Typescript project can be made with confidence.

The moniker you are looking for is "duck-typing". Polymorphism is tightly tied to the notion of explicit interfaces.

While I agree with most of the post, it's just the tip of the iceberg of the discussion. Stuff like interfaces, traits, generics, concepts, inference, duck-typing, implicit conversions, etc. all fuzzyfy the notion of "Strong Typing" in various ways, some more than others.

The real discussion is not about types vs no-types, it's about the role and place for each of these bending of the rule and their associated tradeoff in different contexts. Op even takes inference for granted towards the end of the post, but make no mistake, that's a form of weak(er) typing.

For example, writing template code in C++ without frequent use of type inference (aka. auto) can be an absolute nightmare (I suspect that extends to generics programming at large, but C++ is where I have the most experience here), and the legibility gains from making use of it for iterators is broadly acknowledged as being easily worth the obfuscation for scope-limited variables. But there's also a strong case being made to avoid its use entirely in most other contexts.

But I'm also that OP whom you replied to and I never once mentioned that gas prices have anything to do with the cost of operating the blockchain.

It's only people trying to tell me that the overhead is negligible who seem to be under the impression that low technical overhead means low overhead in general. Gas prices are evidence to the contrary of that.

If I want to operate a service on top of the eth blockchain, I have to factor in gas fees as part of the operation costs.

That's overhead.

If the overhead was negligible, then so would gas costs.

What's preventing people from engaging in these transactions is not a technological problem, but generally a regulatory one.

"This allows people to break the law", which is what you are saying, is not a good thing, even if a subset of the laws being bypassed are unjust. It's the opposite of utility as far as I'm concerned.

Your second point is entirely fair, but only insofar as the added value provided by blockchain cannot be attained by other means.

I challenge you to pick a single example from this list that at the same time can't be done without blockchain, warrants the monstrous overhead, and provides utility other than "make money".

Yes, I should have added that I'm referring specifically to the scenario OP is suggesting, which would require a host <-> client IPC channel, opening up the VM to similar attack vectors to a sandbox.

That's kinda-sorta what they all do already. Not full OS-level VM abstraction, but surprisingly close to it. Exploits like this need to be paired with sandbox-escaping in order to do damage beyond the current browsing session (which VMs wouldn't help with in the first place). And the distinction between sandbox-escaping and VM-escaping is rather thin.

> Although I do dislike that there's a large category of "achievements" nowadays that are nothing more than telemetry for developers.

That's always been the case. Some XBoX360 games went as far as having "reached the main menu" achievements in order to create a baseline user count that didn't include demo terminals running the attract mode on loop.

I agree that cheevos-as-telemetry sounds bad at face value, but consider it the other way around:

Getting pain-free already anonymized telemetry stats via achievements through platform holders has long been a bulwark against intrusive bullshit telemetry by way of making the effort-to-reward ratio of the later just not worth it. This is not unlike the classic "The way to stop piracy is to provide a better UX" argument.

It also has the very important added benefit of making what is being collected extremely transparent to users.

It's necessary because some (let's face it, X) social media companies are suspected of lying (aka engaging in fraud) to consumers by claiming that they are taking aggressive action against hate speech while not actually doing so.

Sure, they could just take them to court for that fraud and get that information via discovery, but just compelling companies to publicly disclose the info bypasses all that and puts the decision making back into the hands of the consumers. And what is more American than that?

The reports are to sent to the attorney general who has to make them publicly available to everyone, including the universities.

That being said, the fact remains that you are presenting the law as if it was was you expect the next step to be, which is misleading at best.

The law doesn't compel any form of moderation though. All it does is require transparency. How is that censorship?

It's not so much that there are people who genuinely believe that stuff, there have always been some of those.

The issue is that they have managed to reach a critical mass where they can exert some real and harmful social and political influence.

It's hard to believe nowadays that conspiracy theories used to be a fun thing to engage with leisurely.

The important part is that all the intermediate strings used during the computation are constexpr, to guarantee that the work happens during compilation.

Also, constexpr symbols can be demoted to regular const as needed by the compiler if necessary, such as when getting a pointer to one. constexpr doesn't mean "compile-time only", it means "compile-time compatible"

Ideally, functions should be clear at the call site without a reader having to jump to the declaration to understand what's going on, and you don't get the return type there in the first place.

Consistency. The rationale is: "always use auto as the return type, and add a postfix type if inference can't do the job for a reason or another."

Perhaps, but this has little to do with it.

In what scenario is user-auditable traceability of firmware images anything but a good thing?