5 ms·

But what practical problem is such a scheme actually solving? If I write response["headre"] = ... I have a bug, sure, but an obvious bug that will be fix

by EpicEng 13y ago

But what practical problem is such a scheme actually solving? If I write response["headre"] = ... I have a bug, sure, but an obvious bug that will be fixed very quickly. With this type system I am now limited in an annoying way. I don't get it.

pcwalton 13y ago
> I have a bug, sure, but an obvious bug that will be fixed very quickly. People say the same thing about null pointer exceptions, but null pointer exceptions are a huge problem in practice. Every bug is "obvious" in retrospect.
- EpicEng 13y ago
  No, this is not the same as a null pointer. Null pointers are typically much more sneaky, this line means the header will not be written and the error is right in your face. I do understand the desire to prevent these sorts of errors at the language level, but not at the cost of functionality. I don't agree with this one, but I do (for example) appreciate libraries such as the STL which (hopefully) prevent that pointer issue you brought up (and more). The STL doesn't (often) force me to work around silly limitations though. Does this library provide for creating arbitrary headers in some other fashion? If not, why?
asdf1234 13y ago
And yet bugs like this make it into production systems all the time. Several Rails security bugs have been almost as trivial and just as avoidable.
peq 13y ago
For me, a big benefit is the tooling support. If the API is statically typed, I can easily find the headers I am able to set using my IDE. And for setting the date I don't have to check the http spec for which syntax I have to use for the date.
- EpicEng 13y ago
  That's not a bad point, I'm just not sure I am willing to give up functionality for tooling. The end goal here is a program that people can use to get things done, not awesome IDE integration.
asdasf 13y ago
>I have a bug, sure, but an obvious bug that will be fixed very quickly I love that there are people who say things like this totally seriously.
- EpicEng 13y ago
  I'm not sure what you've done to make you feel like being condescending is something you have earned, but please feel free to share your body of work. I've worked on very large, complex, mission critical systems my entire career. Medical devices mostly. If you're not catching these sorts of errors early then you aren't modeling and testing your software correctly (or at all). All of the objects in the world aren't going to prevent you from writing bugs and crappy code. OO is no panacea and we've known that for quite some time now. I don't want to use a library which is limiting because it thinks it is doing me a favor.
  - asdasf 13y ago
    What an odd response. I haven't done any OO programming in nearly a decade, and I would not consider doing it ever again. I don't know where you got the idea that OO has anything to do with this. I do catch these sorts of errors early on, because they are type errors, and thus the compiler catches them. That is very much the point. The fact that you think you are infallible and can write 100% perfect test coverage, while thinking I am being condescending is pretty hilarious.
    - EpicEng 13y ago
      Not odd at all; you were being condescending, trying to paint me as someone who isn't as good a programmer as you are. Maybe I'm not, but I've written some very robust systems code in my career, so don't be so quick to write people off. I don't think I'm infallible (straw man much?), but I do think that dead simple errors such as this would be caught by any amount of actual testing. That said, I wouldn't be against a better design. Why doesn't this library provide a way to add arbitrary headers? Oh, right, that would still involve using a string. Gasp, no, that shouldn't be allowed. We have to protect the poor users of our library. Yeesh. You can't always protect a programmer from themselves while still allowing the flexibility/power needed to get shit done. I'd rather use the map than some overly architected and frustrating library. I have a problem with abstractions that get in my way.

by EpicEng 13y ago

pcwalton 13y ago

> I have a bug, sure, but an obvious bug that will be fixed very quickly. People say the same thing about null pointer exceptions, but null pointer exceptions are a huge problem in practice. Every bug is "obvious" in retrospect.

EpicEng 13y ago
No, this is not the same as a null pointer. Null pointers are typically much more sneaky, this line means the header will not be written and the error is right in your face. I do understand the desire to prevent these sorts of errors at the language level, but not at the cost of functionality. I don't agree with this one, but I do (for example) appreciate libraries such as the STL which (hopefully) prevent that pointer issue you brought up (and more). The STL doesn't (often) force me to work around silly limitations though. Does this library provide for creating arbitrary headers in some other fashion? If not, why?

asdf1234 13y ago

And yet bugs like this make it into production systems all the time. Several Rails security bugs have been almost as trivial and just as avoidable.

peq 13y ago

For me, a big benefit is the tooling support. If the API is statically typed, I can easily find the headers I am able to set using my IDE. And for setting the date I don't have to check the http spec for which syntax I have to use for the date.

EpicEng 13y ago
That's not a bad point, I'm just not sure I am willing to give up functionality for tooling. The end goal here is a program that people can use to get things done, not awesome IDE integration.

asdasf 13y ago

>I have a bug, sure, but an obvious bug that will be fixed very quickly I love that there are people who say things like this totally seriously.

EpicEng 13y ago
I'm not sure what you've done to make you feel like being condescending is something you have earned, but please feel free to share your body of work. I've worked on very large, complex, mission critical systems my entire career. Medical devices mostly. If you're not catching these sorts of errors early then you aren't modeling and testing your software correctly (or at all). All of the objects in the world aren't going to prevent you from writing bugs and crappy code. OO is no panacea and we've known that for quite some time now. I don't want to use a library which is limiting because it thinks it is doing me a favor.
- asdasf 13y ago
  What an odd response. I haven't done any OO programming in nearly a decade, and I would not consider doing it ever again. I don't know where you got the idea that OO has anything to do with this. I do catch these sorts of errors early on, because they are type errors, and thus the compiler catches them. That is very much the point. The fact that you think you are infallible and can write 100% perfect test coverage, while thinking I am being condescending is pretty hilarious.
  - EpicEng 13y ago
    Not odd at all; you were being condescending, trying to paint me as someone who isn't as good a programmer as you are. Maybe I'm not, but I've written some very robust systems code in my career, so don't be so quick to write people off. I don't think I'm infallible (straw man much?), but I do think that dead simple errors such as this would be caught by any amount of actual testing. That said, I wouldn't be against a better design. Why doesn't this library provide a way to add arbitrary headers? Oh, right, that would still involve using a string. Gasp, no, that shouldn't be allowed. We have to protect the poor users of our library. Yeesh. You can't always protect a programmer from themselves while still allowing the flexibility/power needed to get shit done. I'd rather use the map than some overly architected and frustrating library. I have a problem with abstractions that get in my way.