Here's a thought. Not sure of the logistics of it but perhaps it could be used to build tools for an IDE environment. Could start with trying it with Neovim and Emacs and of course there's VSCode/VSCodium as a plugin. A lot is text manipulation so what better place for that. I mean I know you talked about that a bit at 17:30 but didn't mention how that would look.
I personally love mixing Python and bash. I do agree that keeping the tool chain simpler is better and I stick to plain bash when I can. But the dependencies issue would apply equally to dt if it was in my tool chain.
I'm still thinking through the dependencies issue and what can be done here, so some of this is still thinking out loud. (I also love mixing Python and Bash and AWK and a ton of other languages. It's kinda my thing) With Python (and Perl, Ruby, Raku, etc) the problem some large codebases can end up with is dependencies that span multiple dimensions. A non-trivial number of software packages in the distro can rely on the version of the interpreter. The package manager itself (e.g. yum) can depend on the version of the interpreter. Unmodeled dependencies in bootstrapping scripts can also depend on the version of the interpreter. This is where upgrades like the Python 2.7 upgrade can get very very hairy. My idea with dt is that it's unlikely to be attractive for general purpose programming in the first two (large) domains, which simplifies using it in the last (small) domain. I could totally be wrong or fail at this in a number of ways. It's also not a language that needs a steady stream of change over time (since it will avoid things like networking, and use functional semantics) so I believe it can result in an as-stable-as-awk implementation. What's driving my intuition here is that in a package manager ecosystem no one states that they take a dependency on POSIX utilities like awk, bc, grep, sed, etc. or other common utilities like tar. (Except things like Nix and Guix) Depending on POSIX and coreutils (or busybox etc) is sort of implicit, but it also sort of just works since the software is well-defined and stable.
forth uses a threaded code execution model. This was a thing in the late 60s and 70s as memory was a scarce resource and threaded program binaries were more compact. The predecessor to the famous C language, the programming language B, used a threaded code execution model. Oh, and as the Wikipedia entry for "Threaded code" notes, this term is not to be confused with multi-threading concurrency - totally unrelated.
Here's a thought. Not sure of the logistics of it but perhaps it could be used to build tools for an IDE environment. Could start with trying it with Neovim and Emacs and of course there's VSCode/VSCodium as a plugin. A lot is text manipulation so what better place for that. I mean I know you talked about that a bit at 17:30 but didn't mention how that would look.
Thanks everyone for watching!
Talk notes at 42:52
Best demo of dt as a language is when I debug the presentation itself starting at 45:15
@booniepepper debugging mid-talk like a boss! lol Great talk. Looking forward to looking at the dt source code.
Thanks haha. I got to live-learn string escaping in a shell context for the 10,000th time
I personally love mixing Python and bash. I do agree that keeping the tool chain simpler is better and I stick to plain bash when I can. But the dependencies issue would apply equally to dt if it was in my tool chain.
I'm still thinking through the dependencies issue and what can be done here, so some of this is still thinking out loud. (I also love mixing Python and Bash and AWK and a ton of other languages. It's kinda my thing)
With Python (and Perl, Ruby, Raku, etc) the problem some large codebases can end up with is dependencies that span multiple dimensions. A non-trivial number of software packages in the distro can rely on the version of the interpreter. The package manager itself (e.g. yum) can depend on the version of the interpreter. Unmodeled dependencies in bootstrapping scripts can also depend on the version of the interpreter. This is where upgrades like the Python 2.7 upgrade can get very very hairy.
My idea with dt is that it's unlikely to be attractive for general purpose programming in the first two (large) domains, which simplifies using it in the last (small) domain. I could totally be wrong or fail at this in a number of ways. It's also not a language that needs a steady stream of change over time (since it will avoid things like networking, and use functional semantics) so I believe it can result in an as-stable-as-awk implementation.
What's driving my intuition here is that in a package manager ecosystem no one states that they take a dependency on POSIX utilities like awk, bc, grep, sed, etc. or other common utilities like tar. (Except things like Nix and Guix) Depending on POSIX and coreutils (or busybox etc) is sort of implicit, but it also sort of just works since the software is well-defined and stable.
forth uses a threaded code execution model. This was a thing in the late 60s and 70s as memory was a scarce resource and threaded program binaries were more compact.
The predecessor to the famous C language, the programming language B, used a threaded code execution model.
Oh, and as the Wikipedia entry for "Threaded code" notes, this term is not to be confused with multi-threading concurrency - totally unrelated.
nice tool... syntax reminds me REBOL
Why on Earth would you make '\' syntactically important in a language designed for one-liners?
Go boonie!!
dt as in "strong and complicated password" :D
Love that DistroTube meme 😂