1. 19
  1.  

  2. 4

    it’s much easier to add features slowly based on need than it is to determine all of the useful behaviors before starting development, and it’s much easier to test a small number of base features before building on top of them than to test a large complex language all at once.

    I don’t agree that adding features one by one improves anything about the language design. One huge challenge is that each feature interacts with most of the other ones and you need to consider each combination with the full set anyways.

    Let us assume you start with a small number of base features A, B, and C. You determine all useful behaviors, test the features and their interactions, you tune them to a sweet spot of language design. Now you add feature D. Assume it interacts with B and C. To find the new sweet spot, you have to tune B and C. This means all the time spent into tuning for the sweet spot A-B-C was wasted once you introduced D. Ok, maybe not all time, because you probably learned something on the way. Still, the overall process does not look efficient to me.

    The thoughts are the reason why I think it is a bad idea that the Go designers avoid adding Generics. I believe it is unavoidable to add them at some point and then a lot of tuning is invalidated.

    On the other hand, it seems unavoidable. I do not know any language, which did not grow further after 1.0. Simple languages (Lisp, SQL, SML) get extended when they get in contact with the real world.

    1. 1

      In my experience having a slightly larger language, and trimming down features after you have gained some insights into what has worked and what hasn’t is one of the best approaches to adopt.

      This of course requires the ability to carefully manage deprecation and migration, and not having made crazy promises about compatibility like some languages of the 90ies did. Looking at many more recent languages, this has substantially changed though, with the stronger focus on adoption over existing users.

    2. 4

      I took exception to this passage:

      D can’t compete because the whole point of a general purpose language is to appeal to devs who failed the marshmallow test & want to minimize the initial steepness of the learning curve.

      (my emphasis)

      I don’t know if learning C++, Java, or C# is indicative of a wish for instant gratification. (C++ for example can have a steep learning curve). It can also be indicative of wanting to work as a software developer, and using a language that might not be a master of one trade specific problem domain, but good enough to let you work to get dinner on the table.

      Edit phrasing