Worst part?

Their whole software stack is running on some version of Visual Basic, written by a dude that did not trust "others code" so he wrote everything from scratch, and retired about 5 years ago.

Nobody knows how any of it works, or has any clue. The company will continue to run it and pay him for consultations as long as he is able to do it.

But it is a generational opportunity - we can remove a lot of barriers that come with knowledge, lack of it, access to it and more. Someone can easily get pretty on point medical advice without access to doctors. Get specific engineering advice without engaging with those engineers. We can apply common sense or specific knowledge on scale - in a world where about 50% of people have IQ under 100 and access to knowledge is gated behind lines and payments, this has a huge chance ot improve their lives.

And there is the whole shadow inference economy - just for example, a few corporations I have worked with in insurance and telecommunications have been slowly introducing it inside their workflows and their data tooling, being able to clean data, tag it, analyse it in a way that before would probably cost them billons in human costs.

One of them has a database going back to the 80's, with data being formatted and reformatted in all shapes and sizes, coming back all the way from paper records for some of their oldest clients. Cleaning this up was unimaginable before as a "something we can do in a day" project, but was more of a "possible with insane costs". This lead to all further activity being shaped by decisions someone made 40+ years ago, details being lost, data being thrown away or saved in random notes.

And there's millions of companies like that all around the world, which can now do "impossible" and become much more efficient and productive for a much cheaper price and in way less time than ever.

My parents love using ChatGPT, asking it all kinds of questions. My mom discovered Claude and helps her immensely with her job - where she would have to take it home and work a few hours to be able to finish the tasks on her computer, as her company that still uses Office 98, now Claude does it in 5 minutes.

They fixed so many random issues using it, it is insane. My dad had a bike issue which would otherwise be solved by either trying to find obscure manuals from 20 years ago on random forums with me translating it from english to our language, or by taking it to a mechanic which could take months. This way, he just snapped a few photos, said what the problem is, and in a few minutes he had the fix.

I've built software that uses LLM's for a specific usecase - besides general adoption, professionals in the field contacted me and thanked me for making their lives easier, as the tasks would often take a lot of manual work. These people are earning way more from using my software, than I am from their subscriptions, which is still about 20x more than my API costs are.

While most non-dev people are behind the curve, the impact it has on their lives is becoming bigger and bigger by the day.

Then I remembered the "text completion LLM thingy" I saw on HN, and tried it out in the playground. Once I gave it an IRC style example of a conversation to complete, I was like hm, this could work. Then I figured out I could "sort" people into different groups based on personality using the same text completion engine and some answers they provided. Then I noticed I could have it provide me with JSON directly.

That's when I realized how big this could be for code and data analysis - even tried to convince an at the time cofounder to pivot into AI coding, but to no avail.

Once the API was released and the art project chatbot got launched (and the theater show associated with it, which even won some awards), people who used it loved the chatbot, got into heated arguments with it, tried to teach it things, talked about their lives and were sad when it didnt remember something.

That was when I understood the social impact this could have on people - they really behave like its a person on the other side. They show interest, think it displays emotion, try to entertain it, be polite, ask about its thoughts and hopes and dreams. And even when they knew they were talking to a machine, they were still trying to be friends and make it happy, which was quite beautiful to see.

Later on, I had a third oh shit moment - once the 3.5 API was out and about, I prototyped a Rust code generation harness for a client, akin to a primitive claude code. That was the "I'm getting a bit worried" oh shit moment, and it caused a lot of reflection and thinking about the future. And I happily welcome it.

What is _the proof_ if all the proofs are not _proofs_?

I don't babysit my LLM based services which are used by coaches and clients around the world. One of my LLM based solution get 30-4k daily hits and I have users coming back on the regular to use it. without babysitting, doing things that would take them hours of manual work and research.

I don't babysit the developers I work with and our clients, which both use LLM's themselves and at scale with their clients, serving all kinds of LLM powered services to millions of users worldwide.

You are not "seeing" the large adoption because:

- The technology is "a few years old" in its usable state - The corporate adoption cycle is slow - You have to understand the technology to use it in a good way, which most corporate devs and PM's do not

