4 ms·

Maybe this is a terrible stance but if the idea pisses off Jonathan Blow and Casey Muratori, I wouldn't take that as a bad sign. jblow and Casey are brilliant p

Maybe this is a terrible stance but if the idea pisses off Jonathan Blow and Casey Muratori, I wouldn't take that as a bad sign. jblow and Casey are brilliant programmers and I mean them no disrespect, but their philosophies are certainly in the vein of prescriptive, "correct" ways of writing code. Namely you should write code that is fast and efficient. Unfortunately (or not, depends on your view), programmers do not like prescriptive, "correct" ways of writing code. Worse is better and all. If you give them a cheat code to let them use a little more performance, give them a little more headroom, they'll take it. For all the jblows and muratori's in the world, there's a lot more people who don't care about perf and just want to make cool stuff. For better or worse.

stephc_int13 5y ago
This is related to programmers tribes. Casey and Jon and from the engineering tribe. The cool stuff tribe is what I call the business oriented tribe. But I think you're missing the point. The technical merits of Mighty is a secondary problem.
- hardwaregeek 5y ago
  Could you expand on what I'm missing? I'd love to hear your analysis (not sarcastic, would love to hear other people's thoughts)
  - throwaway17_17 5y ago
    Obviously not the parent commenter, but I’ll give this a shot. I think that Jon and Casey’s (and those of like mind) are not commenting on Mighty as a piece of individual tech, but commenting on the fact that Mighty as a product could even be in a position to exist. I am most likely to phrase the general position (which I think Jon and Casey would support) put forth as follows: the problem a service like Mighty is trying to solve ONLY exists because the standards and practices of modern software development is fundamentally broken. You even touch on this in your GP post about devs taking the shortcuts to ‘making something cool’. As the parent post calls it, the cool stuff tribe are those developers who will use available cheat code because they expect that doing so is acceptable. Your GP post seems to try and counter the Jon and Casey position by saying that because developers just want to make things that they will and there is no concern for any impacts these accumulating decisions may have. I think the ‘you’re missing the point’ comment derives from here. You seem to be saying that Jon and Casey’s position is not palatable to devs because those devs are not concerned with performance and don’t like to be told to consider such aspects of the things they make. But, J&C’s point is that if the standards for developing software were not so broken then the position of the cheat code using devs would be uniformly decried as substandard and unacceptable. In a world where development standards were in line with J&C’s views Mighty would not be in a position to be a viable product because using the web via a native browser accessing properly developed web content would be a pain free and perform any experience.
throwkeep 5y ago
"For all the jblows and muratori's in the world, there's a lot more people who don't care about perf and just want to make cool stuff. For better or worse." And that it's mostly people who don't care about this on deeper level are why we have such a bloated ecosystem. Layers of bad code stacked on layers of bad code. If there were more jblows and muratori's in the world, Mighty would have no reason to exist. The web would already be performant. That PaulG is bullish on Mighty strikes me as a pessimistic view and a bet that the underlying problem won't be solved.
- hardwaregeek 5y ago
  Yeah I mean I'm not saying it's a good thing that Mighty exists or that it might succeed. I'm just saying that we shouldn't take pithy Twitter replies as evidence it'll fail.
arduinomancer 5y ago
> Namely you should write code that is fast and efficient I don't think this is accurate. I watched a talk with Jonathan Blow recently and he went on for quite a while railing against premature optimization. https://youtu.be/JjDsP5n2kSM?t=561 https://youtu.be/JjDsP5n2kSM?t=561
- jecel 5y ago
  Premature optimization makes it harder to write fast and efficient code. That is because you guessed where the bottlenecks would be before you had enough information (which is why it was "premature"). The optimizations make the code more brittle and hard to change so that when you reach a position to measure where the bottlenecks are it is too complicated to do the proper optimizations.

stephc_int13 5y ago

This is related to programmers tribes. Casey and Jon and from the engineering tribe. The cool stuff tribe is what I call the business oriented tribe. But I think you're missing the point. The technical merits of Mighty is a secondary problem.

hardwaregeek 5y ago
Could you expand on what I'm missing? I'd love to hear your analysis (not sarcastic, would love to hear other people's thoughts)
- throwaway17_17 5y ago
  Obviously not the parent commenter, but I’ll give this a shot. I think that Jon and Casey’s (and those of like mind) are not commenting on Mighty as a piece of individual tech, but commenting on the fact that Mighty as a product could even be in a position to exist. I am most likely to phrase the general position (which I think Jon and Casey would support) put forth as follows: the problem a service like Mighty is trying to solve ONLY exists because the standards and practices of modern software development is fundamentally broken. You even touch on this in your GP post about devs taking the shortcuts to ‘making something cool’. As the parent post calls it, the cool stuff tribe are those developers who will use available cheat code because they expect that doing so is acceptable. Your GP post seems to try and counter the Jon and Casey position by saying that because developers just want to make things that they will and there is no concern for any impacts these accumulating decisions may have. I think the ‘you’re missing the point’ comment derives from here. You seem to be saying that Jon and Casey’s position is not palatable to devs because those devs are not concerned with performance and don’t like to be told to consider such aspects of the things they make. But, J&C’s point is that if the standards for developing software were not so broken then the position of the cheat code using devs would be uniformly decried as substandard and unacceptable. In a world where development standards were in line with J&C’s views Mighty would not be in a position to be a viable product because using the web via a native browser accessing properly developed web content would be a pain free and perform any experience.

throwkeep 5y ago

"For all the jblows and muratori's in the world, there's a lot more people who don't care about perf and just want to make cool stuff. For better or worse." And that it's mostly people who don't care about this on deeper level are why we have such a bloated ecosystem. Layers of bad code stacked on layers of bad code. If there were more jblows and muratori's in the world, Mighty would have no reason to exist. The web would already be performant. That PaulG is bullish on Mighty strikes me as a pessimistic view and a bet that the underlying problem won't be solved.

hardwaregeek 5y ago
Yeah I mean I'm not saying it's a good thing that Mighty exists or that it might succeed. I'm just saying that we shouldn't take pithy Twitter replies as evidence it'll fail.

arduinomancer 5y ago

> Namely you should write code that is fast and efficient I don't think this is accurate. I watched a talk with Jonathan Blow recently and he went on for quite a while railing against premature optimization. https://youtu.be/JjDsP5n2kSM?t=561 https://youtu.be/JjDsP5n2kSM?t=561

jecel 5y ago
Premature optimization makes it harder to write fast and efficient code. That is because you guessed where the bottlenecks would be before you had enough information (which is why it was "premature"). The optimizations make the code more brittle and hard to change so that when you reach a position to measure where the bottlenecks are it is too complicated to do the proper optimizations.