Live data from Hacker News

A Plea for Lean Software (1995)

liam-on-linux.dreamwidth.org

131–136 of 136 posts

Re: A Plea for Lean Software (1995)

#131
post #38

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…

Next to nothing of what VS code does depends on it running in a browser other than to the extent VS Code has made it so. It's not special. If anything it's one of the most clunky editor I've used because it tries to shoehorn everything into a convoluted UI. It's because my time matters to me I avoid VS Code as much as possible. The problem with VS Code is not that it's too slow, or too memory hungry. It could use far…

there are other advantages to running in the browser. The fact that the editor is written in JavaScript/Typescript html/css means it runs in any browser. It's why there's been an explosion of online IDEs like codesandbox.io, stackblitz, github codespaces, google code cloud, repl.it and 100s of others.

Re: A Plea for Lean Software (1995)

#132
post #17

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…

> We tried that in the Windows 9x days.

You say that as if it was some kind of failed one-off experiment of the 90s. We tried it in the Multics days, it caught on and the design philosophy is still popular to this day. It works quite well in systems with centrally managed software repositories, even if it doesn't in a system where software is typically distributed on a 3rd party shareware collection CD or download.com.

Re: A Plea for Lean Software (1995)

#133

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…

My time is free. I'm not going to see a dime for any time I save by using this tool or that tool on my computer. Hardware, on the other hand, is not free, so I prefer to sacrifice time for being able to use less expensive hardware (within reason). Of course, Sublime Text exists and does everything I want from VSCode at a fraction of the hardware usage. So I don't have to choose one or the other, because actual good s…

Consider an economy of time, where you have a finite amount of time to spend, so that time spent on one thing is time not spent on another thing. If you can spend money (or maybe earn less money) to avoid spending time doing things that are uninteresting, boring or unproductive, you are allowing yourself to spend more time on things that are interesting, fun or productive.

Re: A Plea for Lean Software (1995)

#134
Please stop blaming the tools, companies, users, God, your neighbour, politicians, capitalism, or whatever else developers traditionally like to blame for low performance software.

The truth is that developers are responsible for developing slow software. Nobody else.

So if your code is slow, take responsibility for your own work and fix it! Learn how to make your code fast. Listen to developers who know how to write fast software (game developers for example). You might learn something.

But most importantly pick architectures that are fast by design. Most popular architectures are not and never will be.

A single modern server is unbelievably powerful and can do an enormous amount of work if you code it well.

Re: A Plea for Lean Software (1995)

#135

Very few people ever even attempt to write "lean software". The definition is a little nebulous, but "software without bloat" is a good one. This means that you have few dependencies, and the ones you have themselves have few dependencies, for a starter. But right there you have the first problem, which is that dependencies grow stronger with the number of users, and the number of users grows with applicability, henc…

Not my experience.

I write high-performance business/enterprise software every day and get rewarded for it. Keeping the architecture simple but fast by design makes everything so much easier and productive.

I really wish developers would take responsibility for their own low performance code instead of blaming everybody/everything else.

Re: A Plea for Lean Software (1995)

#136
post #130
post #124

Earlier quoted context omitted.

Not sure what you're referring to. Files opened from disk in Firefox aren't forbidden from running JS.

Files opened from disk can run JS. But you can't do without getting a cross-origin error, even if it's in the same directory. So any kind of code organization at all is prohibited.

  ~/scratch/wrong$ cat ./index.html
  
  
  
  
  
  
  

otherfile.js did not run

~/scratch/wrong$ cat ./otherfile.js window.onload = (() => { document.querySelector("p").textContent = "wrong. (otherfile.js ran)"; });
Post reply on HN