Happy New Year, Branden - and all. On 01.01.26 19:58, G. Branden Robinson wrote:
> Hi Erik, > Happy New Year! > At 2025-12-30T02:00:17+0000, dvalin--- via GNU roff typesetting system > discussion wrote: > > They say language forms our thinking. I find that yacc/bison forms the > > grammar. > > Prompted by our recent discussion I went back and read the original YACC > paper (and had a light bulb moment about dc(1), but I'll save that story > for another time). There's a lot in there I had forgotten about. An > important element is that YACC uses the ordering of rules to lend > priority to productions, which can silently resolve some conflicts. I'll have to take a look at that, to refresh understanding. I can see it in the |-ored lines of a rule, but beyond that, it's grammar all the way down, I figure. ... > Simplifying GNU troff's grammar has been a (largely unplanned) theme of > my work in the 1.24.0 release cycle. > > I know I'm gonna get yelled at for it, though. If there's no yelling, then you're not pushing the envelope. Grammar simplification improves both maintainability and reliability of any enhancements/extensions. And more explicit user source is more readable, and that comes with simplicity, I submit. ... > My favorite job, though, was at a research lab. I think you > need both scientists and engineers, because each can anticipate > different ways that things won't work. > > Junior practitioners are full of ideas, overly optimistic notions, and > unrealistic notions of scheduling, which apart from the cheaper wages > they tolerate is why bad managers love working with them. They provide > plenty of smoke a first-line manager can inhale and then go blow up the > rears of the bigger bosses. And when the schedule slips, as it almost > always does, the junior engineers are there to take the blame for their > poor estimation skills. When you're the manager and it comes time to > lay off staff, they've already given you all the excuse you need to chop > them--you don't need to do any thinking. Thinking bad! It was my great good fortune to design & develop embedded systems in the pioneer era, much of it in assembler or my own macro languages. Managers only intruded to enquire about progress, most of the time. After the first decade, I found that the team collectively estimated about 25% low, so I added 30% in my Gantt charts. After that, we always finished on time. Mind you, I also stole many a manweek to develop custom tools, for improved productivity. That provided additional freeboard for final bugslaying. (As with offering my intended solution, plus two stinkers, when asked for three ways forward, these measures were mainstays of my "Upward Management" process.) > That said, once in a while a practitioner, junior or otherwise, comes up > with a neat idea. At its best, one of these is a win for everybody. > Management gets a deliverable, the practitioner gets satisfaction and > (ideally) peer respect, and the scientists have something new they can > adapt to purposes unforeseen by others and--the best part--get to try to > figure out how they can break it. My rule was always to praise a team member in public, and correct in private. A leader achieves nothing more than his team's success, so the only thing more important than encouraging them is enabling them. (Assuming you've selected competently.) ... > > They say that writing believable engaging dialogue is difficult - but > > you have it down pat! > > Thank you! For that and for overlooking my failure to write "R&T" or > "T&R". I'm over-accustomed to sticking Kernighan's initial in things. > > Like many, I'm a frustrated writer. > > "Everybody does have a book in them, but in most cases that's where it > should stay." -- Christopher Hitchens That's doubtless true - and the time, effort, and skill acquisition required to author an engaging book is often possible only in retirement, I think. But some say it is worthwhile to go through that, even if it is never published. In my view, a code designer/implementer who produces/enhances a tool of use to many, is a memewright, creator of writing which leaps off the page and carries out useul tasks. It does not merely amuse or entertain. And groff, with a bit of some sort of markup preprocessing to ease generation of italics, could be handy if the book does materialise. ... > I find AWK fascinating. To me, it seems close to a sweet spot in the > programming language design space. I should do some more thinking and > figure out why. Maybe it has enough features to be widely adaptable to > problems but at the same time it refuses to yield to the siren song of a > module system or "standard library". It seems inevitable that any > language offering that facility becomes weighted down by reference > material. In my career I've been disappointed that most of the fun of > learning a PL is front-loaded. You get the basic concepts/modeling/ > "paradigms" and, often, you can see how it's good for something and can > help you solve problems. (And other people have seen that too, which is > how you hear of it in the first place.) The thin, handily indexed, Addison Wesley reference was my bible. Then something on-line, after the coprocess interface was added. Now that's the *nix way to blow away limitations. My infatuation resulted from its ability to defeat complexity with simplicity - regexes in the code, both constant and variable, plus associative arrays. A vendor of an ITUT SDL compiler suite, $0.2M per seat 20 years ago, included as a minor feature, a state machine State Reachability test tool. I wrote and debugged one in a rainy weekend, spent in Bangalore - using AWK. ... > But AWK? AWK hasn't bloated. Maybe Perl "stole its thunder", by which > we mean "took the bullet". I tried Perl - briefly - and confirmed that it is the quintessential "Write-Only language". > Or--maybe--AWK occupies, or is near propinquity to, that really sweet > spot in n-dimensional programming language design space I spoke of. > > So if I ever write my own AWK, I have a name for it. AWKupy. > > Mascot? A porcupine with a Guy Fawkes mask. Ah, that is more assertive than AWKword. No porcupines in Aus, but when I drained nigh on 200L from the rainwater trunk between roof and tanks this week, an echidna rushed at least 100m, in 42°C (108°F) heat, to the outflow drain, stuck its beak into the end of the stream to confirm it wasn't a mirage, then waded upstream to the deepest point, and settled to the bottom, refusing to move, even though I was barely 5m away. Regards, Erik
