I remember an article a couple of years ago where someone rigged up a camera to measure key press to screen update on different machines and the results were eye opening.
edit: found it http://danluu.com/input-lag/. The Apple ][ ties for first place with an iPad Pro.
"Almost everything on computers is perceptually slower than it was in 1983" https://threadreaderapp.com/thread/927593460642615296.html
I find myself frequently bamboozled until I stop and try and determine which mode I'm in. Navigation behaves differently to browsing, which behaves differently to searching, which behaves differently to viewing an individual result. I'll be thrown from one mode to another and never feel in control of the app.
Pressing on some place while being in other than top mode.
The back button experience.
And the bottom drawer, no idea when I should pull it up or down, or if I am currently in it.
There were websites I had never heard of using hundreds of megs. Also acehardware.com for some reason using hundreds of megs.
Also Github "community" forums and Travis "community" forums (I don't use travis anyore) using hundreds of megs. Are some websites just caching the entirety of every page you look at in local storage? How rude.
* When used with an Apple Pencil (30ms). When used with touch it drops to 70ms.
Also, it's worth noting that there's a very limited list of devices tested there and it heavily skews Apple.
This is part of what I meant when I said "drastically restrict the problem space".
What on earth have we done to ourselves?
That's a big part of what we've done to ourselves. And this makes computers better for a whole lot of people.
First, all those things sans high DPI functionality existed in 1998.
Second, most of Electron apps don't benefit from these theoretical advancements.
Preemptive multitasking existed in 1998 and worked every bit as well as it does today. Even in MS Windows.
Security, nah. We have more attack vectors than at any point in the past. And just more crapola caked on to "protect" against those.
https://www.fltk.org/doc-1.3/fluid.html
You pretty much draw the UI in fluid and fill out the callbacks. Yeah it's C++ but it's not particularly esoteric C++.
No need for that - you could use Zig or Rust. Though both need a better GUI frameworks, but it's certainly more efficient with them.
I moved from sublime to atom to VS code, but eventually settled on Vim because I was able to get the same features (that I used) while getting almost instant response. A feeling that has completely changed how much I enjoy writing any sort of text.
But eventually wasn't able to get the same code completion, and searching was also a bit more painful.
How do you go about that? Would you mind sharing your setup? :)
The intro looks great I will definitely check this out.
Thanks for sharing!
It's conceptually similar to sketching out the design of your code with a pen and paper or whiteboard. First write it quickly, then make it correct.
Anyway, if you don't care about all that, you can get a similar effect by turning off intellisense (or equivalent) in your IDE while you write, then turn it back on at the end to get what you just wrote to compile. I do this sometimes in Android Studio.
The VSCode Neovim extension makes neovim run as its backend, while giving you all the IntelliSense etc of VSCode. I can’t tell exactly you how it affects responsiveness as I only toy around with it, but it does feel noticeably better in some aspects...yet maybe occasionally glitchy?
Anyway it’s pretty interesting, especially if you’re already using neovim anyway.
For searching, use SilverSearcher / fzf
For C/C++, could use QT Creater or KDevelop too, which I think are pretty good in latency.
BEFORE the typed character shows up? Are you sure?
16ms should be an absolute upper bound for a character to show up. Everything else comes after.
Another example is the Enlightenment window manager. It was considered a little heavy, but good looking. But because there was a large hiatus in development, it got "stuck in the past" and now, it is one of the lightest there is.
I'm just kidding. Don't want to start a fight here.
But those wars are long over anyway, these days. One might just as well fight over whether the monolith on Earth's moon is better than the one on Europa, or vice versa.
We had them.
> we could be writing all our programs in C, still.
You don't need to use C, there are other languages. For example a hello world in Free Pascal[0] (a natively compiled language with no runtime or other dependencies, which supports object oriented programming and has RTTI rich enough to implement automatic object serialization, semi-automatic memory management, strings that know about their encoding, etc) is just 32KB.
Some time ago i wrote Fowl[1], a mostly complete recreation of the OWL toolkit that came with Turbo Pascal for Windows, the demo program of which is around 80KB.
Of course for a more realistic (and MUCH easier to use and develop with) approach, you'd need something like Lazarus[2]. A minimal application in Lazarus is 2.18MB. This might sound too big... and TBH it is, but the size doesn't grow too quickly from there. For example a profiler i wrote recently for Free Pascal applications is... 2.16MB (yes, smaller, why? Well, because i replaced the stupidly huge default icon with a smaller one :-P and without the default icon a minimal application is 2.05MB so the profiler added around 100KB of additional "stuff").
> It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters
FWIW we had those, Visual Basic (or even QBasic) would format your code as you type it, Visual Basic 6 and Visual C++ 6 would profile auto-completion (VB6 even for dynamic stuff), etc. Only issue with C++ was that sometimes it wouldn't work around complex macros.
But modern editors do a bit more, still no excuse for being that sluggish. Lazarus does pretty much everything you'd expect from an IDE with smart code completion (e.g. things like declaring variables automatically, filling method bodies, etc) and code suggestions yet it runs on an original Raspberry Pi.
Now i'm not saying that you should not be using whatever you are using or that you should code on a Rasberry Pi or even to switch to Free Pascal / Lazarus (which honestly is far from being free of issues), but i think that you're overestimating what tools do nowadays and many people are so used to running slow and bloated software that take it for granted that things should be like that and cannot even imagine things being better.
[0] https://www.freepascal.org/
But it is also an interesting thing to mention because in the last two C++ jobs i had where Visual Assist was preinstalled on my machine, i always disabled it because it was slowing down Visual Studio too much and the functionality VS provides is more than enough - VA does provide a bit more, but for me wasn't worth the slowdown.
If you’re using Visual Studio for C++ I’d highly recommend Resharper C++. If you develop for Unreal Engine Rider for Unreal C++ is literally unreal, it makes me not hate writing Unreal C++ code.
One of my key learnings with alternative languages is to always use the SDK tools from the platform vendor, everything else comes and goes, while playing catch up all the time.
Anyone measuring typing speed as productivity measurement is doing it wrong.
Writing code is around 50% of daily activities.
Visual Assist doesn't do nothing when I have to write documentation, architecture diagrams, meetings to decide roadmap items, demos at customer review meetings,....
On top of that, none of the OS SDK replacements offer better UI or debugging capabilities across the platform tooling, they just play "catch-me if you can" with what I can get on day 0 of each OS SDK release.
JetBrains wants to be Borland, yet they don't sell any of the platforms, or languages.
I guess Kotlin and Android marriage will help them, as they are trying to make it their "Delphi", lets see how it plays out if Fuchsia ever happens.
https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...
> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA.
I don’t measure my productivity by how much code I can write, that was just an example.
The way I work designing systems and architecture, I have already made the solution in my head and basically the “coding” part is just trying to get that info out as fast as possible. I have a similar thing to eidetic memory, but I am so ADHD what gets remembered can be random or missing stuff. I remember all code I’ve ever written, seen, or thought about and tools that allow me to basically brain dump this info greatly improve my production, leadership, confidence, and architectural designs.
Even so, shouldn’t it be able to do that in 16ms?
Do modern graphics drivers for X or Wayland hand off font rendering to the GPU? They probably should -- it's maybe 100 or so small textures per font-selection, 150KB or less prerendered with 3-bit alpha, and maybe 100 loaded up into graphics RAM at a time -- 10MB is nothing, really.
It's just that text editors of the modern day are programmed by people who prefer to not write it that way - mainly because it's quite hard, and the modern OS doesn't usually fit well into this framework of rendering for multi-tasking. And it takes more effort too.
Much easier to rely on a UI framework which adds overhead. The expectation is that the user probably won't care, and prefer that the software be more feature rich.
IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhere in the middle.
OT but a bone to pick with that article:
> Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT.
That isn't what my text editor is doing, though. It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters. Sometimes I feel like people forget that.