7 ms·

As soon as Blow and others start pontificating about how modern software is terrible, I get frustrated; my viewpoint differs with theirs so drastically that I d

by johnfn 4y ago

As soon as Blow and others start pontificating about how modern software is terrible, I get frustrated; my viewpoint differs with theirs so drastically that I don't even know where to begin. I might start somewhere around here: I think the fact that modern software is "terrible" is actually a sign of the dramatic success, not failure, of programming. The reasons that Blow et all normally cite as why software is terrible are usually that, 20 and 30 years ago, engineers were able to pull off superhuman feats compared to the engineers of today. I accept this unquestionably. They wrote software that ran quicker and was more space-efficient than modern software. But running software that fit in kilobytes of RAM was never the goal of software engineering. The goal was providing value to your users. Blow et. al. seem to think that efficient software is the goal. I couldn't disagree more. The goal is always to produce things that users can actually use. And if that means doing hideously inefficient things, like running your app inside a chrome shell, so be it, if that means you delivered value faster. And the amount of engineering effort per unit of value created has gone down so much today compared to 30 years ago. In the past, engineers could squander days or weeks trying to make code more memory efficient, or finding the exact right sequence of ASM instructions to waste less CPU cycles. These are issues I don't even have to think about. Heck, I can do extremely stupid and inefficient things, like use a garbage collector, or electron, and for the most part, users don't even care[1]. What an incredible success! Essentially, I think what Blow is seeing when he cites the demise of modern software engineering is in fact that the bar to writing usable software has dropped immensely. I can understand why this is a frustrating thing for him, because it effectively means that his skillset is not as valuable as it used to be. But I just can't agree at all. How amazing that we can be so wasteful and yet still produce such great software, and furthermore what an incredible success that engineers like me don't need to even think about ASM and RAM efficiency. [1] Yes, some users do care, and I think that a disproportionate majority of them hang out on Hacker News. :P

agentultra 4y ago
I too find his presentation pretentious and his claims suspect. He has released two games in his career so far and an as-yet-to-be-released compiler that he’s been toying with for years: and he calls modern software developers unproductive! However I think efficiency still matters depending on the use case and to his credit I don’t think he says that everyone has to care about efficiency. I think the point he makes is that we might be losing the ability to produce efficient code because we’re not teaching these techniques. And that is perhaps why we buy $3000 Facebook browsing machines that don’t feel any faster than computers 20 years ago. Often they are slower. If we only teach folks how to script Unity and Unreal how are we supposed to get the next generation of engine developers to build the foundations of the technology?
- darepublic 4y ago
  Fwiw I would say he has been highly productive compared to most engineers. Two complete games of that quality nothing to sneeze at. But he does seem to take certain ideas much further than I would
- johnfn 4y ago
  Well, I wouldn't go that far. Blow is a smart guy, and games are hard to make. Two mainstream successes are more than I have. :P > If we only teach folks how to script Unity and Unreal how are we supposed to get the next generation of engine developers to build the foundations of the technology? Why can't we have both? Lowering the bar to allow less-experienced engineers to create things doesn't mean that we've prevented engineers with more experience from continuing to exist and thrive. We've just created a richer stratification of skill levels than previously existed.
  - agentultra 4y ago
    Fair, I was being a bit harsh with his credentials. He’s also freely streaming and posting how bad modern software is. And again I don’t think he said, in the talk mentioned in tfa, that we can’t have both. His primary concern seems to be that the scales have tipped too far one way. I think there is some merit to that. Go to any game dev forum and ask about programming and 9 times out of 10 you will be guided towards using a game engine. The common wisdom is: don’t learn to program, just make the game. And that is 100% fine advice and Blow admits that in the talk. But knowledge transfer is the key here and if we’re not making enough space in the education of future programmers for that lower level part of the stack then maybe one day we (as in society) could forget how. I still think that’s highly unlikely to be happening today but it’s an interesting thing to think about. I find myself often frustrated by how much gobs of memory, fast drives, and cores we throw into modern machines and yet my browser can still stutter while scrolling a page.
    - kelnos 4y ago
      I'm not really so worried about this knowledge transfer thing. I think programming knowledge is being transferred just fine. It's hard to see it, though, because there are several orders of magnitude more programmers now than there were 20 years ago. You don't need a constant X% of programmers to know how to build a game engine. You just need a couple hundred of them, or so, and as long as that knowledge is passed to a couple hundred of the next generation of programmers, that's fine. And if only a couple hundred -- or even a thousand -- programmers know how to build a game engine, it's easy to see how it might feel hard to find those people among the millions of programmers out there. But they're there, and they're mostly probably doing useful work and are propagating their knowledge appropriately. I also think that many many many more people know how to write efficient programs than Blow or other doomsayers might fear. It's just that most of us have better things to do than micro-optimize or write our own engines or toolkits or whatever for everything, and the state of modern computing means that we don't have to bother -- even while many of us decry the inefficiency of things like Electron, or in attempting to write a high-scale distributed system in Python or Ruby. And I agree with you that it's dumb that we can throw an 8-core 4GHz CPU and 32GB of RAM at a web browser, and it can still stutter while scrolling down a page. We clearly haven't always found the best balance here. But that doesn't mean we've lost the ability to do so. I think plenty of people have all this tribal programming knowledge, and they're doing just fine passing it along to the next generation of programmers. It's just that most people don't need to actually make use of that knowledge in their day-to-day work. Yes, I do believe that lack of use causes some atrophy, but I don't think that's the big problem that some would make it out to be.
