7 ms·

It's been a while since I watched this but my current thoughts on "Growing a language" is that I fear it is an unhelpful simplification of what makes language d

It's been a while since I watched this but my current thoughts on "Growing a language" is that I fear it is an unhelpful simplification of what makes language design hard. IMHO language design is a holistic design problem that needs global optimisation. You cannot incrementally hill-climb yourself anywhere useful when you can't backtrack over past decisions. It is like designing a workshop. You only have so much space within arms reach. Here you place your most frequently used and valuable tools. You can "grow your language" by adding tools but they can't replace what you have in this limited and privileged position - instead, new tools have to go in cupboards or on another table. The new tools will have higher friction than the first priority tools you added. Maybe you can have a workshop where you imagine a tool and it appears in your hand thereby removing the constraint of "tools within reach" but I think this then makes it too ephemeral and abstract. It is the constraints that makes a language tactile and ergonomic - remove the constraints and you have no structure at all. In this case, the "tools within reach" are your core keywords and syntax. Growing features via libraries or syntactic extensions generally incur more ceremony and less elegance. Having totally flexible syntax extensions/keywords doesn't solve the problem, it just moves up a level abstraction/generality and means you have given your users the "design a language" problem instead of solving it for them.

wool_gather 8y ago
> you have given your users the "design a language" problem instead of solving it for them This is an interesting observation that reminds me of > In Lisp, you don't just write your program down toward the language, you also build the language up toward your program. from Paul Graham's "Programming Bottom-Up". Some people would consider it an advantage being allowed to fold the "design a language problem" into the overall problem. More, I think this is just a matter of degree, not kind. As soon as you have something as apparently simple as named procedures, you're really writing a DSL, albeit very coarsely, for your business problem. Add named record types. Add textual macros. Add operator overloading. Add Lisp-style macros. At every point where the language allows a word on the screen to stand in for something larger, you're giving the programmer the power to design a language for their problem domain.

wool_gather 8y ago

> you have given your users the "design a language" problem instead of solving it for them This is an interesting observation that reminds me of > In Lisp, you don't just write your program down toward the language, you also build the language up toward your program. from Paul Graham's "Programming Bottom-Up". Some people would consider it an advantage being allowed to fold the "design a language problem" into the overall problem. More, I think this is just a matter of degree, not kind. As soon as you have something as apparently simple as named procedures, you're really writing a DSL, albeit very coarsely, for your business problem. Add named record types. Add textual macros. Add operator overloading. Add Lisp-style macros. At every point where the language allows a word on the screen to stand in for something larger, you're giving the programmer the power to design a language for their problem domain.