That sounds like a Wrapper<Func1Payload>, not a Ticket<Func1Call> that will become an extra parameter of Func2 whose only purpose is to prove to Func2 that you called Func1.
And you wanted to make sure that func2 and func3 can only be called after func1 has been called.
A wrapper on the output of func1 here would be awkward because then you return Wrapper<Func1Done>(bar0). But func2 does not even need a bar0 and neither does func3.
So the solution is to return (bar0, Wrapper<Func1Done>) from func1 where
I think this is a good argument for the Ticket, however, for the case where these three functions are generically useful, not just used in this specified order, I would write a specific function, just copy-paste of the bodies capturing the required ordering as an implementation detail.
Obviously if you are operating in a wide, concurrent async system then the Ticket and separate function calls is the better mechanism for the ordering.
That's fair but then you have to make your args a struct for this bespoke purpose; an anti pattern.
Also, many other functions can depend on the ticket from func_1. So making the ticket separate and generic on the process is the right (imo) solution here.
Why should this be such a bad anti pattern? Sure, a function might not need to work on the entire data model, but with pass by reference, does it matter that much? I dont see big negatives by using struct args, possibly wrapped in some typestate.
On the other hand, doesnt seprating args and typestate defeat the purpose? Since they can now be constructed separately.
It's because I use Ticket<T> in situations where I need to remember (force other users to use) a sequence of functions that take arguments not necessarily constructed by others.
//One could also place all the data in a giant struct and move that across all functions but that eventually leads to struct bloat unless we use an explicit state machine, in which case type state is better
Why not return a WrittenBuffer<'a>? This can also be used to specify the methodset allowed or required plus any further type transitions out of WrittenBuffer, for example into a new CompressedBuffer, or similar patterns.
That's fair, but you would have to make sure that write_buffer is the only function that can create a WrittenBuffer<'a>. And then the second function could take a WrittenBuffer<'a> as an unused arg
I think my point is that types and “typestate” do not need to be two separate things. For example, in the Lua API for C, one obviously requires a Lua context handle in order to perform any other operations, so the handle must be obtained first, by calling the context initializer function. There is no need for an extra “typestate” parameter since the dependency is explicit and enforced.
Yes and no. The big advantage of a GUI is having interactive 2D coordinate input support (aka a pointer, or gestures.) While I think a keyboard can be a great control surface, that’s one thing it really lacks and only GUIs really offer. So to enforce that the whole GUI must be keyboard-drivable requires limiting the major advantage of the GUI. I’m a fan of the Emacs or Plan9 styles where the keyboard and pointer are able to be used together synergistically. You also see some of this in tools like video, DAW, and 2D/3D graphical scene editors.
I agree. I mention this briefly in one of the footnotes. There are some tasks that greatly benefit from the mouse (e.g photo editing tasks where arbitrary region point and click is required).
This does not contradict the argument. The rest of the interface, everything that is known and stable in advance, should be full keyboard-driven.
Let’s use the obvious example of a paint program. Clearly continuous 2D pointer input is an essential feature that would be almost impossible to replicate with only a keyboard. To step back a few levels, a node graph editor with many elements will simply always be easier to interact with using a mouse. But editing text and interacting with other applications such as visual debugger are really only a tiny bit removed from that.
But that's a limitation you've made up, driven by keyboard doesn't mean "only"! It just means that all actions should be possible with a keyboard. So in your 2D paint ideally there should be a way to draw a line with a keyboard
You’re presuming here that CEOs cause companies to make profit instead of serving as a scapegoat for their often unavoidable market dynamics (at best).
I may be able to do all the labor myself, but need investors because I can’t afford the capital.
I may be able to do all the labor myself, but want to ensure continuity beyond my ability or interest to do the labor myself. (Sometimes this is by my wish; sometimes by the wish of consumers of my service.)
I may be able to do all the labor myself, but not want to expose my entire net worth to the financial obligations of the company.
There are plenty of cases where a single person company makes good sense.
At what point does a company become a company if one person doesn’t make a company? What’s the threshold for non-labor where a company becomes a company?
The prevailing mentality seems to be that if we don’t win in the next three quarters it will be such a catastrophe that there won’t be a future at all.
In my experience xhigh very often produces better results on the first try to the extent that the less cogitation-enthused settings actually waste more in the long run.
Digression, but this is the real Great Filter imo, not AI. I think technology advances to a point where it only takes one or two bad actors to type the right prompt to get a recipe for civilization-destroying bioweapons before you get anywhere near true AGI or anything relevant to the Kardashev scale. Biology is fragile.
But not that that’s a good justification for hamstrung models. I think it’s just the inevitable endgame and it’s more sad than scary
I don't fully understand the instinct to regulate local models for this? It seems like the wrong place to address the problem.
You can download Ebola sequences right now if you want to. That's not the same as having an isolate. The difference is a lot of messy reality. This kind of work is not generally "one shot" (Claude make me a supervirus, make no mistakes), it requires lab space, iteration, and specific resources. It has a footprint.
Wouldn't it make more sense to monitor / regulate facilities where you can sequence or request assembly of DNA, RNA, restrict and monitor the supply of key reagents and so on?
Yeah I was thinking more on the scale of nation-state level actors. Most leaders would not consider a bio weapon due to potential blowback on their own population, as they generally don’t want to be the leader of a nation of corpses and ashes.
But if they don’t care, or if they already are the leader of a nation of corpses and ashes, maybe there’s not so much holding them back.
In my layman’s perspective, bio weapons seem to be more dangerous and volatile than nuclear weapons. And increasingly easier to engineer as biotech advances. I think about the headlines of “microscopic robots that target tumors from within your body” and see the horrifying opposite side of the double-edged sword.
>I don't fully understand the instinct to regulate local models for this? It seems like the wrong place to address the problem.
Those with such instinct deserve not the liberties they wish to deprive from others. Sam Altman and Dario Amodei do not deserve to touch their own uncensored SOTA models. Their access should be audited publicly to ensure this restriction holds, until such time they publicly renounce their censorship instincts and publicly release their uncensored models. Fair 's fair! :^)
It depends how easy it is (now, or in the near future) to turn information into weapons, and how realistic control of materials is. There's a reason we control access to plutonium, but information about metastable hafnium.
It does seem to me that for this specific problem the materials are a lot more amenable to control than the information is?
There's also this weird revealed threat model thing going on? Like why does it make sense to support heavy LLM restrictions but leave benchtop oligo synthesisers completely unregulated? (Note: I do agree that wanting to regulate BOTH is at least a consistent and defensible position).
I find it philosophically interesting because the problem is not strictly information control. Local models don't have any special extra information with respect to biological research. What has to be restricted is using information that's already publicly known in the wrong ways.
reply