3 ms·

> A programming language is more scalable if an engineer unfamiliar with a code base written in it produces correct code more quickly. > Scalability is often a

by saurik 3y ago

> A programming language is more scalable if an engineer unfamiliar with a code base written in it produces correct code more quickly. > Scalability is often at odds with peak effectiveness, the maximum effectiveness of an engineer who is intimately familiar with the codebase... I would think we would want to use the term "scalability" in this kind of context to say something more like "a programming language is more scalable if it makes it easier to have large numbers of engineers all working on features of a single app concurrently without stepping on each other's work (even if they have to go to great effort to learn how to do so)"? (edit addition 25 minutes later:) As a maybe overly-trivial example, it can be really irritating to work with other developers in an object-oriented programming language that requires all the fields or methods of a class to be declared in one place, as you can end up with constant merge conflicts. If you can create a new file and declare fields and methods that extend an existing class -- preferably with the fields in that new file being scoped to only being accessible to methods in that new file -- that can be a massive help (even if it makes other specific aspects of understanding the functionality of the class a bit more difficult).

marcosdumay 3y ago
I have always used it to mean how large a codebase you can create without complexity growing out of control (of a fixed sized team). But I do like your usage too. We do need new words here.
The_Colonel 3y ago
> a programming language is more scalable if it makes it easier to have large numbers of engineers all working on features of a single app concurrently without stepping on each other's work This is optimizing for a wrong (minor) problem. As the application grows, both accidental and essential complexity grows. More and more of engineers' time is spent analyzing existing code, and they typically spend less time writing new code. The limiting factor in large/old codebases (which is where the word "scalability" comes into play IMHO) is the inability of even experienced engineers to understand aspects of the codebase. This is why I think e.g. Java has been so successful in the "big & complex" space. Java is annoying to write, but easy to read. I mean, some more conciseness would make it easier to read, but it's still quite OK. Very importantly, it's OK to read even if the dev writing it wasn't good / didn't observe best practices etc. I often have to deal with code written 20 years ago, and you can't change the past ... Regarding the merge conflicts - they happen, most of the time causing only minor problems, sometimes it's a bigger deal. Some programming styles can help you avoid some minor merge conflicts, but I doubt they will be effective in avoiding the real troublesome merge conflicts (which go far beyond introducing a new field).

by saurik 3y ago

marcosdumay 3y ago

I have always used it to mean how large a codebase you can create without complexity growing out of control (of a fixed sized team). But I do like your usage too. We do need new words here.

The_Colonel 3y ago

> a programming language is more scalable if it makes it easier to have large numbers of engineers all working on features of a single app concurrently without stepping on each other's work This is optimizing for a wrong (minor) problem. As the application grows, both accidental and essential complexity grows. More and more of engineers' time is spent analyzing existing code, and they typically spend less time writing new code. The limiting factor in large/old codebases (which is where the word "scalability" comes into play IMHO) is the inability of even experienced engineers to understand aspects of the codebase. This is why I think e.g. Java has been so successful in the "big & complex" space. Java is annoying to write, but easy to read. I mean, some more conciseness would make it easier to read, but it's still quite OK. Very importantly, it's OK to read even if the dev writing it wasn't good / didn't observe best practices etc. I often have to deal with code written 20 years ago, and you can't change the past ... Regarding the merge conflicts - they happen, most of the time causing only minor problems, sometimes it's a bigger deal. Some programming styles can help you avoid some minor merge conflicts, but I doubt they will be effective in avoiding the real troublesome merge conflicts (which go far beyond introducing a new field).