[bvanderveen]

Presumably it's meant to be used when you're writing a shell script and you have some problem in front of you that would be trivial to solve in a real programming language and you find yourself saying a sentence starting with "I just wanna…" and rage-googling or asking ChatGPT or whatever.

[stingraycharles]

Would be great if it could show some things it can do that awk can’t. Because awk is typically my Swiss Army knife if I run into these situations.

[bayindirh]

I think it's written by someone who finds pipes and awk too awkward to work with.

I know people who can't be bothered to learn these tools and write complete programs to solve problems instead of a shell one-liner.

Looks similar.

Edit: My brain skipped words while typing.

[booniepepper]

> I think it's written by someone who finds pipes and awk too awkward to work with.

Actually it's exactly the opposite, it's born out of a love for pipes, and shells, and tools like awk. If you know anyone working at Amazon, ask them to search "11 years of work in a weekend" for a tale of shell heroics that I wrote about while I worked there.

dt is intended to be a new tool in the "shell one-liners" category, just with concatenative FP semantics. :) It will not be everyone's cup of tea, and I will still love and use awk when appropriate

[foul]

> I think it's written by someone who finds pipes and awk too awkward to work with.

This one of substituting AWK/shell/sed/Perl with a forth-like lang is a good idea in a sense, it doesn't break the flow because presentation comes later and logic is at the beginning of the dt part, with the aforementioned tools you have the logic and output mixed all over the place. I will however still use AWK.

[bayindirh]

> ...it doesn't break the flow because presentation comes later and logic is at the beginning of the dt part

I didn't mean to discredit the work done. It's a big undertaking in any case. The idea and the aim is good, however it breaks the conciseness and reduces the speed of implementation.

> with the aforementioned tools you have the logic and output mixed all over the place.

I think this is a secondary effect of composability, pipe and conciseness requirement.

> I will however still use AWK.

Me too, and this is why I made my prior comment, exactly.

[booniepepper]

awk is an inspiration, and a great simple tool. Not trying to compete, but add more tools in the space.

Probably dt will never be able to do things that awk can't do... At least for the non-trivial things. But I think it will be able to do some things with a more readable/declarative syntax.

I'll fill this out later, but imagine dt as trying to be a shell-friendly Functional Programming riff on awk, with first-class functions and no need to regex match or BEGIN etc. At the end of the day, assuming it catches on, I suspect choosing dt will probably be more often about taste

[usrbinbash]

> you have some problem in front of you that would be trivial to solve in a real programming language

Which is the exact point in time when I solve the problem by using a real programming language.

[e12e]

Isn't that why Larry made perl? To avoid using a real programming language like awk? ;)

[NullInvictus]

My read as well.

I write shell-scripts when the current tools solve the problem easily. I distribute shell scripts to colleagues (never customers) only when I absolutely do not want to install extra software on their system.

I avoid awk and perl because if I'm going to introduce a second language to a tool, I'm not going to pick the niche ones everyone only learns opportunistically if at all. At that point I'd rather pick something my colleagues are deeply familiar with.

And on a small level, writing these little binaries that truly do one thing and do it well and that I understand intimately is a private joy.

[RadiozRadioz]

Awk and Perl niche? How about "reliably installed on every GNU/Linux box this side of the century". Their fault for not knowing their own systems. Anything pre-installed is fair game.