4 ms·
Another option is to use tooling that helps you write little languages with debugging, profiling, etc for free. An interesting article I saw the other day: htt
by fwip 4y ago
Another option is to use tooling that helps you write little languages with debugging, profiling, etc for free.
An interesting article I saw the other day: https://news.mit.edu/2023/d2x-easier-way-get-bugs-out-programming-languages-0407 https://news.mit.edu/2023/d2x-easier-way-get-bugs-out-progra...
- quelltext 4y agoIsn't that article / researcher saying the same opinion the submission article is responding to? JetBrains about 9-10 years ago made those arguments and claimed to work on providing the tools to solve those challenges. I'm kind of curious what actually happened in that time. I've actually seen a few of these research projects over the years, i.e. providing tools to build languages with automated IDE and debugging support. Ultimately, I think (like the submission article's author) that it's something else holding adoption back. It may simply be lack of a convincing use case, e.g. industry adoption by one large company could make the overall approach (DSLs) more convincing. Now DSLs or DSL-like languages are of course in use in many orgs but they very often aren't more than configuration languages and often embedded in something else. Very rarely do they get complex enough to warrant debuggers. So I think we a) still lack good examples of DSLs being worth it, or b) a more convincing argument why today's methods would benefit from building a whole new language (incl. tooling).