I don’t agree.
Yes, of course everyone should consider if they really even need their DSL. But sometimes as the author rightly notes, sometimes the alternative to a DSL is a lower or significantly more complex existing interface style (such as SQL).
I Don't Want to Teach My Garbage DSL, Either
11–20 of 54 posts
Re: I Don't Want to Teach My Garbage DSL, Either
#12Earlier quoted context omitted.
Do anyone here expose real sql querying capabilities to your users?
In a dark past my company did: because these users were paying CMS users, they would not try to hack things, but rather because of the power of SQL and their lack of knowledge, they broke a lot which required backups to restore. We are talking mid 90s and Perl CGI scripts.
Could you not have given them read-only access?
Re: I Don't Want to Teach My Garbage DSL, Either
#13A DSL can be immensely useful in terms of useability. But it is not trivial to be done right. You need to define a consistent grammar, make sure it's intuitive to your users and free of all sorts of fun bugs that happen when odd constructs are put together.
Re: I Don't Want to Teach My Garbage DSL, Either
#14Earlier quoted context omitted.
It's not a bad idea, aside from putting your blog entirely on a third party like github. Utterances is the alternative to disqus that uses github issues.[0] Personally I think the best solution is using a static site generator like Hugo or Zola to control how you generate your content, and then host that using Caddy + Docker. A database is overkill. You can also use caddy's git plugin to kick off automatic builds bui…
raganwald.com uses github’s md-to-html thingy, which is jekyl. But there is nearly zero walled garden downside. I own the domain, I don’t use github.io, so I don’t fear link rot if I move. Because it’s git, I always have a copy of everything locally, I don’t depend on github for storage. Because it’s jekyll, I can generate my blog on my own system and upload it somewhere else whenever I want. I don’t support comments…
Yeah, you're always going to be reliant on third parties in a complex world. What is important is how beholden or locked in you are in any given arrangement. If you are free to move from one contractor to another because they are all interoperable, then you're independent in a more important sense.
Re: I Don't Want to Teach My Garbage DSL, Either
#15Earlier quoted context omitted.
In a dark past my company did: because these users were paying CMS users, they would not try to hack things, but rather because of the power of SQL and their lack of knowledge, they broke a lot which required backups to restore. We are talking mid 90s and Perl CGI scripts.
That sounds kind of terrifying.
Read only access to a replica databases seems quite a sensible choice for me.
If along you expose not the the real tables but views I honestly don't see what could go wrong.
Re: I Don't Want to Teach My Garbage DSL, Either
#16If your API is so complicated that it becomes a DSL, then perhaps there should be better communication between frontend and backend teams. Setting up a lean API contract makes more sense than creating an internal DSL or exposing internal data stores directly to users.
Re: I Don't Want to Teach My Garbage DSL, Either
#17If your API is so complicated that it becomes a DSL, then perhaps there should be better communication between frontend and backend teams. Setting up a lean API contract makes more sense than creating an internal DSL or exposing internal data stores directly to users.
Do you extend this criticism to GraphQL?
Re: I Don't Want to Teach My Garbage DSL, Either
#18A DSL can be immensely useful in terms of useability. But it is not trivial to be done right. You need to define a consistent grammar, make sure it's intuitive to your users and free of all sorts of fun bugs that happen when odd constructs are put together.
I think you're describing what Fowler[1] calls an "external" dsl ie separate lexer, parser, and code generator. The alternative being "internal" dsl, something that uses a languages own constructs to create stuff; ie like how Ruby is is used in several well known frameworks.
[1] https://www.goodreads.com/book/show/8082269-domain-specific-...
Re: I Don't Want to Teach My Garbage DSL, Either
#19Unrelated to the article, just found it interesting how he’s using github to literally auto generate his blog via their md-to-html thingy, and issues for comments.
It's not a bad idea, aside from putting your blog entirely on a third party like github. Utterances is the alternative to disqus that uses github issues.[0] Personally I think the best solution is using a static site generator like Hugo or Zola to control how you generate your content, and then host that using Caddy + Docker. A database is overkill. You can also use caddy's git plugin to kick off automatic builds bui…
If you use the static-generator approach, how do you do comments? If you just allow posts you open yourself up to many fun attacks.
Re: I Don't Want to Teach My Garbage DSL, Either
#20If your API is so complicated that it becomes a DSL, then perhaps there should be better communication between frontend and backend teams. Setting up a lean API contract makes more sense than creating an internal DSL or exposing internal data stores directly to users.
Some things are irreducibly complicated. You can't set up a lean API contract for a complicated thing without giving up power. The example of SQL is pertinent. Any attempt to set up a lean API contract for a relational database is doomed to be weak and painful to use. Without knowing the specific problem domain the blogger was dealing with, you can't know whether that was the situation. But if we assume they are competent, then we can assume a lean API was not possible.