WalterBright 4y ago
And the new James Webb telescope runs Javascript! It must have power and CPU cycles to burn.
- westoncb 4y ago
  I'm genuinely curious why you think they chose to have it run javascript. I just spent a few minutes looking into their actual usage of it and, ime, it has all the indications of being a reasonable decision. Here's a bit more info from [0]: > It is my opinion that NASA settled on the Nombas engine, after extensive research of their own into all the options available at the time, not so much because of the JavaScript language itself (although the familiarity of the language was a bonus), but because of the solid and robust nature of the ScriptEase engine and the tools that went with it. [0]: http://brent-noorda.com/nombas/us/index.htm http://brent-noorda.com/nombas/us/index.htm
  - WalterBright 4y ago
    Can't wish away the power, memory, and speed issues JavaScript has, meaning the telescope must have all three to burn. I've written a Javascript engine back in 2000. I came away from that with a distaste for dynamic typing. It seems easier to write code with dynamic typing, but I wouldn't give it many points for robustness. JS has many odd behaviors if an unexpected type was passed to a seemingly simple function.
    - westoncb 4y ago
      You've sidestepped my question though :) Why do you think NASA made the decision to use it? Is it not possible there were legitimate reasons? The implications you're suggesting about power, memory, and speed, or even predictability in semantics, depend on the particular language spec they implemented (it was not standard ecmascript), how they implemented, and how that implementation was used within the larger system. It seems to me like just knowing it was javascript (for some definition of javascript) is not enough.
      - 4y ago
Barrin92 4y ago
>The goal is always to produce things that users can actually use. consumer software exists downstream from advancements created by people who care about performance and correctness. You can only do extremely stupid things because someone else did non-stupid things to enable that kind of waste. That sort of works as long as the wasteful people don't outnumber and outrun the few people who keep everything glued together, but if they don't then at some point this arrangement breaks down. Maybe let's try to convince developers and consumers to be smarter rather than try to make software dumber. We should take a page out of the semiconductor industry's book which is run by engineers and builds towards engineering and scientific targets, not consumer demands. Those are a byproduct afforded by increases in performance. That's why chips, unlike software, get faster.
- johnfn 4y ago
  I kinda said the same thing in another reply, but why can't we have both? We can have experienced engineers working on low-level perf and correctness, and then we can have normal, less experienced engineers who just need to glue together a CRUD app to save some people some time. > That's why chips, unlike software, get faster. The difference is that perf is a feature of chips. It's not necessarily a feature of software.
- sanderjd 4y ago
  > Maybe let's try to convince developers and consumers to be smarter rather than try to make software dumber. I don't get this. What would it mean for consumers to be "smarter"? Smarter in what way?
  - Jensson 4y ago
    We taught the world how to read a century ago, surely we can teach every human how to navigate interfaces more complex than Twitter? Its just that today we expect interfaces to have zero learning time, that doesn't seem to be a very efficient use of software. Like, imagine how much better many interfaces could be if we taught basic regular expressions in schools? Things like searching and filtering could be much more expressive everywhere. Regular expressions are so simple that anyone could learn them in a few hours.
LanternLight83 4y ago
I'd highlight the handmade.network software community, who superficiality side with Blow, but if you read their manifesto on their website, it puts a lot of emphasis on the end user's experience. They cite Casey (of Handmade Hero), and I recall watching a casual lecture of his on a case study of Performant Software. In his conclusion he proposed that as innovative greenfield projects claim thr low hanging fruit of developing software markets, those markets will increasing reward competitors who can undercut on the basis of intentionally (or deeply) crafted software architectures and the associated benefits to users (stability and performance). This is could be refuted by the suggestion that early market participants can establish strong enough monopolies to overcome their technical debt, but still shows another source of motivation for the Handmade community's ideals.
- sceadu 4y ago
  They will get to relearn about first mover advantage and switching costs