So it will take a bit for the "obvious" adaptation on large scale.

But you won't "know" when the large adoption happens.

Silent inference is growing every day, and that is what real adoption looks like - not an LLM being in your face chatbox, but running in the background, sorting, finding, fixing things, aligning data, figuring out analytics, tuning the ads, cleaning the datasets.

Would love to see more about it, or see more about the actual compiler docs.

While the UI framework part is neat, I prefer not to force everything into TS. Combining it means UI definitions and semantics get mixed into AST, making the unbundling of them a humongous task in itself.

Exactly the reason I built my own with pretty similar native UI semantics which supports Rust, Go, Kotlin and more (https://hypen.space) - would love to integrate Perry with it to compile TS apps directly into the runtime - but while the idea itself is great, looking at the documentation makes it hard to implement, and a lot of parts seem confusing.

Can I just use the compiler without the rest of the framework? What is the architecture? What are the limits?

After digging through the documentation, I'm unfortunately just more confused honestly. There are dozens of packages and slop markdown files such as `BUG_STRING_COMPARISON.md` and or `PERRY_UI_IMPLEMENTATION.md` which is an instruction file left for the LLM that just makes me trust the project less.

So while the idea is cool and the performance seems cool, the AI slop presentation would definitely need improvement. Adding a human touch would make it much, much better, as one could actually understand what they are dealing with.

Comments URL: https://news.ycombinator.com/item?id=48322045

Points: 4

# Comments: 0

They were a great brand, cool phones, one of early Android players.

After being bought out by Google, Motorola had some of the best devices out there with stock android, especially in the budget segment (and loved among android devs).They had one of the best smartwatches in the game at the time - Moto 360 (2014!!).

Then, after dropping the Nexus 6, Google stripped the patents and sold them to Lenovo. For a while it was ok, even dropping the relatively innovative Moto Z which had all the cool "modular" addons, played with it for a bit and seemed cool.

And then, things seemed to start taking a turn for the worse as Lenovo kept enshitiffying it more and more, using the brand name as a wedge in the market in which they are basically forgotten. They have the Razr brand which is cool, but the segment that was their best (budget phones) is now ruined with adware so they can extract every bit of value from it.

Such a sad ending for a company that was so early in the space.

It's the same patterns we see with human devs, just applied on codebases at scale.

The conclusion has an interesting tibid tho - maybe the frameworks and their developers should start including more abstract focused primitives instead of just the low level ones, similar to what Encore did, as that way the behavior is encoded at the framework level.

Comments URL: https://news.ycombinator.com/item?id=48132408

Points: 1

# Comments: 0

You can build your core in Go or any other supported language, and write the UI in the Hypen DSL.

While desktop is still in the works and should be out in the next week or two, currently the alpha supports Native iOS, Android, Web and Web Canvas, and just like mobile, the Desktop will be _real_ native.

While HTML serves its purpose, especially for documents, the modern web is a giant mess of that legacy, combined with unfriendly ergonomics and glue/hacks built on top just so we as developers can have better DX for creating complex software on top of it.

Building a browser means having to deal with all that legacy, wether we like it or not, so most of the browser market got captured by the big players who have enough manpower to cover all those edge cases. That also means we have to deal with whatever technical choices or bloat they make, causing an infinite stream of issues, from memory usage, to size, to limitations that don't make sense in 2026 but are still there because someone 20 years ago decided to write them like that. As I deal with mobile webviews a lot in my daily work, I unfortunately had to get familiar with quite many gotcha's and edge cases, and some are just... absurd in this day and age.

I believe we need a separation between an application layer and the document layer, and especially between the UI language and the actual application code - script tags serve their purpose, but again, they are a hacky solution with its own bag of tricks, and those tricks impact all of the software built upon it.

Now, a bit of a shameless plug I've been working on something to fill that gap, at least for myself and hopefully for others who encounter the same issue - it's called Hypen (https://hypen.space) and it's a DSL for building apps that work natively on all platforms, with strict separation of code/UI/state, and support for as many languages and platforms as I can maintain, not "just javascript". While currently it's focused on streaming UI, it's built with Rust and WASM at it's core and will soon allow fully "compileable" apps.

While it may not be the future of software, once you get into building something like that, it becomes obvious that the way we are building now is at least wrong, and at best kafkaesque.

I tried ticking every part - not working. Then I tried just the core. Not working. It took me 5 captchas until I got to one that had different images.

Terrible experience. Most of the time I just close the site now as I can't be arsed.

Back in the heyday, I used to work in a startup devoted to the cinema world, where with one app you could buy tickets for all cinemas - even those that did not "officially" support it.

Among them were arthouse theaters in Hamburg, which I often used for testing, as most of the time reserving a few seats would not matter as they would be empty, at least during the day. Some of them had projections of old movies, and I was like "if I lived there, I'd go every day".

Ironically, now I live between 2 art cinemas in my city and rarely go to any of them :)

> Agile as "devs can do what they want" never really existed ;-)

