Oh well. I might be to picky here, but how I see things, determinism cannot be improved or worsened, but achieved or not achieved. Or Partially archieved, when analyzing a system that has both components that are deterministic or non deterministic.
There are times to think in absolutes, and when talking about deterministic behavior of technical systems, this is one of them. Join the sith side, we have cookies, and when we say we have cookies, we do.
Yes! The "-ness" implies some degree of spectrum already, and from what I know and understand, one can talk about different degrees/classes of randomness. "decreasing entropy" would work too, I guess (Intuitively: If one would open a bet on a system outcome, how high would the quotas be? If there is some degree of randomness in the system, it would make sense to put money on multiple different outcomes to minimize ones losses. Only if there is no randomness at all, it would be rational to bet all money on the one option we expect).
Another further distinction would be between "true randomness" and "We do not know all input factors yet, hence, the outcome appears random to us". The former is something that genuinely exists in the universe as far as I understand physics (i.e. even if all input parameters are known, it is not possible to predict the outcome reliably, which seems to be the case for quantum physics, which I have the surfacest or surface levels of understandings about), the later boils down to reducing "unknown unkowns".
In practise, this means stuff like using seeds for random number generators, fixing things that look random like day of the week of a DateTime.now(), and so on. Depending on what you do, it might be never possible to get rid of all randomness, but I am 100% convinced that you can always contain it into a well-defined cage, and control everything else down to the last bit.
That also made me think of the opposite: "Increasing predictability" would be acceptable for me too, and a deterministic process/component/system/whatever is one that is at maximum possible predictability for me then.
In all seriousness, this seems like it could be fine if done well. You can just have a model do a pass over the system prompt and set reasonable parameters based on that. That's probably not what they're doing, but it could be.
The live translation demo reminds me of the Babel Fish in The Hitchhiker's Guide to the Galaxy. This could be very valuable to have in your headphones while travelling.
Not super impressed by the model constantly interrupting the user in the other demos though.
Might want to set `overscroll-behavior: contain;` on those scroll areas, having the whole page move up and down (or worse, navigating Back when scrolling left) isn't great UX.
I once made the mistake to reply one of those threads with a public email address, it's now an incubator for AI-generated spam. And not just slop text: now we're getting full vibe-coded HTML UI..
The whole point of shadcn/ui is that it’s customisable (that’s why the components are copied into your app as opposed to installed from a central npm package).
That's nominally true, but a project using shadcn/ui is nearly immediately identifiable as such because most do not deviate from the defaults it (or Tailwind) provides. A UI for toggling border radius and colour palettes isn't going to help this.
The driving purpose of Tailwind is to provide a massive suite of utility classes to atop a consistent set of design tokens and yet the vast majority of projects using it will be plucking patterns wholesale from TailwindCSS Plus, Flowbite, etc.
Even Bootstrap was designed for customisation but still, a large number of teams who deployed it would stick largely with the defaults. It's just how it goes, and it's a perfectly valid complaint from observers.
I have absolutely nothing against Tailwind and shadcn/ui so don't take this as a criticism. This is aimed squarely at the people who point out that these tools are designed for customisation without acknowledging nearly every deployed example pulls from the same limited pool of defaults, UI components and larger templates. And why wouldn't they, tailored design systems take incredible effort and skill to get right.
The reason why customizing has some mild disincentive is because as you install more components, all the other new components won't be aware of your changes. Otherwise it's a great start for a custom design system.
You're right. You could expect something like this to happen. But so far it seems that the content api and version control are not interwined. Maybe this will change in future.
I used to do that exact job 10 years ago (without AI, obviously). I figure that career would be very different now.
There was something exciting about sleuthing out how those old machines worked: we used a black box approach, sending in test samples, recording the output, and comparing against the digital algorithm’s output. Trial and error, slowly building a sense of what sort of filter or harmonics could bend a waveform one way or another.
I feel like some of this is going to be lost to prompting, the same way hand-tool woodworking has been lost to power tools.
It will be the future for sure, software as a tool for everyone.
While there is something lost in prompting, people will always seek out first-principles so they can understand what they are commanding and controlling, especially as old machines become new machines with new capabilities not even imaginable before due to the old software complexity wall.
It's exactly as you say: software as a tool for everyone and it's hard for programmers like me to accept that because I've spent so much time, read so many books, and work so hard perfecting my craft.
But smart programmers will realize the world doesn't care about any of that at all.
You’re ignoring Jevons paradox. Everyone, both people and companies, will be making exponentially more software with these tools. Software that both needs to get created, debugged and updated to realize the intention of it. That’s what our time will be spent on as programmers.
At the same time ability to write software is exploding we are watching large entities in the market consolidated and small businesses end up on the down side of the K shaped economy. Programmers demand and pay should go down as supply increases just like every other person in an economy.
Exactly! There isn't enough woodworking jobs for thousands of thousands of workers. Of course you have people handcrafting things and people demanding handcrafted things. Programming will be the same.
This doesn’t seem right to me. Carpentry still seems like a pretty solid line of work with a lot of jobs. I know at least one guy who moved from EE work to contracting because he could make a lot more money that way.
Given, a lot of it is framing houses and remodeling. And there are fewer jobs in hardwood furniture these days. But a lot of that is because US furniture manufacturing was moved to China 20 years ago, not because of power tools.
If anything, the advent of power tools in the 40s/50s made single family homes more affordable and increased construction demand.
https://en.wikipedia.org/wiki/Erik_Satie