I don't think programming has yet stagnated enough for this to hold. For domain specific languages you need specified domains.
Little languages are the future of programming
91–100 of 216 posts
Re: Little languages are the future of programming
#92Earlier quoted context omitted.
CMake's perfectly fine once the Stockholm sets in.
It really isn't, but it is a bit like democracy, it could be better, but given the landscape and IDE integration capabilities, it is the best the C and C++ community alongside tool vendors have agreed upon. I certainly rather use CMake, even if I need an open book on the side, than Gradle, Blaze, autotools, yet another Python based build tool,.... However, most of the times, since my use of C++ is related to personal…
> it is the best the C and C++ community alongside tool vendors have agreed upon.
Well yeah but only because it's the only build tool that the C++ community has vaguely agreed upon.
Meson and Bazel are much better, but also much less popular.
Re: Little languages are the future of programming
#93Weren't they called DSLs a while ago?
The OP even uses "Domain Specific Language" in the article.
Re: Little languages are the future of programming
#94Author and comments are sticking to text based languages for some reason.
I think visual ones have proven to be more accessible to non-programmers. There are downsides ofc ... for programmers =) As a programmer myself I do not think it will be great to push visual languages too far but business is business.
Re: Little languages are the future of programming
#95People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. The problem is that your DSL has to be understood by other people, including future you. Programming tasks are vast, combinatorially explosive state spaces full of weird potential interactions between features…
And even if you do invest in proper documentation and support, you still have to overcome the hurdle that people just _don’t want to spend time learning your one-off language_ - there’s nontrivial opportunity cost in learning something that won’t be useful anywhere else. So people will just do the bare minimum which will lead to misunderstanding and bugs.
> people just _don’t want to spend time learning your one-off language_
Which people though? If you make a DSL that non programmers in your organization use, I'm sure they will appreciate not having to learn the intricacies of Rust or whatever's in fashion this week.
Re: Little languages are the future of programming
#96Earlier quoted context omitted.
It really isn't, but it is a bit like democracy, it could be better, but given the landscape and IDE integration capabilities, it is the best the C and C++ community alongside tool vendors have agreed upon. I certainly rather use CMake, even if I need an open book on the side, than Gradle, Blaze, autotools, yet another Python based build tool,.... However, most of the times, since my use of C++ is related to personal…
> it is the best the C and C++ community alongside tool vendors have agreed upon. Well yeah but only because it's the only build tool that the C++ community has vaguely agreed upon. Meson and Bazel are much better, but also much less popular.
The fact that there simply isn't a widely accepted build system just means it's not a solved problem yet.
Re: Little languages are the future of programming
#97hm, im a little unhappy about the author comparing Knuth's solution to a handfull of shell utilities.
for one, the author says knuths program written in WEB was 10 pages long, discounting the fact that these 10 pages are HEAVILY annotated.
my other point is:
tr has 1917 LOC,
sort has 4856,
uniq has 663
and sed is in its own package at around 10 MB
all including comments and docs for sed
it's fine and good that you can use composition with shell utilities, but come on, write that example program in C99 and you'll be a not very happy coder at all. in general i find the comparison rather rude. Knuth was supposed to show ?his? programming language WEB and as a "critique" McIlroy farts out a shellscript like "lmao first".
indeed, you do not often need to count word frequencies.
but what was this article supposed to be really about? software engineering 101 aka dont-reinvent-the-wheel/DRY?
or perhaps literate programming?
Re: Little languages are the future of programming
#98Earlier quoted context omitted.
It really isn't, but it is a bit like democracy, it could be better, but given the landscape and IDE integration capabilities, it is the best the C and C++ community alongside tool vendors have agreed upon. I certainly rather use CMake, even if I need an open book on the side, than Gradle, Blaze, autotools, yet another Python based build tool,.... However, most of the times, since my use of C++ is related to personal…
> it is the best the C and C++ community alongside tool vendors have agreed upon. Well yeah but only because it's the only build tool that the C++ community has vaguely agreed upon. Meson and Bazel are much better, but also much less popular.
Certainly not better in their dependency on Python and JVM, or IDE integration across Qt Creator, KDevelop, Visual Studio, Android Studio, Clion, VSCode, C++ Builder.
Re: Little languages are the future of programming
#99hm, im a little unhappy about the author comparing Knuth's solution to a handfull of shell utilities. for one, the author says knuths program written in WEB was 10 pages long, discounting the fact that these 10 pages are HEAVILY annotated. my other point is: tr has 1917 LOC, sort has 4856, uniq has 663 and sed is in its own package at around 10 MB all including comments and docs for sed it's fine and good that you ca…
Related: https://buttondown.email/hillelwayne/archive/donald-knuth-wa...
As you say, Knuth was asked to demonstrate his literate programming... In some ways this is a direct request for the non-pithy, articulated, first principles answer. I would more say Knuth was set up than that he was framed, but tomato-tomato. :)
Re: Little languages are the future of programming
#100People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. The problem is that your DSL has to be understood by other people, including future you. Programming tasks are vast, combinatorially explosive state spaces full of weird potential interactions between features…
That if you do it properly and not just amalgamate few "known" languages into some unholy monstrosity. I'm looking at you Ansible.
Generating data files via templating languages was never a good idea
Using data languages as essentially code is also similarly bad idea.
Ansible does both at once.