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.
FWIW there are several Haskell and OCaml shell projects on this wiki page, which is editable:
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...
Good reminders; just not readily seeing Babashka (Clojure through GraalVM) so mentioning here for sake of sexp closure.
https://github.com/babashka/babashka
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."
Or indeed the "what". Did he ever show an example of what the shell scripts look like? I couldn't see it.
The first link takes you to the home page, which links to examples; probably a better starting point.
https://chrisdone.github.io/hell
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.
Chris discusses the rationale in his blog post at https://chrisdone.com/posts/hell/
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.
Let me introduce to you Kaldi, a speech-to-text engine. I put the link right into models directory, to save you some time.
https://github.com/kaldi-asr/kaldi/tree/master/egs
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.
> generally not intended to be used more than once or twice
on that note: https://news.ycombinator.com/item?id=41489436
For those like me who want to see actual examples of Hell scripts: https://chrisdone.github.io/hell/examples/
Why are there no examples with "#!/usr/bin/env ghc" at the top?
It's not a shell script without the Linux incantation stanza.. for reals. How are you going to get started without the proper boiler plate?
It's "#!/usr/bin/env hell" - this isn't ghc. See https://chrisdone.com/posts/hell/
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.
(Ideally it should be #!/usr/bin/env descend, to folloe the style.)
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 really like this page, with slides on the left and blog on the right.
I bet reddit.com/r/ProgrammingLanguages/ would like this.
I love these names!
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.
You could use the Scheme Shell instead, if you don't like static typing.
https://en.wikipedia.org/wiki/Scsh
And specifically https://en.wikipedia.org/wiki/Scsh#%22Acknowledgments%22