- kelnos 4y ago
  I want them to be correct, but I agree with the sibling poster that getting to market first and developing network effects tends to win. Perfect truly is the enemy of the good. "Good enough", by definition, is good enough, and perfection is rarely rewarded. Unless such perfection provides a huge leap ahead for users, which is rarely the case.
sweetsocks21 4y ago
I think you're correct in this assessment. I've recently switched from many years of low-level programming, doing real time animation/graphics into the large scale SaaS world. The things these two camps of software engineers care about are completely different. In the SaaS world it's all about interfacing between systems and managing complex business processes. There's often a lot of organization/political problems, along with auditing and legal requirements. There seems to be a lot more emphasis on developer productivity than end user performance. Not that these engineers don't care about performance, but their tolerances are much higher. For example 100-200ms turn around is entirely acceptable, or even fast, in the SaaS world. While in my previous job that was absurdly slow, and unacceptable. I think another under appreciated thing is that the scale and complexity is truly larger today than yesteryear. Even in real time graphics, Unreal Engine incorporates literally decades of cutting edge research into a framework that a new game programmer can start running with in hours. There's the various platforms like mobile, PC/Mac/Linux, graphics APIs like DX12, Metal, Vulcan, multiplayer syncing, animation, model importing, etc etc. There's just so many more things to support these days that there's going to be some slippage. And each of these new tools and platforms were made with the intention of doing something better than a previous one, but then the real world creeps in and here we are. It would be great to see more effort and research into rethinking from the base level, maybe even hardware, of how we can simplify this entire software stack and have our cake and eat it too.
rstat1 4y ago
Kinda think that you celebrating being wasteful is proving his point. In my mind writing performant, somewhat efficient code does nothing but improve the UX, and if you actually care about your users having a good experience using your software then you shouldn't be celebrating wastefulness.
- Ygg2 4y ago
  Wasteful is relative. By focusing on optimization you are being wasteful with programmer's time.
  - rstat1 4y ago
    Making a better product is not wasteful of anyone's time.
    - Ygg2 4y ago
      Better for who? What you consider good and I consider good for a product can, but doesn't have to be the same. And there is an opportunity cost in doing one or the other.
iamwil 4y ago
I don't think inefficiency is his only point. If it could be written with all the inefficiencies and deliver value faster without bugs, that's one thing. But the problem is, software is consistently buggy, and you run into them every day. It's now hard to notice because it happens so often, we're inured. That's why he challenges you to write down all the bugs you run into everyday, to make yourself more aware. You can see his list here. https://youtu.be/pW-SOdj4Kkk?t=1347 https://youtu.be/pW-SOdj4Kkk?t=1347 I've also done this exercise, and it's surprising how many you notice when you're looking for it and write it down. Modern software is terrible in the sense that it's still buggy and hard to use despite access to immense power of modern computers--not merely that it's inefficient.
- tialaramex 4y ago
  Jonathan does indeed complain about bugs, but as is typical for this type of programmer he's sure these are somehow being introduced by "Bad" programmers who are incompetent or lazy, not by "Good" programmers like Jonathan. You get stuff like: "The Jai philosophy is, if you don’t want idiots writing bad code for your project, then don’t hire any idiots." which probably feels good to say to yourself, but of course it's not going to result in fewer bugs. Jonathan doesn't like Exceptions, which, fine, I agree control flow and error reporting shouldn't be bundled together, but if you're serious about preventing bugs and you don't want exceptions, you need to actually write a lot of error handling, which means error handling needs to be ergonomic in your language. In Jai there might be error flags, you might be expected to check them but if you don't it won't complain because you undoubtedly know best. Pressing on regardless becomes ergonomic like in C. And so Jai certainly isn't going to do anything about how buggy software is.
  - imran0 4y ago
    > Jai certainly isn't going to do anything about how buggy software is. Nothing is going to do that, except the competence of the developer.
    - tialaramex 4y ago
      That's certainly Jonathan's contention. I would argue that it's already obviously wrong.