No real agile ever really exists in the end :)

But it's not devs not doing "what they want" that bothers me - it's the absurdly over-planned project estimates and timelines, with every detail of the project being specced out, not a lot of margin room for errors, invoking the name of "agile principles" as a way to deal with exactly things the PM's don't want to deal with in that moment.

I'd be fine with some degree of planning ahead, or starting with prototypes/PoC's, but such a huge part of the industry just chunks it into "same boat but we'll put agile stickers on the holes", and there is a whole industry of ceremonies around it, that it breaks the "core principles" of agile.

What a beautiful irony have we built :)

We do agile

Guess what? Every single one of them was doing waterfall.

Their agile included preplanning and pre-specifying the full spec and each task, before the project kicked off. We'd have meetings where we'd drill down into tasks, folks would write them down so detailed that there would be no other way than doing that. Agile would be claimed, but the start date, end date, end spec and number of developers was always concrete.

Sometimes, the end date was too late, so a panic would ensue. Most of the time, the date was too late because developers had "unknowns" which then had to be "drilled down and specced so they wouldnt be unknowns". Sometimes, nearly 50% of the workweek was spent on meetings.

A few times, a project was running late - so to make sure we are _really_ doing it agile, we'd have morning standups, evening standups, weekly plannings, retrospectives, and backlog refinement. It would waste the time, and the "unknowns" aka "tickets to refine" were again, as always, dependant upon the PM/PO/CEO's wishes, which wouldn't get crystallized until it was _really last minute_.

One customer wanted us to do a 2 year agile plan on building their product. We had gigantic calls with 20+ people in them, out of which at least half had some kind of "Agile SCRUM Level 3 Black belt Jirajitsu" certificates.

To them, Agile was just a thing you say before you plan things. Agile was just an excuse to deal with project being late by pinning it on Agile. Agile was just a cop out of "PM didn't know what to do here so he didnt write anything down". Agile was a "we are modern and cool" sticker for a company.

And unfortunately, to most of them, agile was just a thing you say for the job, as their minds worked in waterfall mode, their obligations worked in waterfall mode, companies worked in waterfall mode, and if they failed their obligation to the waterfall, their job would go down one.

So while we were doing the Agile ceremonies, prancing around with our Scrum master hats, using the right words to fit into the Agile™ worldview - we were doing waterfall all along.

And after 15 years, I'm not even sure - did agile really ever exist?

Yeah, we cannot predict with 100% accuracy the results of a model, not mentally, as to be able to do that we should be able to do the same math in our head and that's just ultra rare next level intelligence. And we can make a reliable predictor, but making a reliable prediction model of a models results would be the same model in the end.

So the closest that we can get to "understanding" it fully, is learning how it works, and developing intuition around it. And I think we pretty much have that, at least among the people in the field. Those who worked on training it especially have some intuitive understanding of what is going on, otherwise they would not know where to "test and hack".

It's math all the way down, but I feel like the angle some people in early days used about "magic emergent properties" or "signs of consciousness" ended up making it seem more mystical than it is.

