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.

      1. 2

        As advice for seasoned language designers, trying to come up with the whole vocabulary before doing any development makes sense – you’ll end up with a much smaller and more conceptually-coherent language.

        However, Mr. Bright’s article was intended as advice for people who are writing their first language & have never studied language design. My rebuttal is also intended for that audience.

        (I like D a lot. I think it’s brilliant. I just don’t think that when a beginner programmer first starts playing with language design ideas, he should be trying to write a hefty compiled language like D. That was the thrust of my complaint, and unfortunately I didn’t make it very clear!)

    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

      1. 1

        I didn’t mean to suggest that only undisciplined developers learn ‘general-purpose languages’. What I meant is that undisciplined programmers only learn ‘general-purpose languages’, and believe that they can thereby avoid needing to learn more than a handful of languages.

        A good developer knows how to use a general purpose language in addition to a variety of specialist languages, for those situations where a good tool for the job doesn’t exist and a general purpose language is least-bad.

        (I’m also, of course, coming from a utopian point of view – one where people make technical decisions for technical reasons, rather than using the wrong tool for the job out of ignorance or coercion. Ignorance and coercion are the order of the day, but I would prefer not to cater to them!)