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.
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."
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.
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.
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.
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.
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
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.
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.
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'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