5 ms·

Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That’s the least of my problems. I

Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That’s the least of my problems. I don’t write a big mess of code, I’m constantly working iteratively on a small piece of code to make it perfect. Usually first pass is to make it perfect, then I refactor it right away to make it readable. I work that way, function by function. I never have the class of bugs in my projects that people seem to laud about typing to solve. It’s kind of ridiculous to me and cumbersome and makes certain dynamic programming concepts difficult or impossible. I don’t want to give up power just because other developers are sloppy. I want my code to be readable, and succinct. A lot of times that requires creating functions dynamically at runtime or some other such thing that would void the benefits of a typing system anyways. I recognize that in working with a team where people have other styles, varying attention to detail levels and skill, they can’t all be trusted to produce bug-free code without the constant nagging and overhead of a pedantic type system. My solution is not to employ another piece of technology to solve this problem, rather it’s just not to work with those people. If you can’t write dynamic code without a bunch of type errors at runtime, learn to be a better programmer first before blaming the tools.

hnarn 6y ago
> Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That sounds fine, as long as no-one else will ever have to read or work on your code.
- Narishma 6y ago
  Including future you.
andrewvc 6y ago
Do you work on small or large code bases? On truly large projects you often find yourself making changes without that level of deep understanding. On these projects you often find yourself needing to work on higher levels of abstraction. Types help here by instantly telling you what the data is and providing hints. Types take extra time to write and maintain, but they significantly reduce the difficulty of working on large projects.
eropple 6y ago
> Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. How many times has six-months-hence you cursed you for this attitude? Be honest.
- emidln 6y ago
  Never. This is why we write small functions that, as much as possible, depend only on their inputs and avoid mutation. Code becomes simple to reason about. You don't need to worry when composing these small pieces like you do when passing mutable objects, using out variables, etc.
  - eropple 6y ago
    See, that's interesting. 'Cause I do write small functions, I do avoid side effects, I do avoid mutation--and writing code in dynamically typed languages still bites me when I'm forced to do it. (It isn't really any faster to write, either.) So you could be leaps and bounds better than me. Or you could be--let's be generous and call it "optimistic to a fault"--and retrofitting to a narrative about Good Programmers Don't Need Guardrails. And, TBH, I see a lot of people who are the latter and very few who are the former--and most of that very few tend towards statically or at least optionally typed languages by default. So forgive me if I don't believe you.
    - ronanyeah 6y ago
      Anything to justify not learning a new language.
  - jimnotgym 6y ago
    An experienced developer I know with a dead simple function fell for the classic 10+20+30=102030 bug the other day. Had it not been noticed in production it would have been very costly. It was an edge case he had not encountered in the wild, but had thought to handle just-in-case. Integration tests missed it too. Sure, good unit tests could have caught it, but Typescript would not have allowed it in the first place.
stefankorun 6y ago
What a pretentious comment, everyone makes mistakes and everyone can write a big mess of a code eventually. The benefit of typesafety is how easy we can spot that and recover / rewrite when needed.
spyke112 6y ago
You must be one of those 10x developers. Good for you.
heavyset_go 6y ago
> Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. Will you in two years? Will your coworkers? Will the contractor who has no context for the code understand it? Like variable names, types convey information that are crucial to the understanding of your application. Under the hood, there are "types", even if they are weak, so you'll need to know about implicit typing anyway. Making them explicit is both a way to test correctness and a way to document your code.
siscia 6y ago
> Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. Can you say the same about all your dependencies?
yawaramin 6y ago
'Forgive me, but when I program I know what memory I allocated, whether they are accessed within their proper bounds, and whether they are all deallocated properly.' Meanwhile: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... 'Percentage of memory safety issues has been hovering at 70 percent for the past 12 years.' And this is not just Microsoft–it's a pretty consistent finding across industry, that when programming in C/C++, memory safety issues make up around 65% to 70% of all issues. What this tells us is that people in general can't guarantee the safety of their code, but an automated checker can.
kingdomcome50 6y ago
I suppose you are also going to tell us that after you’ve fitted all of those perfect functions together into that perfect program, the requirements have never changed. And I suppose when those requirements never changed you never had to rewrite lots of these perfect functions or resort to “append only” programming in order to make sure regression was impossible instead of making large changes in place. Forgive me, but it’s clear you have never worked on a program of any consequence, so it’s hard to read your comment and do anything but wish you the best while also completely ignoring its content.
- hombre_fatal 6y ago
  In these discussions I basically see people try to fool other experienced craftspeople about the reality and core axioms of the craft. The idea of ascending as a developer to a point where you don't need guardrails and never have to refactor code is just not going to convinced experienced developers. It's clear bullshit. It's like trying to convince experienced motorcyclists that you don't need a helmet because you're quite the driver. It's just defensive driving, people! That the helmet is some sort of crutch you've transcended, and maybe if everyone had a bit more skill -- like yourself -- they'd understand. Yet it always seems to be half of the dynamically- vs statically-typed language debate.
