caspper69

Ok, I will need to work on my reading comprehension skills.

That being said, I thought the purpose of OCR was to take text from a non-digital source and make it digital.

Why should we have to OCR something that exists already in a perfectly interchangeable digital format already?

Continuing on with my "old man yells at cloud" meme of late, here's my hot take:

So let me get this straight- we are going to train AI models to perform screen recognition of some kind (so it can ascertain layout and detect the "important" ui elements), and additionally ask that AI to OCR all text on the screen so it has some hope of being able to follow some natural language instructions (OCR being a task which, as a HN thread a day or two ago pointed out, AI is exceedingly bad at), and then we're going to be able to tell this non-deterministic prediction engine what we want to do with our software, and it's just going to do it?

Like Homer Simpson's button pressing birdie toy? :smackshead:

Why do I have reservations about letting a non-deterministic AI agent run my software?

Why not expose hooks in some common format for our software to perform common tasks? We could call it an "application programming interface". We might even insist on some kind of common data interchange format. I hear all the cool people are into EBCDIC nowadays.

Then we could build a robust and deterministic tool to automate our workflows. It could even pass structured data between unrelated applications in a secure manner. Then we could be sure that the AI Agent will hit the "save the world" button instead of the "kill all humans" button 100% of the time.

On a serious note, we should study various macro recording implementations, to at least have a baseline of what people have been successfully doing for 40+ odd years to automate their workflows, and then come up with an idea that doesn't involve investing in a new computer, gpu, and slowly boiling the oceans.

This reeks of a solution in search of a problem. And the solution has the added benefit of being inefficient and unreliable. But, people don't get billion dollar valuations for macro recorders.

Is this what they meant by "worse is better"?

Edit: and for the love of FSM, please do not expose any new automation APIs to the network.

When the executive is also vested with the power of enforcement, then, by construction, it usurps the power of the other 2 branches to check its authority.

Which I think is obvious- a power hungry executive who disputes an attempted check of its authority by one of the other branches can simply decline to enforce.

Ipso facto, unchecked executive power.

Edit: you seem informed, so you should know that issues like these are not new; Andrew Jackson famously ignored the Supreme Court and told them to get bent way back in 1832 after their decision in Worcester v Georgia.

To use a programming analogy, our government's type system has a soundness problem. That means we, as a civilized society, have to follow a few unwritten rules to make sure the system remains functional and doesn't crash. One of those is for the executive to exercise restraint on the technical power they have in the interest of not encountering UB.

Yes, virtual DOM. My mistake. Not even sure why I used the term shadow DOM.

That makes sense. I understand the rationale now.

I appreciate the detailed and thoughtful response.

I have hopes that adoption outside of stodgy enterprises will pick up, which would of course help the job situation (in due time of course).

Sometimes it's hard to shake the rep you have when you're now a ~25 year old language.

Awareness takes time. People need to be told, then they need to tinker here and there. Either they like what they see when they kick the tires or they don't.

I'm pretty language agnostic tbh, but I would like to see it become a bit more fashionable given its modernization efforts, cross-platform support, and MIT license.

I've played with JSX a couple of times but not HTMX, and it's been a while since I wrote any Go code (pre-generics, so I've got some reading to do).

I have been looking to slap together a small blog platform, and this sounds like a perfect setup. Thanks, I appreciate the tips.

And yes, I would be honored if you used my analogy! Hopefully it can give some frustrated devs a chuckle and brighten a small part of their day.

I hope you understand that a fair bit of my second post was tongue-in-cheek.

I appreciate the concrete examples, and yes, that makes perfect sense when you start getting into data-heavy frontend applications. I do remember jQuery being useful for AJAX and for DOM selection primarily, so I get it.

And of course I knew I was missing something, that's why I asked lol, the question was serious and I knew HN wouldn't let me down.

I'm still a bit mystified about the necessity of a shadow DOM, it just seems counterintuitive to me, but perhaps it's because I'm not familiar with browsers' DOM handling conventions. Perhaps me gaining some insight there would make the purpose of a shadow DOM more clear.

Honestly, I really did figure that it had something to do with the event model (not the DOM or shadow DOM). Something about providing a more consistent apparatus for wiring and handling events.

I still think there's a lot of unnecessary spinning of the wheels on the front end, but that gets beat to death around here, so I'll let it be.

Well we can all relate to that. We've all got to eat (and stay warm & dry).

I think I'm just getting to the "old man yells at cloud" stage of my career.

I think of all of the things that we could have built over the years, and understand, I say this not to detract from all of the great software that has been built, but to lament the fact that devs spend so much time spinning their wheels these days (when not reinventing them, or trying to fit a square one on a race car) that we have spent so much opportunity cost that could have been the next big thing or the better version of an old thing.

I would just implore people to go back and look at the history of computing, and the things we had back then (even if they were research demos or ahead-of-their-time pipe dreams), and remember that we have 100,000-1,000,000x the compute (or more) than we had when these older things were built. We can do better.

And remember, not every abstraction is a useful one, not every appeal from authority should be taken as gospel, that creating software can be one of the most creative and expressive endeavors one can undertake, that there is no greater joy than seeing people use the things you build (or help build), and that there's no such thing as perfect software (but we should always strive to get as close as reasonably possible).

I like it.

I will add it to my lexicon.

Thanks!

I don't mean to be obtuse, so let me make sure I have this right (and please afford me some leeway on my gentle ribbing, I assure you it's all in good fun and nothing personal):