Olreich 4y ago
He's also claimed that our computers are 2+ orders of magnitude off the productivity that should be achievable while reaching his goals. It's not so much that all software of old was amazing, it's that we really have lost something when RemeDyBG is 1000x faster than Visual Studio, with Visual Studio having hundreds of years of development effort and RemeDyBG has a couple years of development effort. His philosophy is that if we built software differently, we could build it faster and it would be faster. The emphasis on garbage collection and borrow checkers and everything else related to memory management misses the point (memory arenas are way better for the vast majority of use cases). The emphasis on Object-Oriented code is awful. The paradigm of RAII is completely counterproductive. There are very specific issues that Blow takes on, not just a general feeling of malaise.
geodel 4y ago
> The goal is always to produce things that users can actually use. And if that means doing hideously inefficient things, like running your app inside a chrome shell, so be it, if that means you delivered value faster. I guess core issue to me is this value delivered to whom. So far the value I see it is for framework users who could pull a 100K lines CRUD app in one month, of which 99% is just framework glue/code. However as end user I am getting rather bad user experience, my computer fan is running at full speed, Loading webpages or filling online forms so slow, endless error popups come and disappear and I can't do anything about it. It is not even about efficiency, just plain unreliable/unusable software delivered in name of "empowering" me. If I weren't software engineer I wouldn't even know that this crap is pulled by software engineers. Non-technical person would simply assume computer is bad/old, internet is slow and so on.
greggman3 4y ago
I very much disagree with JBlow because I came from games, I had similar opinions, and then I worked on "real software" (Chrome) and I had my thinking corrected. The problems JBlow and similar game devs are solving are not the same problems being solved elsewhere if you they really tried to solve the *same* problems I strongly believe they'd change their minds. IIRC one example he once brought up was a text editor written with a small amount of code. Yea sure, I also had a word process that fit in 16k (https://en.wikipedia.org/wiki/AtariWriter https://en.wikipedia.org/wiki/AtariWriter) but we're not on ASCII based computers with only text mode. Just a full unicode font takes 10s of megs of space. We're asking our software to draw fonts in any size, in several styles, in any language, and with emoji. That alone would break most of his assumptions because you can't just put them all in memory as pre-rendered glyphs, your user's don't have enough memory. Yet in games, most game devs would just basically say "F-that, you only get ASCII" or "F that, we're only supporting EFIGS + Katanana" and we only need 1 style. Two good articles on the issues of text that games never deal with https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/ https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/ The point being, it's the same all the way down in all areas. Game networking is not nearly as complicated as say the networking in a browser, that has to be able to run N video streams + M audio streams + X WebRTC video chats + Y Websockets, and video capture + audio capture and sending that data over the net, etc vs some game which if it ever plays video (many don't) only ever plays one video at a time, in known sizes and formats, and usually not streamed over the net but read directly from storage, etc... Or take just displaying images. Most games know up front how many images will be displayed. You might even give your artists a budget, no area of the game can use more than XX megs of image data. A browser can't run with those limits. Go look at imgur.com or scrolldit.com or pinterest. Situations games never deal with. And on top that there's just getting shit done. If I can write an app in a high-level system and ship on iOS, Android, Windows, Mac, iPadOS, I'm going to. I don't care that it's more bloated than if I hand coded assembly language for each one and neither do my customers. Sure they care if my app is buggy or the UX sucks but that's got nothing to do with whether I squeezed out every last byte and cycle out out of it. HNers like to rant about apps that use some kind of less than native framework but nearly all them are using well made apps that use those frameworks, they're just not aware of it because the people making them did a good job.
inglor_cz 4y ago
I think it is important to have at least some software as efficient as possible, especially server software, because huge data centers eat a lot of electricity and we cannot always take cheap electricity for granted. (The recent price spikes in Europe are crazy.) That said, such improvements may well be canceled out by other activities such as Bitcoin mining.
lapinot 4y ago
> But running software that fit in kilobytes of RAM was never the goal of software engineering. The goal was providing value to your users. By this definition of the goal you are indeed obviously right. So it's pretty clear that Blow and others don't agree with this goal. I'll try to map out two different povs on the goal of engineering: imho the goal you are describing, talking about "value" etc is associated with a world-view based of economic exchanges, on the idea of markets. In this world-view, engineering will have as goal to sell something to a third-party and be profitable to you, thus you will minimize your costs and do the minimum you can get away with. This is the pov of current hegemonic the economic sphere. What Blow defends, ie an engineering goal of using minimal resources for a given concrete objective, is much more in line with a world-view based on commons, on basic infrastructure for common needs. In this world, the most natural setting for doing the engineering work is not one of economic exchange, but one of cooperative, where the people that need the thing get organized somehow to get the thing done. In this setting, it is clear that the goal is not to do the minimal thing they will be ok with, the goal is to create a durable tool that will be practical to use and use minimal resources. In particular the investment (in human planning) can be very high, it doesn't really matter. This world is also close to the concepts of lowtech (basically favoring simplicity and robustness). > Yes, some users do care, and I think that a disproportionate majority of them hang out on Hacker News. :P A disproportionate majority of what? This is a classical hn fallacy: yes apparently hn likes to defend things being done "nicely" (at a good technical/resource tradeoff point) and not just "well enough" (at a short term profitable tradeoff point). But the silent majority that doesn't care you are talking about is very much restricted to the people that can afford paying for ever changing computing devices. Old people (cannot change fast), young people (get old family devices), people in less geopolitically gifted areas (less globalized purchase power), .. they all have almost obsolete technologies because they are constrained in several ways. You are talking about the majority of people that are visible to your economic world, but a lot of people are not inside of it, or on its outskirts (and if you say "but the economic sphere must be more inclusive and expand" then you are again pushing a particular view, which is not the only one and is debatable). One can also make the case that with the current state of affairs regarding fossil energy and limits to growth, going further more and more people are going to have these big constraints. This second view is very popular with people thinking seriously about ecology and crisis.
mooselaker 4y ago
I think the most steelman version is that he argues efficient software does in fact provide value to users. Whether or not they know it. And perhaps not always in terms of the application they have running right in front of them, but at a systemic or societal level. Little things add up, especially since software has eaten nearly every crumb.
JediLuke 4y ago
stephc_int13 4y ago
One of his point is that software engineering techniques did not improve at all, and even regressed, but all of that is/was hidden by the fact that hardware got us a free ride for several decades. You can use terribly slow scripting and techniques and get something working, not because the tooling is genius, but because the hardware is so incredibly fast.

