Ammonite-Ops VS refined

Scripting API is quite limited, so the third option. - reuse the ammonite scripts https://github.com/com-lihaoyi/Ammonite or look how this is implemented (using internal compiler API),

Your exposure to Functional Programming with Haskell and Clojure suggest you will certainly pick up Scala quickly. With ZIO and cats, you can write robust software quickly. Consider the excellent Coursera Scala course. Get "the Red Book" https://www.manning.com/books/functional-programming-in-scala, and most important, play. Experiment to see how things work. Get https://ammonite.io/

Here's an example of a smaller project that added telemetry without suffering a fork:

https://github.com/com-lihaoyi/Ammonite/issues/607

Or ammonite - I've ran Gatling performance test from a simple script based on this gist it fetches all the dependencies, compiles and runs the test, producing nice html report..

Scala with the Typelevel ecosystem. Stay on the jVM, but have a much more pleasant and robust experience, including a great REPL.

If you are installing, and you are learning, I would also recommend ammonite as an easier REPL.

I've been using amm on and off https://ammonite.io/#Ammonite-Shell

pretty nice if you know scala, still have to use regular shell(s) so I do not forget them

I've never tested Ammonite, only read the https://ammonite.io/#Ammonite-Shell, so I'm only guessing here.

From what I understand, Ammonite was designed as a "readline shell" as I wrote in the article. It perpetuates this approach that everything is a command.

The thesis of my article suggests we do the opposite: I'm suggesting to rethink shells by starting from the interface (here the SLY REPL) and then implement the shell features.

In particular, it seems that Ammonite does not support back-references and I'm not sure it has an interactive inspector.

While Ammonite seems to be a definite improvement over the _syntax_ of Bash, etc., I'm not sure it brings much novelty in terms of user interface. But again, I know very little about it so I may have missed some features :)

I wonder what people think about Ammonite (https://ammonite.io/)?

It's not Lisp but Scala so may not be the authors language of choice however it can be used as a Shell: https://ammonite.io/#Ammonite-Shell

I am personally using it and compared to a classical shell like Bash it's really nice for more structured data related tasks (exploring some API, checking some data, creating a bunch of PRs at once, ...).

It also makes use of Scala's adjustable syntax and functional concepts so you basically get shell piping but in a strongly typed fashion (e.g.

Perhaps refined would help you? It lets you set constraints (i.e. "rules") for values / types. You get compile-time enforcement for constants and fallible methods for runtime values (i.e. Either[Error, RefinedValue]).

This is more or less how derivation works when you want to use something like Refined types (it exposes Validate[Type, Refinement] typeclass if I remember correctly). Enumeratum exposes Enum[A], and newtypes expose Coercible[From, To].

You will probably be interested into Iron or Refined.

You want either a refined type, a newtype, or if you are in Scala 3 an opaque type.

Refined Scala

Additionally, I also like to use Refined, so that my names are actually NonEmptyStrings, and I'll usually go even farther and make a LastName type alias to NonEmptyString and a FirstName type alias to NonEmptyString so that I can legitimately return just Char as an initial, for example. That way parsing guarantees you're not just sending me empty stuff that is just as useless as an empty person, and also so that I don't accidentally put a FirstName where a LastName should go somewhere in my code.

I wrote a short piece on my company's blog explaining how we used refined to validate incoming data and parse it into more… well, refined types: https://engineering.contentsquare.com/2021/scala-refined-types/

This example uses probably the most popular JSON library for Scala, Circe. There is another Scala library that lets us "be more specific with," or "refine," our types, called Refined. http4s doesn't provide any particular support for Refined, but Circe has a module integrating Refined, meaning that all of Circe's parsing, encoding, and decoding support is integrated with Refined. Putting together http4s' Circe support, Circe's generic codec derivation, and Circe's Refined integration, here's what I came up with: