Hacker News Reader

Comment by arnioxux | Hacker News Reader

I'm not a scala dev but I'm curious, what makes scala a good scripting language? Bash has its faults but it's still great for adhoc stuff and when it stops being great you can just move to a more specialized build config tool. Scala seems a bit more verbose and it's unclear what you gain from it.

Is it similar to what's going on the JS world where people just want to use one language for client, server, and build tools? (and for this case, even the terminal shell?)

View on HN

For anything complex it is better to use a real language, not bash. If you are a Scala developer then Scala is a pretty good choice. However lots of folks use Groovy or Python which have the advantage that a wider group of people can learn how to use them.

The JS everywhere crowd is rather narrowminded and don't seem to be aware that they are reinventing a wheel that others have already done better.

But if you spend most of your day writing JS and you find yourself needing to write complex bash scripts, give your head a shake and use JS instead. It is better to use a real programming language where you have test frameworks, build tools and so on.

Don't forget, on the JVM, you not only have Apache Groovy and JS(Nashorn) for scripting, but also Clojure which is suitable for complex scripts, even providing terse macroing. It's very handy to define a macro to avoid repetition typical in tests.

A big strength of Scala scripting is the availability of the whole JVM ecosystem, and the ivy integration in Ammonite makes this seamless. Check out the "Ammonite Cookbook" section of the site for some examples. The bash equivalent would be use of command-line tools like netcat, sed, etc. Powershell for the JVM (seen in another comment) is a great analogy. Working in REPL mode, testing snippets and exploring library signatures, is very productive. Also, I'd argue that Scala becomes less verbose than Bash as you do more interesting things. No question that it's much slower.

I think you're right about the one language thing. If you're developing a system in Scala, you might as well do scripts in the same language, with API access to your system. (Real world example: server deployment script prompts for initial admin password, computes and persists hash using server API).

Unless you know Scala already well, it doesn't make sense to use it as a script language — there are cleaner alternatives (not Bash, though — Bash is just awful). But if you do, it makes perfect sense. Scala is one of the most expressive languages out there.

I think that about sums it up perfectly: If you don't know Scala, learning it just to script with is extremely inefficient. However, if you already know Scala well, all you need is the right library of functions to have a really nice (and much-safer-than-bash) scripting language (or you would if not for the long waits for compilation and startup JVM startup).

I really enjoy using chains of map.filter.foreach.map in scala, it feels powerful but also simple

I imagine piping in bash feels similar, so there's at least a common problem/solution between them

> I imagine piping in bash feels similar...

It is. Piping is akin to an untyped subset of working with Scala's collections, and there's a similar workflow between the two, e.g.:

In bash, you build up a command line with something like (as a stupid example, the number of unique file sizes in a directory):

    Step 1) $ ls -l
    Step 2) $ ls -l | awk '{print $5}'
    Step 3) $ ls -l | awk '/\d+/ {print $5}'
    Step 4) $ ls -l | awk '/\d+/ {print $5}' | sort -n
    Step 5) $ ls -l | awk '/\d+/ {print $5}' | sort -n | uniq

You can see the correspondence with collections--typically building up in the editor in a similar staged manner ending with something like:

    Process("ls -l").lines   // ls -l part
      .map(_.split("\\s+"))  // awk part {
      .filter(_.length > 4)  //   ...
      .map(_.apply(4).toInt) // }
      .sorted                // sort -n part
      .distinct              // uniq part

The tradeoffs between the two are essentially verbosity versus data safety (perhaps not important with a throwaway inspection, but more important when working on larger programs...).

However, the building process is the same--you don't write the latter all at once, you gradually mold the pipeline until you get the output you want.

I am a scala dev but for scripts I use ruby. With pry, I have a great REPL, and ruby has no problem with those filter chains.

  [1] pry(main)> `ls`
  => "README.md\n" + "_build\n" + "config\n" + "lib\n" + "mix.exs\n" + "test\n"
  [2] pry(main)> `ls`.split
  => ["README.md", "_build", "config", "lib", "mix.exs", "test"]
  [3] pry(main)> `ls`.split.map(&:upcase)
  => ["README.MD", "_BUILD", "CONFIG", "LIB", "MIX.EXS", "TEST"]
  [4] pry(main)> `ls`.split.map(&:upcase).select { |x| x.match(/E/) }
  => ["README.MD", "MIX.EXS", "TEST"]

Building a rest API for a DevOps platform wont be easy in bash.

Scala is also less verbose, easy todo FP with and its very natural to do system/db work with.

Its basically a better java for me.

Scala can be very concise - you can write Scala that looks very much like Python (indeed most Python just translates directly). E.g. it's got quite a low-ceremony syntax, not needing as many brackets or braces as other languages. But yeah wanting to use the same language everywhere is also a factor. Being able to call functions from your main codebase in your scripts is really nice.

Yeah, I agree here. I think each language has it's faults, and I'm not sure if Scala is the best for scripting and that sort of thing.

Personally, I try to use Groovy for any semi-complicated sort of script. It has many features that are similar to Scala, and usually ends up being very concise and readable.

I don't personally agree with the following sentiment although I have certainly gone down this path myself even considering my beliefs. I think for a lot of people they'd rather not context switch into another language, or in many cases simply aren't proficient in a more appropriate language. Many devs are far from polyglots.

Even though I think that's the wrong approach I certainly have had many instances where I've whipped something quick up in language X even though it was wildly inappropriate simply because for me it was going to be faster

Reply on news.ycombinator.com