by johnfn 4y ago

agentultra 4y ago

I too find his presentation pretentious and his claims suspect. He has released two games in his career so far and an as-yet-to-be-released compiler that he’s been toying with for years: and he calls modern software developers unproductive! However I think efficiency still matters depending on the use case and to his credit I don’t think he says that everyone has to care about efficiency. I think the point he makes is that we might be losing the ability to produce efficient code because we’re not teaching these techniques. And that is perhaps why we buy $3000 Facebook browsing machines that don’t feel any faster than computers 20 years ago. Often they are slower. If we only teach folks how to script Unity and Unreal how are we supposed to get the next generation of engine developers to build the foundations of the technology?

darepublic 4y ago
Fwiw I would say he has been highly productive compared to most engineers. Two complete games of that quality nothing to sneeze at. But he does seem to take certain ideas much further than I would
johnfn 4y ago
Well, I wouldn't go that far. Blow is a smart guy, and games are hard to make. Two mainstream successes are more than I have. :P > If we only teach folks how to script Unity and Unreal how are we supposed to get the next generation of engine developers to build the foundations of the technology? Why can't we have both? Lowering the bar to allow less-experienced engineers to create things doesn't mean that we've prevented engineers with more experience from continuing to exist and thrive. We've just created a richer stratification of skill levels than previously existed.
- agentultra 4y ago
  Fair, I was being a bit harsh with his credentials. He’s also freely streaming and posting how bad modern software is. And again I don’t think he said, in the talk mentioned in tfa, that we can’t have both. His primary concern seems to be that the scales have tipped too far one way. I think there is some merit to that. Go to any game dev forum and ask about programming and 9 times out of 10 you will be guided towards using a game engine. The common wisdom is: don’t learn to program, just make the game. And that is 100% fine advice and Blow admits that in the talk. But knowledge transfer is the key here and if we’re not making enough space in the education of future programmers for that lower level part of the stack then maybe one day we (as in society) could forget how. I still think that’s highly unlikely to be happening today but it’s an interesting thing to think about. I find myself often frustrated by how much gobs of memory, fast drives, and cores we throw into modern machines and yet my browser can still stutter while scrolling a page.
  - kelnos 4y ago
    I'm not really so worried about this knowledge transfer thing. I think programming knowledge is being transferred just fine. It's hard to see it, though, because there are several orders of magnitude more programmers now than there were 20 years ago. You don't need a constant X% of programmers to know how to build a game engine. You just need a couple hundred of them, or so, and as long as that knowledge is passed to a couple hundred of the next generation of programmers, that's fine. And if only a couple hundred -- or even a thousand -- programmers know how to build a game engine, it's easy to see how it might feel hard to find those people among the millions of programmers out there. But they're there, and they're mostly probably doing useful work and are propagating their knowledge appropriately. I also think that many many many more people know how to write efficient programs than Blow or other doomsayers might fear. It's just that most of us have better things to do than micro-optimize or write our own engines or toolkits or whatever for everything, and the state of modern computing means that we don't have to bother -- even while many of us decry the inefficiency of things like Electron, or in attempting to write a high-scale distributed system in Python or Ruby. And I agree with you that it's dumb that we can throw an 8-core 4GHz CPU and 32GB of RAM at a web browser, and it can still stutter while scrolling down a page. We clearly haven't always found the best balance here. But that doesn't mean we've lost the ability to do so. I think plenty of people have all this tribal programming knowledge, and they're doing just fine passing it along to the next generation of programmers. It's just that most people don't need to actually make use of that knowledge in their day-to-day work. Yes, I do believe that lack of use causes some atrophy, but I don't think that's the big problem that some would make it out to be.

WalterBright 4y ago

And the new James Webb telescope runs Javascript! It must have power and CPU cycles to burn.

