Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Only Unbreakable Law [video]

youtube.com

Post reply on HN
Print view View original

61–70 of 107 posts

Re: The Only Unbreakable Law [video]

#61

Post by belugacat »

erikerikson wrote: post #58
lliamander wrote: post #53

Earlier quoted context omitted.

I agree with you general about the point of the article and the validity of Conway's Law, but I have a quibble: > Like many have said in the past, computer science is not really “science” or even engineering. Computer Science is absolutely science, as much as physics is. Science is the ability to make precise predictive models of the world using math. Computer Science provides plenty of those. For example, by knowing…

Outside of the U.S.A. (notably in the U.K.) the computer science department is known as the informatics department. This makes the larger claim that the field's interest is information theory. Consider the information theoretic guarantees of total order broadcast and it's equivalence to consensus. Consider also the relationships between automata and languages, computational complexity theory, the relational calculus.…

This is kind of getting into weird semantics.

For what it’s worth I hold a BSc from a large, reputable UK university in computer science, not informatics, so it’s not as universal as you suggest.

I do also hold an undergraduate degree from a French university in informatique, a contraction of “information automatique”. Both words are equally important in the name of that discipline, and the “automatique” part is very much about process.

But we are debating the map here, not the territory.

Re: The Only Unbreakable Law [video]

#62

Post by andrelaszlo »

brown wrote: post #15

Nice video. Conway's 1968 paper is a good find. The conclusion is slightly defeatist, but ultimately correct. At time 49:23, Casey says "But we have to do them right now, because we haven't figured out how to do it better." [excessive modularity] is the worst form of [software development] – except for all the others that have been tried.

Perhaps it's a desperate attempt to defer the problem of what the organization should look like. The more nodes you have in your graph, the easier it will be to collapse it into something that maps to the organization you want?

Re: The Only Unbreakable Law [video]

#63

Post by hahamrfunnyguy »

Ygg2 wrote: post #16
0xbadc0de5 wrote: post #3

Having 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.

I would say it's more like a builder arguing against building codes. A high-quality building can certain be built without them, but sticking to some known formulas makes sure that everyone working on it is able to anticipate what others are going to do. It also makes sure that the building won't collapse, though this aspect doesn't really apply to software.

Software has gotten a lot more complicated since the 1990's and from my experience, projects where design patterns are used effectively run a lot more smoothly than those where they're not used or not used effectively. It's great when you can open a project from 15 years ago and say "Actually, the code isn't too bad!" because the developers followed some rules of thumb.

I agree with Casey that these rules of thumb aren't going to lead to higher-quality software from the end user's perspective. I doubt that they're going to make it worse though, unless they're blindly followed.

Re: The Only Unbreakable Law [video]

#65

Post by galangalalgol »

andrelaszlo wrote: post #62
brown wrote: post #15

Nice video. Conway's 1968 paper is a good find. The conclusion is slightly defeatist, but ultimately correct. At time 49:23, Casey says "But we have to do them right now, because we haven't figured out how to do it better." [excessive modularity] is the worst form of [software development] – except for all the others that have been tried.

Perhaps it's a desperate attempt to defer the problem of what the organization should look like. The more nodes you have in your graph, the easier it will be to collapse it into something that maps to the organization you want?

Sometimes it feels like a desperate attempt to defer working on some part of the problem a team doesn't know how to solve. Usually some domain specific thing no one wants to think about. So onion layers get put in wrapped around that bit without actually solving it, just creating an abstraction by which the rest of the system will use the "magic". But often the abstraction overconstrains the domain specific magic through ignorance, so it all has to change when someone gets around to adding it. Seen this over and over.

Re: The Only Unbreakable Law [video]

#66

Post by krapp »

hahamrfunnyguy wrote: post #63
Ygg2 wrote: post #16

Earlier 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.

I would say it's more like a builder arguing against building codes. A high-quality building can certain be built without them, but sticking to some known formulas makes sure that everyone working on it is able to anticipate what others are going to do. It also makes sure that the building won't collapse, though this aspect doesn't really apply to software. Software has gotten a lot more complicated since the 1990's…

On the other hand, Casey's been working on Handmade Hero for almost a decade, and has what amounts to an overengineered debug room with less actual gameplay complexity than you'd find in any framework tutorial. Meanwhile actual game developers would pick up a framework, use all those abstractions and libraries Casey finds unnecessary and surpass Handmade Hero in an afternoon.

There's something to be said for not wasting time on things that don't matter to anyone but yourself, and code aesthetics is often one of those things.

Re: The Only Unbreakable Law [video]

#69

Post by Dudeman112 »

ukj wrote: post #54
Dudeman112 wrote: post #51

Earlier quoted context omitted.

And that's how you know someone got way too drunk on other people's ruminations without first hand experience. Of course scientists care about their models being close to/matching reality. Have you ever spent any amount of time in an university's lab? Approximately everyone I've met in my alma mater cared about their models being close to reality (or as truthy as they can be).

And that’s how you know somebody has only second-hand experience of science - having never reflected upon, or examined the (very human) limits of the knowledge they have been given by others. What scientific procedure would you use to establish whether one working scientific model “matches” reality; while another working model doesn’t? Nobody has direct access to reality outside of their own theoretical paradigm of u…

>What scientific procedure would you use to establish whether one working scientific model “matches” reality; while another working model doesn’t?

See what model1 gives as a prediction for input X. See what model2 gives as a prediction for input X.

Input X in the world and compare what actually happened.

The models that more closely predict the observations are more likely to reflect reality (aka being closer to the truth).

You don't have direct access to reality. And yet if someone thinks F = ma isn't closer to the truth than F = ma^4 (for the usual symbols and approximations and blah blah, assume I'm aware Einstein existed) then they got way too drunk on other people's philosophies.

Most scientists I met and worked with care if their models are close to reality/truth. Epistemological uncertainty does not mean every model is equally untruthful.

Re: The Only Unbreakable Law [video]

#70

Post by 3np »

Ygg2 wrote: post #16
0xbadc0de5 wrote: post #3

Having 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.

I have no opinion on them as this is the first time I see them but their misrepresentation of Amdahl's law bothered me as their version makes it incorrect to the point of being useless. Here's how they present it:

  T(n) = b + (T(1)-b)/n

  T(n): Time to run task for n parallel threads (workers)
  b: Time it takes to run part of task that can not be parallelized

  Therefore:

  T(inf) = b
This misses the cost of coordinating between workers. It also removes the key part of it being a theoretical limit of the speedup as resources increase.

Their attempt to simplify it makes the new version dangerously wrong if you take their word for it.

Less wrong:

  T(n) >= b + (T(1)-b)/n
Or even (but now it's not really Amdahl's again):

  T(n) >= b + (T(1)-b)/n + C(n)
In fact, for many problems T(n) > T(n-1) for some n, as at some point C(n) > (T(1)-b)/n

This is not really "a more subtle improvement", "new version", or "refinement". It was known in the field in the 70s. That is, Brook's Law can apply to parallelized computation, not just to teamwork. Which OP observes but still doesn't make them see the errors in their previous assertion.

Post reply on HN