As a haskeller, and shell scripter, I find this a refreshing and exciting experiment.
Much of the goodness of haskell, but with a much tighter focus and smaller scope.
No imports, language pragmas, packages or build tools needed;
all of the building blocks listed on one short page, https://chrisdone.github.io/hell/api.
More platform independent, robust, and regular than shell.
Potentially a nice learning language / stepping stone to haskell itself.
It's quite verbose right now, and I don't see much networking API yet, but it's just starting. I could see it easily growing into something very nice.
Interesting but not a great piece for anyone not into functional language design. A pretty deep dive into the "how" while completely ignoring the "why."
If you're giving a presentation, you should start by telling the audience what it is you're talking about. Someone in the audience won't have a clue, and usually most of the audience have no clue.
Thanks for this! I read that but I'm still not convinced. Quote:
They lean far too heavily on sub processes to do basic things.
I thought this was the whole point of a unix scripting language! Most of the scripts I'm writing are not interactive REPLs or string-parsers, they're glue code for batch-invoking commands on files. Stuff like converting a bunch of FLAC files into MP3 with lame or avi video files into mkv with ffmpeg.
What bash offers me is very terse command invocation and powerful filename globbing, including regexp substitution. Scripts like this are generally not intended to be used more than once or twice, and so a type system like Haskell provides is irrelevant here. If you're writing something that's going to be iterated on and maintained for years then you're writing an application, not a script.
There are a bunch of shell, Perl and Python scripts there, with some awk in between. These scripts are often copied almost verbatim between models and this, believe me, can lead to all sorts of errors.
The running joke around working with these scripts was "all these .sh should be .hs," i.e., these scripts should be implemented in Haskell.
This seems to be a deep tour of the implementation as much as the language. So it's not supposed to be a first principles talk. That's fine. It's not all for everybody.
How was this page generated? I have a marp presentation (https://github.com/jonocodes/awesome-keyboards) that I would like to have shown on a single page like this with the notes expanded.
I've wanted many things from shell but never to write Haskell in Shell. This turned something relatively naturally expressible into something so complex that requires type theory
There is no reason why one has to enjoy a haskell-like syntax over Bourne shell syntax but I think you're wrong about the tool. The author states that "It should have no abstraction capabilities (classes, data types, polymorphic functions, etc.)." Granted, there may be types but without those abstractions, I don't think you need to know much of anything about type theory.
Internal DSLs for Shell - https://github.com/oils-for-unix/oils/wiki/Internal-DSLs-for...
and ones in many other languages like Scheme and Lisp
e.g.
https://github.com/jgoerzen/hsh/wiki
https://github.com/luke-clifton/shh/tree/master/shh
And also a page of alternative shells:
https://github.com/oils-for-unix/oils/wiki/Alternative-Shell...