westoncb 4y ago
I'm genuinely curious why you think they chose to have it run javascript. I just spent a few minutes looking into their actual usage of it and, ime, it has all the indications of being a reasonable decision. Here's a bit more info from [0]: > It is my opinion that NASA settled on the Nombas engine, after extensive research of their own into all the options available at the time, not so much because of the JavaScript language itself (although the familiarity of the language was a bonus), but because of the solid and robust nature of the ScriptEase engine and the tools that went with it. [0]: http://brent-noorda.com/nombas/us/index.htm http://brent-noorda.com/nombas/us/index.htm
- WalterBright 4y ago
  Can't wish away the power, memory, and speed issues JavaScript has, meaning the telescope must have all three to burn. I've written a Javascript engine back in 2000. I came away from that with a distaste for dynamic typing. It seems easier to write code with dynamic typing, but I wouldn't give it many points for robustness. JS has many odd behaviors if an unexpected type was passed to a seemingly simple function.
  - westoncb 4y ago
    You've sidestepped my question though :) Why do you think NASA made the decision to use it? Is it not possible there were legitimate reasons? The implications you're suggesting about power, memory, and speed, or even predictability in semantics, depend on the particular language spec they implemented (it was not standard ecmascript), how they implemented, and how that implementation was used within the larger system. It seems to me like just knowing it was javascript (for some definition of javascript) is not enough.
    - 4y ago

Barrin92 4y ago

>The goal is always to produce things that users can actually use. consumer software exists downstream from advancements created by people who care about performance and correctness. You can only do extremely stupid things because someone else did non-stupid things to enable that kind of waste. That sort of works as long as the wasteful people don't outnumber and outrun the few people who keep everything glued together, but if they don't then at some point this arrangement breaks down. Maybe let's try to convince developers and consumers to be smarter rather than try to make software dumber. We should take a page out of the semiconductor industry's book which is run by engineers and builds towards engineering and scientific targets, not consumer demands. Those are a byproduct afforded by increases in performance. That's why chips, unlike software, get faster.

johnfn 4y ago
I kinda said the same thing in another reply, but why can't we have both? We can have experienced engineers working on low-level perf and correctness, and then we can have normal, less experienced engineers who just need to glue together a CRUD app to save some people some time. > That's why chips, unlike software, get faster. The difference is that perf is a feature of chips. It's not necessarily a feature of software.
sanderjd 4y ago
> Maybe let's try to convince developers and consumers to be smarter rather than try to make software dumber. I don't get this. What would it mean for consumers to be "smarter"? Smarter in what way?
- Jensson 4y ago
  We taught the world how to read a century ago, surely we can teach every human how to navigate interfaces more complex than Twitter? Its just that today we expect interfaces to have zero learning time, that doesn't seem to be a very efficient use of software. Like, imagine how much better many interfaces could be if we taught basic regular expressions in schools? Things like searching and filtering could be much more expressive everywhere. Regular expressions are so simple that anyone could learn them in a few hours.

LanternLight83 4y ago

I'd highlight the handmade.network software community, who superficiality side with Blow, but if you read their manifesto on their website, it puts a lot of emphasis on the end user's experience. They cite Casey (of Handmade Hero), and I recall watching a casual lecture of his on a case study of Performant Software. In his conclusion he proposed that as innovative greenfield projects claim thr low hanging fruit of developing software markets, those markets will increasing reward competitors who can undercut on the basis of intentionally (or deeply) crafted software architectures and the associated benefits to users (stability and performance). This is could be refuted by the suggestion that early market participants can establish strong enough monopolies to overcome their technical debt, but still shows another source of motivation for the Handmade community's ideals.

sceadu 4y ago
They will get to relearn about first mover advantage and switching costs
kelnos 4y ago
I want them to be correct, but I agree with the sibling poster that getting to market first and developing network effects tends to win. Perfect truly is the enemy of the good. "Good enough", by definition, is good enough, and perfection is rarely rewarded. Unless such perfection provides a huge leap ahead for users, which is rarely the case.

sweetsocks21 4y ago

I think you're correct in this assessment. I've recently switched from many years of low-level programming, doing real time animation/graphics into the large scale SaaS world. The things these two camps of software engineers care about are completely different. In the SaaS world it's all about interfacing between systems and managing complex business processes. There's often a lot of organization/political problems, along with auditing and legal requirements. There seems to be a lot more emphasis on developer productivity than end user performance. Not that these engineers don't care about performance, but their tolerances are much higher. For example 100-200ms turn around is entirely acceptable, or even fast, in the SaaS world. While in my previous job that was absurdly slow, and unacceptable. I think another under appreciated thing is that the scale and complexity is truly larger today than yesteryear. Even in real time graphics, Unreal Engine incorporates literally decades of cutting edge research into a framework that a new game programmer can start running with in hours. There's the various platforms like mobile, PC/Mac/Linux, graphics APIs like DX12, Metal, Vulcan, multiplayer syncing, animation, model importing, etc etc. There's just so many more things to support these days that there's going to be some slippage. And each of these new tools and platforms were made with the intention of doing something better than a previous one, but then the real world creeps in and here we are. It would be great to see more effort and research into rethinking from the base level, maybe even hardware, of how we can simplify this entire software stack and have our cake and eat it too.

