While you can use uniform registers to implement the uniform keyword from shading languages, the two are not the same. Uniform registers are not constants, and they are only uniform/shared across one warp. Nvidia architectures before Turing did not have uniform registers.
Visual programming languages are not prevented from using textual symbols, though. And many people use diagrams to communicate ideas more efficiently than they could with text alone.
This is a really interesting system, and I'm excited to give this a try!
Without knowing whether the following cases would actually be useful/relevant, I'm curious if these things apply to Unison:
- Is there a way to "pin" a symbol to a specific hash/version so it won't automatically update when the referred function gets a change? I.e. I could write:
A = B@ ++ "world"
and when I store and retrieve it, it becomes (example syntax):
A = B@a3yx ++ "world"
- Is there a way to refer to a function/symbol by name rather than by hash? I.e. a call site which uses B by looking up which hash is currently associated with the name "B", such that if I do two simultaneous renames, B->D and C->B, the code would now refer to the function previously known as C?
- Are there ways in which the way function updates "bubble up" through the codebase (I assume updating a function means updating every function that calls it, recursively) could become a problem? It would seem that changing one little function could have a knock-on effect that requires re-hashing most of the codebase.
> It's not a matter of identity, but explanatory power. To reiterate, the self-acknowledgement/'diagnosis' as autistic (not ASD) is 'useful from a self-compassion and tolerance standpoint'. So instead of, why do I find X difficult when everyone else finds it easy (or even laughs/condescends/points it out), I can say, I'm autistic, that's not easy for me.
It bothers me a bit that, if you turn it around, the lack of an explanation would be an impediment to self-compassion and tolerance. "I find X difficult" ought to be enough, whether that coincides with any other traits (autistic or otherwise) or not.
You make a good point. The "I find X difficult" is a 'disability' trait, and disabilities are only really relevant where they conflict with the expectations of wider society. In all cases it's really the social exclusion that's the problem. If someone has a trait that either can't be changed, or takes exceptional effort to mask, it shouldn't be on them to do the impossible. If however it's just habit, or actual lack of effort to change, that's a completely different thing.
Which could be a coordination problem, though. Where initial high costs are due to a lack of scale whereas if everyone participated, costs would come down fast.
>The whole point of interfaces is that you're not supposed to care how a method is implemented, only what it does which is explained by a combination of context, naming and documentation.
There are, however, cases where code is a better explanation of "what it does" than naming and documentation. Both naming and documentation are hard and can become out-of-sync. Code is less ambiguous than natural language.
Sure, I'm not saying nobody should ever read code. I'm just saying we should aspire to write code which does not need to be read to be understood at a high level. If you really need the low-level details they're there, I'm just saying I don't want to have to think about them if I can avoid it.
As an example I've never read the source code of any language's String implementation, but I've used them in many different languages.
I also don't like the "they can become out of sync" reasoning. That's like saying speed limits are pointless because people break them. If you change the code you update the name and comment. That's your job. I'm not saying you should document every class in your system like it's the Java standard library. A standard library doesn't change that much and its documentation is viewed by millions of devs so it makes sense to spend a lot of time documenting it.
That's the gold standard, it would be great if our code could be like that but it would be impractical given the frequency of change in most active development systems. So we find a middle ground, we focus our effort on the interfaces between subsystems. You section your codebase into subsystems so that the application's core can interact with the database without worrying about database details, or get some data from an API without worrying about whatever weird quirks the API has. You construct a subsystem around the API which handles all the API details so that your core can interact with the API without having to worry about auth or weird API quirks or the fact that the API entities have 50 properties and you only need 7 of them. You hide away all that stuff in a subsystem and then you design a nice and clean interface that the application core interacts with. If there are any implementation details that the consumer of the interface needs to know to use it, you document it.
Just try your best to make your subsystems usable without having to deep dive into them for implementation details every 5 minutes.
One way to get deterministic output is to use integer/fixed point math. Quantised models already do that for matrix multiplication, but things like softmax may still be implemented using some floating point math. It's possible to replace that, just takes a bit of extra work and is probably slower than using the GPU's native float ops.
