Yes, and it's so strong it makes the topic totally moot. The author has just stated in his experience DSL:s have turned into a mess. The same could be said for any known well established technique that is not used competently. "No, all tools don't suck. But please don't use the chainsaw as a hammer"
Yep. But they're overused and underused each day... Everything can be a spreadsheet and nobody questions if there are better ways of holding that particular data
The issue that I've seen with Excel is that it's often seen as the hammer -everything is a nail- for people that are less inclined with technology / set in their way.
They will use it both as intended, a spreadsheet for calculations, usually for reports.
But also as publishing software (think InDesign) and format their spreadsheet to look like an invoice / quote, a hand made Gantt chart (yeah with arrows as delimiters, as opposed to filling the cells), etc ...
It's both a fascinating and horrific thing to behold, something that wouldn't be out of place in a H.P Lovecraft story.
We're going to try to get the Gantt folks to modernise a bit and use a dedicated tool for planning but we already know it's going to be complicated to get the senior folks to even consider it.
> But also as publishing software (think InDesign) and format their spreadsheet to look like an invoice / quote, a hand made Gantt chart (yeah with arrows as delimiter
Meh, I think I've done all these things myself at some point.
I'm very familiar with Excel, so sometimes it's easier to throw something together using a tool I know well, rather than get (or maybe buy) and learn new software.
Dan Bricklin himself said in an interview (I think this one [0]) that when they created VisiCalc (the first spreadsheet program) with Bob Frankston, they designed it to mix data and non-data. It was entirely part of their vision of a malleable information space.
Of course at some point of using it for everything any tool become the wrong tool, but most of the time users creating sophisticated layouts in a spreadsheet actually use the spreadsheet as intended in the original, powerful vision of its inventors.
"As intended" is a suggestion, not reality. Physical reality doesn't have XML tags attached to things, saying "this is a hammer, you shall use it to drive small nails, and small nails only". The same thing applies to software. There are tools more and less convenient for a task, but ultimately it's the task that matters.
Consider invoices: before computers, they were done on the ultimate universal medium - paper. Even today, they exist as documents primarily meant to be read by humans. They have some required information and vague shape they're supposed to resemble, but that's it. It's much faster to make one with Excel than with InDesign, doubly so if you already know Excel. The part that Excel doesn't support - invoice life-cycle management - can be done elsewhere (file system is damn good at it), and often isn't even a part of the task - that aspect is handled by the accountants you CC when sending out an invoice.
Excel is really a kind of smart virtual paper with affinity for grids. People use it for a lot of weird things because it usually works damn well for those.
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.
> "I think DSLs are about defining a 100% textual format."
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.
> 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.
(Emacs also has an even more spreadsheet-like mode; ses-mode, but that saves its data in less-than-purely-textual format. Or, at least, less textual than org-mode.)
> 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.
If you could invent a text format that could be efficiently edited with a basic text editor then I would agree it's a DSL. But I feel like you would lose a lot by dropping a dedicated GUI, e.g.:
- horizontal scrolling of columns, adding, hiding columns
- "smart copying" a formula by scrolling down
- selection of rows/columns/cells
I don't think anybody would use such DSL using a basic editor.
Overall it's discussion about the definitions of terms, but I don't understand why people want to capture anything having some "editable format" as a "DSL" when addtional terms like "visual programming" allow more differentiation?
Let's take the Wikipedia definition, not the examples list:
> A domain-specific language (DSL) is a computer language specialized to a particular application domain.
where computer language links to a list of things that includes "programming languages", which visual programming languages are a part of.
Other sections of the article also mention some graphical examples, e.g. UML. (which isn't a programming language, but a modeling language, also used sometimes as an input to software)