A framework will allow me to separate the app from its backend?

The web, by its very nature, runs on a client/server architecture, so it has long been possible to separate the front from the backend via an API (we can argue the level of difficulty involved, but I would say the friction was substantially reduced with the introduction of XMLHttpRequest).

So aside from separation via API, according to your list, that leaves us with (1) a bigger development team; (2) a less efficient result; (3) a potentially more polished result (I added possibly, because I'm dubious about the claim that a JS framework makes the result more polished- does it make the browser render the HTML components in a higher resolution or higher color bit-depth?); (4) someone on call (like an employee or group of employees who have to be on call at all times? or am I misunderstanding?); and (5) a better "bus factor" which is a term that I am actually unfamiliar with (is this jargon, or is it an actual technical term/concept?).

Which of these are technical in nature, or rather I should say, which of these factors has anything to do with software (in the abstract) or actual code or markup (in the concrete)?

Now for my more serious follow up: just level with me; is this all bs? Do people use these frameworks because they don't know any other way to do it? Is it a code / organizational issue? Did people take the "separate all code from all HTML/CSS" advice too far and adopt it as dogma? Do people find the event model in JS to be too complex or unreliable? Is it an issue of people getting hooked on frameworks while JS was in flux so they needed the polyfills? Is it that people fell in love with TS, which naturally led to framework-itis?

I feel kind of like I went to the future, and everybody rides exercise bikes everywhere they go to stay in shape, but since exercise bikes don't go anywhere, they have to be put in the bed of a pickup truck first, you know, to actually go places, but then there was a gas shortage, so it was decided to save gas we'd all carpool by putting 5 pickup trucks on a single semi-truck flatbed. Because that's just how things evolved.

So now you're explaining to me why I see people riding exercise bikes on top of pickup trucks that are themselves being pulled 5 at a time on the back of a semi truck, and you're looking at me like I'm out of touch because I can't figure out why you guys can't just walk the 250 feet to the store across the street.

Having spent a decade in the late 90s / early aughts doing PHP web development (including Bootstrap), I can't for the life of me figure out why modern frameworks need hooks and a shadow DOM and a component model.

I dabbled for a bit about a decade ago, and the first and last JS framework I worked with was Angular2 (which was in beta); this was right about the time Typescript was getting started (in fact, I distinctly recall that a substantial number of popular JS libraries didn't even have TS bindings at that time).

I think I didn't really want to look stupid by asking in public on HN, but given recent events, I think that ship has sailed :)

Other than analytics, what in the world do we need all of this JS for? I used jQuery (sparingly I might add), and it did its job.

Most web forms don't even have that many components.

I honestly don't mean to insult anyone, and I know I must just be naive about something.

Because otherwise, HTML/CSS aren't that complicated. Messy? Sure. Large? Yup. Duplicative in areas? 100%.

So what am I missing? What exactly does React do so well that the added complexity and resulting slowdowns become an acceptable tradeoff?

You are technically correct.

What you are overlooking is the underhanded plays executed by a certain political party to allow one president during one 4-year term to appoint 3 supreme court lackeys in order to ensure no matter what bs went before them, they'd rule in his favor.

The idea of the "unitary executive", a concept that has long been a wet dream of the Federalist Society and other conservative think tanks, is the most decidedly un-American thing I can imagine.

Our country was founded on the idea of 3 co-equal branches of government, who each have the duty and authority to exercise checks and balances against the other 2 branches (trust but verify).

Further, the citizens are supposed to have representatives in the house & senate who act as their voice on issues and execute their will and represent their interests.

Nowhere in this entire framework was there a President with the authority to rule by executive fiat, who has absolute immunity from every law of the land, and who is given free reign to do as he pleases like a bull in a china shop. The President of the United States is not a Monarch and he is not a King. There is no divine bloodline in the US of A. The President should always be answerable and accountable to the citizens of the United States and the other 2 branches of government, and they should be held to account for his/her actions.

The current legal framework is a travesty and a result of a gradual erosion of many foundational principles of our republic that have been ground down since FDR dared to empower the working man 80 years ago. In short, it's an abomination.

And don't give me this "but Biden had that same authority" bs. Anybody who knows anything about politics know Dems are spineless. If a Dem tried to pull one tenth of the shit the Republicans do, Rs would be all over AM radio, Fox News, Breitbart, X, Rogan, screaming at the top of their lungs about socialism or some kind of "takeover" or telling people their country is being stolen from them, or some other boneheaded idiotic conspiracy theory. They know there's always someone to fall for their shit. Remember the guys showing up at the DC pizza place looking for the child sex dungeon in the non-existent basement? Yeah, these geniuses.

It's always the same old shit- rich & powerful people don't like being told "no" by the government. Oh, and they also hate paying the government (we all do, but to them it's an actual insult). This is a tantrum of epic proportions, and all this crap is political theater for people who don't know any better.

As an aside, not a one of them has any problem holding out their hand to get old Uncle Sam's money, nor do they have a problem suckling at the government teet their entire career. Ironic, no?

If half these people knew they were carrying water because some spoiled brat of a man didn't want to pay his taxes or got pissed because they can no longer light a river on fire, they'd tell these gold-brickers to pound sand.

But that can't happen anymore. Everybody is plugged-in. The algorithms that drive engagement drive the feedback loop. People can't even argue anymore, because no one knows what the hell is really going on.

This is what our ancestors fought and died for: Twitter and Donald "I can't even make money running a casino" Trump.

The worst part? These people truly don't care. "Gee whiz, why are all these billionaires building bunkers thousands of miles away from the continental US?" Because they're planning to light the USA on fire and bounce. They don't care if you are a republican or a democrat. They don't care about anything. They got theirs. They raped the system, rigged the system, and that's it. Why? Because, paraphrasing George Carlin, "You ain't in their club, you ain't ever going to be in their club. They don't give a shit about you."

And one half the country is helping burn it all down, while blaming the other half of the country for "making them do it ha ha, see what you get you stupid <insert insult here>", meanwhile, the greatest grifters of all time will be sneaking out the back door with the loot to live out their days sipping mai tais, sailing around on aircraft carrier sized yachts, talking on satellite provided cellphones, and jacking off all day, while we continue to argue with each other about whose fault it is that all the money's gone.

Pathetic.

I think you mean "if we don't like it, it will be lied about and demonized".

DJT & Friends don't exactly have a stunning track record of being truthful.

In fact, I don't think the man ever tells the truth. And I wish that were hyperbole. He literally just makes shit up as he goes along, and his legions of brainwashed followers just repeat what he says and twist facts to try to fit the narrative after the fact.

Biden was a geriatric moron, and I'm sure he looked the other way while people he knew profited from his actions, but this MAGA shit is a grift on a whole other level. This is like stealing the Holy Grail and getting away with it.

Brigading you is not my intent, so please don't take my comments that way.

I just want to add that C# is getting pretty fast, and it's not just because people have had a long time to submit better implementations to a benchmark site.

The language began laying the groundwork for AOT and higher performance in general with the introduction of Span<T> and friends 7 or so years ago. Since then, they have been making strides on a host of fronts to allow programmers the freedom to express most patterns expected of a low level language, including arbitrary int pointers, pointer arithmetic, typed memory regions, and an unsafe subset.

In my day-to-day experience, C# is not as fast as the "big 3" non-GCed languages (C/C++/Rust), especially in traditional application code that might use LINQ, code generation or reflection (which are AOT unfriendly features- i.e. AOT LINQ is interpreted at runtime), but since I don't tend to re-write the same code across multiple languages simultaneously I can't quantify the extent of the current speed differences.

I can say, however, that C# has been moving forward every release, and those benchmarks demonstrate that it is separating itself from the Java/Go tier (and I consider Go to be a notch or two above JITed Java, but no personal experience with GraalVM AOT yet) and it definitely feels close to the C/C++/Rust tier.

It may not ever attain even partial parity on that front, for a whole host of reasons (its reliance on its own compiler infrastructure and not a gcc or llvm based backend is a big one for me), but the language itself has slowly implemented the necessary constructs for safe (and unsafe) arbitrary memory manipulation, including explicit stack & heap allocation, and the skipping of GC, which are sort of the fundamental "costs of admission" for consideration as a high performance systems language.

I don't expect anyone to like or prefer C#, nor do I advocate forcing the language on anyone, and I really hate being such a staunch advocate here on HN (I want to avoid broken record syndrome), but as I have stated many times here, I am a big proponent of programmer ergonomics, and C# really seems to be firing on all cylinders right now (recent core library CVEs notwithstanding).

Understood.

Borrow checking is not the only way to achieve memory safety.

Can't speak for CUDA specifically, because I don't do anything with LLMs or ML locally, but I did have to rebuild ffmpeg with some some bits built with nvcc (and maybe an nvidia provided library- sorry it's been a while) to get GPU accelerated transcoding going.

But yes, the GPU passthrough layer in WSL2 (or however it's actually implemented) is present by default.

If anything, WSL1 showed me that MS still has some programming chops lurking around (I mean, obviously, I know they have some truly amazing developers and their research talent is top notch), but that project was technically pretty cool with the pico-processes and syscall translation layer.

But the one thing they would never be able to overcome was CUDA and kernel modules. If you show people "Linux" and they can't build their software, then it might as well be hot garbage.

I use WSL2 daily and far more often than my actual Linux VMs. It's not the fastest, but it did solve a huge chunk of the problems with WSL1. No, it's not native, but I already have 3 monitors, a huge tower, and a Mac Mini M1 on my desk. I didn't need a native box at my fingertips (those go on a rack in the basement, lol).

Your comment posted as I was making my edit re: Go.

Thank you for the detailed clarification.

His blog post is based upon the premise that his generational gc allocator doesn't seem to provide the performance benefits that generational gc is claimed to provide vs other more traditional gc approaches (e.g. mark and sweep- also his implementation).

My initial take is that either his implementations are deficient in some way (or not sufficiently modern), there's some underlying latent issue that arises from the Scheme to C compiler or the kind of C code it generates, or perhaps the benchmarks he is using are not indicative of real-world workloads.

But- I am out of my depth to analyze those things critically, and he seems to write about GC quite a bit, so maybe he's very in tune with the SOTA and he has uncovered an unexpected truth about generational gc.

It certainly wouldn't be the first time that an academic approach failed to deliver the benefits (or perhaps I should say the benefits weren't as great in as many scenarios as originally opined).

As an idiot programmer, my understanding is that Java, .NET & Go all have generational GC that is quite performant compared to older approaches, and that steady progress is made regularly across those ecosystems' gc (multiple gcs in the case of Java).

P.S. and now I see in a comment below (or maybe above now) that Go doesn't use a generational gc. I'm surprised.

It is my understanding that Dan Gilbert (Detroit businessman, owner of the Cleveland Cavaliers) sold Rock Financial to Intuit who then re-branded it as QuickenLoans.

Gilbert then bought the mortgage unit back from Intuit a few years later, and re-branded it RocketMortgage.

I don't think Rocket has anything to do with Intuit/Quickbooks/TurboTax, with RocketMortgage being in Detroit and Intuit still in California (although I know geography doesn't have anything to do with anything really).

That being said, I fully agree with you 120%. I know desktop QB isn't great (it used to be, especially the DOS-based versions), but the SaaS is a hellhole. It's even worse.

How can businesses literally waste people's time like this? It's a real, quantifiable drain on productivity, with an absolutely insane multiplier based on the number of QuickBooks users. Things that used to take under 30 seconds (marking transactions cleared), now takes a minimum of 5 minutes or more. Ditto for any data entry.

For any bookkeeper, this could be an hour or two of just wasted time, each and every day. Just poof. Why? ARR.

Seriously, f*ck these guys. Asshats.

P.S. on your latency comments; I have something that is very relatable (because I do not think modern developers can relate to a non-programming workflow), modern devs, how would you feel if all of a sudden, every keypress in your IDE now took 3 seconds instead of being (mostly) instantaneous? How about if every time you saved your source file locally you got a spinning icon that took 5-10 seconds? What about if the "cd" command on the cli or the "up dir" or "back dir" button in your file explorer suddenly similarly randomly had a spinning icon for 15 seconds? These tiny delays add up in heavily-used software.

This is the effect your latency has on OTHER PEOPLE'S WORK. Just because you think that random sales, accounting, and clerical staff might not be on your level, doesn't mean they like having their time wasted. It's just absurd that this has become commonplace. If devs had to put up with it, that shit would stop immediately, because then they would feel the pain.

My rant is about shitty online modern software that replaced fully functional (and fast) software for “reasons”.

I don’t even know what you’re asking.

None of which handle bookkeeping, which is what Quicken was used for.

I think it should have been obvious from my list of complaints that I was doing something a little more involved than "checking my bank balance".

This may come as a surprise to you, but the vast majority of users absolutely hate it when their software changes.

They don't want all new interfaces with all new buttons and options and menus.

People get used to their workflows and they like them. They use their software to do something. The software itself is not the goal (gaming excepted).

I'm not suggesting that things should never be gussied up, or streamlined or made more efficient from a UX perspective, but so many software shops change just to change and "stay fresh".

> Does it really make sense to use Quicken (?) with a dialup modem that called into my bank once a day to update my balances like I did in 1996

Well, the modern hot garbage Intuit forces people to use takes 5-15 seconds to save a transaction, 3-5 seconds to mark a transaction as cleared by the bank, it sometimes completely errors out with no useful message and no recourse other than "try again", has random UI glitches such as matched transactions not being removed from the list of transactions to match once matched (wtf?), and is an abject failure at actually matching those transactions without hitting "Find matches", because for whatever reason the software can't seem to figure out that the $2182.77 transaction from the bank matches the only $2182.77 transaction in the ledger. That one really gets my goat, because seriously, WTF guys?

Not to mention the random failure of the interface to show correct totals at random inopportune moments.

Oh, and it costs 5x as much on an annual basis.

I sure would take that 1996 version with some updated aesthetics and a switch to web-based transaction downloading versus the godawful steaming pile of shit we have now- every day of the week and twice on Sunday. Hands down.

This idea that we've made progress is absolutely laughable. Every single interaction is now slower to start, has built-in latency at every step of the process, and is fragile as hell to boot because the interface is running on the framework-du-jour in javascript.

Baby Jesus weeps for the workflows forced upon people nowadays.

I mean seriously, have none of you 20-somethings never used a true native (non-Electron) application before?

Don't worry, they'll figure out a way to compile Skia to webassembly and re-link it to the DOM through JS.

Maybe then the circle(jerk) will be complete.

Ugh.

Thank you.

I appreciate the follow up and references.

Now I've got some Friday night reading :)

Do you believe that existing open source symbolic kernels are the limitation here, given that we can now easily (for some value of n) render the notation and the notes/annotations?

I mean, there are a ton of math libraries available for most programming languages, but symbolic solving is pretty important here, because presumably people would want to (for example) show the integral or summation symbols and use algebraic notation rather than, say, Mathematica functions.

I see you responded to both of my comments in this thread, but I'll save us both the trouble by doing a single reply.

I understood/understand the representations, and I am sure they are made in good faith.

At the same time, I also understand the reality of having the things you do seriously impact the work of others and the types of issues that can cause.

I did state that I was leaning on the side of him being unreasonable, but also that I understood the concern. Nothing more, nothing less.

In my research a few weeks back, I went down the rabbit hole of region based memory management, and Cyclone was one of the first languages I came across (the majority of academic papers on the topic retrofitted an existing language- usually C).

I might be wrong here, so please feel free to correct me if so, but I don't think borrowing was a concept, per se, of the language itself.

As you mention, the concept the Rust designers took from Cyclone was explicit lifetimes.

Borrow checking provides two features (but in my opinion in a very un-ergonomic way): (1) prevention of use after free; and (2) temporal memory safety (i.e. guaranteeing no data races, but not eliminating race conditions in general).

I'm still wobbly on PLT legs though; I'm sure there's a pro or ten who could step in and elaborate.