5 ms·

(2018) btw. I saw this much earlier in the day and dismissed it. I just now read more of it. I was first off-put by the title, but then it goes on to say: > [

(2018) btw. I saw this much earlier in the day and dismissed it. I just now read more of it. I was first off-put by the title, but then it goes on to say: > [...] design is about everything that’s leftover after we remove all the function bodies. It worth taking a moment to think about what that looks like. Here are some of my own immediate thoughts: 1. Everything that’s left is just types. [...] Which reaffirms my suspicion that "Types!" are this writer's hammer for all of programming's nails, or possibly a click-bait writing device. There's probably a better article in here trying to get out as the end notes mention. [Maybe read them first.] But I couldn't even agree with the first one: > I meant for the main point of today’s essay to be universal: hence my emphasis that types are central to design even in dynamically typed languages. [...] I can't say I've ever considered types/signatures when sketching out a design. That comes much later in prototyping and actual implementation--I suppose if I used Haskell that might be different.

nightski 2y ago
I am skeptical. You don't even know if a relevant piece of data is say a number or text before you start writing out code? You don't think at all about how you will group data together? You don't think about the operations that will be performed on that data and how they will transform it? What do you think about when it comes to design?
- acchow 2y ago
  Location of data, policies, cross-cutting concerns, latency/performance requirements, etc. “Much later” is probably an exaggeration. You get to types “soon after” the initial design.
  - qayxc 2y ago
    Types are a useful design tool to explore the problem domain first, while the rest are details that emerge from that. Sure, if one starts with architecture, you're right. The software architect needs to consider these first. The programmer on the other hand ideally expects those as inputs. When tasked with wearing on multiple hats (architect, programmer, user), I agree with your point. From a programmer's point of view, however, (abstract) types are IMHO indeed a much more useful tool as they cover many of the other concerns (policies, performance, etc.), too.
    - acchow 2y ago
      In my experience, a software engineer wears all the hats nowadays. Even crossing into product design and user experience.
  - nightski 2y ago
    It's interesting that you think about those things without even understanding how you are going to solve the user's problem first. Aka functional requirements.
packetlost 2y ago
I find this really hard to believe to be honest. Even dealing with things as rudimentary as a file handle are really thinking about a type of some abstract thing, even if you don't really conceptualize it as such. Types are the way to put a name on that abstract classification, so in dynamically typed languages even the name of a variable or function assigns a classification to the data it holds/returns, even if it's only really enforced by the programmer. There are basically no untyped programming languages for a reason, types are a fundamental concretization. In fact, I would argue there is no such thing as untyped programming, there's just different degrees to which the programmer is the enforcer of correctness.
oh_my_goodness 2y ago
Sure, I think the author overstates his/her case and "finds the One Ring". But it's not a dumb article. "Design is everything that's leftover after we remove all the function bodies" seems like a useful perspective.
- slowmovintarget 2y ago
  Except it's not. The word "design" originated from the notion of marking out or pointing out. To do it well is to take the problem apart into small challenges that can be solved, with a plan on how to make the pieces hang together again. Design often includes algorithms, which don't devolve merely to types. So this statement only makes tangential sense if all you're ever building is CRUD applications.
boscillator 2y ago
I pretty much always start with types/signatures when sketching out a design. I guess if there is a complicated algorithm, I might start with pseudo code for it, but even then, I probably want to start with what it's inputs are and what it's outputs are.

nightski 2y ago

I am skeptical. You don't even know if a relevant piece of data is say a number or text before you start writing out code? You don't think at all about how you will group data together? You don't think about the operations that will be performed on that data and how they will transform it? What do you think about when it comes to design?

acchow 2y ago
Location of data, policies, cross-cutting concerns, latency/performance requirements, etc. “Much later” is probably an exaggeration. You get to types “soon after” the initial design.
- qayxc 2y ago
  Types are a useful design tool to explore the problem domain first, while the rest are details that emerge from that. Sure, if one starts with architecture, you're right. The software architect needs to consider these first. The programmer on the other hand ideally expects those as inputs. When tasked with wearing on multiple hats (architect, programmer, user), I agree with your point. From a programmer's point of view, however, (abstract) types are IMHO indeed a much more useful tool as they cover many of the other concerns (policies, performance, etc.), too.
  - acchow 2y ago
    In my experience, a software engineer wears all the hats nowadays. Even crossing into product design and user experience.
- nightski 2y ago
  It's interesting that you think about those things without even understanding how you are going to solve the user's problem first. Aka functional requirements.

packetlost 2y ago

I find this really hard to believe to be honest. Even dealing with things as rudimentary as a file handle are really thinking about a type of some abstract thing, even if you don't really conceptualize it as such. Types are the way to put a name on that abstract classification, so in dynamically typed languages even the name of a variable or function assigns a classification to the data it holds/returns, even if it's only really enforced by the programmer. There are basically no untyped programming languages for a reason, types are a fundamental concretization. In fact, I would argue there is no such thing as untyped programming, there's just different degrees to which the programmer is the enforcer of correctness.

oh_my_goodness 2y ago

Sure, I think the author overstates his/her case and "finds the One Ring". But it's not a dumb article. "Design is everything that's leftover after we remove all the function bodies" seems like a useful perspective.

slowmovintarget 2y ago
Except it's not. The word "design" originated from the notion of marking out or pointing out. To do it well is to take the problem apart into small challenges that can be solved, with a plan on how to make the pieces hang together again. Design often includes algorithms, which don't devolve merely to types. So this statement only makes tangential sense if all you're ever building is CRUD applications.

boscillator 2y ago

I pretty much always start with types/signatures when sketching out a design. I guess if there is a complicated algorithm, I might start with pseudo code for it, but even then, I probably want to start with what it's inputs are and what it's outputs are.