TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Software Disenchantment (2018)

934 点作者 ibdknox超过 5 年前

120 条评论

rogerdb超过 5 年前
&gt; Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters?<p>I think the analogy here is backwards. The better question is &quot;how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?&quot;. I&#x27;d say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important.<p>If basic computer operations like loading a webpage took minutes rather than seconds, I think there would be more general interest in improving performance. For now though, most users are happy-enough with the performance of most software, and other factors like aesthetics, ease-of-use, etc. are the main differentiators (admittedly feature bloat, ads, tracking, etc. are also a problem, but I think they&#x27;re mostly orthogonal to under-the-hood performance).<p>These days, I think most users will lose more time and be more frustrated by poor UI design, accidental inputs, etc. than any performance characteristics of the software they use. Hence the complexity&#x2F;performance overhead of using technologies that allow software to be easily iterated and expanded are justified, to my mind (though we should be mindful of technology that claims to improve our agility but really only adds complexity).
评论 #21930722 未加载
评论 #21931091 未加载
评论 #21930760 未加载
评论 #21931533 未加载
评论 #21930607 未加载
评论 #21934648 未加载
评论 #21931874 未加载
评论 #21933301 未加载
评论 #21930945 未加载
评论 #21932537 未加载
评论 #21933661 未加载
评论 #21930816 未加载
评论 #21934080 未加载
评论 #21931851 未加载
iamwil超过 5 年前
I agree it&#x27;s all slower and sucks. But I don&#x27;t think it&#x27;s solely a technical problem.<p>1&#x2F; What didn&#x27;t seem to get mentioned was the speed to market. It&#x27;s far worse to build the right thing no one wants, than to build the crappy thing that some people want a lot. As a result, it makes sense for people to leverage electron--but it has consequences for users down the line.<p>2&#x2F; Because we deal with orders of magnitude with software, it&#x27;s not actually a good ROI to deal with things that are under 1x improvement on a human scale. So what made sense to optimize when computers were 300MHz doesn&#x27;t make sense at all when computers are 1GHz, given a limited time and budget.<p>3&#x2F; Anecdotally (and others can nix or verify), what I hear from ex-Googlers is that no one gets credit for maintaining the existing software or trying to make it faster. The only way you get promoted is if you created a new project. So that&#x27;s what people end up doing, and you get 4 or 5 versions of the same project that do the same thing, all not very well.<p>I agree that the suckage is a problem. But I think it&#x27;s the structure of incentives in the environment that software is written that also needs to be addressed, not just the technical deficiencies of how we practice writing software, like how to maintain state.<p>It&#x27;s interesting Chris Granger submitted this. I can see that the gears have been turning for him on this topic again.
评论 #21931008 未加载
评论 #21930370 未加载
评论 #21933291 未加载
评论 #21930667 未加载
评论 #21934923 未加载
surround超过 5 年前
From a Reddit comment:<p>&gt; While I do share the general sentiment, I do feel the need to point out that this exact page, a blog entry consisting mostly of just text, is also half the size of Windows 95 on my computer and includes 6MB of javascript, which is more code than there was in Linux 1.0. Linux at that point already contained drivers for various network interface controllers, hard drives, tape drives, disk drives, audio devices, user input devices and serial devices, 5 or 6 different filesystems, implementations of TCP, UDP, ICMP, IP, ARP, Ethernet and Unix Domain Sockets, a full software implementation of IEEE754 a MIDI sequencer&#x2F;synthesizer and lots of other things.<p>&gt;If you want to call people out, start with yourself. The web does not have to be like this, and in fact it is possible in 2018 to even have a website that does not include Google Analytics.<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;programming&#x2F;comments&#x2F;9go8ul&#x2F;comment&#x2F;e6689uu" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;programming&#x2F;comments&#x2F;9go8ul&#x2F;comment...</a>
评论 #21934030 未加载
评论 #21934059 未加载
评论 #21933794 未加载
FartyMcFarter超过 5 年前
Long ago I watched a documentary about the early Apple days, when management was encouraging their developers to reduce boot times by 10 seconds. The argument was that 10 seconds multiplied by the number of boot sequences would result in saving many human lives worth of time.<p>Edit: found a link with the same story: <a href="https:&#x2F;&#x2F;www.folklore.org&#x2F;StoryView.py?story=Saving_Lives.txt" rel="nofollow">https:&#x2F;&#x2F;www.folklore.org&#x2F;StoryView.py?story=Saving_Lives.txt</a><p>The software world needs more of this kind of thinking. Not more arguments like &quot;programmer&#x27;s time is worth less than CPU time&quot;, which often fail to account for all externalities.
评论 #21932486 未加载
评论 #21931623 未加载
评论 #21936197 未加载
评论 #21934935 未加载
评论 #21933613 未加载
评论 #21933077 未加载
d23超过 5 年前
Performance is one thing, but I&#x27;m really just struck by how often I run into things that are completely broken or barely working for extended periods of time.<p>As I write this, I&#x27;ve been trying to get my Amazon seller account reactivated for more than a year, because their reactivation process is just... broken. Clicking any of the buttons, including the ones to contact customer support just take you back to the same page. Attempts to even try to tell someone usually put you in touch with a customer service agent halfway across the world who has no clue what you&#x27;re talking about and doesn&#x27;t care; even if they did care, they&#x27;d have no way to actually forward your message along to the team that might be able to spend the 20 minutes it might take to fix the issue.<p>The &quot;barely working&quot; thing is even more common. I feel like we&#x27;ve gotten used to everything just being so barely functional that it isn&#x27;t even a disadvantage for companies anymore. We usually don&#x27;t have much of an alternative place to take our business.
评论 #21932277 未加载
评论 #21933418 未加载
评论 #21934588 未加载
评论 #21933655 未加载
评论 #21932931 未加载
评论 #21933093 未加载
buboard超过 5 年前
He has a nice follow up which gets to the reasons why<p><a href="https:&#x2F;&#x2F;tonsky.me&#x2F;blog&#x2F;good-times-weak-men&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tonsky.me&#x2F;blog&#x2F;good-times-weak-men&#x2F;</a><p>Another take: rewrites and rehashes tend to be bad because they are not exciting for programmers. Everything you re about to write is predictable, nothing looks Clearly better and it just feels forced. First versions of anything are exciting, the possibilities are endless, and even if the choices along the path are suboptimal, they are willing to make it work right.
评论 #21930949 未加载
评论 #21931264 未加载
评论 #21931521 未加载
评论 #21930913 未加载
cortesoft超过 5 年前
He seems to make a contradictory point... he complains:<p>&gt; iOS 11 dropped support for 32-bit apps. That means if the developer isn’t around at the time of the iOS 11 release or isn’t willing to go back and update a once-perfectly-fine app, chances are you won’t be seeing their app ever again.<p>but then he also says:<p>&gt; To have a healthy ecosystem you need to go back and revisit. You need to occasionally throw stuff away and replace it with better stuff.<p>So which is it? If you want to replace stuff with something better, that means the old stuff won&#x27;t work anymore... or, it will work by placing a translation&#x2F;emulation layer around it, which he describes as:<p>&gt; We put virtual machines inside Linux, and then we put Docker inside virtual machines, simply because nobody was able to clean up the mess that most programs, languages and their environment produce. We cover shit with blankets just not to deal with it.<p>Seems like he wants it both ways.
评论 #21931821 未加载
评论 #21932800 未加载
评论 #21930806 未加载
评论 #21932133 未加载
arh68超过 5 年前
See also: in <i>Good times create weak men</i> [0], the author explains his interpretation as to why. I can&#x27;t summarize it well. It&#x27;s centered around a Jonathan Blow talk [1] <i>Preventing the collapse of civilization</i>.<p>[0] <a href="https:&#x2F;&#x2F;tonsky.me&#x2F;blog&#x2F;good-times-weak-men&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tonsky.me&#x2F;blog&#x2F;good-times-weak-men&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=pW-SOdj4Kkk" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=pW-SOdj4Kkk</a>
评论 #21930880 未加载
city41超过 5 年前
This article really resonates with me. But my biggest complaint is everything is _so_ buggy! I won&#x27;t name any names, but I find many major pieces of software from large, well known companies are just riddled with bugs. I also feel like you almost need to be a programmer to think of workarounds &quot;hmm, ok, so clearly it&#x27;s in a bad state. If I had coded this, what boundaries would likely cause a complete refresh?&quot; My wife is often amazed I can find work arounds to bugs that completely stop her in her tracks.<p>Before we fix performance, bloat, etc, we really need to make software reliable.
评论 #21931704 未加载
评论 #21931179 未加载
userbinator超过 5 年前
A related article in a similar spirit from 4 years ago: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8679471" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8679471</a><p><i>I can comfortably play games, watch 4K videos, but not scroll web pages?</i><p>I think this is one of the more important points that the article tries to get across, although it&#x27;s implicit: while the <i>peak</i> of what&#x27;s possible with computing has improved, the average hasn&#x27;t --- and may have gotten worse. This is the point that everyone pointing at language benchmarks, compiler&#x2F;optimisation, and hardware improvements fail to see. All the &quot;Java&#x2F;.NET is not slow&#x2F;bloated&quot; articles exemplify this. They think that, just because it&#x27;s <i>possible</i> for X to be faster, it always will be, when the reality couldn&#x27;t be further from that.<p>Speaking of bloat, it&#x27;s funny to see the author using Google&#x27;s apps and Android as an example, when Google has recently outdone itself with a 400MB(!) web page that purports to show off its &quot;best designs of 2019&quot;: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21916740" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21916740</a>
评论 #21931044 未加载
jancsika超过 5 年前
&gt; How is that ok?<p>Probably because a browser like FF has the goal to load and display arbitrary dynamic content in realtime like a reddit infinite scroll with various 4k videos and ad bullshit, whereas the game has the goal to render a known, tested number of pre-downloaded assets in realtime.<p>Also on shitty pages the goal is different-- load a bunch of arbitrary adware programs and content that the user doesn&#x27;t want, and only after that display the thing they want to read.<p>Also, you can click a link somewhere in your scrolling that opens a new, shitty page where you repeat the same crazy number of net connections, parsing ad bullshit, and incidentally rendering the text that the user wants to read.<p>If you want to compare fairly, imaging a game character entering a cave and immediately switching to a different character like Spiderman and inheriting all the physics and stuff from that newly loaded game. At that point the bulk of your gameplay is going to be loading new assets and you&#x27;re back to the same responsiveness problems of the shitty web.<p>Edit: clarification
评论 #21933761 未加载
评论 #21931715 未加载
评论 #21930965 未加载
johnr2超过 5 年前
One thing nobody seems to mention is the environmental cost of inefficient software. All those wasted CPU cycles consume electricity. A single laptop or phone on it&#x27;s own is insignificant, but there are billions of them. Combine that with the energy wasted shovelling unnecessary crap around the internet, and it adds up to a big CO2 problem that nobody talks about.
评论 #21930751 未加载
评论 #21931836 未加载
评论 #21932384 未加载
评论 #21930872 未加载
评论 #21931017 未加载
评论 #21930815 未加载
评论 #21931395 未加载
评论 #21931808 未加载
peter_d_sherman超过 5 年前
Excerpt:<p>&quot;An Android system with no apps takes up almost 6 GB. Just think for a second about how obscenely HUGE that number is. What’s in there, HD movies? I guess it’s basically code: kernel, drivers. Some string and resources too, sure, but those can’t be big. So, how many drivers do you need for a phone?<p>Windows 95 was 30MB. Today we have web pages heavier than that!<p>Windows 10 is 4GB, which is 133 times as big. But is it 133 times as superior? I mean, functionally they are basically the same. Yes, we have Cortana, but I doubt it takes 3970 MB. But whatever Windows 10 is, is Android really 150% of that?&quot;<p>My favorite line: <i>&quot;Windows 95 was 30MB. Today we have web pages heavier than that!&quot;</i><p>If there&#x27;s a new saying for 2020, it <i>shouldn&#x27;t</i> be that &quot;hindsight is 2020&quot;... &lt;g&gt;<p>Also... each web page should come with a non-closable pop-up box that says &quot;Would you like to download a free entire OS with your web page?&quot;, and offers the following &quot;choices&quot;:<p>&quot;[Yes] [Yes] [Cancel (Yes, Do It Anyway!)]&quot;. &lt;g&gt;
评论 #21931721 未加载
评论 #21933930 未加载
评论 #21931779 未加载
评论 #21933863 未加载
评论 #21931650 未加载
johnwatson11218超过 5 年前
When I was in school and first leaning about programming I assumed that code written in C or Java would eventually be ported to hand tuned assembler once enough people were using it. Then I got in to the industry and realized that we just keep adding layer after layer until we end up at the point this article talks about.<p>I remember once reading that IBM was going to implement an XML parser in assembler and people were like &quot;Why? If speed is needed then you shouldn&#x27;t use XML anyway.&quot; I thought that concern was invalid because these days XML ( or JSON ) is really non-negotiable in many scenarios.<p>One idea that I&#x27;ve been thinking about lately is some kind of neural network enabled compiler and&#x2F;or optimizer. I have heard that in the javascript world they have something called the &quot;tree shaking&quot; algorithm where they run the test suite, remove dependencies that don&#x27;t seem to be necessary and repeat until they are getting test failures. I&#x27;m thinking why not train a LSTM to take in http requests and generate the http response? Of course sometime the request would lead to some sql, which you could then execute and feed the results back into the LSTM until it output a http response. Then try using a smaller network until something like your registration flow, or a simple content management system was just a bunch of floating point numbers in some matrices saved off to disk.
评论 #21931084 未加载
评论 #21932145 未加载
评论 #21938155 未加载
anilakar超过 5 年前
An unpopular but effective short-term solution: Developers ought to use five year old hardware for development and testing tasks. FWIW, my work laptop and mobile phone are both 2015 models and I feel they&#x27;re completely adequate for running all the software I&#x27;ve written.
评论 #21931608 未加载
评论 #21932219 未加载
评论 #21931876 未加载
评论 #21931255 未加载
评论 #21931877 未加载
评论 #21933231 未加载
评论 #21932111 未加载
lxe超过 5 年前
I’m tinkering with the Atomic PI SBC — Quad Core 1.5ish GHz Intel Atom with 2 Gigabytes of RAM. You can load up an OS and launch Firefox with maybe 3 tabs until you run out of memory and have to page out (which will basically hang the device due to eMMC&#x2F;flash I&#x2F;O speeds).<p>These kind of specs are incredible for a high-end desktop machine from 15 years ago that would be good for almost anything — gaming, browsing, etc... What happened to software (Linux &amp; Friends, Firefox, etc) that renders hardware obsolete so quickly? Is it just purposeful optimization that uses more RAM to benefit performance elsewhere, or is it truly this disenchantment?
xorand超过 5 年前
Programming is now a bureaucracy.<p>[1] &quot;In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely&quot;<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Jerry_Pournelle#Pournelle%27s_iron_law_of_bureaucracy" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Jerry_Pournelle#Pournelle%27s_...</a>
评论 #21931985 未加载
megous超过 5 年前
I was in Rome recently, and google maps were basically unusable on EDGE (dsepite pre-downloading the area before the trip). We&#x27;d wait a minute (or more) for a timetable of a bus stop and a route of the bus to be show on the map.<p>Try planning a route in an unfamiliar area with this slow an UI when you are standing outside and there&#x27;s no place to sit and rest, and you need to click around on a bunch of stops just to see what busses are going through a stop and where they are heading.<p>So yes, optimization is still important.<p>We replaced the glorious and easily iterated and expanded google maps app with a photograph of a public transport map, and we could get an answer of how to get from any A to any B within seconds of looking at the map without typing or searching or waiting for anything.<p>Which also shows that, sometimes, slow software is less than useless.
评论 #21931759 未加载
评论 #21932108 未加载
评论 #21931184 未加载
评论 #21932083 未加载
评论 #21931019 未加载
评论 #21930869 未加载
评论 #21930800 未加载
megous超过 5 年前
Even quite underpowered phones can boot in ~1-2 seconds if optimized for that. Not everything in the phone will startup in that amount of time (modem, wifi), but it&#x27;s possible to start to Linux userspace and display fully interactive UI in that amount of time.<p>Even my e-book reader Linux port boots to UI in ~2s.<p>It really is just bloat and lack of care.
评论 #21931801 未加载
_trampeltier超过 5 年前
It&#x27;s not just the problem with large and slow today. There are also these dark patterns everywhere special in Android. Even local thing do not work, if there is a network connection, but connections for ex. to Google are not allowed. For ex. the standard Android &quot;Photos&quot; App does not always show you the newest pictures, if the network blocks Google. Also you can&#x27;t share something to another App if you have a network connection, but Google is blocked. If you switch off the network complete on the phone, everything is working again.
评论 #21931506 未加载
_bxg1超过 5 年前
I&#x27;m so weary of this moral panic we&#x27;ve been having. There are so many other factors to be weighed against efficiency when it comes to making software. There are completely legitimate tradeoffs to be made that sacrifice performance. There are also programmers who write bad code on all dimensions - performance included - out of sheer laziness. But those aren&#x27;t the primary cause of this hardware &quot;waste&quot;. Demanding efficiency for efficiency&#x27;s sake, ignoring all other constraints, is shortsighted and narrow-minded.
评论 #21930623 未加载
评论 #21934721 未加载
keyP超过 5 年前
I think people who recognise this have generally been developing from the days where computing resources were scarce (or on mediums now where they need to be efficient). It was a necessecity to implement efficient techniques instead of a nice to have. Nowadays those restrictions have been lifted for the most part.<p>In this day of &quot;Agile&quot; development, as long as something&#x27;s working during UAT, that&#x27;s all that&#x27;s needed for sales and consumers.<p>Webdev, IME, is an example where the ecosystem has facilitated bloated websites. I&#x27;ve worked with developers who throw any library they can just for basic things because they don&#x27;t have a need to try to optimise. The meme of using jQuery for everything when it came out has just been replaced by other frameworks. I find it often depends on developers who really want to work on something and take pride in it vs those who just need something on their CV or got hired by following a few tutorials on the web but not understanding what they wrote (which, to me, signifies a hiring problem in the company). During code reviews, I encourage leads to keep calling up hacky code to a point where the developer will just start writing it properly the first time round. As developers, I feel we should be aware of not creating selfish software which hogs memory from other software or requires huge data downloads for mobile users (whenever doable). Possibly a naive ideal but if it&#x27;s a byproduct of developing fast software for my end users, I think that&#x27;s a win-win.
评论 #21930827 未加载
jmpeax超过 5 年前
&gt; Jonathan Blow has a language he alone develops for his game that can compile 500k lines per second on his laptop. That’s cold compile, no intermediate caching, no incremental builds. You don’t have to be a genius to write fast programs.<p>The guy is most definitely at least a genius.
评论 #21930842 未加载
评论 #21932077 未加载
S-E-P超过 5 年前
The linked Medium article (when talking about npm) was what I expected, but gives wonderful examples of just how bad it&#x27;s gotten.<p>For those who don&#x27;t want to dig, one example was Ember.js, which has a dependency called &quot;glimmer&quot; which makes up ~95% of the code size. The author looked into glimmer and found that it had the entirety of the Encyclopedia of Britannica&#x27;s &quot;G&quot; section to include a definition of &quot;glimmer&quot; in their help menu.<p>And that wasn&#x27;t even the most ridiculous example.<p>It&#x27;s shameful that it&#x27;s gotten this bad; but when you look at what people are expected of in the current climate it makes sense that this would happen.<p><pre><code> * Horrendously short deadlines for enterprise CRUD (and the &quot;frameworks&quot; that support it) * REUSE REUSE REUSE THIS REFUSE (few seem to know how to read source code before installing the dependency) * &quot;Not paying me enough for that shit&quot; * &quot;We can&#x27;t rewrite, we put 20 years into this codebase&quot; * Even our languages are shit, JS (despite it&#x27;s usefulness) has undefined behavior as a feature. * [among many others I&#x27;m sure you could think of] </code></pre> It&#x27;s toxic, corps incentivize lazy quick work that won&#x27;t hold up in the long run, but they are too stupid to realize that. Though i blame more so the sycophant that just silently nods and does the work without a sliver of conscience telling them that &quot;this is wrong&quot;.<p>Civility has a lesser place in efficiency then what we have now; you can&#x27;t make a decent product without bashing a few skulls (figuratively ofc)<p>Lastly, don&#x27;t be afraid to reinvent the wheel if your wheel is better than mine.
评论 #21933445 未加载
评论 #21933439 未加载
hermitcrab超过 5 年前
As a dinosaur who has been programming for &gt;30 years, it shocks me how bloated many modern programs are. The installers for my own products are around 20MB and most of that is Qt libraries. But 100s of MB seems to be standard now. The Airbnb app on my iPhone is 210 MB. I understand that if you are shipping a 3d game with maps, textures, sound etc, but not for a mobile phone app.
评论 #21932026 未加载
评论 #21931523 未加载
coldtea超过 5 年前
&gt;<i>And then there’s bloat. Web apps could open up to 10 times faster if you just simply blocked all ads. Google begs everyone to stop shooting themselves in the foot with the AMP initiative—a technology solution to a problem that doesn’t need any technology, just a little bit of common sense. If you remove bloat, the web becomes crazy fast. How smart do you have to be to understand that?</i><p>If you &quot;simply blocked all ads&quot; the people making the pages wouldn&#x27;t have the income which they maintain the pages with.<p>How smart do you have to be to understand that?<p>&gt;<i>We haven’t seen new OS kernels in what, 25 years? It’s just too complex to simply rewrite by now. Browsers are so full of edge cases and historical precedents by now that nobody dares to write layout engine from scratch.</i><p>Well, there&#x27;s Fucsia, speaking of new kernels. And Mozilla is doing exactly that, written a new layout engine from scratch (plus a language to write it in).<p>(I agree with the general sentiment of the post, but the examples are often shoddy)
评论 #21931076 未加载
评论 #21930904 未加载
评论 #21930902 未加载
评论 #21931461 未加载
评论 #21931858 未加载
zzo38computer超过 5 年前
Yes, it is true, many programming they don&#x27;t do such a good job. I do try to make better software, but will not always succeed. Also computer hardware is becoming too complicated too actually, I think. I generally don&#x27;t add so much dependencies to a program though. Some people (including myself) do still write DOS programs sometimes. The web browser is too complicated. I use IRC and NNTP, I think they are much better anyways than Slack and so on (and even this HN, too, I think). I do program in C (I use other programming languages as well, but mainly C). Many programs I think have too many animations. And a lot of programs, they just write it stupid!! TeX is good and it still works more than thirty years later, and is fast, too. But anyways I don&#x27;t like WYSIWYG, so that is why I don&#x27;t use LibreOffice and Microsoft Word and so on.
trixie_超过 5 年前
Energy (or more accurately power) is a scarce resource. If it&#x27;s not being spent to keep the organization or individual going, then it could be argued that the energy is wasted. As it requires functioning organizations to acquire more energy and so on.<p>All systems - biological, physical, meta-physical are built on layers that once deep enough are pretty well cemented in. Hindsight is 20&#x2F;20 and though we know if the foundations were different things would be better - they won&#x27;t actually change until the energy gain exceeds the energy cost of uprooting everything to make the change.<p>Just saying this problem isn&#x27;t exclusive to software, but also laryngeal nerves in giraffes, x86, and Esperanto.
评论 #21931794 未加载
TheTank超过 5 年前
In addition to the costs of developing good foundational code, I think revenue is becoming a driver for slower-than-necessary software.<p>An increasing number of providers (for example databases) charge per server, per core, or another hardware-usage metric. The more hardware, the more revenue for them as they make about 90% margin for every new machine. There is a high incentive to get users to need more machines on their &quot;managed cloud&quot;.<p>Vendors could try to improve their software so it requires twice as little CPU. But why bother since this would result in 2x cost in revenue? It makes more sense to focus on horizontal scalability than on core efficiency so users can keep on adding machines to their cluster over time.<p>If software is running at 1% of the maximum performance as suggested in the article, a 1% improvement could reduce costs by 50%. But I think none of the existing vendors will ever make the move as it conflicts against their own interest.
vojta_letal超过 5 年前
&gt; Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. ... Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance.<p>&gt; I can comfortably play games, watch 4K videos, but not scroll web pages? How is that ok?<p>IMO the comparison should be buildings &lt;-&gt; fine-tuned libraries (i.e. video decoding algorithms), modern applications &lt;-&gt; cities.<p>Go to any city center in Europe. Urban planning a century ago was much more elegant and elaborate taking into consideration the city as a whole. Nowadays developers and investors often ignore important aspects, such as surrounding buildings, infrastructure, making cities inefficient for the people who actually live there.<p>Any system which has plenty of resources has to become inefficient. It&#x27;s just that the Moore&#x27;s law allows for pretty damn inefficiency.
评论 #21931646 未加载
评论 #21930978 未加载
arithma超过 5 年前
Users don&#x27;t know about this performance gap, but there is a gap, and that gap is an economic opportunity.<p>Since the current practices are so inefficient, users are having to pay for this from pocket as hardware expenses. Buy a $1000 smartphone, to get the same experience as last-year&#x27;s.<p>A different stack (don&#x27;t need to reinvent the universe), can be branded as brutally efficient, uses slim hardware, and strict engineering practices to provide a much better experience at a fraction of the price (1&#x2F;5 possible.)<p>I believe nobody is doing that yet since there are two main barriers:<p>1- Risk of no-market (I think this might be proven unfounded, given the current trend in price hikes)<p>2- Capital investment necessary to get started (But this also can be solved given the obvious appetite for the next-big-thing money being poured left and right, without anything catching on yet)
coldtea超过 5 年前
&gt;<i>You’ve probably heard this mantra: “Programmer time is more expensive than computer time.” What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time.</i><p>The argument is incomplete.<p>The correct question (to maintain the analogy) is:<p>&quot;Would you buy a car if it eats 1000 liters per 100 kilometers, but that doesn&#x27;t affect you at all (you still get to where you want to be fast enough), and the time to manufacture and cost to buy it is much lower than would be possible with more efficient car that used 10 liters per 100 km?&quot;<p>The answer to which would be yes. A software that does a task we do once a day or so at 1 second vs 0.2 seconds doesn&#x27;t cost us money (and even the environmental impact is small).
评论 #21931845 未加载
评论 #21931434 未加载
评论 #21931498 未加载
评论 #21933162 未加载
mrcsharp超过 5 年前
I agree with the author on every point except:<p>&gt;That is not engineering. That’s just lazy programming<p>I don&#x27;t believe that developers&#x2F;programmers are all lazy. There are a lot that want to do a good job optimizing their code and making sure it performs well and is future proof as much as possible. I believe that budget limits and pressure from deadlines set by non-technical people forces even the good programmers to cut corners in order to deliver.
评论 #21933211 未加载
ken超过 5 年前
&gt; I want to take pride in my work. I want to deliver working, stable things. To do that, we need to understand what we are building, in and out, and that’s impossible to do in bloated, over-engineered systems.<p>Somebody needs to <i>write</i> this software. Efficient, maintainable, and debugged are not the low-energy state.<p>That means it either needs to come from business, or from open-source hobbyists. Business doesn&#x27;t see a competitive advantage in it -- even Apple, which has traditionally cared more about UX than anybody, just has to be better than their #2 competitor (and price of entry to &quot;desktop OS&quot; or &quot;smartphone OS&quot; is high so that list is short, and not changing on any relevant timescale). And the open-source world has never delivered well on the end-user experience side of things.<p>The sad truth is that users would rather have new software for $0 (paid by ads, or media subscriptions, or whatever) than pay what it truly costs to develop software.<p>My main hopes today are that the end of Moore&#x27;s Law will force companies&#x27; hands, or that government will step in to regulate minimal quality, or that workers will organize so they can stand for quality behind a CBA. These all seem rather unlikely at this junction. The number of programmers in it for the paycheck far outweighs the number of people who care about simplicity.<p>Software is going to get much worse before it gets better.
nixpulvis超过 5 年前
Heh, software in general, absolutely! But I think the &quot;Web 2.0&quot; is the worst offender: <a href="https:&#x2F;&#x2F;nixpulvis.com&#x2F;ramblings&#x2F;2018-08-11-web-shit-point-oh" rel="nofollow">https:&#x2F;&#x2F;nixpulvis.com&#x2F;ramblings&#x2F;2018-08-11-web-shit-point-oh</a>
评论 #21931805 未加载
dang超过 5 年前
Discussed at the time: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18012334" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18012334</a>
perceptronas超过 5 年前
I like the fact that people are starting to get fed up with slow software. Maybe this will increase demand big enough and we can start seeing new performant software popup
valtism超过 5 年前
The article quotes this in regards to npm: <a href="https:&#x2F;&#x2F;medium.com&#x2F;s&#x2F;silicon-satire&#x2F;i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;s&#x2F;silicon-satire&#x2F;i-peeked-into-my-node-mo...</a>?<p>It seems he does not realise that this is a satire piece, and seem to completely buy in to his view of the world instead of seeing things in a more nuanced way.
评论 #21930843 未加载
sytelus超过 5 年前
A single car has about 30,000 parts, counting every part down to the smallest screws (according to Toyota). A lot of people don&#x27;t understand the difference of complexity between a car and software. The analogy between two is quite unfortunate.<p>The software in nutshell is programmable transistors. Each CPU instruction is in effect just a convenient way to design a specific electronic circuitry. Even a trivial act of printing Hello World takes an astonishing amount of complexity when you take into account all kind of protoicals, APIs, driver codes, kernal code, fonts, rendering, graphics that gets executed in between. If you showed a computer printing Hello World on screen to someone from 1920s who knows how to build electronic circuits and primitive &quot;display&quot;, they can estimate the amount of work that would be required to do that. Nothing has changed from 1920s to 2020s in terms of complexity to enable simple Hello World. A relatively simple program will easily exceed 30,000 low level components working together to achieve a goal in an intricate dance. Now think of large code bases with million lines of code... This is why software is hard, software is complex, software is messy and software is magic.
burlesona超过 5 年前
Nothing feels more broken to me than the React &#x2F; Javascript web ecosystem. Writing rich, stateful UI&#x27;s in HTML isn&#x27;t trivial, but React plus webpack hell turns this into a mess that is so difficult to develop, maintain, and reason about, that people just quit trying and accept that their error tracker will be full of random bugs that nobody can explain or reproduce. It makes me sad.
overgard超过 5 年前
I totally agree with him that it&#x27;s awful, but I think the problem is that making things efficient is expensive in terms of time and having to hire expertise. Evidently efficiency just doesn&#x27;t have enough return on investment for companies to care. The thing about looking back at the windows 95 era and comparing it to now, is that windows 95 <i>needed</i> to be efficient to be usable, windows 10 doesn&#x27;t.<p>The exception would be games and embedded software, but even there, there&#x27;s certain degrees of lazyness. For instance, games are very cpu&#x2F;memory&#x2F;gpu efficient, but they&#x27;re almost always ridiculous when it comes to disk space usage. There&#x27;s no reason that your average AAA game needs to take up 50GB other than that things which could address that aren&#x27;t worth the fuss. (I&#x27;m thinking common demo-scene tricks like procedural textures&#x2F;data&#x2F;everything, aggressive compression schemes, reusing assets, etc.)
评论 #21930305 未加载
minimuffins超过 5 年前
All these critiques really resonate with me. I&#x27;ve asked myself that same &quot;What could it possibly be DOING!?&quot; question every time I update windows. Recently I started learning 6502 assembly so I can write NES games. It&#x27;s really pleasant to abandon the layers and layers of dysfunctional, messy framework goo that is now the norm in my daily work life in web based programming.<p>But something crucial is missing from this manifesto. As the author says, the problems don&#x27;t exist because we can&#x27;t solve them, but because no one ever takes an interest in solving them. We&#x27;re all engineers, so why don&#x27;t we just do some engineering and fix this bullshit? Well, because it wouldn&#x27;t make any money.<p>Perplexingly and contradictorily, the profit motive drives both innovation and stasis, both growth and sprawl, and both efficiency and inefficiency. The problem is both technical and social, and probably so will be the solution.
smadurange超过 5 年前
My concern about this state of affairs in software engineering is that it may be producing generations of engineers who couldn&#x27;t actually build&#x2F;conceive things better (eg. Building a rendering engine or a mobile OS) if they wanted to concentrating that power in a few corporations. That&#x27;s a bit terrifying.
cutler超过 5 年前
Second the OS &gt; VM &gt; Docker &gt; Kubernetes gripe. Soon no-one will know how to admin a sys. Companies like Hetzner (<a href="http:&#x2F;&#x2F;www.hetzner.com" rel="nofollow">http:&#x2F;&#x2F;www.hetzner.com</a>) are offering an 8-core VPS with 32Gb RAM for a mere $40 per month but all we hear about is AWS. It&#x27;s insane. Facebook conqured the world on a fraction of that hardware back in 2004. Docker and Kubernetes were originally designed to solve problems managing massive fleets of servers but now devs at every 2-bit startup with a single server are expected to be hiding their efforts behind these 2 extra layers. &quot;Over-engineering&quot; doesn&#x27;t even come close.
评论 #21932712 未加载
d_burfoot超过 5 年前
Can someone from the quant&#x2F;HFT world comment on whether these kinds of problems exist in that sector as well? Somehow I imagine that the fierce competitiveness of trading would force people to write better software, but that’s just a theory.
评论 #21933166 未加载
phillipcarter超过 5 年前
A coworker of mine explained his belief that professional software development is an inherently economic activity. This was clarified by saying that the amount of imperfections, performance problems, and bugs in a piece of software is not reflective of the software nor its writers, but what most end users ultimately care about.<p>Whenever I read posts like Software Disenchantment, I find myself agreeing with that philosophy. In other words, it’s probably by design. Of course this doesn’t account for the enormous waste of time and money that occurs during software development, but that doesn’t really affect my feelings on the matter.
评论 #21932076 未加载
itqwertz超过 5 年前
...And someone just made their first million with some buggy PHP app. Perfectionism is the enemy of progress. In the end, software is categorized into two types: software that people bitch about and software no one uses.
29athrowaway超过 5 年前
In the past, there were elixirs that claimed to cure baldness, impotence, cancer, etc. Marketing based on unproven claims was legal, and everyone was doing it.<p>Software today is in the snake oil era. &quot;Secure&quot;, &quot;privacy-friendly&quot;, &quot;robust&quot;...<p>We need the government to create the FDA of software, to protect the consumers against potentially harmful software, marketed using false advertisement.<p>We also need job applicants to be protected against predatory companies that hire people that want to do right by the customer, but are forced to produce rushed, poor quality stuff.
cryptica超过 5 年前
&gt;&gt; Build systems are inherently unreliable and periodically require full clean<p>What frustrates me above all else is the trend of compile-to-javascript languages. IMO interpreted languages are great, of course some performance was sacrificed to get there - I think that was a fair trade-off because saving the developer from having to build the project is a HUGE advantage when developing (at least for my particular development flow)... So when I see people throwing away that massive advantage by adding an unnecessary compile step in order to get slightly better syntax or static typing (e.g. CoffeeScript or TypeScript), I find it deeply disturbing. Static typing can be a useful feature, but is it worth adding a compile step? Not by a long shot.<p>And the idea of transpiling a language into an interpreted language is just ridiculous in principle. We had an army of very smart people who invested a huge amount of time and effort into making efficient interpreters for certain languages but all that work is thrown away as soon as you add a build step.<p>And the stunning thing is that it&#x27;s actually possible (easy even) to create excellent software with clean code without a build step (I&#x27;ve done it many times) but these simple, clean approaches are never popular. People want to use the complex approach that introduces a ton of new problems, delays and compatibility issues.
noyc超过 5 年前
While I agree with the author&#x27;s observation on efficiency and simplicity in modern software, I think that the article&#x27;s tone is needlessly antagonistic. It read like a diatribe about all of us these terrible programmers screwing up software for him. Perhaps I am an exception, but so far the majority of programmers I&#x27;ve worked with were very conscious of their software&#x27;s performance and worked hard on making it as fast as they could.<p>The problem is that when your software is built on top of a framework and&#x2F;or uses X different web APIs etc then you often run into issues where a part of the system that you don&#x27;t have control over causes performance issues and you don&#x27;t have the expertise&#x2F;time to profile it in order to fix it. So I think what&#x27;s causing problems is that software has become a lot more about putting together frameworks, libraries and reusable components and when faced with such a complex system a programmer will often give up and say &quot;there! it&#x27;s as fast as I can make it without rewriting everything from scratch&quot;.<p>Therefore, the issue seems to be that programmers are building on top of other systems that they don&#x27;t know enough about to use efficiently. The author does mention this issue in his article as well, but in a slightly derogatory fashion blaming programmers for bringing in dependencies they don&#x27;t need.<p>I think if everybody had the time and ability to write everything from scratch like Jonathan Blow is doing with Jai then yes, things would be more efficient. It is far easier to profile and debug code you&#x27;ve written yourself. However, seeing how this isn&#x27;t feasible for most projects, I think more focus should be put on better documentation of frameworks and libraries.
eximius超过 5 年前
I agree with this.<p>I think we need a guild. We need licensed software engineers.<p>Not every programmer needs to be one, just like not every engineer needs to be licensed, but there needs to be a licensed engineer on every team. And, of course, sometimes there doesn&#x27;t need to be. But I sure wish there was the option.<p>And hell, bring back apprenticeships and mentoring with the guild. There is so much we could learn from the physical science engineering disciplines
评论 #21930839 未加载
评论 #21930874 未加载
评论 #21930780 未加载
notSupplied超过 5 年前
This is Jevon&#x27;s Paradox of software development.<p>As self driving cars enable us to fit far more cars on the road before causing the same level of congestion, people will start taking increasingly longer car rides for decreasingly valuable reasons, up until the roads are equally intolerable as they were before the innovation had occured.<p>Replace &quot;self driving cars&quot; with &quot;faster hardware &#x2F; more memory&quot;.
matheusmoreira超过 5 年前
A good way to remove bloat is to find and remove needless abstractions. Even a C compiler will produce huge executables and it takes a lot of work to reduce a program to the smallest amount of code:<p><a href="http:&#x2F;&#x2F;www.muppetlabs.com&#x2F;~breadbox&#x2F;software&#x2F;tiny&#x2F;teensy.html" rel="nofollow">http:&#x2F;&#x2F;www.muppetlabs.com&#x2F;~breadbox&#x2F;software&#x2F;tiny&#x2F;teensy.htm...</a>
mc3超过 5 年前
Sounds like he wants software to contain AGI, such that it can work out which version of a document you want to keep, and fix it&#x27;s own errors.<p>Honestly things were way more sucky years ago. Your Windows computer crashing was just normal in the 90&#x27;s. Rebooting and reinstalling par for the course. Getting Linux to install with drivers working seemed impossible unless you carefully chose hardware.
titzer超过 5 年前
FTA: &gt; As a general trend, we’re not getting faster software with more features. We’re getting faster hardware that runs slower software with the same features.<p>Or fewer features. Talk to an actual professional who uses spreadsheets all day long about switching from Excel to Google sheets. It&#x27;s infuriating the infantilization of UIs and the &quot;oh they&#x27;ll never miss it&quot; attitude.
评论 #21930860 未加载
slx26超过 5 年前
we all want simple, fast, small programs with clear objectives.<p>but:<p>- economic incentives do not align with common sense<p>- landscape is fragmented, continually evolving and unstable<p>- we are all posers. we all have opinions and morals, look at others and criticise, but when it comes to our own work we are just like anyone else. we need money to live, so we just go with the flow
cryptica超过 5 年前
From the JavaScript ecosystem, I&#x27;m frustrated by Babel&#x27;s popularity. Whenever I discuss it with developers, everyone agrees that it&#x27;s not worth it, and yet people still use it! It&#x27;s as if we have no choice in the matter!<p>The whole point of Babel was to allow us to use the latest JavaScript syntax so that we wouldn&#x27;t have to update our own source code when the new syntax finally became broadly supported by browsers and other engines.<p>IMO, the Babel project is a failure because:<p>- Babel itself is always being upgraded to support newer ECMAScript syntax, so people still need to upgrade their own code whether they use Babel or not. The only benefit is that using Babel allows you to use these features before other people.<p>- Instead of just worrying about how JavaScript syntax changes affect your code, with Babel, you also need to worry about how Babel upgrades will affect your code. The babel plugin dependencies often change and break over time (even if you don&#x27;t change your own code) and you always have to support both ecosystems.<p>So when you consider the big picture, Babel doesn&#x27;t save you from having to upgrade your own code (as per its original promise). When you evaluate the pros and cons, the cons greatly outnumber the pros:<p>Pros:<p>- You get to use the newest language features before other people.<p>Cons:<p>- You need to maintain your code for compatibility with two ecosystems instead of just one. Keeping up with both ECMAScript + Babel is a lot of work. I would even argue that staying up to date with Babel is more work because dependencies keep changing underneath your project.<p>- It forces you to use a build step so you lose the benefits&#x2F;iteration speed that an interpreted language brings to your development flow.<p>- Adds a lot of bloat and unnecessary, hard-to-describe dependencies to your project which can open up security vulnerabilities and make your code more opaque and brittle.
tanseydavid超过 5 年前
This is extremely well-worded and gets right-to-the-point. This is so refreshing in contrast to the constant attempts to <i>explain</i> why software is so slow, bloated and especially unreliable.<p>An explanation of &quot;why&quot; does not explain &quot;why this is acceptable&quot;.
didibus超过 5 年前
&gt; “Programmer time is more expensive than computer time.”<p>I support the idealism of the article, but this quote is very accurate. Nobody wants to pay for quality software. Not your users, not your stakeholders, not even you!<p>And that&#x27;s because the price of quality isn&#x27;t just a little more expensive. It&#x27;s not 1$ a year. It&#x27;s exponentially more expensive. And some of those paid efforts will still end up slow and crappy in outcome, because of something else the article doesn&#x27;t acknowledge:<p>Writing fast, efficient, simple, correct, full featured software is really really hard.<p>So not only is it expensive, it&#x27;s also just plain difficult. Meaning it&#x27;s not just about money and resources, but also time, time to experiment and fail.
wffurr超过 5 年前
&gt;&gt; That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply.<p>If I think back to my engineering school days, the definition of &quot;engineering&quot; for my classmates in civil and electrical engineering was to look up well defined procedures and calculations from a book and apply them. No deep understanding required to design a bridge that didn&#x27;t fall down or a circuit that didn&#x27;t overheat.<p>What&#x27;s the equivalent for software? Design patterns were a bust. SICP is for cultists. It&#x27;s a huge void. There is hardly any such discipline as &quot;software engineering&quot; yet.
coldtea超过 5 年前
&gt;<i>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. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and also process input, recalculate the world and dynamically load&#x2F;unload resources. How come?</i><p>Well, where&#x27;s your word processor buddy? Try to write one to achieve those goals -- and offer what people want today, including syntax highlighting, linting, auto-completions, etc, and come back to us...
评论 #21930958 未加载
评论 #21931106 未加载
acvny超过 5 年前
Each and every point the author makes shows lack of understanding of some basic things. Comparing cpu resources with fuel consumption? Really? Or windows update taking 30 minutes... Remember premature optimization is the root of all evil.
davnicwil超过 5 年前
&gt; Linux kills random processes by design. And yet it’s the most popular server-side OS<p>There&#x27;s no reference for this in the article, and it caught my attention - anyone have any idea what the author is talking about here? Never heard of this before
评论 #21931980 未加载
评论 #21931998 未加载
angarg12超过 5 年前
I can imagine how many software products come get to this state. At some point someone makes a poor design decision, and that sets a precedent. Or programmers can&#x27;t be bothered to clean up and refactor their code, and it adds over time.<p>But the best explanation for why this problem persists even in teams of proficient engineers that I have seen comes from the 2005 GDC Keynote from John Carmack [1].<p>&gt; I can remember clearly in previous projects thinking [...] I&#x27;ve done a good job on all of this but wouldn&#x27;t it be nice if I could sit back and really clean up the code, perfect the interfaces, and you know, just do a wonderful nice craftsman job [...] interestingly this project I&#x27;ve had the time to basically do that and I&#x27;ve come to the conclusion that it sort of sucks [...] there&#x27;s a level of craftsman satisfaction that you get from trying to do what you do at an extreme level of quality and one thing that I found is that&#x27;s not really my primary motivation [...] that&#x27;s not what&#x27;s really providing the value to your end-users [...] you can sit back and I am do a really nice polishing job it&#x27;s kind of nice but it&#x27;s not the point of maximum leverage and I found.<p>So, as others have mentioned here, there is a threshold where extra performance provides less value to the project than, say, an extra feature.<p>It seems that in some cases we have crossed that threshold and some software has become comically bloated. I attribute the reason why these are not solved to the same reasoning. Refactoring an existing project to reduce the bloat would take too much time and effort from one single developer, that could be used somewhere else, although in the end everyone would benefit from it. So you are better off adding stuff to the dumpster fire and moving on.<p>It&#x27;s sort of a tragedy of the commons [2] of software performance.<p>[1] <a href="https:&#x2F;&#x2F;youtu.be&#x2F;N0auhzHZe5k?t=1015" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;N0auhzHZe5k?t=1015</a><p>[2] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Tragedy_of_the_commons" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Tragedy_of_the_commons</a>
ateng超过 5 年前
&gt; 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.<p>Modern text editors have to deal with proportional font, right to left writing, anti-aliasing, and a big bag of Unicode related issues (Arabic is going to break all assumptions you have on language and text editing)<p>Fantastic read on this subject from few months ago:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21384158" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21384158</a>
misir超过 5 年前
I remember 5-6 yrs ago I tried to create an app using Pascal to remove cache&#x2F;temporary files, fix registry errors and a few optimizations like popular &quot;optimization&#x2F;speedup&quot; apps. I wanted to show the progress on progress bar but see what: the process just took 0.3-0.5 seconds and the progress bar is not required anymore. But I wanted to show it anyway and put random amount of wait time (sleep) between steeps. I didn&#x27;t realize why the popular apps needs 3-5 minutes for the task that my simple app just needs 0.5-1 second.
sergiotapia超过 5 年前
&gt;I’ve been programming for 15 years now. Recently, our industry’s lack of care for efficiency, simplicity, and excellence started really getting to me, to the point of me getting depressed by my own career and IT in general.<p>You and me both buddy! 11 years here, you are not alone in this!<p>What I found helped me take my mind of this nagging feeling is to bring in a tool that is like a razer sharp brand new scalpel. That was Nim. It&#x27;s readable, small, fast, and spits out tiny statically compiled binaries.<p>Find your scalpel and slice and dice. Back to basics. Purity.
评论 #21931892 未加载
swills超过 5 年前
I love that he linked this page in the article:<p><a href="https:&#x2F;&#x2F;docs.gitlab.com&#x2F;ee&#x2F;administration&#x2F;operations&#x2F;unicorn.html#unicorn-worker-killer" rel="nofollow">https:&#x2F;&#x2F;docs.gitlab.com&#x2F;ee&#x2F;administration&#x2F;operations&#x2F;unicorn...</a><p>because I&#x27;ve had to deal with that a bit. N.B. the last sentence here:<p>One other thing that stands out in the log snippet above, taken from GitLab.com, is that ‘worker 4’ was serving requests for only 23 seconds. This is a normal value for our current GitLab.com setup and traffic.
qwertygerty超过 5 年前
It appears to me that much of your complaint is based on the flawed assumption that the software &quot;industry&quot; is filled with engineers. (&quot;Industry&quot; because in software what appears to be production of something new, is really just a re-invention or re-creation of what&#x27;s been done before - and unfortunately rarely an improvement)<p>For example, how many authors on medium proclaim themselves &quot;Senior Software Engineers&quot; but when you dig find they&#x27;ve got maybe 5 years experience doing web development, with no CS or engineering education. Maybe stuff like a 36hr &quot;Web Development Bootcamp&quot;. Do people really not understand the definition of an engineer anymore?<p>From there they progress into the deeper parts of software. And create the atrocities to be found in the npm registry, which become dependencies of dependencies of dependencies that results in nightmares everytime one needs to navigate to a website.<p>If it would&#x27;ve been possible to see the background and education of the numerous critics here, what may we find? If I (the developer as described by the OP) am surrounded by people like me, and the world filled with people who think like me, and create things at a similar cognitive level as my peers, would I not misjudge the collective level of quality that I perceive to be acceptable? Smells like confirmation bias to me? Maybe a few others. Dunning-Kruger anyone?<p>In their defense, the marketing campaigns created by large corporations to turn the supply-demand (cost of employment) of employees in their favor, has I think been a big part of the problem. First the programmers, then the &quot;Data Scientists&quot;, etc - the amount of disappointment and student debt being created as these people eventually realise they&#x27;ve been sold something that they&#x27;re not suited for!<p>If we cannot critically look at our industry and admit our flaws, we cannot move forward as a collective.
Izkata超过 5 年前
&gt; A 16GB Android phone was perfectly fine 3 years ago. Today, with Android 8.1, it’s barely usable because each app has become at least twice as big for no apparent reason. There are no additional features. They are not faster or more optimized. They don’t look different. They just…grow?<p>I jumped straight from Android 2 to Android 8 development and was surprised myself, so did some investigation and have half an answer. The author is actually wrong here, on both looking different and additional functionality. However, the bloat is still far larger than it needs to be.<p>All the bloat comes from the AppCompat modules, which all the docs recommend to the point of it apparently being required if you don&#x27;t know better.<p>AppCompat is for both supporting differing APIs and creating a consistent look and feel across different Android versions. Each Android version has its own visual design, which Google decided was a bad thing, opting to use AppCompat so the most recent designs (and in some regards design functionality like coloring the selection handles) were used in older versions of Android.<p>To do this however, it includes a crap-ton of images. The build scripts are supposed to remove the unused ones, but even with maximum trimming enabled it can only remove somewhere around 10%. There are hardcoded inclusion rules for some of the AppCompat java code, that no one&#x27;s found a way to override, which in turn reference the images - so they get kept a well, even if your app never uses them.<p>As for differing APIs, notifications have changed massively over the years. The interface is so different you do actually need the AppCompat subset for notifications to target different Android versions (and that can be used separately from the rest of AppCompat), but there also have been a huge number of new features added to notifications - such as delay settings, shortcuts, icons, even full-on fancy designs, that didn&#x27;t exist early on.<p>I&#x27;m calling this only half an answer because there&#x27;s no apparent reason for some of the notification API changes, and the build scripts&#x2F;AppCompat can certainly be significantly improved to remove more cruft. I have a sneaking suspicion that it&#x27;s not done because this is low-hanging fruit for handing over signing keys to Google for their &quot;optimized&quot; builds...
ChrisMarshallNY超过 5 年前
Lots of moving parts.<p>I am a dependency skeptic. I think that you need them to do big stuff, but should probably avoid them for small stuff.<p>High-quality dependencies can have a drastic impact on the quality of your software, but so can low-quality dependencies.<p>I think we are at the tail-end of a &quot;wild west&quot; of dependencies.<p>When the dust settles, there will be a few really good, usable and stable dependencies, and a charnel pit, filled with the corpses of all the crap dependencies, and, unfortunately, the software that depended on them.
评论 #21932231 未加载
chrismmay超过 5 年前
Great article. Author makes some really good points. Surely the big tech firms have skunk works projects going on to rebuild the problem areas? Microsoft. Google. Facebook. Amazon. Netflix. They all must have decent sized R&amp;D departments? Perhaps an independent, very public, curated list that points out areas that desperately need work would be helpful. Name and shame so-to-speak, would prod them to move in the right direction on the areas that need work the most.
systematical超过 5 年前
Couldn&#x27;t agree more. I am going to throw marketing under the bus for web application bloat. They make us install script after script for tracking you. They are the worst.
vojta_letal超过 5 年前
Most of the issues outlined are problems of the web. The HTML+CSS+JS combo is just painfully slow and wasteful by design - it&#x27;s just way too many levels of flexible abstractions. Which is suboptimal for app development. Moreover it&#x27;s expensive to maintain two apps - web and native - which share have the exact same UI&#x2F;UX. Hence the rise of Electron, React Native , ...<p>The only way out of this is to rethink the web. Which is a hard one to tackle.
评论 #21934267 未加载
评论 #21934300 未加载
pm90超过 5 年前
IMO the article is painting a really negative picture about the state of technology. Any profession with large enough practitioners will create tons of crappy stuff; with most professions that crap is just not discoverable. e.g. if you&#x27;re a crappy carpenter, only your city or neighborhood can see your shitty work. But if you make a crappy website or app, anyone in the world can see and use it.
评论 #21931308 未加载
评论 #21931053 未加载
rckoepke超过 5 年前
&gt; Google Play Services, which I do not use (I don’t buy books, music or videos there)—300 MB that just sit there and which I’m unable to delete.<p>Thats....not what google play services is, like at all. <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;android&#x2F;guides&#x2F;overview" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;android&#x2F;guides&#x2F;overview</a>
bhupesh超过 5 年前
&gt; 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.<p>because we are going to make editors using JAVASCRIPT, which was never meant to be used this way
LogicalBorg超过 5 年前
The law of software bloat has been known since the 1980&#x27;s. It&#x27;s called Wirth&#x27;s Law, or &quot;What Intel giveth, Microsoft taketh away&quot;. See <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Wirth%27s_law" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Wirth%27s_law</a>.
jordanbeiber超过 5 年前
I’m in a bad mood today, and IM bad mood O, much of this is a symptom of modern economics and business management.<p>Also - resources that are essentially free to use (customer&#x2F;users CPU cycles, storage and bandwidth) will be consumed.<p>We as consumers are paying the bills for it all in different ways(electricity, new gadgets, cloud costs etc).
SebastianFrelle超过 5 年前
How does this apply to programming languages? I&#x27;ve always heard that developers should just stick to the language in which they&#x27;re most productive, but am I part of the problem if I pick Python over a more performant language like Rust or Go for all of my work (web apps, command-line tools, etc.)?
amelius超过 5 年前
Nowadays, the shittiness of software doesn&#x27;t come from lack of performance, but from ads and tracking.
agumonkey超过 5 年前
Large socio economic factors are at play.<p>It depresses me to no end too, but i am surprised in the least.<p>There were tiny groups trying to go frugal and solid. Remember suckless ? I forgot other names, there&#x27;s also alan kay vpri project with ometa.<p>Maybe we should make a frugalconf. Everything 25fps on a rpi zero
Aeolun超过 5 年前
In my opinion, the reason nobody cares about something taking 15 seconds, is because the process would have taken them 4 hours of manual work.<p>Of course they’re going to accept that delay, even if adding a few million numbers together should really take less than a millisecond.
jakear超过 5 年前
Yet another Electron hit-piece... curious, how do other cross-platform frameworks compare in both build time and live-reload time? For comparison, VS Code clean builds in about a minute, and a change-build-reload dev cycle is about a second or two.
jayd16超过 5 年前
Everyone is so angry. Isn&#x27;t this the the world of ubiquitous code and unlimited resources we wanted?<p>Not everything needs to be super efficient. Most things are tuned for production cost and time. Efficient code isn&#x27;t going anywhere. Relax guys.
评论 #21930330 未加载
评论 #21930767 未加载
评论 #21931101 未加载
jeromebaek超过 5 年前
The AI&#x2F;ML hype drives away talented students from engineering and systems research, as well. Because of the hype engineering somehow is less prestigious than “data science”. Wonder how long until this trend will blow up.
niknetniko超过 5 年前
I agree with the overal sentiment, yet the examples could be better.<p>&gt; 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. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and also process input, recalculate the world and dynamically load&#x2F;unload resources. How come?<p>Text is very complicated. Does your 42-year-old Emacs support Unicode? And not just accents, but whole different scripts?<p>See <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21105625" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21105625</a> for some discussion and a good link about the complexities of rendering text.
评论 #21930713 未加载
评论 #21930987 未加载
block_dagger超过 5 年前
This article ignores the primary reason for the basic “problem”: changeability. How easy is it for me to hire a cheap programmer to iterate my profitable saas biz to keep it relevant in the rapidly changing market?
bluedays超过 5 年前
Whenever I read articles like this I often wonder how much overhead is due to security concerns, and how much that overhead and additional complexity contributes to the problem of slower software.
barrkel超过 5 年前
The rant is entertaining. The problem is pricing. Developers largely don&#x27;t pay the costs for what they deploy; there&#x27;s no profit in efficiency. Thus things aren&#x27;t efficient.
nprateem超过 5 年前
So we really need to blame the developers of all the (free) libraries we use for not optimising them to the nth degree so our code doesn&#x27;t become bloated...<p>No one&#x27;s forcing you to use a library. But if you do they come with tradeoffs.<p>OK, things are slow and buggy. But we&#x27;ve got lots <i>more</i> things thanks to all the productivity we&#x27;ve gained from using libraries, etc. That means we collectively solve more problems for more people.<p>Purism is a nice idea, but ultimately probably not worth the effort until things become so bad that they are, and at that point become a differentiator. I mean, I don&#x27;t care if a web page is twice the size of Windows 95 because my computer is way faster than a 486.
mothsonasloth超过 5 年前
Choose your scape-goat:<p>a) Lack of fundamental understanding of how computers work<p>b) Abstraction away from the bits, flops, shifts and pops<p>c) Quick sort<p>d) Electron.js<p>e) Ruby hipsters<p>f) Magical cloud computing<p>g) Software companies that know the cost of everything and the value of nothing<p>h) All of the above
xadhix超过 5 年前
Had to remove background to read the article :D <a href="https:&#x2F;&#x2F;imgur.com&#x2F;gFla2WG" rel="nofollow">https:&#x2F;&#x2F;imgur.com&#x2F;gFla2WG</a>
rs23296008n1超过 5 年前
npm would be a lot better if it flattened out its node-modules. I&#x27;ve seen plenty of structures with multiple identical installs of the same library.<p>All module folders should be at root level.<p>Need version 15 and version 16? Yep different folders under the root. Modulename_version, eg somelib_0.1.15 alongside somelib_0.1.16<p>It would allow clear identification of old versions and much less duplication. Less bloat. No way to have duplicate copies of the same library.
zuhayeer超过 5 年前
&gt; Web pages ask you to refresh if anything goes wrong. Who has time to figure out what happened?<p>I feel like this is a feature, not a bug of software dev. The fact that you can push updates out so instantaneously allows you to work incredibly incrementally. You can make barely functional, inefficient things (shortcut hacks) just to make sure that your product is something that people actually use before focusing on optimization. If users are willing to put in the extra work to &quot;refresh&quot; the page, then certainly there&#x27;s some real problem you are solving.
erikbye超过 5 年前
This whole article is regurgitation, aside from that, I was just wondering, what complex, highly efficient software has the author written?
georgeecollins超过 5 年前
The analogy to cars misses where they are in their life cycle. When cars were evolving at a faster pace, and gas was relatively cheaper, they did get something like 5-10% efficiency, particularly when you correct for the level of emissions produced.<p>Gas car technology matured, gas got more expensive, and cars got more efficient. Moore&#x27;s Law isn&#x27;t going to go on forever. We are hitting limits in battery life. Software will tend to get more efficient over time.
Wald76超过 5 年前
Safari on iOS would not render Nikita’s article until I killed and restarted it, nicely illustrating one of his key points.
评论 #21930928 未加载
drbojingle超过 5 年前
I understand what the author is saying but it sounds like wanting tech for tech&#x27;s sake. If the user doesn&#x27;t care, then does it matter that sites are slower? And if it matters, why hasn&#x27;t someone come along and done something better like the author suggests? Surely this trend in tech performance has been going on for so long that someone could be doing something about it?
AkshatM超过 5 年前
Obligatory mention of Parkinson&#x27;s law (<a href="https:&#x2F;&#x2F;www.wikiwand.com&#x2F;en&#x2F;Parkinson%27s_law#&#x2F;Generalization" rel="nofollow">https:&#x2F;&#x2F;www.wikiwand.com&#x2F;en&#x2F;Parkinson%27s_law#&#x2F;Generalizatio...</a>), which states<p>&gt; The demand upon a resource tends to expand to match the supply of the resource (If the price is zero).<p>Have cheap hardware, software <i>will</i> expand to use more of it.
kraig911超过 5 年前
Everyone forgets the spiritual cost that it takes on the meat to make silicon think. Does it suck? Certainly not. Could it be better yes. That&#x27;s why we&#x27;re here. Right now though the human can barely interpret things less than 1&#x2F;60th of a second. Speed&#x2F;Performance isn&#x27;t everything.
haecceity超过 5 年前
Ha! And people call me crazy for using emacs and eww for everything.
EdSharkey超过 5 年前
Since about 2004, when computers started having lots of excess ram and CPU, all that excess went towards surveillance. Your software is slow because watching you is hard work!
dustingetz超过 5 年前
Peter Principle<p>Conway&#x27;s Law
utxaa超过 5 年前
Avast! the river was angry at us arr ...
xmzx超过 5 年前
Something no one has said which probably should be mentioned is that programmers today are just not as good as programmers of yesteryear.
评论 #21930764 未加载
idclip超过 5 年前
This. I feel this to the bone.
graycat超过 5 年前
From the OP:<p>&gt; I hope I’m not alone at this. I hope there are people out there who want to do the same. I’d appreciate if we at least start talking about how absurdly bad our current situation in the software industry is. And then we maybe figure out how to get out.<p>Okay, I&#x27;ll respond, especially on the last part &quot;how to get out&quot;.<p>For the problems and struggles in the OP, I&#x27;ve seen not all of them but too many and sympathize. Mostly though, I don&#x27;t have those problems, and the main reason is in the simple, old advice in the KISS Principle where KISS abbreviates Keep it Simple Silly although the last <i>S</i> does not always abbreviate <i>silly</i>.<p>In particular my startup is a Web site and seems to avoid all of the problems in the OP. Some details:<p>(1) Bloated Unreliable Infrastructure?<p>My Web site is based on Microsoft&#x27;s .NET with ASP.NET for Web pages and ADO.NET for access to SQL Server (relational database). The version of .NET I&#x27;m using is some 4.x. So far I&#x27;ve seen essentially no significant revisions or bugs.<p>For the software for my Web pages I just used one of the languages that comes with .NET. I wanted to select between two, the .NET version of C# and the .NET version of Visual Basic. As far as I can tell, both languages are plenty good ways to get to the .NET classes and make use of Microsoft&#x27;s <i>managed code</i>, e.g., garbage collection, and their CLR (common language run time) code. And IIRC there is a source code translator that will convert either language to the other one, a point which suggests that really the two language are deeply equivalent.<p>I&#x27;ve written some C code off and on for 20+ years; mostly I remember the remark in the Kernighan and Ritchie book on C that the language has an &quot;idiosyncratic syntax&quot; or some such -- I agree. I never could understand the full generality of a declaration of a function -- IIRC there is some code in the book that helps parsing such a statement. I do remember that<p>i = ++j+++++k++<p>is legal; I don&#x27;t want any such code in my startup; also my old tests showed that two compilers gave different results.<p>I find Visual Basic to have a less &quot;idiosyncratic syntax&quot; and a more <i>traditional</i> syntax closer to the original Basic and then Fortran, Algol, PL&#x2F;I, Pascal, etc. So, my 100,000 lines of typing are in the .NET version of Visual Basic (VB).<p>For my Web site, part of the code is for a <i>server</i> process for some of the <i>applied math</i> computing. The file of the VB source code is 478,396 bytes long (the source code is awash in comments), and the EXE version is 94,720 bytes long. As far as I can tell, the code loads and runs <i>right away</i>. Looks nicely small and fast and not bloated or slow to me.<p>(2) A bloated IDE (integrated development environment).<p>I have no problems at all with IDEs. The reason is simple: I don&#x27;t use one.<p>Instead of an IDE, I typed all my code, all 100,000 lines, into my favorite text editor, KEdit. It has a macro language, KEXX, a version of REXX, and in that language I&#x27;ve typed about 200 little macros. Some of those macros let KEdit be plenty good enough for typing in software.<p>E.g., I have about 4000 Web pages of .NET documentation from Microsoft&#x27;s MSDN site. Many of the comments in my VB source code refer to some one of those pages by having the tree name on my computer of the HTML file; then a simple command displays the Web page. When reading code and checking the relevant documentation, that little tool works fine.<p>After all, VB source code and HTML code are just simple text; so are my Web site log files, the KEXX code, Rexx language scripting code, all the documentation I write either in the code or in external files (just simple text or TeX language input), etc. So, a good general purpose text editor can do well. And, &quot;Look, Ma: I get to use the same spell checker for all such text!&quot; The spell checker? ASPELL with the TeX distribution I use. It&#x27;s terrific, really <i>smart</i>, blindingly fast, runs in just a console window.<p>For KEdit, it seems to load and run right away. I just looked and saw that what appears to be the main EXE file KEDITW32.exe is<p>1,074,456<p>bytes long -- not so bloated.<p>(3) Windows 10 Home Edition Reliability.<p>For a move, I got an HP laptop; it came with Windows 10 Home Edition. I leave it running 24 x 7. It hasn&#x27;t quit in months. It appears that now the Microsoft updates get applied without stopping the programs I usually have running, e.g., KEdit, the video player VLC, Firefox, etc.<p>Using carefully selected options for ROBOCOPY, I do full and incremental backups of <i>my</i> files. I keep the ROBOCOPY log output; that output shows the data rate of the backup, and I have not seen that to grow slower over time. The <i>disk</i> in that laptop is rotating, and I&#x27;ve never done a de-fragmentation. So, I can&#x27;t complain about performance growing slower from bloat, disk fragmentation, etc.<p>(4) Windows 7 64 bit Professional Server.<p>For a first Web server, I plugged together a mid-tower case with an AMD FX-8350 processor, 64 bit addressing, 8 cores, 4.0 GHz standard clock speed and installed from a legal CD and authentication code Windows 7 64 bit Professional SP1. As I left that pair running 24 x 7, occasionally it would stop with a memory error of some kind. I installed an update and never again saw any reliability problem in months of 24 x 7 operation.<p>Since then I looked into Windows 7 64 bit updates and concluded that (i) there was a big <i>roll-up</i> of about 2016 or some such; (ii) since then there have been updates and fixes monthly and cumulative since the big roll-up, and (iii) the updates for Windows 7 64 bits and Windows Server 2008 are the same.<p>I can believe that Windows Server 2008 long ran and still runs some of the most important computing in the world. So if my Windows 7 64 bit Professional has the same updates as Windows Server 2008, maybe for use as a server my Windows 7 installation will be about the most reliable major operating system in computing so far. Fine with me.<p>So, I am not screaming bloody murder about operating system or software reliability.<p>(5) Smart Phone Bloat and Reliability.<p>I have no problems with smartphones if only because I have no smartphone and don&#x27;t want one: When smartphones first came out, I saw the display as way too small and the keyboard as just absurd. Heck, in my desktop computing I have a quite good keyboard but would like a better one and, of course, would like a larger screen -- no way do I want to retreat to an absurd keyboard and a tiny screen.<p>Next I guessed that there would be problems in security, bloat, reliability, system management, documentation, and cost. Maybe history has confirmed some of these guesses!<p>For a recent move, I got a $15 cell phone and did use it a few times. Then I junked it.<p>My phone is just what I want -- a land line touch tone desk set with a phone message function from my provider. Works fine. So, I have a phone with lower cost and no problems with keyboard, screen, security, bloat, or documentation. Ah, old Bell Tel built some solid hardware!<p>(6) Web Site Speed, Reliability, and Bloat.<p>My Web site apparently has few or no problems with speed, ....<p>Why? The site is simple, just some very standard HTML code sent from now old and apparently rock solid ASP.NET.<p>Fast? The largest Web page sends for just 400,000 bits.<p>The HTML used is so old that it should look fine on any device anywhere in the world with a Web browser up to date as of, say, 10 years ago.<p>The key to all of this? The KISS Principle.<p>YMMV!
jimhefferon超过 5 年前
&gt; Modern text editors have higher latency than 42-year-old Emacs.<p>Hmmm. Let&#x27;s think about this.
评论 #21931401 未加载
fizixer超过 5 年前
This is me.
omg_ketchup超过 5 年前
RIP Flash
angleofrepose超过 5 年前
What are you up to these days Chris? And the obligatory question, what is your take on the article&#x2F;why post?<p>I piled standout quotes below.<p>I think a big takeaway from the intersection of Bret Victor, Alan Kay, Jim Hollan and the ink&amp;switch folks and your work is that the right dynamic interface can be the &quot;place we live in&quot; on the computer.<p>Victor shows a history of interactive direct manipulation interfaces, live environments where explorations of models or the creation of art go hand in hand with everything else related to that task: data input, explicit (programmatic) requirements and the visual output.<p>Hollan and ink&amp;switch show the environment (ZUIs, canvas) can contain everything for doing work, the code alongside any manipulation of the viewport that can be conceived. Tools infinitely more advanced than Microsoft OneNote and designed 40 years ago.<p>From what I know about your work, I see another take on the environment I want to live in on the computer. I dont understand why I would want to lose power by stepping away from my language&#x2F;interpreter&#x2F;compiler&#x2F;repl into a GUI or some portal when I can bring whatever it is which is nice about GUIs or portals into my dynamic computing environment. I very much want a personal DSL or set of DSLs for what I do on the computer, and I want to be able to hook into anything ala middle mouse button in plan9.<p>The superior alternative to walled gardens and this absurd world of bloat and &#x27;feature loss&#x27; (for lack of a better term for software engineering&#x27;s enthusiastic rejection of history) seems to be known, and facets of it advocated by you and these others. It seems clear that &quot;using the computer&quot; needs to return to &quot;programming the computer&quot; and that to achieve that we need to fundamentally change &quot;programming the computer&quot; to be a more communicative activity, to foster a better relationship between the computer and the user.<p>Where is this work being done now? VPRI shut down 2 years ago, Dynamicland seems to be on hiatus? I am inspired most these days by indie developers who write their own tools and build wild looking knowledge engines or what they sometimes call &quot;trackers.&quot;[1] And of course the histories and papers put forward by the above and their predecessors. And I play with my own, building an environment where I can write, draw, code, execute and interact with it all. I see no existing product which approaches what I want.<p>&gt; Everyone is busy building stuff for right now, today, rarely for tomorrow.<p>&gt; Even when efficient solutions have been known for ages, we still struggle with the same problems: package management, build systems, compilers, language design, IDEs.<p>&gt; You need to occasionally throw stuff away and replace it with better stuff.<p>&gt; Business won’t care Neither will users. They are only learned to expect what we can provide.<p>&gt; There’s no competition either. Everybody is building the same slow, bloated, unreliable products.<p>&gt; The only thing required is not building on top of a huge pile of crap that modern toolchain is.<p>&gt; I want something to believe in, a worthy end goal, a future better than what we have today, and I want a community of engineers who share that vision.<p>[1]: <a href="https:&#x2F;&#x2F;webring.xxiivv.com" rel="nofollow">https:&#x2F;&#x2F;webring.xxiivv.com</a>
评论 #21931078 未加载
syntheticnature超过 5 年前
Some valid and useful points wrapped up in a pile of failure to do even trivial research (e.g. Google Play Services isn&#x27;t what the author thinks, the iOS &#x27;nothing changed&#x27; hand-wave) and the sensibility of someone walking around an art show saying &quot;I could do that, better.&quot; The author could bear introduction to Chesteron&#x27;s Fence, if nothing else, and a review of their apparent GitHub profile points to, perhaps, needing some time spent in the land of embedded systems to understand why a phone doesn&#x27;t just boot in 1s.
评论 #21931854 未加载
bronlund超过 5 年前
I&#x27;ve seen several similar posts like this, but this is the best one yet. Kudos!
tyzerdak超过 5 年前
Don&#x27;t feed the russian troll. These trolls take 1% truth and mix it with 99% lie.
shiftless超过 5 年前
To put a finer point on it, software today is absolute garbage. I&#x27;ve been screaming about this for decades.<p>All of this bloated &#x27;shitware&#x27; today is the result of it having been written by people who a) have no deeper understanding of what the computer is actually doing; also known as typical Python&#x2F;Java&#x2F;etc&#x2F;etc&#x2F;etc programmers, and&#x2F;or b) simply not giving a damn about conservation of resources--as further evidenced by all of the other extremely wasteful and destructive habits they hold in their personal lives, and in their societies in general.<p>After all, this is the same civilization that&#x27;s burning through increasingly vast quantities of oil at an astounding rate, despite the fact that previously existing abundant and cheap oil is nearly depleted, with no possibility of replenishment or replacement. So is it any surprise that foolish developers also burn through CPU and memory with reckless abandon?<p>Really, the problems we face aren&#x27;t just in software; they&#x27;re more about the foundations of our entire Western &#x27;civilization.&#x27; Such problems generally tend to be rather intractable, in the historical view.<p>I&#x27;m working to construct, in my own computing life, something of a &#x27;personal oasis&#x27;, which is increasingly removed and estranged from all of the horrible things I see Other People out there having to suffer in their personal computing lives, thanks to talentless &#x27;developers&#x27; who <i>Just Don&#x27;t Fucking Care</i>. Some of these pricks actually have the audacity to call themselves &#x27;engineers&#x27;, even.
评论 #21930534 未加载
评论 #21930530 未加载
评论 #21930358 未加载
评论 #21930345 未加载
评论 #21933219 未加载
评论 #21930126 未加载
评论 #21930424 未加载
评论 #21930029 未加载
qaq超过 5 年前
Well complaining about it does not change anything. Support the projects that you believe will help with these problems with $ and things might actually change.
评论 #21932534 未加载
lazyant超过 5 年前
Whenever I see a rant that is a blanket &quot;all is bullshit&quot; list of complaints, I check if there are any actionable proposed solutions. Author gave none, so I dismiss all this with a flick of my hand.
CivBase超过 5 年前
I get really tired of hearing people complain incesently about how inefficient software is. I want it too, but it isn&#x27;t going to just happen.<p>Effiency is a selling point that most users don&#x27;t care much about in most markets. There are efficient browsers out there but everyone uses Chrome because those browsers are inferior to Chrome in many other ways. Ways that are more important to the average browser user.<p>If there&#x27;s a market for a more efficient software solution, go make it and get rich. Otherwise, I&#x27;m getting sick of the complaining.
erikbye超过 5 年前
Here&#x27;s why I&#x27;m slightly annoyed by articles like this one. Oftentimes the &quot;Software is slow&quot; mantra rings true, but here&#x27;s the thing: everyone repeating it claims it&#x27;s the shit further down the stack that&#x27;s the cause of the slowness, this is often untrue. V8 is fast; it&#x27;s your shit JS code that is slow. PostgreSQL is fast; your shit queries are slow. We live in the age of the Stack Overflow programmer. Think about it for just a second, what requires the most competency? Writing V8 or PostgreSQL, or churning out some JS for a web app or Electron? It&#x27;s not the programmers working on the former that is not concerned about performance. They spend considerable effort on it.<p>The least competent programmers are the once writing slow code. The least competent programmers are the ones working at the top of the stack.
评论 #21934171 未加载