On Mon, Jul 18, 2016 at 3:17 PM, Rob Landley <r...@landley.net> wrote:
>> This is the problem with DSLs... shell, make, awk, and presumably bc >> all started out as very specific languages, for different purposes. >> Over time, they all grew a C-like imperative language. And nobody >> wants to remember 3 or 4 different syntaxes for that: <...> >> It does seem that if you rule out Python/Perl, > > And ruby, php, java, javascript, tcl, lithp, go, swift, rust... <...> > back under OS/2 there was something called Rexx, Apple had AppleScript... REXX began on mainframes, supplied with IBM's VM/CMS OS, and is now in a lot of places. It got ported the the Commodore Amiga as the scripting language. IBM now calls if Open Object REXX, and it's available as open source for Windows, Linux, and OS/X, Mark Hessling maintains a variant call Regina REXX that is also open source and cross-platform, and there are others like BRexx. I have a flavor of REXX on my Android tablet. >> However, I did a bunch of research and hacking on Kernighan's Awk. I >> was trying to morph it into a "proper" modern language. > > Another one? > > why? > > Presumably you wouldn't remove anything significant from the base > language, since that would break compatability with existing awk > scripts, so your reaction to awk was "how could I fork this to make it > bigger"? > > This feels like a variant of https://xkcd.com/927/ somehow. <grin> The reason is presumably to reduce the number of languages a programmer must learn and remember. But Andy's comments earlier about remembering those different syntaxes overstates the issue. As a rule, you learn and recall the syntaxes you actually use. You probably have to learn and use more than one, but you know that going in. You likely aren't going to learn/use a lot of different scripting languages, because they address specific domains you may not be working in. Under Unix, I gained reasonable fluency in the Bourne shell language, and added the extensions in ksh when it got to the point where it could be installed as /bin/sh. Under Linux, I use bash, but it might as well be the Korn shell for my purposes. I've simply had no need for the additional bells and whistles bash added. I occasionally used awk and sed for domain specific stuff not intended for doing in the shell, and learned just enough perl to be dangerous because it got deeply embedded in system administration chores. These days, I'm watching a few distros move to doing everything in Python with some dismay. > The lua thing fell apart trying to write mount, ifconfig, netcat, > losetup, nsenter, ionice, chroot, swapon, setsid, insmod, taskset, > dmesg... The language just didn't have the bindings. I rather like Lua, but I bear in mind the domain it addresses. It's intended to be an embedded scripting language you can call from within your application. You can't write stand alone Lua code because it lacks the infrastructure. It assumes the application it's embedded in will handle that, and it doesn't need to. It's gotten a fair amount of pick up as the script engine for games, and there are a couple of IDEs intended for writing Lua used in games. It's also popping up as the script language in editors. One of the things I'm poking at the TextAdept, an extensible text editor. It uses the Scintilla edit control, and Lua for scripting. The C code is under 2,000 lines and will remain so (and is basically the framework to embed Scintilla and Lua.) The actual editing functions are written in Lua, and you can extend it all over the map by writing Lua code, in a manner akin to extending Gnu Emacs in eLisp. The Lua code is currently about 4,000 lines. > There are an awful lot of scripting languages. And new ones emerging all the time, with a Darwinian natural selection going on as they struggle to define the specific problems they are addressing and see whether enough other people have those problems to gain traction. > One of the reasons some of these tools fall out of use is the > documentation for them is terrible. (Gnu man pages often point to "info" > pages nobody will EVER read and which sometimes _still_ aren't online.) > I'm trying to write --help text for each command that's sufficient to > learn to use the command just from that. It's not easy and I'm not happy > with a lot of the results (terse vs complete vs easy to read, pick 2). > Working on it... This is something I was unhappy about from the days when I was learning Unix using SysVR2. Documentation was man pages, but the man pages were references which assumed you already had background knowledge. They were not tutorials. (And they also implicitly assumed there was a guru on site to supply the background knowledge you might lack. If you *were* the guru on site and didn't grok the man page, you had trouble right here in River City.) Given how Unix was developed, it was likely inevitable. Many Unix tools were the products of developers at Bell Labs scratching personal itches, and everyone was at Bell Labs, so you could talk directly to the guy who wrote a tool to clear up misunderstanding. Once Unix escaped into the wild, that happy circumstance vanished. > It would be nice if there were some youtube clips on "an introduction to > sed", "an introduction to awk", and so on. I might wind up doing them > someday if nobody else beats me to it. Oh, crap. Sorry, but one of my pet peeves these days is the increasing use of video as documentation. Video has a place, but I can *read* much faster than I can *watch*. Give me a bleeping written tutorial, that I can have open in one window while I experiment in another. > Rob ______ Dennis https://plus.google.com/u/0/105128793974319004519 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
