[jrochkind1]

> I wonder if it would actually be better for software teams to build not the thing they want, but rather the thing that makes the thing they want.

Sounds so appealing to programmers, so much harder than it sounds. A dangerous fantasy many ships have broke upon.

The proposals of "yagni" and the "mvp" are in some sense a reaction to the danger.

On the other hand, when it works, it works. I'd say Rails is an example.

[braindouche]

Rails is not an example. Rails was extracted from a single project codebase, Basecamp. Extracting a Solution Factory out of the solutions we make is a great idea, but starting with a factory-first mindset is what distracts and then breaks programmers.

[Ididntdothis]

Usually you have to first build the thing you want and then you can build the thing that will build what you want. You can’t go straight to the second. You need the experience of having built the thing.

[solotronics]

Interesting, I keep building very similar patterns of automation in my systems management programs. Recently have started to think about what it would look like to make a generalized control software for the systems I interact with, to make the automation more uniform. I think this is probably what led to the teams that made ansible or saltstack.

[mannykannot]

The 'notation' level similarly seems to be promoting the use of DSLs, and everything you say here also applies there (maybe I'm jaded, but on more than one occasion, I have had to deal with the consequences of an incomplete DSL that had no real justification, and was clearly developed for egocentric reasons. I have also come across exactly one DSL (not mine) that was both justified and well-done.)

More generally, I agree with the author on the importance of seeing a hierarchy here.

[cle]

We have a lot of progress to make here. Writing a language isn’t nearly as simple as writing a mere lexer, parser, type checker, and compiler/interpreter. You’ll spend just as much, or even more, time worrying about developer ergonomics (IDE integration, frameworks, toolchains, etc.). Projects like Language Server Protocol are great steps in the direction of making languages easier to implement, and LSP in particular is a great example of a “solution factory”.

[TeMPOraL]

That's intentionally making the problem three orders of magnitude more complicated than it should be, though.

In Lisp world, you start your DSL with a simple defmacro, and iterate from there. Lexer, parser, type checker and compiler is already handled for you, you only need to add some code where the rules differ. For a DSL you create within your codebase, you almost never need to do extra work here.

[jrochkind1]

In ruby a DSL is just ruby as well, although it perhaps ends up having to _look_ more like ruby than a Lisp DSL would. (Not sure, only vaguely familiar with lisp). But at any rate it's the same thing as far as "create within your codebase", no extra work of a lexer, parser, etc. This is a thing people do in ruby and call it a "DSL", when they are using fancy techniques to make it especially concisely expressed and well-fit for the domain (but it's still really just ruby under the hood, no parsing step but parsing ruby code with your ordinary ruby interpreter).

Which has always made me think... so HOW is this different than an API anyway, why does it have a special name? Aren't all API's "domain-specific languages" of a sort? Certainly they can be good or bad APIs, in a variety of ways, including being a good or poor fit for the domain of work they are trying to enable. But if in the end the implementation is just (ruby) calling methods on instances, or (lisp) calling macros and lambdas (or however you'd describe it in lisp if i've gotten it wrong)... isn't that what every API is, what's the difference?

[Someone]

IMO, Calculator Construction Set is a better example (https://www.folklore.org/StoryView.py?story=Calculator_Const...)

Pinball Construction Set (https://en.wikipedia.org/wiki/Pinball_Construction_Set) takes that a step further, not only allowing you to change colors and patterns, but truly allowing you to change the pinball machine.

And of course, there’s tools such as dBase II, Excel, Visual Basic and HyperCard.

[iamthepieman]

The thing that makes the thing I want IS the language simply put.

More completely it's the environment, architecture, language, requirements, customer, experience and team.

I've rarely found a need for a generator that wouldn't be more simply and universally solved via a configuration pattern.

[dgb23]

Generating tests from a specification or operations from a schema don't seem to fall into this category.

[arethuza]

Yeah it's the splendid old "hammer factories" rant from Joel on Software!

[sixplusone]

>A dangerous fantasy many ships have broke upon.

viz the yet-anothers of: make build system, programming language, configuration syntax, (mvc) framework, ORM, game engine, CMS...

Sourceforge and github are filled with monuments to unrealized dreams and wasted centuries.