161–170 of 216 posts
Earlier quoted context omitted.
I think one of the biggest counter examples to your argument is SQL. It's been around a long time. It's not general purpose. It's considered the best option there is if your setup allows you to use it.
SQL is a beast of a language and there's definitely room for improvement. Also it's not Turing complete
Earlier quoted context omitted.
And even if you do invest in proper documentation and support, you still have to overcome the hurdle that people just _don’t want to spend time learning your one-off language_ - there’s nontrivial opportunity cost in learning something that won’t be useful anywhere else. So people will just do the bare minimum which will lead to misunderstanding and bugs.
> people just _don’t want to spend time learning your one-off language_ Which people though? If you make a DSL that non programmers in your organization use, I'm sure they will appreciate not having to learn the intricacies of Rust or whatever's in fashion this week.
Custom languages, with limited support, limited community, limited extendability etc. are just like that - limited. And as soon as you hit a wall with them, transition will cost more (in both time and money) than saved in the first place by using "easier" tooling for non-programmers.
People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. The problem is that your DSL has to be understood by other people, including future you. Programming tasks are vast, combinatorially explosive state spaces full of weird potential interactions between features…
There are some modern success stories like LINQ or JSX.
Earlier quoted context omitted.
Both of these things are theoretically true, but only if the little language has enough resources behind it to optimize and build enough tooling. A big language is much more likely to have those resources because the target market is big enough to justify it. A niche little language will likely never get that kind of mass behind it, so the tools will be lacking and the runtime won't be optimized.
Big general purpose languages don’t have the capability for certain kinds of performance improvements or static analysis so the market size isn’t a factor.
I’m not here to tell you how very clever you are for reinventing the wheel. I have my own shot to get done and that’s easier when we make a smaller language out of our general purpose language by agreeing to style guidelines, instead of avoiding solving social problems with technology by creating your own game to change the rules.
When everyone in your group expects the rest of the team to commit 10% of our attention to their tool or module, that doesn’t scale. If we go more than 50% total our capacity to solve problems becomes hamstrung.
If you work someplace where new devs are useless for a year, you’ve likely already got the snowflake disease.
Earlier quoted context omitted.
And even if you do invest in proper documentation and support, you still have to overcome the hurdle that people just _don’t want to spend time learning your one-off language_ - there’s nontrivial opportunity cost in learning something that won’t be useful anywhere else. So people will just do the bare minimum which will lead to misunderstanding and bugs.
> people just _don’t want to spend time learning your one-off language_ Which people though? If you make a DSL that non programmers in your organization use, I'm sure they will appreciate not having to learn the intricacies of Rust or whatever's in fashion this week.
Earlier quoted context omitted.
It really isn't, but it is a bit like democracy, it could be better, but given the landscape and IDE integration capabilities, it is the best the C and C++ community alongside tool vendors have agreed upon. I certainly rather use CMake, even if I need an open book on the side, than Gradle, Blaze, autotools, yet another Python based build tool,.... However, most of the times, since my use of C++ is related to personal…
> it is the best the C and C++ community alongside tool vendors have agreed upon. Well yeah but only because it's the only build tool that the C++ community has vaguely agreed upon. Meson and Bazel are much better, but also much less popular.
Earlier quoted context omitted.
Big general purpose languages don’t have the capability for certain kinds of performance improvements or static analysis so the market size isn’t a factor.
I don’t want to spend all day playing human debugger because your little language doesn’t support debugging. I’m not here to tell you how very clever you are for reinventing the wheel. I have my own shot to get done and that’s easier when we make a smaller language out of our general purpose language by agreeing to style guidelines, instead of avoiding solving social problems with technology by creating your own game…
People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. The problem is that your DSL has to be understood by other people, including future you. Programming tasks are vast, combinatorially explosive state spaces full of weird potential interactions between features…
Regarding CMake’s horrific documentation: I will literally be willing to pay money for someone who can show me how/if it’s possible to wire in a different language to CMake! I believe it’s possible, I’ve seen some functions deep in the crappy docs that make it look like it is, but I cannot for the life of me work it out. The language in question produces C object files!
* Add a builtin command [1] that takes a string or filename and calls the interpreter with any additional data you want to pass.
* Add a flow control command [1] that passes the inline block to the interpreter of your choice. You'd probably have to override cmFunctionBlocker as well for this.
Note that this can't fix the deep design issues in CMake like the insane string representation.
And no, I'm definitely not in therapy from CMake-induced PTSD.
[1] https://github.com/Kitware/CMake/blob/master/Source/cmComman...
I am very familiar with DSLs but had not heard them called "little languages". I cannot say I find it fitting as it makes me think more of languages with reduced syntax or semantics.
I haven't done any research on this but I suspect that usage predates "DSL," or at least was popular before the term DSL was widely known and used for it. I mostly see "little language" used in older sources, mid-90s or earlier. It seems to be making a comeback though! I prefer it too. It's not really more descriptive than DSL but it's not much less, and is less jargony and just cuter.
The AWK Programming Language, 1988, Chapter 6: Little Languages
https://archive.org/details/pdfy-MgN0H1joIoDVoIC7/page/n11/m...
Earlier quoted context omitted.
Both of these things are theoretically true, but only if the little language has enough resources behind it to optimize and build enough tooling. A big language is much more likely to have those resources because the target market is big enough to justify it. A niche little language will likely never get that kind of mass behind it, so the tools will be lacking and the runtime won't be optimized.
Big general purpose languages don’t have the capability for certain kinds of performance improvements or static analysis so the market size isn’t a factor.
Proper debugging, syntax highlighting, language servers, security audits. These are things that engineers in the real world expect a language to have, and each little language would have to reinvent each of them. In contrast, a library can piggyback off of the tooling provided in the host language.
So even if a language can deliver on the performance and static analysis that it promises (which few will), it cannot reach adoption because it cannot provide the infrastructure needed.
(That doesn't need even get into the onboarding concerns that I and others have raised about having a codebase that is strung together from a dozen tiny languages.)