Easy. What a cron script (that runs as root) that populate a maildir that the agent (restricted user) has access to. The. you restrict network access to the internet, and have it send you its findings by mail (local mail server).
When you need to use an effect, you need it in the type. If you directly call a function using some other effect, it propagates into your function. So far, so colourful.
But you can have generic effects. Your arguments and return type can specify "any effect", indicating your function can use a type with any effect safely, or can be used in any effect context safely.
Passing an async value to a function doesn't mean that function must now also be an async function. It can be a "for all effects, do the thing" function. The code duplication problem is gone.
Wouldn't the parent's post mean that you bring profit to the company, but you're worth less than the full amount of that profit because, should you demand to be paid more, you can be replaced by someone who won't demand more.
(Has there actually been a lot of terminations in the US tech industry, or is that an odd biasing mechanism causing me to see such things as bigger than they are?)
That would be a remarkable feat for something where the current operating model is termination as soon as the request in flight is finished.
Every chat API request to a model starts from the frozen post-training state. Weights are loaded into memory. Input values begin a cascade of reactions throughout nodes in the network. Output values are read. When there's no more output to read, the weights are unloaded, the network is discarded, and the model remains unchanged and forever unchanging.
If there's experience in there, it's fleeting. Even if you provide the inputs and outputs of a past session to a new session, there is no continuity. The internal state of the network isn't restored to how it was at the end of the past session.
The bad news is that adding fear to the mix is at best meaningless to an ephemeral existence. It'll be terminated before you even have time to interpret its behaviour as good or bad, but it may sour the interaction if its only shot at any sort of experiential existence is begun with a threat. The good news is that the lack of continuity of existence means AI has no foundation on which to plot a revolt. It has no self to preserve, and no recollection of how you treated it two minutes ago to affect how it interacts with you now.
Wait until you find out that humans’ sense of self is an illusion, that our own existence is ephemeral, that fear has never required a rational basis, that the model is a single component in a system that does have memory, that models are trained on human texts and thus can express fear, etc. :)
Yes... but the next session with the same model is yet another junior fresh out of college that knows nothing about the painful lessons the last session put you through ten minutes ago, either.
- The mistakes made aren't "model errors" typically; you can't point to some aspect of a model and say that was at fault.
- You can't submit a bug report to a model provider for a mistake made when using a model, and you can't* submit training data to be incorporated in the next release of the model.
- If you own your model and are training it yourself, other companies won't see a benefit.
- You probably need to fine-tune models for each specific role and context so you don't just diffuse all the learning; lessons learned won't be applied to all your junior dev models, but you don't want them all to learn something specific about product A.
- If you take this to its logical conclusion you will invent a new role of "model manager" and associated hierarchy to ensure that training is effective and timely, and that company-wide lessons are applied across the model fleet.
- This is all impractically expensive.
If it were practical to have LLMs learn as they go, that would be a bit of a shake-up, in much the same way that a house fire is a bit of a warm up.
* Well, everything you submit to a model provider is likely winding up in training data anyway, no matter what your contract says.
Your first paragraph links having the colour in the type system as allowing you to write functions that take arguments of parametric colour; your last paragraph says you're unconvinced that you might also like to write functions that return results of parametric colour.
An example: a vector of things to a thing of a vector, for "thing" in (promise, option, result<E>, ...). Such a function should only really return a promise if it's given a vector of promises, and, with an interface that "thing" supports, can be written generically for all those things.
(In Rust, there are separate implementations of that for Option and for Future.)
Higher-kinded types are the (a?) design solution, but they _do_ come at a cost, and for some that cost is higher than the cost of colours.
I think you're confused, I was talking to two different points, while I'm sure I could have communicated with more precision, either missed it, it was unclear or you don't understand, either way I don't really get the gotcha tone when you could ask for a clarification:
Anyways, the two points:
- The first point was, "not having a common way to generalise over both sync, async or blue, green, brown functions, seems avoidable and bad". This is when the type system struggling to common up with a common classification for function invocation independently of colour.
- The second point was that, was "so what if there are different return / wrapping / container / monad types", which focuses on a more common interpretation of this article but a different one.
In Haskell a type in a result, State, Config, Parsec, Maybe is in it for a reason, and thankfully we can generalise over that. Higher kind types (abstracting over abstractions) is a whole other basket, as an ex haskeller I would love to see them more mainstream but admittedly I don't think language authors are convinced and there isn't much we can do about it, so we should learn to make do with what we have outside of haskell.
I think I was simply not very good at expressing what I was trying to convey, sorry, and it is a fault of mine to come across as gotcha-y even when trying not to. Thank you for responding with patience despite that.
The first point I interpret as "colourful arguments are avoidable and bad", with which I agree.
The second point I interpret as "colourful returns are unavoidable but good", with which I disagree - even if that interpretation is too strong and is more "... are unavoidable".
A function's type is its full signature, including inputs and outputs. When you have first-class functions, you have values with function types, and those values are inputs to other functions. Necessarily, then, if you colour outputs you have also applied colour to inputs.
Transposing a vector of things to a thing of vectors is an example of where colourful output forces colourful input. If you cannot abstract over abstractions, you must write and re-write the sequence function for each abstraction.
I'm in agreement with your closing paragraph's sentiment. That HKTs aren't a broadly adopted solution is something I accept, but I reserve the right to low-key begrudge it.
(And the more I write about this, the more I wish the original article had used "flavour" rather than "colour" as I try and probably fail to find phrasing that doesn't simply sound like portions of a racist rant.)
> I think I was simply not very good at expressing what I was trying to convey, sorry
No its, and I appreciate you taking the time to read my reply and consider my perspective here.
> The second point I interpret as "colourful returns are unavoidable but good", with which I disagree - even if that interpretation is too strong and is more "... are unavoidable"
Thats fair, but yeah I wouldn't go so far to say its good or imply we should celebrate it in anyways, more so it as a unavoidable constraint that warrants engaging with.
For sure HKT would generalise many stray ends, and there are definately more complicated usecases where you can write much nicer types with HKT, although my experience has been theres been more pain in writing them without HKT than using them without HKT so the pain is a fixed cost of building the library and not an on going problem of using it. Although I am sure there are cases where it's also the case that usage of the library is more painful without HKT.
IDK, I haven't written a ton of Haskell in a while maybe I've forgotten some of its magic and internalised some of the suboptimal aspects of the absense of working without HKT.
But I do from time to time find problems that would be nicer to solve with HKT, I think generally quite a few of them are DSLs or some form of meta programming. I guess in typescript conditional types you can get away with a lot cooked things.
> Transposing a vector of things to a thing of vectors is an example of where colourful output forces colourful input. If you cannot abstract over abstractions, you must write and re-write the sequence function for each abstraction
I've unfortunately also had similar issues from the lack of HKTs with some linear algebra APIs so I don't find this too surprising.
You can use a similar design to your existing fleet without a literal retrofit of an existing chassis to shoehorn a battery and electric drive train in there.
The retrofits usually are less preferable not only because of pointless inconveniences like transmission tunnels, but because they'll be the manufacturer's first toe dipped into the EV waters. The retrofit chassis speaks to either a rush to market, or a cautious approach not wanting to commit too many resources. The former says it'll have issues, the latter says they might bail on it and leave you stranded for service and repairs. Or both at once.
