4 ms·

I always liked DHH's take on these sorts of arguments (paraphrasing): who the hell cares? Once you know the purpose of the '=' how often do you make mistakes re

by dkrich 9y ago

I always liked DHH's take on these sorts of arguments (paraphrasing): who the hell cares? Once you know the purpose of the '=' how often do you make mistakes reading or writing code? Whereas Java is all about protecting developers from themselves, Ruby (for example) let's you get away without variable type declaration because at the end of the day, how often do you not know whether a particular variable is a string or an integer? Enough to justify enforcing declaring everything at the outset or receiving errors throughout your code? That's not to say that those enforcements never make sense. I think that structured languages like Java are better for larger teams where enforcing standards is more important than a smaller team. But there are other ways to do that and a lot of time the rules make development a horrible experience.

AdeptusAquinas 9y ago
I prefer to take the middle ground: implicit typing in C#/Scala with var. Benefits of both worlds.
deleted 9y ago
[deleted]
ben509 9y ago
> because at the end of the day, how often do you not know whether a particular variable is a string or an integer? I'm refactoring some data-pasta to more clearly declare types because we just have dicts of lists of whatever, so often enough that a random reader chimed in after 20 minutes.
sanderjd 9y ago
My issue with the larger teams vs. smaller teams argument is that the price of success is finding yourself with the wrong tools because successful projects usually grow large teams. The counterargument is that the price of choosing the right tools for a large team may be failure when those tools don't let you execute quickly enough. I don't really buy this trade-off. Maybe it is true for the specific language of Java for a small team (I'm not so sure it is) or Ruby for a large team (I have lived this and found it to be anecdotally true, so I do buy this one), but I don't believe you have to make this choice; I believe there can be languages that are productive for small teams while avoiding foot-guns for large teams.
danaliv 9y ago
> how often do you not know whether a particular variable is a string or an integer? In someone else's code? 100% of the time. I was once a diehard Ruby believer, and I still use it for small programs. But having had the singular displeasure of working on a huge Ruby codebase (pre-JVM Twitter), I have learned, in the hardest possible way, that untyped languages are absolute nightmares when more than one person is involved.
mikekchar 9y ago
As someone who does Rails development as his day job, man do I hate convention over configuration. The argument, "Once you know that X, it's very easy to understand" sounds great, but there are a lot of Xs! This is fine if Rails (or whatever) is your life and you are going to be Rails-boi or Rails-grl until the industry moves on and you pick up your next career at MacD's. From a language, library, or framework I want to be in and out as fast as possibly. I want to have unambiguous usage that is easily discoverable. I want to avoid having to load a million things into my memory -- not least because I work with a huge pile of legacy code that all uses different technology. Rails is not the worst system I've ever used for this, but it's edging up there. Ruby, as a language, I don't mind at all, but the coding convention of people who primarily use Rails is something that I think can be improved dramatically. Of course, IMHO ;-)
lmm 9y ago
> Once you know the purpose of the '=' how often do you make mistakes reading or writing code? A nontrivial proportion of people who start trying to learn to program never get past that point, so it's worth taking them into account. > at the end of the day, how often do you not know whether a particular variable is a string or an integer? Strawman. Types are not about the difference between a string and an integer, they're about the difference between a user id and an order id, or a non-empty list and a possibly-empty list, or...
- bogomipz 9y ago
  >"Strawman. Types are not about the difference between a string and an integer, they're about the difference between a user id and an order id, or a non-empty list and a possibly-empty list, or..." Can you explain - how is the difference between a string and an integer different from the difference between a user id and an order id? You're calling the OPs comment a straw man but I'm not understanding how your examples are not the same thing given type system that understood all four of those.
  - lmm 9y ago
    Many Ruby users don't realise that the type system can understand all these differences. How often do you not know whether a particular variable is a string or an integer? Not very often. How often do you not know whether a particular variable is a user id or an order id? Much more often. So if you think the only kind of difference a type system can tell you about is the difference between a string and an integer, you vastly underestimate the number of bugs that a type system could help you avoid.

by dkrich 9y ago

AdeptusAquinas 9y ago

I prefer to take the middle ground: implicit typing in C#/Scala with var. Benefits of both worlds.

deleted 9y ago

[deleted]

ben509 9y ago

> because at the end of the day, how often do you not know whether a particular variable is a string or an integer? I'm refactoring some data-pasta to more clearly declare types because we just have dicts of lists of whatever, so often enough that a random reader chimed in after 20 minutes.

sanderjd 9y ago

My issue with the larger teams vs. smaller teams argument is that the price of success is finding yourself with the wrong tools because successful projects usually grow large teams. The counterargument is that the price of choosing the right tools for a large team may be failure when those tools don't let you execute quickly enough. I don't really buy this trade-off. Maybe it is true for the specific language of Java for a small team (I'm not so sure it is) or Ruby for a large team (I have lived this and found it to be anecdotally true, so I do buy this one), but I don't believe you have to make this choice; I believe there can be languages that are productive for small teams while avoiding foot-guns for large teams.

danaliv 9y ago

> how often do you not know whether a particular variable is a string or an integer? In someone else's code? 100% of the time. I was once a diehard Ruby believer, and I still use it for small programs. But having had the singular displeasure of working on a huge Ruby codebase (pre-JVM Twitter), I have learned, in the hardest possible way, that untyped languages are absolute nightmares when more than one person is involved.

mikekchar 9y ago

As someone who does Rails development as his day job, man do I hate convention over configuration. The argument, "Once you know that X, it's very easy to understand" sounds great, but there are a lot of Xs! This is fine if Rails (or whatever) is your life and you are going to be Rails-boi or Rails-grl until the industry moves on and you pick up your next career at MacD's. From a language, library, or framework I want to be in and out as fast as possibly. I want to have unambiguous usage that is easily discoverable. I want to avoid having to load a million things into my memory -- not least because I work with a huge pile of legacy code that all uses different technology. Rails is not the worst system I've ever used for this, but it's edging up there. Ruby, as a language, I don't mind at all, but the coding convention of people who primarily use Rails is something that I think can be improved dramatically. Of course, IMHO ;-)

lmm 9y ago

> Once you know the purpose of the '=' how often do you make mistakes reading or writing code? A nontrivial proportion of people who start trying to learn to program never get past that point, so it's worth taking them into account. > at the end of the day, how often do you not know whether a particular variable is a string or an integer? Strawman. Types are not about the difference between a string and an integer, they're about the difference between a user id and an order id, or a non-empty list and a possibly-empty list, or...

bogomipz 9y ago
>"Strawman. Types are not about the difference between a string and an integer, they're about the difference between a user id and an order id, or a non-empty list and a possibly-empty list, or..." Can you explain - how is the difference between a string and an integer different from the difference between a user id and an order id? You're calling the OPs comment a straw man but I'm not understanding how your examples are not the same thing given type system that understood all four of those.
- lmm 9y ago
  Many Ruby users don't realise that the type system can understand all these differences. How often do you not know whether a particular variable is a string or an integer? Not very often. How often do you not know whether a particular variable is a user id or an order id? Much more often. So if you think the only kind of difference a type system can tell you about is the difference between a string and an integer, you vastly underestimate the number of bugs that a type system could help you avoid.