No post body was provided.
The Only Unbreakable Law [video]
41–50 of 107 posts
Re: The Only Unbreakable Law [video]
#42A law that doesn't make predictions isn't a law. A law that is not falsifiable isn't a law. It is an unscientific belief. It's truly incredible to me that people, like the person in this video, can speak with such confidence about how, for example from this video, "if we look at an org chart for an organization, and we look at the structure of the products that it produces, we would expect them to basically just be c…
No post body was provided.
Re: The Only Unbreakable Law [video]
#43I’m fairly conflicted by this, because it’s fairly insightful, but it’s also probably overselling itself. They expound quite hard on the idea that abstraction is inherently bad, and I feel this is a poor choice of words, and perhaps a mistake. Abstractions have cost . In many forms, and especially if the abstraction is a poor one. However… they don’t seem to differentiate between good and bad abstractions. They seem…
> They seem to regard all abstraction as simply unnecessary...
I would be surprised if the video author agreed with this statement. My understanding of his point is something more general and almost trivially true, i.e. a given set of abstractions can't solve problems the same way as a different set of abstractions. The strong version is a Venn diagram
┌──────────────────────────────┐
│ │
│ Implementations expressable │
│ by abstraction set A │
│ │
│ ┌──────────────────────┼───────┐
│ │ │ │
│ │ Implementations │ │
│ │ expressable by both │ │
│ │ │ │
└───────┼──────────────────────┘ │
│ Implementations expressable │
│ by abstraction set B │
│ │
└──────────────────────────────┘
Said another way, abstractions cut down the space of possible solutions.
Cutting down the space definitely has large upsides. If you're trying to build a nuclear plant, we probably want to weed out the cake-baking solutions. For especially large and complex problems with horrendously large solutions spaces, abstractions function as a way of compartmentalizing some of that solution space into manageable sub-problems. However, maybe there is a better set of sub-problems?
After a year hammering on some software development project, you probably have a much clearer idea of the problem's nuances than when first starting. Wouldn't it be great if we could perform low-cost rewrites? If you can hold the entire source code in your head and cognate about it, that's probably even possible. Could any one human hold all of Firefox in their head?
One point from the video stands out to me: abstractions might just be a necessary evil. They are effective tools for helping humans cognate about complex problems, which involves limiting our ability to cognate about potential solutions.
Anyway, I am reminded of the surprising solutions found by genetic algorithms and their ilk.
Re: The Only Unbreakable Law [video]
#44Even more depressing than "The 20 million lines problem" - because the gist of the talk is that programming with more than one person is doomed to fail, and programming with less than two is even worse.
No post body was provided.
Re: The Only Unbreakable Law [video]
#45Earlier quoted context omitted.
I've found him passionate and smart. But rarely right. Like him bashing SOLID principles. It read like a man arguing against hammers, and instead suggesting using drills (which is fine if you need to drill a hole but bad advice if you want to hammer a nail). Like yeah, SOLID is over used and over-stated, but they were invented to stop certain set of problems.
With both Casey and Jon Blow I find that if I mentally prefix what they say with "When developing AAA games..." then they are almost always right. Much of it doesn't transfer far outside that domain.
What are you talking about? Neither one of them has ever shipped a AAA game.
Re: The Only Unbreakable Law [video]
#46I’m fairly conflicted by this, because it’s fairly insightful, but it’s also probably overselling itself. They expound quite hard on the idea that abstraction is inherently bad, and I feel this is a poor choice of words, and perhaps a mistake. Abstractions have cost . In many forms, and especially if the abstraction is a poor one. However… they don’t seem to differentiate between good and bad abstractions. They seem…
> They seem to regard all abstraction as simply unnecessary... I would be surprised if the video author agreed with this statement. My understanding of his point is something more general and almost trivially true, i.e. a given set of abstractions can't solve problems the same way as a different set of abstractions. The strong version is a Venn diagram ┌──────────────────────────────┐ │ │ │ Implementations expressabl…
No post body was provided.
Re: The Only Unbreakable Law [video]
#47Quoted post unavailable.
> You can safely ignore this guy.
Thanks for telling us this. We might have thought for ourselves based on the content, but now we don't need to.
Re: The Only Unbreakable Law [video]
#48Quoted post unavailable.
No post body was provided.
Re: The Only Unbreakable Law [video]
#49What is this clickbait garbage?
Re: The Only Unbreakable Law [video]
#50Having watched Casey's Handmade Hero series since day-1, I've always found him to be highly skilled and insightful. While not a game developer myself, learning from his approach to first-principles software development and code optimization has paid dividends in my day to day work nonetheless.
I've found him passionate and smart. But rarely right. Like him bashing SOLID principles. It read like a man arguing against hammers, and instead suggesting using drills (which is fine if you need to drill a hole but bad advice if you want to hammer a nail). Like yeah, SOLID is over used and over-stated, but they were invented to stop certain set of problems.
The most bizarre part is that he took issue which the Liskov substitution principle which is just the intuitive definition of what semantic subtyping means. This isn't some crazy clean code "functions should have less than 20 lines" dogma, subtyping without semantic subtyping is just nonsensical.