zamalek 6y ago
The line of perfect and infallible humans began with you, and will one day end with you. The rest of us need a bit of help to smooth over our human faults. The only perfect decision I made is to accept that I make imperfect decisions, I wish I could attain the consistent perfection that you describe here.
cultofmetatron 6y ago
Maybe you are one of those 10x programmers who can magically keep track of all the type data in your head and always catch yourself before you push to prod. I and most people however are human and make mistakes sometimes. Worse, the bigger the project, the more you need to collaborate between people and sometimes teams. Types are almost like docs that check your code at compile time and reduce the chances of human error creating a production failure. Its not a panacea but its certainly nice to know that if I change a functions parameter, that the system breaks someone else's code depends on that function following a certain signature. At that point, I can either write a different function, message him to update his code or discuss how to make the changes together. All 3 cases are MASSIVE upgrades over fiding out shit broke in prod with some undefined behavior arising.

hnarn 6y ago

> Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That sounds fine, as long as no-one else will ever have to read or work on your code.

Narishma 6y ago
Including future you.

andrewvc 6y ago

Do you work on small or large code bases? On truly large projects you often find yourself making changes without that level of deep understanding. On these projects you often find yourself needing to work on higher levels of abstraction. Types help here by instantly telling you what the data is and providing hints. Types take extra time to write and maintain, but they significantly reduce the difficulty of working on large projects.

eropple 6y ago

> Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. How many times has six-months-hence you cursed you for this attitude? Be honest.

emidln 6y ago
Never. This is why we write small functions that, as much as possible, depend only on their inputs and avoid mutation. Code becomes simple to reason about. You don't need to worry when composing these small pieces like you do when passing mutable objects, using out variables, etc.
- eropple 6y ago
  See, that's interesting. 'Cause I do write small functions, I do avoid side effects, I do avoid mutation--and writing code in dynamically typed languages still bites me when I'm forced to do it. (It isn't really any faster to write, either.) So you could be leaps and bounds better than me. Or you could be--let's be generous and call it "optimistic to a fault"--and retrofitting to a narrative about Good Programmers Don't Need Guardrails. And, TBH, I see a lot of people who are the latter and very few who are the former--and most of that very few tend towards statically or at least optionally typed languages by default. So forgive me if I don't believe you.
  - ronanyeah 6y ago
    Anything to justify not learning a new language.
- jimnotgym 6y ago
  An experienced developer I know with a dead simple function fell for the classic 10+20+30=102030 bug the other day. Had it not been noticed in production it would have been very costly. It was an edge case he had not encountered in the wild, but had thought to handle just-in-case. Integration tests missed it too. Sure, good unit tests could have caught it, but Typescript would not have allowed it in the first place.

stefankorun 6y ago

What a pretentious comment, everyone makes mistakes and everyone can write a big mess of a code eventually. The benefit of typesafety is how easy we can spot that and recover / rewrite when needed.

spyke112 6y ago

You must be one of those 10x developers. Good for you.

heavyset_go 6y ago

> Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. Will you in two years? Will your coworkers? Will the contractor who has no context for the code understand it? Like variable names, types convey information that are crucial to the understanding of your application. Under the hood, there are "types", even if they are weak, so you'll need to know about implicit typing anyway. Making them explicit is both a way to test correctness and a way to document your code.

siscia 6y ago

> Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. Can you say the same about all your dependencies?

yawaramin 6y ago

'Forgive me, but when I program I know what memory I allocated, whether they are accessed within their proper bounds, and whether they are all deallocated properly.' Meanwhile: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... 'Percentage of memory safety issues has been hovering at 70 percent for the past 12 years.' And this is not just Microsoft–it's a pretty consistent finding across industry, that when programming in C/C++, memory safety issues make up around 65% to 70% of all issues. What this tells us is that people in general can't guarantee the safety of their code, but an automated checker can.

kingdomcome50 6y ago

I suppose you are also going to tell us that after you’ve fitted all of those perfect functions together into that perfect program, the requirements have never changed. And I suppose when those requirements never changed you never had to rewrite lots of these perfect functions or resort to “append only” programming in order to make sure regression was impossible instead of making large changes in place. Forgive me, but it’s clear you have never worked on a program of any consequence, so it’s hard to read your comment and do anything but wish you the best while also completely ignoring its content.

hombre_fatal 6y ago
In these discussions I basically see people try to fool other experienced craftspeople about the reality and core axioms of the craft. The idea of ascending as a developer to a point where you don't need guardrails and never have to refactor code is just not going to convinced experienced developers. It's clear bullshit. It's like trying to convince experienced motorcyclists that you don't need a helmet because you're quite the driver. It's just defensive driving, people! That the helmet is some sort of crutch you've transcended, and maybe if everyone had a bit more skill -- like yourself -- they'd understand. Yet it always seems to be half of the dynamically- vs statically-typed language debate.

zamalek 6y ago

The line of perfect and infallible humans began with you, and will one day end with you. The rest of us need a bit of help to smooth over our human faults. The only perfect decision I made is to accept that I make imperfect decisions, I wish I could attain the consistent perfection that you describe here.

cultofmetatron 6y ago

Maybe you are one of those 10x programmers who can magically keep track of all the type data in your head and always catch yourself before you push to prod. I and most people however are human and make mistakes sometimes. Worse, the bigger the project, the more you need to collaborate between people and sometimes teams. Types are almost like docs that check your code at compile time and reduce the chances of human error creating a production failure. Its not a panacea but its certainly nice to know that if I change a functions parameter, that the system breaks someone else's code depends on that function following a certain signature. At that point, I can either write a different function, message him to update his code or discuss how to make the changes together. All 3 cases are MASSIVE upgrades over fiding out shit broke in prod with some undefined behavior arising.