Anyone who uses LLMS should suck on my ballsack
Fast
411–420 of 450 posts
Re: Fast
#412It's well known, but this video[1] is a proof of concept demonstration from 4 years ago, Casey Muratori called out Microsoft's new Windows Terminal for slow performance and people argued that it wasn't possible, practical, or maintainable to make a faster terminal and that his claims of "thousands of frames per second" were hyperbolic, and one person said it would be a "PHD level research project". In response, Casey…
I simultaneously love and hate watching Casey Muratori. Love because he routinely does things like this, hate because I have conversations like this entirely too often at work, except no one cares.
Re: Fast
#413It's well known, but this video[1] is a proof of concept demonstration from 4 years ago, Casey Muratori called out Microsoft's new Windows Terminal for slow performance and people argued that it wasn't possible, practical, or maintainable to make a faster terminal and that his claims of "thousands of frames per second" were hyperbolic, and one person said it would be a "PHD level research project". In response, Casey…
I would have loved to live in a universe where we could replace the Windows Terminal with RefTerm - if only, to measure how many hours would pass before a Fortune 500 company has to halt operations, because RefTerm does not properly re- implement one of the subtle bugs creeping from one of the bazillion features that had made WinTerm slow over the years. [1] [1] https://xkcd.com/1172/
I sighed when I read your comment, a comment which is exemplary of what Casey Muratori was ranting against - casual lazy dismissal of the idea that software can be faster, based on misunderstanding and lack of knowledge and/or interest, and throwing out the first objection that comes to mind as if it's an impassable obstacle. There were no bazillion features that made WinTerm slow over the years because Windows Terminal was a new product for Windows 10, released in 2019.[1]. There were piles of problems in Windows Terminal, Casey calls out that it didn't render Right-to-Left Arabic combining glyphs and it wasn't a perfect highly polished program from the outset. And it was an optional download, Fortune 500s wouldn't run it if they didn't want to.
RefTerm was explicitly not a production quality terminal and was not intended to be a replacement for Windows Terminal. RefTerm was a lower bound for performance of an untuned single-thread terminal. RefTerm was a proof of concept that if Microsoft had spent money and engineering skill on performance they could have profiled and used fancy algorithms and shortcuts and reimplemented slow Windows APIs with faster local ones, used threading, and improved on RefTerm's performance. A proof that "significantly faster terminals are unrealistic" is not true, that all the casual dismissals of why it's impossible are not the reasons for slowness, and that 10x better is an easily achievable floor, not a distant unreachable ceiling.
As a result of Casey's public shaming, Windows Terminal developers did improve performance.
Re: Fast
#414> Rarely in software does anyone ask for “fast.” They don't explicitly ask for it, but they won't take you seriously if you don't at least pretend to be. "Fast" is assumed. Imagine if Rust had shown up, identical in every other way, but said "However, it is slower than Ruby". Nobody would have given it the time of day. The only reason it was able to gain attention was because it claimed to be "Faster than C++". Watch…
To a first approximation HN is a group of people who have convinced themselves that it's a high quality user experience to spend 11 seconds shipping 3.8 megabytes of Javascript to a user that's connected via a poor mobile connection on a cheap dual-core phone so that user can have a 12 second session where they read 150 words and view 1 image before closing the tab. Fast is _absolutely not_ the only thing we care abo…
It's not that they convinced themselves, but that they don't know how to do any better. It is as fast as it can be to the extent of their knowledge, skill, and ability.
You see some legendary developers show up on HN from time to time, sure, but it is quite obvious that the typical developer isn't very good. HN is not some kind of exclusive club for the most prestigious among us. It is quite representative of a general population where you expect that most aren't very good.
Re: Fast
#415Fun story time! Early in my career as a software engineer, I developed a reputation for speeding things up. This was back in the day where algorithm knowledge was just as important as the ability to examine the output of a compiler, every new Intel processor was met with a ton of anticipation, and Carmak and Abrash were rapidly becoming famous. Anyway, the 22 year old me unexpectedly gets invited to a customer meetin…
Why do you count it as a highlight if your product failed to meet expectations?
Re: Fast
#416Earlier quoted context omitted.
But both Dafny and Lean (which are really hard to put in the same category [1]) are used even less than TLA+, and the problem of formally tying a spec to code exists only when you specify at a level that's much higher than the code, which is what you want most of the time because that's where you get the most bang for you buck. It's a little like saying that the resistance to blueprints is that a rolled blueprint mak…
Appreciation isn't the same as market share, formal proofs in general are pretty much inexistent in enterprise, unless there are legal requirements to do otherwise. I fail to see how you validate that TLA+ model is actually correctly mapped into the written Java code.
> formal proofs in general are pretty much inexistent in enterprise, unless there are legal requirements to do otherwise.
Formal proofs are rarely used when specifying with TLA+, too, BTW. Writing formal proofs (as you would in Lean) has a very low ROI, and even formal method fans (like me) would tell you that's a tool you should reach for very rarely, and only if you must.
> I fail to see how you validate that TLA+ model is actually correctly mapped into the written Java code.
You don't (not even with Lean), but that we can't have cars that are completely crash-proof doesn't mean that's the standard for accepting or rejecting a safety measure. With TLA+ you can make sure that the design that you have (and you can't validate is actually implemented in code with or without TLA+) is actually good.
In other words, it lets us think about design rigorously. Maybe that's not all we wish for, but it's a lot, and it's not like there are better, easier ways of doing that. Of course, if the goal is to avoid thinking hard about design, then a tool that helps us think even harder isn't what we want.
Re: Fast
#417Earlier quoted context omitted.
But both Dafny and Lean (which are really hard to put in the same category [1]) are used even less than TLA+, and the problem of formally tying a spec to code exists only when you specify at a level that's much higher than the code, which is what you want most of the time because that's where you get the most bang for you buck. It's a little like saying that the resistance to blueprints is that a rolled blueprint mak…
Architectural blueprints are very precise. What gets built is a more detailed form of what is in the blueprint. That is not the case for the TLA+ spec and your 1MLOC Java Database. You hope with fingers crossed that you've implemented the design, but have you? I can measure that a physical wall has the same dimensions as specified in the blueprint. How do I know my program follows the TLA+ spec? I'm not being facetio…
> That is not the case for the TLA+ spec and your 1MLOC Java Database.
That is the case. Of course, nobody bothers to write the TLA+ proof that that is the case, because even if somebody had the resources to do it, the ROI on doing that is not good. If you can avoid 4 major bugs with 10 hours of work, you probably won't want to work an extra 10,000 hours to avoid two additional minor ones. That most people choose to stop when the ROI gets bad and not when they achieve perfection is not a problem.
The question isn't what tool guarantees perfection (there isn't one), but what toolset can reduce the greatest number of (costly) bugs with the least effort, and tools that help you think rigorously about design are a part of such a toolset.
> You hope with fingers crossed that you've implemented the design, but have you?
The same way you always validate that you've implemented what you intended - which is more than just keeping your fingers crossed - except that TLA+'s job is to make sure that what you intend actually works (if implemented).
> While Dafny might not be the answer we should strive to find a good way to do refinement.
TLA+ does refinement in a much more powerful way than Dafny. Neither is able to do it from a high-level design to a large and realistic codebase, certainly in any afforable way, but nothing can. I guess that is a problem, but it's not the problem we can solve, and there are other big problems that we can.
Re: Fast
#418Earlier quoted context omitted.
Naturally. Centuries of typography as a field and your anecdote obliterates it.
Centuries of typography during the age of print. Screens have continuously changed (resolution, refresh rate, size, reflectance, color reproduction, black levels, etc.) over the past 30 years and it's not guaranteed that conventions from print make sense for the current mix of screens.
But we have remained largely the same. And I don't see how colour accuracy affects how many words per line most humans can comfortably deal with.
This whole discussion is silly and rooted in ostensibly clever people who have mastered something unnecessary hard and have now tied their identity to that mastery.
Power users what their tools to be shit. Sure.
Re: Fast
#419The article makes two points—one about software performance, the other about development performance. On the topic of software performance, I think the best explanation I got came from the great Prof. Charles Leiserson’s MIT course on performance engineering: performance is a currency. It’s something we spend to gain other qualities—safety, rich features, user-friendliness, and so on. At the end of the day, a computer can executes about 100 simple primitve instructions. The reason we have a software industry is because of speed.
https://ocw.mit.edu/courses/6-172-performance-engineering-of...
Re: Fast
#420Earlier quoted context omitted.
I don't know how to do it with Claude Code, but I was at a beach vacation for the past few days and I was studying french on my phone with an webapp that I made. Sometimes I'd notice something bug me, and I used cursor's "background agents" tool to ask it to make a change. This is essentially just a website where you can type in your request, and they allocate a VM, check out your repository, then run the cursor LLM…
Is this Terragon's offering, or does Cursor also have web-based background agents?
Cursor has web-based background agents, they launched them recently