vidarh

Yeah, I specifically had the Culture in mind when I wrote that, because Banks seemed a lot more self-aware of that and playing with and actually telling us fun things about his utopia and trying to actively flesh it out, while to me at least it feels like Roddenberry was caught up in wanting Star Trek to be morality plays in space that had to teach a lesson to the point of getting very heavy handed with it at times (and he might be right the heavy-handedness was necessary given some of the takes I've seen on various episodes), while still telling us frustratingly little about his utopia itself.

I think it's selection bias in what we like to remember too. The 50s has huge quantities of post apocalyptic sci-fi for example...

They used to be more common maybe, but even the titular "Utopia" by Thomas More had slavery. Sometimes the "perfect" settings were imperfect due to the times they were written, often they were intentionally imperfect, and that was the point.

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 point is that the discussion is essentially entirely meaningless, as it's pretty much hard to implement any simple construct that can make deterministic decisions based on a data stream and wrap it in a loop without ending up with a UTM.

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.

The context can change each time. To implement a UTM only requires 2 states and 3 symbols or the reverse.

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).

I'm building a little side business with LLMs doing 90%+ of the work, and this includes numerical analysis of revenue to figure out where to direct effort.

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.

One thing that is exciting about Jev-style decision models is that it makes it cheap for things where they can do zero-shot of things where it's not worth your time building a curated dataset.

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)

Sounds worth posting your own ShowHN post for.

The original release was for Amiga and Mac. The C64 version followed around the same time as the PC version, though apparently the C64 version was the original.

Personally I don't like the thought of giving up meta programming, and I don't think it's necessary. Spinel is great as a pragmatic way of getting an AOT compiler for a Ruby subset though, but it's not that hard to support meta programming in an AOT compiler.

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)

> no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.

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.

You're free to like Crystal of course, but for me even for long running tasks (almost my entire desktop, including my wm, terminal, editor are Ruby - I still use Ruby for almost everything; if anything, for more than ever), the Ruby ecosystem beats the steadily diminishing performance gap between MRI and an AOT compiled language to the extent that even going to TruffleRuby where I could keep almost all of my code, is rarely worth it for me.

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.

The challenge for Crystal is that we also have TruffleRuby which gets you the elegance and Ruby interop. To me Crystal feels like it's at the same time too different to Ruby to benefit from the similarity and too similar to create its own viable niche.

It's somewhat similar to Ruby, but it categorically is not Ruby. If you want fast compiled Ruby, TruffleRuby is actually Ruby and relatively compatible with MRI.