Encoding it into your source file has positive externalities. If you're using source control, the comment controlling the linter is tracked alongside the rest of your code. You can track who added it and why. You can share this comment with other engineers on your team.
You could also imagine other representations of the same data (e.g. one large file which includes annotations, or a binary representation). But in this case you lose colocation with the code they're annotating, so it's more likely to drift.
I fully agree that there are probably better UX's out there for this flow, but the source annotation approach is popular for very good reasons.
We recently just deployed Traefik at $job, and found it pretty easy! I didn't do the work myself, but I directly managed the engineer deploying it. It was predominantly reference material but that was really all we needed to get it set up.
Half Dutch half American. I find the Dutch complain a decent bit more, but I find that there is more to complain about in the States. Maar wat is het leven zonder klagen?
One thing I've noticed being back recently: cost of living has gotten very unaffordable in Amsterdam the last time I was back. Cost of basic goods is on par with what I'm used to paying in major American cities, but my Dutch relatives often earn a decent bit less. I wonder if this will affect Dutch happiness in future surveys once affordability exceeds more and more people's earnings.
My understanding is that as part of the Amtrak Improvement Act[1] Amtrak is given preference over freight rail, even on private track. However only the Department of Justice may enforce this, which it has done only once.
Fair warning I haven't read the text of the law in full, only heard this second hand.
Not Hakan, but I was working closely with him at the time. Lyft was on a microservice many-repo setup, and we did pin the version of golangci-lint.
I've found it's actually not so bad to do this kind of work across many repos, as long as you have the tooling to apply the same change to any number of codebases all at once. Our strategy was typically:
- Write an idempotent codemod to do an upgrade. This is easy as long as your configuration is in a declarative language.
- Regularly apply it or update it on all of the applicable repos.
- Merge upgrades incrementally until you've upgraded 100%.
I've been messing around with a graph-based interface for task management over in https://github.com/crockeo/ekad. The interesting branches are:
- `main`, which currently houses a custom interactive graph visualizer built on top of the great `vello` from linebender (https://github.com/linebender/vello).
- `ch/typescript`, which has my attempts at joining a more traditional task manager with a graph visualization.
The issue is that uuid4() would be called a single each time the app was launched when that code was first loaded. Each record produced by an individual instance of the app would have the same ID.
The section "Forget the Theory of Computation, AI will Soon Replace Programmers" feels as if it's missing a practical slant that explains this trend. I think approaching it from a purely theoretical perspective misses the relationship between real software and real problems.
First: most practical problems are computable, and most practical programs do not run forever. Even if an agent had to run a program to termination, it could still use the feedback gathered from running it to make modifications.
Second: an agent with a sufficiently good intermediate representation _which is computable_ doesn't need to actually execute a program to model its behavior. Humans do this all the time--we can read code and understand its approximate function as a means to edit it. I don't want to claim that LLMs have a concept of "understanding," but they definitely build an intermediate representation which, when combined with external input (e.g. having to kill a program, because it exceeded a timeout), can be used to modify the program.
Now with all of that said: I don't feel confident about whether or not AI is actually serious risk to programmers, I just don't feel as if this argument is sufficiently compelling.
I don't believe in the death penalty because I believe taking a human life, no matter the context, is amoral. A murderer may have already committed that injustice, but it does not mean they deserve the same. To me there is no imbalance in empathy just an alignment with that core belief.
You could also imagine other representations of the same data (e.g. one large file which includes annotations, or a binary representation). But in this case you lose colocation with the code they're annotating, so it's more likely to drift.
I fully agree that there are probably better UX's out there for this flow, but the source annotation approach is popular for very good reasons.