I still can feel very lost when refactoring a complex clojure system as opposed to something like Rust, because you have very little information about all the places in your codebase where a certain assumption was made.
You can go crazy and spec everything, in fact that can help, but:
- In practise, nobody does it
- Specs come with no guarantees. They could even be wrong.
- The official implementation stubbornly insists on not checking return types, so half of your annotation may just be glorified documentation (although you can use third party libs like orchestra)
Just imagine: Add a new required field to a spec, and get a convenient list of source code locations that you need to review. That's the promise of a statically checked system. It's not a silver bullet, but not having this leads to what I like calling "refactor anxiety" (i.e.: did I handle all cases?)
I still love clojure no matter what. I think in practise you can express so much, so elegantly, and with far less code, that your project size is always sorta manageable.
Fair enough. But that was not my rationale, it was just a made-up corporate rationale that is not too far from what I can observe in reality. Take, for example, lobbyists in right-to-repair hearings. They use arguments like this: "If we let users repair their smartphones, they might hurt themselves, so it must not be allowed and instead always performed by a skilled technician". The implication always being, that if users hurt themselves, they will sue.
> Anyway I guess people can also buy their own computers if they want to play outside the sandbox.
My point was, precisely, that we might get to some point where this is no longer possible. Imagine they stopped selling what we today call "PC", and instead everything is closer to smartphones or tablets. There would be no way to setup a development environment on the machine. There's no sudo access, no compiler toolchain...
While impressive technology, I still get that eerie feeling of my computer's ownership being slowly taken away from me. The problem is not Github codespaces offering us an alternative to traditional dev environments, the problem may be 10 years from now, when someone says: "All the coding is done on the web nowadays, why should we allow users to install compilers and dev tools on their machine? They may use those for hacking and compromising the security of our systems. They may hurt themselves in the process and sue us! Better not take risks". I'm afraid to go into a future where this is normal...
IMO it's two separate things. Both useful on their own right.
High contrast is very useful for people with visual difficulties, but might even be counter-productive for certain types of eye strain.
I'm under the impression people asking for dark mode are looking for something that will emit less light off their screens, not necessarily make it look nore contrast-y, and the two are more often than not opposite.
To summarize, any change that offers more (as in, more fields in the output) and/or requires less (more of the original parameters made optional) is non-breaking.
Edit: Of course, this is all under the assumption that the semantics of methods should never change. Instead of changing semantics, he proposes to just create a new method with a new name.
I know this is a blog post and not a research paper, but I see two big flaws in it that may mislead the reader:
(i) failing to acknowledge that this same task (semantic role labelling / semantic graph generation) is performed by many existing NLP tools and not even hinting at some comparison results. One would think Semantic Graphs (c) are a novel thing invented at Google (TM).
(ii) Presenting the fact that all the intermediate features are magically computed inside a black box as an improvement. This is, to me, a huge loss. There is great value in this classical NLP pipeline they so much criticise, especially in terms of explainability: "Why is mail an agent in the semantic graph? Because the tagger wrongly tagged it as a noun". I can (easily enough) correct the above in a classical pipeline, while I'm wondering how should I stir those neurons in Google's implementation to fix it.
Anyway, this ended up a bit more ranty than I expected. I actually am looking forward to try this out and see how well it works. I think it's very positive that google open sources their research projects, as I find this is surprisingly uncommon in academia.
I feel the web is so much faster on my phone since I started using brave and blocking all js by default. It's surprising how many pages load just fine with no javascript. Most HN articles do.
You can go crazy and spec everything, in fact that can help, but:
- In practise, nobody does it
- Specs come with no guarantees. They could even be wrong.
- The official implementation stubbornly insists on not checking return types, so half of your annotation may just be glorified documentation (although you can use third party libs like orchestra)
Just imagine: Add a new required field to a spec, and get a convenient list of source code locations that you need to review. That's the promise of a statically checked system. It's not a silver bullet, but not having this leads to what I like calling "refactor anxiety" (i.e.: did I handle all cases?)
I still love clojure no matter what. I think in practise you can express so much, so elegantly, and with far less code, that your project size is always sorta manageable.