3 ms·

When there's no ability in the language to abstract, there's no abstractions to learn, beyond what is built in. But this is not a blessing, it means we have to

When there's no ability in the language to abstract, there's no abstractions to learn, beyond what is built in. But this is not a blessing, it means we have to study every line of code and hope that we can uncover some emergent higher-level structure, if it exists.

dragonwriter 8y ago
Right: phrased differently, weaker abstraction power means recurring problems have to be addressed by documenting patterns with fill-in-the-blanks recipes, instead of reusable code libraries.
realusername 8y ago
> hope that we can uncover some emergent higher-level structure, if it exists. That's exactly what I feel when I read Scala code, everything is a soup of custom operators, implicits and objects disguised like functions (or the opposite, you think it's an object but actually it's a function), it makes the code very hard to maintain and read. At least with Go, Python or Ruby your logic is in plain English, that makes it much easier.
- lmm 8y ago
  I find the opposite. With Scala my logic can be plain English written in the language of the domain, because Scala makes it very easy to push out secondary concerns like authentication or audit logging or error handling out into the type system where they're still there, still managed, still checked by the compiler, still visible on mouseover/click-through in my IDE, but they don't have to obscure the straight-through happy-path business logic. Whereas in Go, all the secondary logic has to be right there, which clutters up the code and makes it harder to see the primary thread, and in Python or Ruby either you do the same thing or else the secondary logic has to work by invisible magic (metaclasses, exceptions, method_missing...) and you have no hope of ever being able to understand what's actually going on.
seanmcdirmid 8y ago
This is analogous to the tension between “worse is better” and “perfect is the enemy of good.” One the one hand, elegance is impossible and one must settle early on inelegance. On the other hand, elegance is possible but one must be clever and spend a lot of time looking for it. These trade offs are really apparent in competing language designs (Scala, Go) and it isn’t clear which ones are the better ones to make.

dragonwriter 8y ago

Right: phrased differently, weaker abstraction power means recurring problems have to be addressed by documenting patterns with fill-in-the-blanks recipes, instead of reusable code libraries.

realusername 8y ago

> hope that we can uncover some emergent higher-level structure, if it exists. That's exactly what I feel when I read Scala code, everything is a soup of custom operators, implicits and objects disguised like functions (or the opposite, you think it's an object but actually it's a function), it makes the code very hard to maintain and read. At least with Go, Python or Ruby your logic is in plain English, that makes it much easier.

lmm 8y ago
I find the opposite. With Scala my logic can be plain English written in the language of the domain, because Scala makes it very easy to push out secondary concerns like authentication or audit logging or error handling out into the type system where they're still there, still managed, still checked by the compiler, still visible on mouseover/click-through in my IDE, but they don't have to obscure the straight-through happy-path business logic. Whereas in Go, all the secondary logic has to be right there, which clutters up the code and makes it harder to see the primary thread, and in Python or Ruby either you do the same thing or else the secondary logic has to work by invisible magic (metaclasses, exceptions, method_missing...) and you have no hope of ever being able to understand what's actually going on.

seanmcdirmid 8y ago

This is analogous to the tension between “worse is better” and “perfect is the enemy of good.” One the one hand, elegance is impossible and one must settle early on inelegance. On the other hand, elegance is possible but one must be clever and spend a lot of time looking for it. These trade offs are really apparent in competing language designs (Scala, Go) and it isn’t clear which ones are the better ones to make.