website source; use git clone git:// to clone this repository. (6031B)

      1 # why program efficiency [and usability] matters
      2 <!--[time 201711241426.09]-->
      4 in 2016 I wrote a small rant about the current downward trend of software and web development, entitled <q>Why program efficiency matters</q>:
      6 <blockquote>
      7 <p>Computer hardware has become faster, more efficient, and more powerful in recent years, which means programmers are not constrained as much by memory and CPU cycles. But does that mean programmers should just give up trying to make their code more efficient?</p>
      9 <dl>
     10 <dt>It doesn't matter if our programs are bigger!</dt>
     11 <dd>I don't know about you, but I enjoy extra disk space for movies and music. Just because disk space is affordable doesn't mean programmers can excuse themselves for adding unnecessary fluff to their projects.</dd>
     13 <dt>It doesn't matter if our code takes up more memory!</dt>
     14 <dd>Multitasking computers have been a thing for a while now. With that said, I would like my computer to actually multitask. I shouldn't have to constantly worry about how many programs I have running in the background and how much memory they consume. Also, there are plenty of older systems running in corporate and educational environments that simply cannot handle modern (and memory-hungry) software without constantly locking up.</dd>
     16 <dt>It doesn't matter if our code is slower!</dt>
     17 <dd>Speed is always a value to strive for. Any sensible person would choose "faster" if presented with two programs that perform the exact same tasks but at different speeds.
     18 </dd>
     19 </dl>
     21 <p>That said, if you have to sacrifice any of the above for security, please do so. Otherwise, if there is any way to make a program smaller or faster or more efficient, without changing the core functionality of the program, then take the time to improve in those aspects. Laziness is no excuse for a slow, fat program. At the same time, don't let yourself be consumed by trying to make your code perform better before you have even finished writing the program.</p>
     22 </blockquote>
     24 this applies to desktop, server, mobile, and Web software all alike:
     26 * desktop operating systems are gradually becoming more bloated and new features are half-baked (such as later versions of Windows), people using Electron to develop fucking everything now (and I'll talk about Electron on its own in a bit).
     27 * server software dependent on weightier languages such as node and python ([] [1] for instance). this is very problematic because servers have much more stressful demands and none of us wish to spend resources we can better use to serve end-users. every bit of RAM and every CPU cycle counts under high load.
     28 * mobile phones are mad useful for on-the-go matters (I'll have a blog post later, describing a smartphone's exact use compared to laptops and desktops) but they're becoming more powerful than most laptops now. many apps are Web-centric and it's quite possible that a lot of the mobile ecosystem is unoptimised: not just the apps but also the operating system and the virtual environments under which apps are designed to run.
     29 * the Web used to have one thing: static content. then forms were introduced, allowing for greater user interaction and ease of use. after that, javascript, and now we have full-blown HTML5+javascript applications that run in your browser. and believe me, I understand the desire to have this capability: it's cross-platform and any device with a modern browser can use your app. however, there are a few things wrong with this: HTML was not really designed to represent full-blown applications, and web developers don't pay a thought to efficiency/accessibility and they will normally take the path of least resistance to deploy their applications. I'll talk more about what I believe the Web should be used for in a later post.
     31 [1]: <>
     33 I'm making this post today because someone sent me a link to a post Casper Beyer made regarding Electron, entitled <q>[Electron is Cancer] [2]</q>. I'll quote some notable passages from the post:
     35 > <q>Well, it works fine on my machine, and I only have 32 gigabytes of ram.</q> - Silicon Valley Developer, 2017
     36 > 
     37 > If that’s you, well then that’s good for you, but just because something performs <q>well enough</q> on your machine doesn’t mean there are not any performance problems. You are not your end-users, and you if you are a developer most likely do not run average hardware.
     39 ^ I made this point in my 2016 rant -- people have different hardware and developers need to keep this in mind, lest they want their programs only to run on a small set of machines in the world.
     41 > <q>Electron is so great, we did not have to hire new people we can just use your web designers that we already have in-house and it is so easy!</q> - Someone Actually Said That
     42 > 
     43 > Okay, sure having a plumber cut out a square wheel from a plank is also a lot easier to do than having a woodworker carve a perfectly round wooden wheel, but it is gonna be one hell of a bumpy ride, and square wheels are actually fine, right?
     45 ^ I've seen this a lot too; people have derived from <q>do one thing and do it right</q> philosophy, both in software and in expertise (although on the expertise side of things, it helps to be well-versed in several areas so you're more valuable in a job, but usually those areas are close enough together that they complement each other. you wouldn't want that plumber performing heart surgery on you, would you?)
     47 if you have time, read Beyer's full post because it covers a lot of good points about Electron and about modern software developers as a whole. it's a rarity to find a decent dev nowadays who cares about efficiency, usability, and accessibility; and that certainly affects where technology is going as a whole. as we depend more on technology in our everyday lives (mobile, IoT, business) there is really no room for sloppy code to run in banks, hospitals, vehicles, and other mission-critical devices.
     49 [2]: <>