rstat1 4y ago

Kinda think that you celebrating being wasteful is proving his point. In my mind writing performant, somewhat efficient code does nothing but improve the UX, and if you actually care about your users having a good experience using your software then you shouldn't be celebrating wastefulness.

Ygg2 4y ago
Wasteful is relative. By focusing on optimization you are being wasteful with programmer's time.
- rstat1 4y ago
  Making a better product is not wasteful of anyone's time.
  - Ygg2 4y ago
    Better for who? What you consider good and I consider good for a product can, but doesn't have to be the same. And there is an opportunity cost in doing one or the other.

iamwil 4y ago

I don't think inefficiency is his only point. If it could be written with all the inefficiencies and deliver value faster without bugs, that's one thing. But the problem is, software is consistently buggy, and you run into them every day. It's now hard to notice because it happens so often, we're inured. That's why he challenges you to write down all the bugs you run into everyday, to make yourself more aware. You can see his list here. https://youtu.be/pW-SOdj4Kkk?t=1347 https://youtu.be/pW-SOdj4Kkk?t=1347 I've also done this exercise, and it's surprising how many you notice when you're looking for it and write it down. Modern software is terrible in the sense that it's still buggy and hard to use despite access to immense power of modern computers--not merely that it's inefficient.

tialaramex 4y ago
Jonathan does indeed complain about bugs, but as is typical for this type of programmer he's sure these are somehow being introduced by "Bad" programmers who are incompetent or lazy, not by "Good" programmers like Jonathan. You get stuff like: "The Jai philosophy is, if you don’t want idiots writing bad code for your project, then don’t hire any idiots." which probably feels good to say to yourself, but of course it's not going to result in fewer bugs. Jonathan doesn't like Exceptions, which, fine, I agree control flow and error reporting shouldn't be bundled together, but if you're serious about preventing bugs and you don't want exceptions, you need to actually write a lot of error handling, which means error handling needs to be ergonomic in your language. In Jai there might be error flags, you might be expected to check them but if you don't it won't complain because you undoubtedly know best. Pressing on regardless becomes ergonomic like in C. And so Jai certainly isn't going to do anything about how buggy software is.
- imran0 4y ago
  > Jai certainly isn't going to do anything about how buggy software is. Nothing is going to do that, except the competence of the developer.
  - tialaramex 4y ago
    That's certainly Jonathan's contention. I would argue that it's already obviously wrong.

Olreich 4y ago

He's also claimed that our computers are 2+ orders of magnitude off the productivity that should be achievable while reaching his goals. It's not so much that all software of old was amazing, it's that we really have lost something when RemeDyBG is 1000x faster than Visual Studio, with Visual Studio having hundreds of years of development effort and RemeDyBG has a couple years of development effort. His philosophy is that if we built software differently, we could build it faster and it would be faster. The emphasis on garbage collection and borrow checkers and everything else related to memory management misses the point (memory arenas are way better for the vast majority of use cases). The emphasis on Object-Oriented code is awful. The paradigm of RAII is completely counterproductive. There are very specific issues that Blow takes on, not just a general feeling of malaise.

geodel 4y ago

> The goal is always to produce things that users can actually use. And if that means doing hideously inefficient things, like running your app inside a chrome shell, so be it, if that means you delivered value faster. I guess core issue to me is this value delivered to whom. So far the value I see it is for framework users who could pull a 100K lines CRUD app in one month, of which 99% is just framework glue/code. However as end user I am getting rather bad user experience, my computer fan is running at full speed, Loading webpages or filling online forms so slow, endless error popups come and disappear and I can't do anything about it. It is not even about efficiency, just plain unreliable/unusable software delivered in name of "empowering" me. If I weren't software engineer I wouldn't even know that this crap is pulled by software engineers. Non-technical person would simply assume computer is bad/old, internet is slow and so on.

greggman3 4y ago