If you train it on a dataset of Othello games, or a dataset including these, you are basically creating a map of all possible moves and states that have ever happened, odds of transitions between them, effective and un-effective transitions.

By querying it, you basically start navigating the map from a spot, and it just follows the semi-randomly sampled highest confidence weights when navigating "the map".

And in the multidimensional cross-section of all these states and transitions, existence of a "board map" is implied, as it is a set of common weights shared between all of them. And it becomes even more obvious with championship models in Othello paper, as it was trained on better games in which the wider state of the board was more important than the local one, thus the overall board state mattered more for responses.

The second research you linked is also has a pretty obvious conclusion. It's telling us more about us as humans than about LLM's, about our culture and colors and how we communicate it's perception through text. If you want to try something similar, try kiki bouba style experiments on old diffusion models or old LLM's. A Dzzkwok grWzzz, will get you a much rougher and darker looking things than Olulola Opolili's cloudy vibes.

The active research is as much as:

- probing and seeing "hey lets see if funky machine also does X"

- finding a way to scientifically verify and explain LLMs behaviors we know

- pure BS in some cases

- academics learning about LLM's

And not a proof of where our understanding/frontier is. It is basically standardizing and exploring the intuition that people who actively work with models already have. It's like saying we don't understand math, because people outside the math circles still do not know all behaviors and possibilities of a monoid.

And another joke says the best way to explain a monad tutorial is to write another one, so sorry for this.

Just think of it as a box.

If amazon sent items themselves, it would be hard to pack, no way to standardize, things would break often or fall out of their respective boxes.

Now, if you put it into one of the standardized boxes, that makes things 100x easier. Now you can put these on a conveyor belt, now you can have robots sorting these, now you can use tape to close them, standardization becomes easy as it's not "t-shirt,tennis ball,drill" but just "box box box".

So now you can do all kinds of things because it's all a box. And you can also stress test the box.

It's the same with these.

A. You can just have a function that: calls a something on IO, maps it's values, does a calculation, retries if wrong, stores the result, spits it out.

Or B. you can have functions that calls any function on IO, functions that map any value to any other value, functions that take any other function and if that function fails calls another function or retries, one that stores any value given to it and returns with information if it saved or not etc.

The result is the same in the end, but while 1 makes the workflow be strictly defined only for that case, and now you have to handle every turn and twist manually (did the save save? what if not? write a check, write a test that ensures its not and the check works, same if it does...) the 2 lets you define workflows with pre-tested, pre-built blocks that work with any part of your codebase.

And it makes your life 1000x easier because now you have common components that work with any data type inside your codebase, do things your way always, are 100% tested and make it easier to handle good cases, bad cases, wiring and logistics. And you can build pipelines out of them. Because at the end, what it does is just lets you chain functions that return wrapped values.

And you end up with code like:

val profileData = asAsync { network.userData(userId) } //returns a Async

.withRetries(3) // Works on Async, and returns Result, retries async if fails

.withTraceId(userId) //wrapped flatmap that wraps success into Trace and adds a traceId

.mapTrace(onError = { ErrorMappingProfile }, { user -> Profile(user.name, user.profileId) } // our mapTrace is a flatMap for Trace objects, so it knows how to extract trace objects, call the functions and wrap them again

.store("profile_data") //wrapped mapCatching again for storage explicitly that works on Trace objects, knows how to unwrap them, stores them,

.logInto(ourLogger) // maps trace objects into shared logger

Each of these things would before have to be manually written inside the function, the whole function tested for each edge case. if/else's, try/catch, match/when/switch.

This way, only thing you need to cover with tests now is `network.userData()`, as all other parts are already tested, written and do what they say they do. And you can reuse this everywhere in your projects. Instead of being a function you call with data, it becomes a function you give a box and it returns a box. Then you can give it to any other function that needs a box. If boxes make no sense, think of the little connectors on lego bricks, or pipe connectors in plumbing, or stacking USB adapters or power strips.

I can't stress enough how much this approach helped me in real life cases - refactoring old codebases especially, as once you establish some base primitives, the surface area starts massively collapsing as the test surface area increases.