vidarh
It makes it harder to extract decent margins from models at or below the quality of the open models, and so makes it harder both for new entrants and for any existing providers that are depending on cheaper models for revenue. At the same time you make people comfortable with your product.
It's the IP version of dumping products below cost if you're capital rich and want to winnow down the competitive field while "buying" customers.
If you're using a closed model, the model provider gets all your data, and can if they want to send back actively hostile tool calls and rely on your harness to catch them without any effort on their side to train that behaviour into their models. The only things you can do about that is to place careful restrictions
If you're using an open model against your own system or a third party provider, the origin of that model could have trained in "triggers" that'd cause the model to produce actively hostile tool calls as well, but they'd have no direct control and would need to train in that behaviour "blind" to how you'd actually use the model.
It doesn't mean you can be complacent about trusting the model, but it does change the likelyhood they'd be able to do any damage, not least because you'd be able to run evals against the model without any risk that the model or provider API could just randomly change on you after a while.
So it takes far more trust to run a closed model than to run an open model even on a hosted third party provider, and certainly far more than to run an open model on your own hardware.
https://www.primevideo.com/detail/0QGEAKI5A10J71NPXAXEX4GSHS
Among the more internationally renowned actors in it you'll find Liv Ullman and Max von Zydow. There's a sequel - Nybyggerna ("The New Land", which is not a direct translation; the original title is better translated "The Settlers") - which I also remember as being good, but I haven't watched either since the 1980's.
But there's also this new adaptation from 2022 which I have not seen:
What you're doing is different to translation, it is insisting on a different grouping. It's rude and insulting.
But even when it comes to translation, then yes, a lot of people take offence at that as well, and you'll notice there is a trend back towards the official spelling of names that has been ongoing for decades for exactly that reason.
Only English speakers ignorant of the history of Scandinavia sometimes excludes it.
Tjere is no English language authority that has any business redefining what Scandinavia means at all. It's just insulting when English speakers believe they get to decide to redefine the names of regions that don't belong to them. It's rude.
In the Nordics the terms are not just "preferred" but unambiguously used this way.
The use to include any country other than Denmark, Sweden, and Norway, is something that will tend to really annoy Scandinavians, as we're generally consistent in that use and it's foreigners trying to tell is what names to use for ourselves.
It may be a losing battle, but it's not one we'll give up on.
In fact, immigration to Norway from Sweden started already back then. My great great grandfather moved from near Bullaren to Southern Norway in the late 1809's. But then emigrated with most of his family onwards to the US a couple of decades later as Norway was also poor at that time.
What was Norway's way out of the worst of that poverty apart from reduced surplus of people from emigration was shipping, and several of his sons, including my great grandfather ended up working on ships (and my great grandfathers family ended up moving back to Norway, supposedly in part because his wife got tired of the warm summers in Brooklyn...)
E.g. consider HG Wells The Time Machine, where the future start out seeming quite like an utopia but then we meet the Morlocks.
But lots of books were downright dystopian much earlier. Heck, several of the "standards bearers" for dystopias pre-date cyberpunk by a lot, like Brave New World, This Perfect Day, 1984.
Particularly stories like The Time Machine where the setting as a whole very much was revealed not to be an utopia were among the most common "utopian" settings pre-cyberpunk.
Pure utopias were very rare for a reason: They're really hard to set compelling in stories in, and so most of the ones that do exist tend to set stories on their edges and fault lines.
What changed with cyberpunk wasn't that (surface) utopias went away, or even that we get to see the imperfect underside, but that the script is flipped so that the protagonist isn't a tourist on the underside, but belongs there, and is often alienated from any seemingly perfect parts of the world they inhabit.
Compare settings that do show both sides, like The Time Machine, and a cyberpunk version of The Time Machine would probably have a protagonist that was a Morlock. The world itself wouldn't change, but we'd get to see it from the opposite POV.
The consequence of that is that the original question GuB-42 raised is pretty pointless too. An "inert" transformer effectively has limitations, but as typically used it trivially becomes Turing complete, and so the class of problems it can solve is the exact same class of problems almost any of our other computational devices can solve.
And if you want to point out that this externalises all of what actually matters if we are talking about e.g. intelligence, then yes, it does. But by extension you can trade complexity of the tape for complexity of the machine, and so you can internalise any part of the problem that can be solved with a finite section of tape as a single state transition (trivial proof: For a given machine M with finite state, you can make your machine N execute those steps as a single state transition by having N run M on a state transition.)
To extend that to where I assume they'd want to go in the first place: A transformer wrapped in a loop with access to "just" a "tape head" can "only" be limited from being theoretically able to get all the way to human level intelligence if human brains depend on computations that exceed the Turing computable. But that is no different from any other Turing complete device.
Of course that says nothing of whether it's a practical way of getting there.
So if you use the context not as a tape in itself, but as an io channel to read/write an infinite tape, the context for any given step can remain fixed in size, and so the step itself can be O(1).
Today the problem you're mentioning is easily avoided if you are aware by ensuring you direct the agents to build tools for anything deterministic.
Every week "we" (myself and Claude) start by analysing revenue from the previous week. Claude will do some manual proposals but they will be based on analysis done by a deterministic script. It will then run workflows that are increasingly calling deterministic scripts - every week another few decision points the agent used to do (and that I had to then manually vet) gets replaced by deterministic scripts.
It is what allows what is a very low margin opportunity to work - it is scaling with the total amount of manual labour and total token use remaining near constant. It's an opportunity that I won't go into much detail about because the margins are thin and the moat narrow and it's basically only viable because of this approach of setting a tiny budget where ~1/3 of it or so is dedicated to systematically eliminating manual and LLM work from the process.
Even so, I expect the opportunity to actually extract profit from it is going to be short-lived - the moat will eventually evaporate if LLMs keep getting cheaper and better in favour of people "just" asking an LLM to do the whole thing end to end.
So on one hand I agree with you - there are lots of things that'd be better automated with scripts, and where there might well always continue to be efficiencies you can extract by turning things into deterministic scripts instead. On the other hand, LLMs are already so cheap for a lot of things that it increasingly doesn't matter, and good enough that where it does matter they will increasingly also just write tools themselves if you ask them and sometimes - and likely increasingly so over time - without even being asked.
Bonus: after using them for a while, you get the beginnings of a training set if you change your mind.
You can do that with LLMs too - it's just a cost and latency question.
E.g. I use an LLM to label my e-mail. I do it because it's low risk enough that I don't care about it being incredibly precise - it does not automatically act on anything, it just labels - and it means I don't have to curate a dataset of what e.g. should get the "receipts" label.
An LLM zero-shots it well enough and cheaply enough to remove my incentive to train a model for my individual e-mail.
If I wanted to scale it up, Jev or similar would probably be better.
A dedicated classifier would almost certainly provide even better precision if I invested the time to curate a dataset.
But the threshold where that is worth it for me given the precision I get from a cheap LLM is pretty high, and it's also less flexible.
E.g. one of the nice things about using a generic model for this is that whenever I add a new tag, it starts using it immediately and odds are good that at most I need to add a line to a file with one-line descriptions of what the folder name means to get decent results.
So there's a space for both LLMs/Jev-likes and custom classifiers.
Use Jev-like models (or LLMs) when the effort to curate a dataset to train a dedicated classifier is too high, and switch to a dedicated classifier when/if you need to scale something to a point where the economics justifies the effort or when you already have the dataset anyway (EDIT: and if you start with an LLM or Jev, collect the data - it will provide a good starting point for your training set if/when you decide to train a dedicated classifier)
Though it makes it harder to generate fast code, it's not impossible given that most Ruby meta programming runs early and then doesn't change the program again, and most patterns are recognisable and it seems likely to be (I'm on and off working on my own Ruby AOT compiler) possible to statically verify for most programs that after a given point most code will not change types and so do static type inference to elide most type checks (a type in such a Ruby program will not be a given class, but a given version of a given class or meta class)
If your code is poorly enough tested for a typo to cause it to crash, a typo is the least of your concerns.
> also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
So you do in several Ruby implementations.
> when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it
I've used Ruby for large scale IO with Ruby for 20 years without problems, even on CPU's far slower, and with Ruby versions far slower than today. If you're doing IO with Ruby and the performance of your language implementation is what is limiting you, rather than spending most of the time in kernel space waiting for system calls to complete, you're doing something wrong.
But my main point was that people who do want a fast Ruby should be aware that Crystal isn't a Ruby in any meaningful sense - if you like Crystal for Crystal, by all means use it.
I'm well aware of how it is used in tech - I've worked in tech for 30+ years.
And frankly, your insulting comments here undermine you further. My English comprehension is well above the average native English speaker, and judging by your comments here I'm not confident I can say the same about yours.
Consider that when multiple people here have issues with understanding you, it says something about your language use, not theirs.
In the UK, an alleged defamatory statement is presumed false and the defendant needs to prove it is true, and that burden is unusually low compared to most other jurisdictions, and certainly much lower than in the US where the burden is on the accuser to prove the statement is false.