I very much disagree with JBlow because I came from games, I had similar opinions, and then I worked on "real software" (Chrome) and I had my thinking corrected. The problems JBlow and similar game devs are solving are not the same problems being solved elsewhere if you they really tried to solve the *same* problems I strongly believe they'd change their minds. IIRC one example he once brought up was a text editor written with a small amount of code. Yea sure, I also had a word process that fit in 16k (https://en.wikipedia.org/wiki/AtariWriter https://en.wikipedia.org/wiki/AtariWriter) but we're not on ASCII based computers with only text mode. Just a full unicode font takes 10s of megs of space. We're asking our software to draw fonts in any size, in several styles, in any language, and with emoji. That alone would break most of his assumptions because you can't just put them all in memory as pre-rendered glyphs, your user's don't have enough memory. Yet in games, most game devs would just basically say "F-that, you only get ASCII" or "F that, we're only supporting EFIGS + Katanana" and we only need 1 style. Two good articles on the issues of text that games never deal with https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/ https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/ The point being, it's the same all the way down in all areas. Game networking is not nearly as complicated as say the networking in a browser, that has to be able to run N video streams + M audio streams + X WebRTC video chats + Y Websockets, and video capture + audio capture and sending that data over the net, etc vs some game which if it ever plays video (many don't) only ever plays one video at a time, in known sizes and formats, and usually not streamed over the net but read directly from storage, etc... Or take just displaying images. Most games know up front how many images will be displayed. You might even give your artists a budget, no area of the game can use more than XX megs of image data. A browser can't run with those limits. Go look at imgur.com or scrolldit.com or pinterest. Situations games never deal with. And on top that there's just getting shit done. If I can write an app in a high-level system and ship on iOS, Android, Windows, Mac, iPadOS, I'm going to. I don't care that it's more bloated than if I hand coded assembly language for each one and neither do my customers. Sure they care if my app is buggy or the UX sucks but that's got nothing to do with whether I squeezed out every last byte and cycle out out of it. HNers like to rant about apps that use some kind of less than native framework but nearly all them are using well made apps that use those frameworks, they're just not aware of it because the people making them did a good job.

inglor_cz 4y ago

I think it is important to have at least some software as efficient as possible, especially server software, because huge data centers eat a lot of electricity and we cannot always take cheap electricity for granted. (The recent price spikes in Europe are crazy.) That said, such improvements may well be canceled out by other activities such as Bitcoin mining.

lapinot 4y ago

> But running software that fit in kilobytes of RAM was never the goal of software engineering. The goal was providing value to your users. By this definition of the goal you are indeed obviously right. So it's pretty clear that Blow and others don't agree with this goal. I'll try to map out two different povs on the goal of engineering: imho the goal you are describing, talking about "value" etc is associated with a world-view based of economic exchanges, on the idea of markets. In this world-view, engineering will have as goal to sell something to a third-party and be profitable to you, thus you will minimize your costs and do the minimum you can get away with. This is the pov of current hegemonic the economic sphere. What Blow defends, ie an engineering goal of using minimal resources for a given concrete objective, is much more in line with a world-view based on commons, on basic infrastructure for common needs. In this world, the most natural setting for doing the engineering work is not one of economic exchange, but one of cooperative, where the people that need the thing get organized somehow to get the thing done. In this setting, it is clear that the goal is not to do the minimal thing they will be ok with, the goal is to create a durable tool that will be practical to use and use minimal resources. In particular the investment (in human planning) can be very high, it doesn't really matter. This world is also close to the concepts of lowtech (basically favoring simplicity and robustness). > Yes, some users do care, and I think that a disproportionate majority of them hang out on Hacker News. :P A disproportionate majority of what? This is a classical hn fallacy: yes apparently hn likes to defend things being done "nicely" (at a good technical/resource tradeoff point) and not just "well enough" (at a short term profitable tradeoff point). But the silent majority that doesn't care you are talking about is very much restricted to the people that can afford paying for ever changing computing devices. Old people (cannot change fast), young people (get old family devices), people in less geopolitically gifted areas (less globalized purchase power), .. they all have almost obsolete technologies because they are constrained in several ways. You are talking about the majority of people that are visible to your economic world, but a lot of people are not inside of it, or on its outskirts (and if you say "but the economic sphere must be more inclusive and expand" then you are again pushing a particular view, which is not the only one and is debatable). One can also make the case that with the current state of affairs regarding fossil energy and limits to growth, going further more and more people are going to have these big constraints. This second view is very popular with people thinking seriously about ecology and crisis.

mooselaker 4y ago

I think the most steelman version is that he argues efficient software does in fact provide value to users. Whether or not they know it. And perhaps not always in terms of the application they have running right in front of them, but at a systemic or societal level. Little things add up, especially since software has eaten nearly every crumb.

JediLuke 4y ago

stephc_int13 4y ago

One of his point is that software engineering techniques did not improve at all, and even regressed, but all of that is/was hidden by the fact that hardware got us a free ride for several decades. You can use terribly slow scripting and techniques and get something working, not because the tooling is genius, but because the hardware is so incredibly fast.