Seems to me that breadboard coding would be a like a spreadsheet where dependencies between cells are visible at a glance and could be "rewired" in a way that's easier than hand editing the formula text
That matches what I managed to glean, though I didn't get much further.
It started making more sense though when I managed to fully understand the AST comparison that was being made. Specifically, this approach lets you do the LISPy "code is data" thing where you can construct your program within your program and then run it, but instead does it via "data is execution+control-flow". Thus gaining the benefits of static analysis on the constructed program since you wrote it all out in the "normal"/static order rather than the "nested"/dynamic view of a program that monads give.
At least that's the gist I got, though take it with a grain of salt, the article went very over my head at times.
> The fundamental thing in question here is what makes Beauty beautiful
GUIs are tools first and art second.
Any GUI that looks good, but gets in the way, or fails to make the task at hand easy is not a good GUI.
The books and research are about making GUIs functional in an effective way. No one is claiming that a GUI that follows all the principles will look good. However it will make the task at hand easier to perform than it otherwise would be.
The problem is when people in charge of GUIs focus exclusively on Graphic Design instead of UI design. They are different fields, with different goals that only sometimes overlap.
I don't disagree with much of what you said. Form and function have to be married harmoniously, which inherently increases beauty. When form decreases function, so does beauty dissipate. And I think GUIs have gone in that direction. They have not maintained the principles that would help bring proper balance.
Using this definition means Firefox is a contender in the browser wars, an independent will be a contender in the next Presidential election, and a hydrogen fuel cell vehicle is a contender for your next car. Can we just leave out this contender nonsense and replace it with exotic choice?
Interestingly, it doesn't always condition the final output. When playing with DeepSeek, for example, it's common to see the CoT arrive at a correct answer that the final answer doesn't reflect, and even vice versa, where a chain of faulty reasoning somehow yields the right final answer.
It almost seems that the purpose of the CoT tokens in a transformer network is to act as a computational substrate of sorts. The exact choice of tokens may not be as important as it looks, but it's important that they are present.
That phenomenon and others is what made it obvious that COT is not its "thinking". I think COT is a process by which the llm expands its processing boundary, in that it allows it to sample over a larger space of possibilities. So its kind of acts like a "trigger" of sorts that allows the model to explore in more ways then without COT. First time I saw this was when I witnessed the "wait" phenomenon. Simply inducing the model to say "wait" in its response improved accuracy of results. as now the model double checked its "work". funny enough it also sometimes lead it to produce a wrong answer where otherwise it should have stuck to its guns. But overall that little wait had a net positive affect. Thats when i knew COT was not same as human thinking as we dont care about trigger words or anything like that, our thinking requires zero language (though it does benefit from language) its a deeper process. Thats why i was interested in latent processing models and foray in that matter.
But why would you want to violate the docs on something as fundamental as malloc? Why risk relying on implementation specific quirks in the first place?
I'm curious too. I find it an occasionally useful feature, but how often I use it goes down as my ability to construct better find-replace/apply-action regex goes up.
> charging for it should help make sure it continues to work
It's there a particular reason you're extending the benefit of the doubt here? This seems like the classic playbook of making something free, waiting for people to depend on it, then charging for it, all in order to maximize revenue. Where does the idea that they're really doing this in order to deliver a more valuable service come from?
Yeah. This is a reaction to providers like blacksmith or self-hosted solutions like the k8s operator being better at operating their very bad runner then them, at cheaper prices, with better performance, more storage and warm caches. The price cut is good, the anticompetitive bit where they charge you to use computers they don't provide isn't. My guess is that either we're all gonna move to act or that one of the SaaS startups sue.
I appreciate being able to pay for a service I rely on. Using self-hosted runners, I previously paid nothing for Github Actions — now I do pay something for it. The price is extremely cheap and seems reasonable considering the benefits I receive. They've shown continued interest in investing in the product, and have a variety of things on their public roadmap that I'm looking forward to (including parallel steps) — https://github.com/orgs/github/projects/4247?pane=issue&item....
Charging "more than nothing" is certainly not what I would call maximizing revenue, and even it they were maximizing revenue I would still make the same decision to purchase or abandon based on its value to me. Have you interacted with the economy before?
It's going to be fun watching HN, which is full of people who support this sort of thing (and even more extreme regulations to boot,) deal with the ramifications of this forum's guidelines and moderation policies being de facto illegal.
It won't even be "turning into Reddit" it's all going to turn into 4chan.
Consider that every time you start a session with Claude Code. It's effectively a new engineer. The system doesn't learn like a real person does, so for it to improve over time you need to manually record the insights that for a normal human would be integrated by the natural learning process.
Yes, that's exactly the problem. There's good reasons why any particular team doesn't onboard new engineers each day, going all the way back to Fred Brooks and "adding more people to a late project makes it later".
reply