4 ms·

> You seem to be writing that a simple language is somehow harder to scale for large teams. My experience is the exact opposite - too expressive language make d

> You seem to be writing that a simple language is somehow harder to scale for large teams. My experience is the exact opposite - too expressive language make devs have different dialects and be too "clever" for the teams long-term good - and I'm pretty dumbfounded that you can try to make sense of that. It doesn't matter what language you use - cleverness will come in anyways. Only the way it is achieved is different. Cleverness in the case of go will just be difficult to understand reflection, where it will be difficult to understand types in Haskell. With go, every line of code will be simpler when compared to Haskell (picking Haskell as an arbitrary example here). However, the go program will also 10x bigger. And complexity grows over proportional with the amount of code. In the end, the understand what the whole thing is doing you will have a harder time compared to the more dense but also much shorter code in Haskell _if you are very familiar and experienced in both languages_.

jahaja 6y ago
I don't agree that dense code is easier to understand at all. It's both harder to understand and much harder to debug. I don't now why more code is in anyway reflective of how hard it is to understand. That would make the Redis code base harder to understand just because it has more features now than 4 years ago. That's just not true. Haskell is also a good example, if it was easy to understand, maintain etc. we would have seen a good examples of large-scale apps and projects being developed in it by now. But we do not. Barely a single one. > _if you are very familiar and experienced in both languages_. This can be translated to "this is so cognitive challenging that you need to be really well-versed to not fuck this up now". That's not a good user-interface for something to scale on large teams.
- valenterry 6y ago
  > I don't agree that dense code is easier to understand at all. I think we just have a different definition of dense code. Here is an example that shows my view on it. Dense: adult_users = users.filter(it.isAdult) Not dense: adult_users = list.empty for(i = 0; i < users.length; i ++) { maybe_adult_user = users.get(i) if(maybe_adult_user.isAdult) adult_users += maybe_adult_user } The first example is not only just "less" code in the sense that the filter function was also defined somewhere before and then just used. No, it is more dense code because it reduces subjective complexity by shifting some of the complexity to existing code _with which the developer hopefully is familiar with_. If the developer is not familiar with it, then the code is actually _more complicated_. The same thing happens to language features, not only to code reuse. Some languages have generics, some don't. Without understanding and familiarity with generics, they will make everything more difficult. Once they are understood, the developer has a productivity advantage (assuming that generics are helpful). However, gaining this initial knowledge and familiarity is very hard, hence not so many people use Haskell or similar languages and many more people use javascript and python and php, so you see more large-scale apps written in them. But we also see that all big companies eventually struggle with the not-dense-enough code and build on top of these languages. Facebook with php->hack, stripe with their own version of Ruby, ...

jahaja 6y ago

I don't agree that dense code is easier to understand at all. It's both harder to understand and much harder to debug. I don't now why more code is in anyway reflective of how hard it is to understand. That would make the Redis code base harder to understand just because it has more features now than 4 years ago. That's just not true. Haskell is also a good example, if it was easy to understand, maintain etc. we would have seen a good examples of large-scale apps and projects being developed in it by now. But we do not. Barely a single one. > _if you are very familiar and experienced in both languages_. This can be translated to "this is so cognitive challenging that you need to be really well-versed to not fuck this up now". That's not a good user-interface for something to scale on large teams.

valenterry 6y ago
> I don't agree that dense code is easier to understand at all. I think we just have a different definition of dense code. Here is an example that shows my view on it. Dense: adult_users = users.filter(it.isAdult) Not dense: adult_users = list.empty for(i = 0; i < users.length; i ++) { maybe_adult_user = users.get(i) if(maybe_adult_user.isAdult) adult_users += maybe_adult_user } The first example is not only just "less" code in the sense that the filter function was also defined somewhere before and then just used. No, it is more dense code because it reduces subjective complexity by shifting some of the complexity to existing code _with which the developer hopefully is familiar with_. If the developer is not familiar with it, then the code is actually _more complicated_. The same thing happens to language features, not only to code reuse. Some languages have generics, some don't. Without understanding and familiarity with generics, they will make everything more difficult. Once they are understood, the developer has a productivity advantage (assuming that generics are helpful). However, gaining this initial knowledge and familiarity is very hard, hence not so many people use Haskell or similar languages and many more people use javascript and python and php, so you see more large-scale apps written in them. But we also see that all big companies eventually struggle with the not-dense-enough code and build on top of these languages. Facebook with php->hack, stripe with their own version of Ruby, ...