matcha_addict @ matcha_addict @lemy.lol

Posts

59

Comments

681

Joined

2 yr. ago

Nothing is without effort. I want something with high confidence. Most organizations fail at testing in one way or another (riddled with false positives, flaky tests, or outright low coverage). Tests are good to have, but they are not enough for what I want.

magic solution

If you think type systems are magic, then sure :)

plesse let us know if you find one

It looks like I can leverage certain type systems to do this. I might need to work with it more before concluding.

Interesting analogy, but it's probably better to address my point directly instead of arguing about woodworking

doesn't mean other code should be using it.

Yes you're right. Sorry it wasn't clear from what I said before, but that's what I am saying too. The point is, if such a change is made, it should explicitly address every code that uses that entity who just added a new field. When I say "address", I mean that the user must at least be forced to "sign off" and explicitly saying a part of the code does not need to be changed due to this change. One possibility is explicitly declaring that a field is not used.

I hope this makes it clearer.

If there's anything that doesn't make sense in my question, feel free to ask any questions or clarifications on any part of it.

if a new field is added and not used in other places, compilation will fail

That's if the field is added but never used. If it is used in some parts of the codebase, but not used / handled in others, compilation will pass. I would prefer that it doesn't. I would prefer that if such a change were to occur, that every part of the codebase that uses that entity is explicitly addressed by the change made.

Again, if there's anything you don't understand, feel free to ask me directly. I do not get notifications when you reply to a comment that isn't mine.

Alright grandpa time to take your meds

Depends on what you consider technical. I don't see this as much different than how type systems prevent type errors.

Just like type systems prevent you from type errors that you may otherwise write unit tests for, I don't see it unviable to have something that protects from the errors I mention.

In fact I think my solution might be in particular use of the type system, which I am experimenting with right now.

Thanks for the tip! I think that is indeed what I need. Thank you :)

I gave an example use case in the main post, but I'll summarize it again here:

Suppose we have a to-do task manager. A task is an important entity that will be used in many parts of our codebase.

Suppose we add a new field to this task entity. For example, let's say we now added a priority field in our task that previously didn't exist, so users can define if a task is high priority.

The problem: this task entity is being used in many parts or our codebase. How do we make sure that every one of those parts that needs to use the new field does use it? How do we make sure we don't miss any?

I hope this makes sense. If it doesn't, feel free to ask any questions.

How did Zed get so much publicity? Do they happen to have a lot of funding or something? I've seen a million of these posts and I'm just really uninterested, as does a big portion of comments I see.

Typescript, but that's not the issue. You probably have to leverage types in a specific way to get all the protections I am talking about. For example, I want it such that if a new field is added to a type, every user of the type must explicitly either use it or explicitly declare that it won't. From my experience with type systems, you typically aren't required to explicitly declare that you won't use a field in a dictionary / record type.

I think you are right. I did not consider this. Will try that next!

Testing definitely works, but the downside is it requires the developer to be proactive, and the effort put in writing tests is non-trivial (and it's easy and common for developers to write bad tests that give false positives).

Automates tests definitely work, but the downside is it requires the developer to be proactive, and the effort put in writing tests is non-trivial (and its easy and common for developers to write bad tests that give false positives).

This is related to what I discussed in the "Searching" section. Entity fields may not be necessarily imported, so they would not be caught in this. Say you're using that field's name in a SQL query, HTTP or GraphQL request / query. This may also not be caught by IDE.

This also would not cover the case where a field is modified without necessarily changing its name, or a new field is added and now the code using that entity is not using the field.

Our politicians may not always get along, but at least they agree about hating brown people.

Someone had to yell "fire extinguisher not guns!" for them to even consider doing anything other than raise guns at a burning man.

I'm being anti assuming cops will be helpful buddies when you do things near an embassy.

That is the point I make. Never trust cops. They will rarely ever be helpful.

Real footage of security cops hard at work:

Secures the embassy from a man caught on fire (very capable!) and is outside its fence. Could you imagine what would've happened if they weren't there? Yeah, still no threat to the embassy :)