6 ms·

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 t

by 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.
kelnos 4y ago
Sure, but... so what? The market has -- unfortunately -- shown us that it's better to put an inefficient, perpetually-buggy product in front of users, than it is to wait until you've micro-optimized everything and fixed most of the bugs. The exact same argument we can use to describe why inefficient software tends to win can be used to describe why buggy software tends to win. Of course users hate bugs. But even more they hate not having software to solve their problems. Hands down I would choose to have something with bugs today, than wait for something bug-free 6 or 12 months from now. And unfortunately, once you put something with bugs in front of users, you're going to be pushed to work on new features for the next version, rather than fixing the bugs of the previous version. But arguably that's irrelevant! Users would rather have those future new features in 3 months, over having all their bugs fixed in 6 months, and then getting those new features in 12 months. It still feels incredibly annoying and lame to me that this is the state of things. And I think that's why people like Jonathan Blow (and many, many others) just don't get it. Working software in users' hands trumps everything else. It almost doesn't matter how inefficient or buggy or $OTHER_NEGATIVE_TRAIT it is. If it solves unsolved problems, then it wins. [Yes, I know, there are limits to what users will tolerate. But most inefficient, buggy software doesn't hit those limits too often. Software that does... well, yep, they tend to fail. But they're quickly replaced by other inefficient, buggy software that users will tolerate. They're not replaced by super-efficient, nearly-bug-free software, because building that software will always take much longer than building the software that users will tolerate. And users want to get shit done, not wait around while you tell them how much better the efficient, nearly-bug-free software will be.
- iamwil 4y ago
  I agree that one major contributor to these problems that he doesn't (fully) address in the talk are the unit economics and market forces that help along these decisions. He does allude to it about faster software (slow being equated with buggy), and I think there are market indications that for specific markets, fast (efficient software) does win--though it is the exception seemingly, rather than the rule. The rule seems to be quick-to-market software wins. However, I think his point has a wider scope, and I don't think it's irrelevant. Yes, in the short term, market forces push us to put software in front of people quickly, even if it's buggy. But is that beneficial in the long term? What would be the consequences of making short term optimal choices here? Would we (as a society) forget how to build the things we rely upon in our society because the complexity is too overwhelming, and at every step, we never went back to clean things up and focus on transferring inter-generational knowledge, because we were too busy putting out features? Just like in the Innovator's Dilemma, the incumbent at every step makes the optimal decision, but ends up getting trounced because a series of local optimized choices is not a globally optimized choice. And Blow here is saying (strongly), that we're doing something similar with how we build software. And I'm inclined to agree with him, even though I fully recognize the market forces as being strong. Would we keep making short-term optimal choices because we have no choice? Or is there a way out? Alan Kay has talked about this in some of his talks. He has some neat ideas, wrapped up in unintelligible slides. I've always thought he needs a graphic designer for his slides. Anyway, his thesis is that we build software today much like how Egyptians built buildings: stacking things wide in order to build high--evident by code bases millions of lines long. We have very few equivalent of arches in software. Once we had arches, we could build higher with less materials. So perhaps there's a way out. We've been searching for it for a long time (in software years, but we're still a young field), ever since before the Mythical Man Month. And Blow, I think, is saying, there are real consequences to this software mess we find ourselves in, the worst of which is the collapse of civ itself, esp if we don't find a way to reign in the complexity and the bugginess. Or we can pray for AGI to get done and do it all for us. finger guns

by iamwil 4y ago

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.

kelnos 4y ago

Sure, but... so what? The market has -- unfortunately -- shown us that it's better to put an inefficient, perpetually-buggy product in front of users, than it is to wait until you've micro-optimized everything and fixed most of the bugs. The exact same argument we can use to describe why inefficient software tends to win can be used to describe why buggy software tends to win. Of course users hate bugs. But even more they hate not having software to solve their problems. Hands down I would choose to have something with bugs today, than wait for something bug-free 6 or 12 months from now. And unfortunately, once you put something with bugs in front of users, you're going to be pushed to work on new features for the next version, rather than fixing the bugs of the previous version. But arguably that's irrelevant! Users would rather have those future new features in 3 months, over having all their bugs fixed in 6 months, and then getting those new features in 12 months. It still feels incredibly annoying and lame to me that this is the state of things. And I think that's why people like Jonathan Blow (and many, many others) just don't get it. Working software in users' hands trumps everything else. It almost doesn't matter how inefficient or buggy or $OTHER_NEGATIVE_TRAIT it is. If it solves unsolved problems, then it wins. [Yes, I know, there are limits to what users will tolerate. But most inefficient, buggy software doesn't hit those limits too often. Software that does... well, yep, they tend to fail. But they're quickly replaced by other inefficient, buggy software that users will tolerate. They're not replaced by super-efficient, nearly-bug-free software, because building that software will always take much longer than building the software that users will tolerate. And users want to get shit done, not wait around while you tell them how much better the efficient, nearly-bug-free software will be.

iamwil 4y ago
I agree that one major contributor to these problems that he doesn't (fully) address in the talk are the unit economics and market forces that help along these decisions. He does allude to it about faster software (slow being equated with buggy), and I think there are market indications that for specific markets, fast (efficient software) does win--though it is the exception seemingly, rather than the rule. The rule seems to be quick-to-market software wins. However, I think his point has a wider scope, and I don't think it's irrelevant. Yes, in the short term, market forces push us to put software in front of people quickly, even if it's buggy. But is that beneficial in the long term? What would be the consequences of making short term optimal choices here? Would we (as a society) forget how to build the things we rely upon in our society because the complexity is too overwhelming, and at every step, we never went back to clean things up and focus on transferring inter-generational knowledge, because we were too busy putting out features? Just like in the Innovator's Dilemma, the incumbent at every step makes the optimal decision, but ends up getting trounced because a series of local optimized choices is not a globally optimized choice. And Blow here is saying (strongly), that we're doing something similar with how we build software. And I'm inclined to agree with him, even though I fully recognize the market forces as being strong. Would we keep making short-term optimal choices because we have no choice? Or is there a way out? Alan Kay has talked about this in some of his talks. He has some neat ideas, wrapped up in unintelligible slides. I've always thought he needs a graphic designer for his slides. Anyway, his thesis is that we build software today much like how Egyptians built buildings: stacking things wide in order to build high--evident by code bases millions of lines long. We have very few equivalent of arches in software. Once we had arches, we could build higher with less materials. So perhaps there's a way out. We've been searching for it for a long time (in software years, but we're still a young field), ever since before the Mythical Man Month. And Blow, I think, is saying, there are real consequences to this software mess we find ourselves in, the worst of which is the collapse of civ itself, esp if we don't find a way to reign in the complexity and the bugginess. Or we can pray for AGI to get done and do it all for us. finger guns