41–50 of 136 posts
Test your software on shitty hardware. It's great that your development computer has 32 cores and 64GB of RAM. But your users aren't so lucky.
Earlier quoted context omitted.
That's data size, not code. There's no fundamental reason that a program that can smoothly render unicode at 4k needs a GB download when kB could suffice.
We tried that in the Windows 9x days. We called that "DLL hell". The idea was that programs would share libraries, and so why have a dozen identical frameworks on the same system? Install your libraries into system32. If it's already there but an earlier version, deploy your packaged one on top. Turns out that nobody writes good installers, and binary level dependency requires too much discipline, and dependencies ar…
I've come to suspect the normal way large companies are organised makes performant software almost impossible. Features are celebrated and make money - whereas performance can be gradually salami-sliced away, with nobody advocating for it. If you can add a feature and it adds just 50ms to a 300ms pageload - it's unlikely anyone is going to block its release on performance grounds. And once the feature is released, th…
Development in any corp today, even middle-sized ones, is a big red tape festival. You have a project divided in sprints that are divided in (often meaningless) tasks, then you have a completely bloated CI/CD system and then things get deployed to three or four environments where people pretend to test everything. Things that might be developed by a journeyman developer in five days take six weeks to be done by a tea…
I think it's even worse than that - those unnecessary processes only exist to try to help management attempt to manage content they don't understand in the first place.
And I say this as someone who regularly implements said delivery processes for customers.
I've come to suspect the normal way large companies are organised makes performant software almost impossible. Features are celebrated and make money - whereas performance can be gradually salami-sliced away, with nobody advocating for it. If you can add a feature and it adds just 50ms to a 300ms pageload - it's unlikely anyone is going to block its release on performance grounds. And once the feature is released, th…
Development in any corp today, even middle-sized ones, is a big red tape festival. You have a project divided in sprints that are divided in (often meaningless) tasks, then you have a completely bloated CI/CD system and then things get deployed to three or four environments where people pretend to test everything. Things that might be developed by a journeyman developer in five days take six weeks to be done by a tea…
(The "test everything" culture was also AIUI in the service of quick iteration; the first versions of Agile are from the early 2000s when dynamic languages were starting to get popular and there wasn't really any kind of static analysis.)
Earlier quoted context omitted.
None of what you describe requires a lot of resources. Remote editing stubs are decades older than VS code, but also, many of us used X - for many years I did all my work over the network because there was no reason not to. A color dialog was tens of KB of code in the 1980s. My own editor handles Unicode well enough for most users in a few dozen lines of code. RTL would take a bit more, but not much. LSP servers if a…
It's a bit theoretical because no editors exist that are smaller that do all of what vs code does. And a lot of what it does relies heavily on the notion that it's running in a browser. So, just tossing that out won't fly since you kind of need it for at least some of the features. It's only when you subjectively remove all the features that you don't care about that it becomes doable to make smaller editors. And tha…
> It's a bit theoretical because no editors exist that are smaller that do all of what vs code does
You can't ever compare two things if you look for all features to match. Sublime is a pretty good comparison - it's wicked fast, has a bunch of the same features and language extensions. Emacs handles unicode just fine and has a huge extension surface area.
> The reason most people don't care is because it simply doesn't matter
Hard disagree here - the reason people don't care is because features sell, and as you said, the alternative option isn't there. I work in Unreal Engine most of the time, and about 3-4 years ago, there was an almost overnight exodus of game programmers who would live and die by Visual Studio who switched to Rider, primarily because it was faster than VS+VAX.
> Laptops are cheap. Memory is cheap. CPU is cheap. Your time is not
This only applies with one application. Now add Slack/Teams, Postman, Outlook, FF/Chrome, Spotify in the mix, and all of a sudden I'm running 6 full web browsers duplicated with all their resources isolated, using more menoey and CPU than Intellij does. I'm fine with Intellij pegging my 32 core thread ripper to index millions of lines of code. I'm less fine with Postman using more CPU than Intellij to display a json document.
> Im writing this on a M1 macbook
Depending on what software you're working on, your users aren't using M1 Macbookd. My partner's work machine is a5 year old i3 with 8GB of RAM. It's borderline unusable with teams and Outlook running IMO. But the person who benchmarks teams is doing so on the M1 MacBook.
Earlier quoted context omitted.
We tried that in the Windows 9x days. We called that "DLL hell". The idea was that programs would share libraries, and so why have a dozen identical frameworks on the same system? Install your libraries into system32. If it's already there but an earlier version, deploy your packaged one on top. Turns out that nobody writes good installers, and binary level dependency requires too much discipline, and dependencies ar…
You can improve things significantly with a bit of coordination. That's how package managers work!
What if you're working on something reasonably novel, like say, open source VR? Well, turns out you may want a quite eclectic mix of dependencies. Some you need the latest version, because it's state of the art stuff. Some is old because the new version is too incompatible. Some is dead.
Getting our work into a Linux distro is on my list, but even if dealing with all the dependencies works out, there's the issue of that we sometimes need to do protocol changes and upgrade on our own schedule, rather than whenever the new distro is released.
Distros are great for things that are supposed to integrate all together. They're less ideal for when you're working on something that is its own, separate thing like a game.
So for the time being, shoving it all into an AppImage it is.
He was calling 1995 text editors which used 4 MB of RAM incredibly bloated compared to the lean software of his youth which ran in 32 KB. Now we do the same, but we look at the text editors of 1995 which used 4 MB of RAM as incredibly efficient and well made, paragons of craftsmanship. Things never change, the old generation fights the new one and calls it stupid.
That 1995 text editor didn't handle unicode. Didn't edit all the languages of the world. Didn't handle emoji. Didn't do auto-complete. Didn't replace colors in CSS with their actual color and popup an inline editor to edit them. They didn't edit remotely (editing remotely is not the same as tmux + vim). VSCode not only edits the files. When you're in a terminal on the remote machine and type 'code somefile', somefile…
Remote editing back in the 1980s was such a common thing on the Smalltalk and Lisp Machines that all system code was on another machine, more times than not you wouldn't even notice that it was a remote file!
One could do "emoji" just fine as well, and files would have WYSIWYG like look to them using "fat strings" -- that is 1980s technology. There is a dungeon crawler map using that feature to render the map as graphics, it is how you would implement chess pieces, or other "picture" like stuff.
Auto-complete was already standard, similar look up of "who calls" / "who uses" functionality to figure out where things are used, online documentation, etc etc etc...
So all this was perfectly possible, and already used and abused in 1995 -- VSCode isn't doing anything new in that regard.
Earlier quoted context omitted.
Development in any corp today, even middle-sized ones, is a big red tape festival. You have a project divided in sprints that are divided in (often meaningless) tasks, then you have a completely bloated CI/CD system and then things get deployed to three or four environments where people pretend to test everything. Things that might be developed by a journeyman developer in five days take six weeks to be done by a tea…
Wasn't "Agile" development supposed to fix this, by keeping team sizes small and workflows as simple and iterative as possible? AIUI, the fabled "two-pizzas team" size was intended as an upper bound for the most complex projects only, not as the new normal. (The "test everything" culture was also AIUI in the service of quick iteration; the first versions of Agile are from the early 2000s when dynamic languages were s…
Agile depends on not having a “big class of managerial people” micromanaging [1] every move done by the squad.
No methodology will work when someone is actively fucking up the process, and agile is no exception.
[1] In before some smartass comes to say “so you don’t want managers”… I qualified my statement with the word “micromanaging”.
Earlier quoted context omitted.
It's a bit theoretical because no editors exist that are smaller that do all of what vs code does. And a lot of what it does relies heavily on the notion that it's running in a browser. So, just tossing that out won't fly since you kind of need it for at least some of the features. It's only when you subjectively remove all the features that you don't care about that it becomes doable to make smaller editors. And tha…
Back in 2014 my company switched from Skype to this hot new tool called Slack for messaging. On my £10,000 workstation with dual xeon processors, 64GB memory and a 1TB SSD, you know what was the second most resource intensive app after my c++ compiler, and above my IDE? Slack. We used to close our chat program to compile to save the 1GB memory it was using. > It's a bit theoretical because no editors exist that are s…
Or your company should buy you a new 96 core Threadripper 1 TB RAM system so that when you use Spotify/Slack/Postman it doesn't impact your productivity.
He was calling 1995 text editors which used 4 MB of RAM incredibly bloated compared to the lean software of his youth which ran in 32 KB. Now we do the same, but we look at the text editors of 1995 which used 4 MB of RAM as incredibly efficient and well made, paragons of craftsmanship. Things never change, the old generation fights the new one and calls it stupid.
That 1995 text editor didn't handle unicode. Didn't edit all the languages of the world. Didn't handle emoji. Didn't do auto-complete. Didn't replace colors in CSS with their actual color and popup an inline editor to edit them. They didn't edit remotely (editing remotely is not the same as tmux + vim). VSCode not only edits the files. When you're in a terminal on the remote machine and type 'code somefile', somefile…
Behold! The peak of technological prowess! So many poor souls of the past died in misery and 4 MB of RAM. They could not taste those sweet fruits of progress.