4 ms·

I appreciate you taking the courage to share your honest thoughts despite how they may conflict with the views of others here. My heart goes out to the people I

I appreciate you taking the courage to share your honest thoughts despite how they may conflict with the views of others here. My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame for their poor performance. That sentiment resembles some of the comments that I’ve written here and my heart really bleeds for them, because I know these people at work and I know that they’re struggling and I also know that they’re good, smart people, who have just fell into a trap of justification. For what it’s worth, in my own journey learning Scala, I simply didn’t have the luxury to blame, and I just forced myself to try and figure out how other people, like the finagle team for example, could be so productive with such an obviously newfangled invention, until I realized… I was wrong. Scala is actually a wonderful language! People move companies to continue working in Scala! In fact the ideas and lessons that I’ve learned from rethinking how I used to do things are so unfathomably valuable to me that I don’t think I will ever look at code the same way again. And before you downvote me please don’t mistake my words for criticism. I truly empathize with how some of the people here may feel and I’m very happy to go into specifics if anyone requests that. I don’t write on HN a lot because a lot of times I think there is just this therapy - or a version of therapy - that amounts to people reinforcing their need to blame things in order to continue excusing the poor performance, and I don’t want to get caught up in it or be made to feel bad for encouraging others to reconsider their virtues. And by the way we all, at times, have poor performance. (Anyway, I dictated this into my phone, so also excuse any weird words or punctuation. I love you all. Some typos were subsequently edited)

bcrosby95 7y ago
Not every language has to be for every person. It's perfectly fine that people enjoy Scala. I think a lot of the negativity about Scala is because lots of companies went in hard on Scala less because of the merits of Scala, and more because Java had such a long period of stagnation.
- asimpletune 7y ago
  This is very true
erikpukinskis 7y ago
> My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame Yah, I have noticed lately a division between two types of programmers. The first is the "infrastructure oriented" programmer. They assume that the rank and file programmers will be expected to write bad code. They look at problems in the codebase as a sign that there is a missing piece of infrastructure. They 1) wait for the pain level to get high enough on the team, 2) identify a class of problems that is not getting solved well, 3) install or implement a new service/middleware/library that solves that class of problem elegantly, and 4) port all of the crappy code over to the new reality. The second is the "pattern oriented" programmer. They assume that sloppy code will create areas of rot around it that become cost centers, and that "low hanging fruit" cleanup tasks will generally pay for themselves. When there are problems in the codebase, they go back and refactor. They advocate for team discussions of patterns, establish precedent for the team to follow, and expect other members of the team to learn and apply those patterns correctly. I'm not really sure whether these two types of programmers should work together. Each group's primary assumption: 1) Programmers will inevitably do sloppy things, and' 2) "Low-hanging cleanup" pays for itself ... is correct in practice. The problem is they are somewhat at odds in terms of pointing to a high level strategy. If you are committed to ripping out and replacing large parts of the codebase when they become unworkable, there's not really any point to trying to keep up with tidying. And if you tidy, you won't really need to rip out large parts of the codebase. So maybe we should just each try to find a team that fits with our values, rather than argue about it.

bcrosby95 7y ago

Not every language has to be for every person. It's perfectly fine that people enjoy Scala. I think a lot of the negativity about Scala is because lots of companies went in hard on Scala less because of the merits of Scala, and more because Java had such a long period of stagnation.

asimpletune 7y ago
This is very true

erikpukinskis 7y ago

> My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame Yah, I have noticed lately a division between two types of programmers. The first is the "infrastructure oriented" programmer. They assume that the rank and file programmers will be expected to write bad code. They look at problems in the codebase as a sign that there is a missing piece of infrastructure. They 1) wait for the pain level to get high enough on the team, 2) identify a class of problems that is not getting solved well, 3) install or implement a new service/middleware/library that solves that class of problem elegantly, and 4) port all of the crappy code over to the new reality. The second is the "pattern oriented" programmer. They assume that sloppy code will create areas of rot around it that become cost centers, and that "low hanging fruit" cleanup tasks will generally pay for themselves. When there are problems in the codebase, they go back and refactor. They advocate for team discussions of patterns, establish precedent for the team to follow, and expect other members of the team to learn and apply those patterns correctly. I'm not really sure whether these two types of programmers should work together. Each group's primary assumption: 1) Programmers will inevitably do sloppy things, and' 2) "Low-hanging cleanup" pays for itself ... is correct in practice. The problem is they are somewhat at odds in terms of pointing to a high level strategy. If you are committed to ripping out and replacing large parts of the codebase when they become unworkable, there's not really any point to trying to keep up with tidying. And if you tidy, you won't really need to rip out large parts of the codebase. So maybe we should just each try to find a team that fits with our values, rather than argue about it.