Readit NewsDCGs are lovely things that allow you to implement a toy example quickly but then the dragon appears and gobbles you up..
The scent of dragon's breath can already be seen in this example in a couple of places.
In the first place, using DCGs generatively is very interesting. It implies that you can write programs that generate strings as easily as parse them.
But the question of which grammars are reversible this way is very thorny. Even worse, this question is highly context specific. A grammar might be reversible in one context and not in another. Reversibility is also very delicate. Adding trivial changes to a parser can suddenly make it no longer reversible.
The second scent is the way that apparently small limitations in the Prolog language start to have very large implications in terms of program complexity. Since these limitations are inherited by the DCG framework itself, it quickly becomes necessary to either lose the attractive identification of Prolog expressions with syntax trees or to wind up with an explosion in program size.
An example appears in this article. The differentiation for each of the functions exp, sin, cos and tan involves a separate definition of the chain rule. For instance, we have
% Cosine derivative (+ chain rule)
derivative(X, cos(E), -DE*sin(E)) :-
derivative(X, E, DE).
% chain rule
derivative(X, F(E), DE*DF(E)) :-
derivative(u, F(u), DF(u)),
derivative(X, E, DE).
We can't do that, however, because Prolog doesn't support unification of functors. We could patch that if we started referring to function application with more elaborate syntax by parsing "sin(exp(x))" as application(sin, application(exp, x)) so that we could unify on sin, but this quickly obscures the syntax tree and removes the delightfully direct nature of DCGs.
We see problems popping up in the simplification as well. The problem of simplification is that you can wind up simplifying in circles which makes a depth first approach as used in Prolog very dangerous. The authors insert a cut to avoid this, but this also suddenly makes the entire system non-reversible.
The fundamental problem is that logic programming in the form of Prolog is practical precisely because of these limits. If you want more expressive power, you need to start talking about much more than unification and depth first search. At that point, you suddenly wind up with mechanisms like coordinate types which have the full expressivity of formal logic, but lose the simple execution of Prolog; simple type checking becomes undecidable.
Would the =../2 predicate help? It allows for you to unify functors without wrapping them in something like your application(exp, x) example. Not sure how it would interact with DCGs, though - never took more than a superficial glance at them.
I don't know, but perhaps due to the fact that due to the CJK unification in unicode, rendering Chinese or Japanese without explicitly setting a font designed for that particular language can output incorrect characters (of the other language, which are considered "the same character" despite being different). Thus, a translation tool would have to explicitly set a font in order to display these languages correctly in a reliable manner, because the surrounding context certainly cannot be assumed to have the appropriate font. And I could easily imagine that someone would choose to keep the same code path for all languages instead of branching for this particular case, resulting in a <font> even for languages other than those two.
Moderation can also be accomplished via a user-level web-of-trust system, where each user can choose who to trust as a moderator, and this trust can propagate recursively to the people trusted by the people you trust, and at each level (even when manually choosing people to trust) this trust can be fuzzy (not full trust vs no trust, but potentially something in between those two), and rapidly decreasing the more distant you get from those you've manually chosen to trust. To solve the issues of spam, censorship, and convenience simultaneously, you simply assign to users some moderators on the trust list by default and allow users to opt out of that trust.
This approach is also applicable in the same manner to the similar problem of curation (i.e. choosing what to highlight instead of what to hide), where the same four approaches are also applicable with largely the same pros and cons.
Speaking of, the above goes for technical professionals too: sooner or later, many of them will put their college kid tinkering hobbies aside and just buy a Mac, freeing up time they would have spent tinkering with a Linux distro to cook dinner for their spouse or play with their kids.
I used to be like you and believed it was senseless and harmful to believe there was a divide between users and programmers. I was smoking that "any user could become a programmer" copium in my 20s. But there is a divide and it's a wide, wide gulf. One of the things that got me to put the programmer hopium/copium pipe down was getting married. She's very smart, but she buys 100% Apple kit and doesn't have to worry about maintaining or configuring anything after initial purchase.
I don't, and I don't believe I'm even in the minority in that regard. What you are referencing is a stereotype that may reflect a minority of so called "techies", but even those are almost certainly only interested in building and configuring things within some specific field of interest, but still want everything outside of that to "just work".
> The rest of us have things to do, and would just rather buy the functionality they need in a ready-to-go and easy-to-use form.
A false dichotomy that is often repeated, but incorrect nevertheless, for it is the proprietary ecosystem that keeps breaking things over and over again, changing UIs, features, and even very basic settings you've set, dropping support for various things (apps, devices, etc.) you might still use and that still work fine.
My linux installations have made everything work directly out of the box (unlike some properietary systems where you have to install things and fiddle with settings to make things work) and have stayed almost identical in terms of their UI and already-existing features for a decade now (and could have for quite a bit longer if I had adopted linux earlier). No properietary system could come even close to this level of "just works"-ness (though apple probably gets far closer than the others).
The vast majority of real, ordinary *users* don't really care.
In most (all?) IDEs you can also tell the IDE to treat the file with a certain extension as written in any language
I am terrible at git on the terminal, but with IntelliJ or emacs and magit, I can trivially find every commit ever to change a file, and easily navigate the commits to see every full commit message. It's not hard when you use a proper tool, and I have a feeling almost everyone has something like that?! Do you really try to stick with the git CLI and memorize hundreds of commands and flags?? Why?!
But more importantly, the CLI allows my typical workflow where I chain together a bunch of git (and other) commands in a row, allowing me to just type in, for instance, several different commits, their messages, and what files should go into each in one go without having to break my concentration by having to move around in some GUI between commits. Sprinkle in some stash manipulation and interactive rebases, compilation, and unit testing, and you'll really start to see how the CLI allows you to offload some of your working memory to your invocation in a way that a GUI just can't.
And nobody reads it because there's so much of it and there's no clear starting point. People just want the summary of what they're looking for.
I started to learn Java almost 20 years ago, we had a text book and everything. After the first two chapters, I learned how to google and instead of reading everything, just find what I need. I never went in-depth with reading because... it's mostly useless knowledge that quickly becomes outdated.