31–40 of 144 posts
Counter example: spreadsheets.
I think DSLs are about defining a 100% textual format. And spreadsheets are GUI apps. There's a DSL for defining a cell formula but in total it's a small part of the experience of using a spreadsheet app.
The argument here boils down to: I haven't seen it work in places where I've been employed so it must not work. Reality check: I've worked on multiple large research teams that successfully developed DSLs still in use by domain experts -- military sigint in one case, doctors in another case, industrial engineers in another. We developed these languages for specific applications where the domain experts needed to prog…
highly technical domain experts are not quite general public.
Of course it is a programming language, but Python can absolutely be used by non-programmers. Not as cleanly as a good programmer will do of course, but I've seen many non-programmers learning it pretty quickly for basic usage (in this case the basic usage is just to use your python module which act as a "DSL")
It also has the advantages of having tons of resources online, IDE, code coloration, etc... the random "user" of your module will in general just have to search "how to do XYZ in python" and get plenty of answer.
1. Visual programming usually turns into a hot mess. It's actually as hard to learn properly as a simple programming language and once learned - usually harder to build things in. How many devs choose a visual environment when there is a genuine option?
2. "Simple" languages - BASIC, Python, Applescript, Logo. They often become complex over time unless ruthlessly maintained.
3. DSL's - probably is they tend to be, erm, domain specific and therefore you have to learn from scratch multiple times if you want to do things outside of your initial domain.
I think a hybrid of all of the above might be interesting:
1. A visual builder as "training wheels" but always ensure a perfect transform from visual to code and back again.
2. A small language with a simple syntax (something Logo or Python-like but even more carefully curated)
3. DSL-like behaviour without being a DSL. Extensibility with elegant syntactic support. Ruby aspired to this but it's Perl-isms stopped it being a good beginner's language.
I think it's better to call the users of such high-level DSLs, accidental programmers . It's not like they are not programmers, its just that they don't see software development as their vocation or profession. Yes, it's important to have languages that target them (e.g. Excel, Latex, SQL). Design of such DSLs is important and hard work. We need more professional activity making DSLs usable, consistent, and extensibl…
Smaller DSLs that could be mix n matched depending on the problem at task might be a better fit.
Wait, I feel like I'm describing a std lib here...
Earlier quoted context omitted.
I think DSLs are about defining a 100% textual format. And spreadsheets are GUI apps. There's a DSL for defining a cell formula but in total it's a small part of the experience of using a spreadsheet app.
What about Unreal Blueprints, Dynamo BIM? Visual GUI doesn't make them less DSLish.
To add another counterexample into the mix, I’ve met many artists and designers who are proficient with Unreal Engine’s Blueprint with no C++ experience. Some have even shipped games made entirely in blueprint with no traditional code.
[1]: https://web.archive.org/web/20160821143752/http://nifflas.ni...
Counter example: spreadsheets.
I think DSLs are about defining a 100% textual format. And spreadsheets are GUI apps. There's a DSL for defining a cell formula but in total it's a small part of the experience of using a spreadsheet app.
That's an unjustified qualification. I could throw together a spreadsheet format that is all text. The spreadsheet GUI then becomes a advanced text editor that, when editing that particular format, exposes advanced content-aware controls not at all unlike advanced text editors like emacs can for s-expressions.
We can bridge the gap in other ways too, for instance the '2d' racket language that lets you do control flow using a two-dimensional ascii art grid: https://docs.racket-lang.org/2d/index.html It's not hard to see how this concept could be iterated on to become something quite like a spreadsheet, and with editor support the editor/language combination would begin to look a lot like a spreadsheet too.
Earlier quoted context omitted.
What about Unreal Blueprints, Dynamo BIM? Visual GUI doesn't make them less DSLish.
I think these are examples of a https://en.wikipedia.org/wiki/Visual_programming_language , while https://en.wikipedia.org/wiki/Domain-specific_language#Examp... are purely text-based.