What modern alternatives to `.sh` scripting exist? Tcl? Is Fish objectively better than Bash and ZSH? Are there any thin wrappers and transpilers on top of sh? Or maybe just good old Perl?
And how does this project address normal pain points of shell scripting, like using arrays and iterating on them for example?
I was thinking a lot on the topic lately and currently have no good answers (never studied the topic in detail). I suppose just replacing `sh` scripting with Golang is also an option. Not the strongest typed or least verbosive language out there but it has a very good cross-compilation story, compiles really fast and produces single binaries that are easy to distribute. So might go with that.
Python is out because startup time wasn't great last I used it for CLI tools (might be an outdated info however, any metrics)? Ruby is also a pretty solid candidate; the lack of static typing is, eh, 50/50 -- might not be important after all.
I also know a guy who replaced Python with OCaml for quick scripting which is rather bizarre to me but knowing a bit more about OCaml nowadays, that actually can work just fine -- and OCaml is very terse.
I would prioritize speed of startup and terse code over everything else. Static typing I want but can very likely do without. I don't care much how portable the program/runtime is; I can distribute it to my machines and I have some influence in my work about what tooling to use.
Now that you mention OCaml, I have been using the OCaml dialect F# for scripting.
It works just like any script (.fsx files) and you can also compile it ahead of time.
There is a REPL for experimenting and the type system provides for a superior IDE experience.
It has the full .NET ecosystem at its disposal. And algebraic data types to ensure you cover all edge cases.
And last but not least - if you are scripting any kind of data wrangling, the Type Providers feature of F# offers a very powerful way to build those ETL jobs with type safety with just a few lines of code.
For my most common uses cases - daily jobs to fetch data from remote APIs, clean, transform and combining data sets in a batch pipeline - the startup time has not been an issue.
Most steps are short scripts of a few hundred lines and compile quickly.
Downloading dependencies (libraries) may take a while depending on how much you pull in from e.g. NuGet (seconds not minutes) but you can keep these between runs.
For historical context, around 1994, I ditched shell with heavy awk and add use in favour of Perl to avoid the heavy overhead of multiple processes being spawned by the shell scripts.
So you have to know both what you need but also which alternatives you are benchmarking it against.
Yeah, I can accept the argument that usually startup time doesn't matter. But since I finally got fed up with shell scripting, I want to find a proper viable long-term alternative. I know that for most of my scripts I won't care neither for startup time nor for strong typing (just an example, I know that OCaml and thus F# have it) won't be necessary. But I just want to have a powerful tool in my hands for those few outlier cases where you'll get pissed off at slow startup.
But I can still agree with you!
> For historical context, around 1994, I ditched shell with heavy awk and add use in favour of Perl to avoid the heavy overhead of multiple processes being spawned by the shell scripts.
I feel a novice now. :D
To be fair, there weren't things I wasn't able to achieve with zsh scripts and `parallel` and the usual suspects (sed, awk et. al.) but when I measure how much time -- and sometimes sanity -- I lose until I make something rather trivial work, the analysis isn't in favour of my current workflow. 500 "quick and dirty" scripts each wasting you 3h as opposed to 5-10 minutes amounts to a LOT of wasted work time.
To be fair, I was not inclined to use F#. OCaml always impressed me with its amazingly fast compiler. But you have a very solid point that with F# you can use the entire .NET ecosystem...
> So you have to know both what you need but also which alternatives you are benchmarking it against.
I don't know exactly what I need, for the better or the worse. I just want to do one big switch (away from sh/bash/zsh scripting) and not have to redo it anytime soon, is all.
Most tasks are I/O bound anyway so normal shell scripting and `parallel` can take you VERY far. But I've been bitten by weak typing and surprisingly parsed values so I am looking for something stricter. Runtime speed is hardly relevant to anything because again, I/O bound is the norm (_especially_ when you work with the network; most network-bound tasks that people put in their scripts nowadays could easily be handled by a Pentium III from back in the day, I feel).
I don’t think you will find a silver bullet. If you switch away from shell and its set of trade-offs you will face another set of trade-offs with the next language.
The art is to select trade-offs that benefit the main line of work you want to do without causing too much trouble.
Personally my scripting preferences have changed over time depending on the types of problems I had to solve and what else I were doing at the same time. I have never found The One Solution but seen things slowly change back and forth over the years.
> I don’t think you will find a silver bullet. If you switch away from shell and its set of trade-offs you will face another set of trade-offs with the next language.
Sadly that's quite true.
So let me correct my statement: I am looking for "shell scripting on steroids" for when I intuit (or discover after 10 minutes of trying) that normal shell scripting won't cut it. I'll still use it but I want to have an extra tool in my belt for those cases when I need something a bit feature-rich but still quick to iterate on.
For now, looking through the sub-thread and brushing off on old knowledge and searching the net for an hour or so, my 3 top contestants are (in that priority order) -- OCaml, Ruby, the RC shell.
> I also know a guy who replaced Python with OCaml for quick scripting which is rather bizarre to me but knowing a bit more about OCaml nowadays, that actually can work just fine -- and OCaml is very terse.
> I would prioritize speed of startup and terse code over everything else.
If speed of startup and terse code are all you want... what's the problem with OCaml? It's got static typing too.
The only problem is that I'm a novice in it and it will take some significant investment of time and energy to learn it well. Which I still plan to do.
Was just wondering if there are replacements for shell scripting that are quicker to learn.
Ruby is fantastic for scripting. It has quite a few of the same conveniences that made Perl great for scripting and it's a lot easier (for me at least) to maintain and understand when seeing it months or years later.
Yes, yes yes. I started Ruby because I got a job at a Rails shop. I didn't like it all that much for a while, but then I decided to write a CLI program in Ruby and break out of rails.
I quickly realized nearly everything I didn't like about "ruby" was actually rails. After a couple of years I moved on and don't do rails anymore, but I ruby is still my go to for any script that requires arrays or maps (the point where bash begins to be really painful).
Ruby is the best scripting language ever IMHO*. Ruby one-liners (inherited from Perl tradition) make it plug nicely into a bash script also.
> time ruby hello.rb
Hello, world!
ruby hello.rb 0.11s user 0.13s system 81% cpu 0.297 total
> time node hello.js
Hello, world!
node hello.js 0.10s user 0.16s system 84% cpu 0.307 total
The API seems to have changed a bit since I last used it, so not sure how nice the current version is. It's also apparently used by a shell-like language called Rash, but I've not used that either https://docs.racket-lang.org/rash
The only thing I really miss from scsh is the process notation (which is arguably the hardest to implement). The rest is pretty well covered in most schemes. Srfi-115 has sexpr regular expressions, srfi-166 is, IMO, the best formatting utility there is.
not very 'alive', but there is a 64 bit port to current scheme48 around, so it can still be used. didn't really make it to distro packages (yet) however
As an aside, it's really cool to see that Naver is not only open sourcing a lot of their technologies, but doing it a lot of it in lisp too.
For those who aren't aware, Naver is the Google/Yahoo equivalent in South Korea. Their main product is a search engine and web portal, but they also have community pages (Naver Cafe), Music, Translation, Webtoons (webcomics) and so on. They have a subsidiary company that's created the LINE messenger app.
Always nice to see cool new lisp projects. The shell angle there also reminds me of guile and especially babashka: https://github.com/babashka/babashka
There's also closh (https://github.com/dundalek/closh) which also provides scripting capabilities appart from the pure interactive shell.
As a newcomer to clojure my question is: what would be the practical differences and deciding factors for doing what would be a ".sh" in babashka vs closh?
Practically, mindshare, because that translates to longterm support and ability to get help if you need it. I know lots of people that use babashka but not a single one that uses closh. Of course, I see the irony in making the popularity argument for a lisp! :-)
I have been interested for years in Data Programming, a weird expression coined by Christopher Ré (PR at Stanford). Basically, the idea is to be able to automatically apply filters on your data before building your model in an ML pipeline. This version of Lisp comes with data structures and pattern matching expressions, to detect some regular patterns in your data... This is the reason why we also have implemented a Python library so that your sieves can be called from within your Python code beforehand.
Yes, good idea. I don't think it would be that complicated... Actually, the language already exposes a "split" method that can be used exactly for that.
What modern alternatives to `.sh` scripting exist? Tcl? Is Fish objectively better than Bash and ZSH? Are there any thin wrappers and transpilers on top of sh? Or maybe just good old Perl?
And how does this project address normal pain points of shell scripting, like using arrays and iterating on them for example?
I was thinking a lot on the topic lately and currently have no good answers (never studied the topic in detail). I suppose just replacing `sh` scripting with Golang is also an option. Not the strongest typed or least verbosive language out there but it has a very good cross-compilation story, compiles really fast and produces single binaries that are easy to distribute. So might go with that.
Python is out because startup time wasn't great last I used it for CLI tools (might be an outdated info however, any metrics)? Ruby is also a pretty solid candidate; the lack of static typing is, eh, 50/50 -- might not be important after all.
I also know a guy who replaced Python with OCaml for quick scripting which is rather bizarre to me but knowing a bit more about OCaml nowadays, that actually can work just fine -- and OCaml is very terse.
I would prioritize speed of startup and terse code over everything else. Static typing I want but can very likely do without. I don't care much how portable the program/runtime is; I can distribute it to my machines and I have some influence in my work about what tooling to use.
Any practical recommendations?