4 ms·
Of possible interest - instead of making a whole new programming language like awk, you can also just systematize generating code for an existing one with a com
by cb321 3y ago
Of possible interest - instead of making a whole new programming language like awk, you can also just systematize generating code for an existing one with a command-line harness.
This can even stay terse & keep a fairly fast edit-test turnaround in a fully statically typed language like Nim: https://github.com/c-blake/bu/blob/main/doc/rp.md https://github.com/c-blake/bu/blob/main/doc/rp.md
- macintux 3y agoWhole new language? Awk is 45 years old.
- cb321 3y agoI agree that "writing/learning a different" (what I meant) is more clear wording than "making a whole new". EDIT: and it is a fair counterpoint that any command with options is, in some sense, also a different language one must learn. Learning API calls is also a different language (at least nouns & verbs if not syntax). But that is all partly the point. awk did/does a programming language with different syntax where other alternatives might be enough.
- BaseballPhysics 3y agoIf you think that's a good idea, you don't understand why tools like awk/perl/sed/etc exist and are popular. They are, by design, optimized toward specific kinds of use cases. In fact, their dynamically typed nature is a perfect example of that since it's much easier to quickly manipulate strings in a language that isn't so strict, as they'll do more heavy lifting for you via automatic coercion while limiting extra syntax/boilerplate (which, granted, is less of a problem with modern type inference). That makes it a lot easier to toss together quick one-liners and glue code, which is where these tools shine in the first place. Hell, even something like python or ruby is just a little too structured for my taste when doing something quick and dirty, which is why I love perl as it can be unstructured if that's all I need, or I can create a more structured program if that's what the problem requires.
- cb321 3y agoIt's just a different & in my experience often neglected point in a similar design space (as that initial, linked text argues). Your tastes & use cases are your own. Almost everything "all depends" upon so very much in computer systems & in life. To add some more color, Nim is also a very adaptable prog.lang. I believe there are converts from Perl in its fan base. Nim's creator long ago recreated some Perl in Nim: https://nim-lang.org/araq/perlish.html https://nim-lang.org/araq/perlish.html Anyway, it's a different set of trade-offs to consider which I thought some reading about learning awk with open minds might find interesting. That's all, really.
- kazinator 3y agoSo Awk is a whole new language, but Nim isn't?
- cb321 3y agoI never said Nim was unique | older than awk. While I cannot make you read my cousin comment to understand I meant "new" as clarified-"different" [1] or click through any links, I can perhaps non-redundantly emphasize that the mentioned approach "works" not just for Nim, but for any language, C & Go (impls refd in mentioned `rp.md`), and Python in another comment in this comment thread: https://news.ycombinator.com/item?id=37295399 https://news.ycombinator.com/item?id=37295399 (maybe even with `eval` there!) Only, the approach "works" with differing levels of "success" for different use cases / contexts. It is true (whichever) shell language is still there to differ in shell 1-liner cases. That is also true of sed / awk / perl / ... If you don't want to click through on `rp.md`, you could also read Ben Hoyt's article on his Prig if you like: https://benhoyt.com/writings/prig/ https://benhoyt.com/writings/prig/ discussed on HN a while back https://news.ycombinator.com/item?id=30498735 https://news.ycombinator.com/item?id=30498735 It's not actually that different from your `cppawk` that you mention elsethread.. just maybe rotated 27 degrees away in "idea space". ;-) [1] https://news.ycombinator.com/item?id=37293475 https://news.ycombinator.com/item?id=37293475