Comment by ilyash | Hacker News Reader

Comment by ilyash | Hacker News Reader

Hello. Author of Next Generation Shell [1] here. I've skimmed ABS documentation and was surprised by the amount of similarities in thinking and reasoning between ABS and Next Generation Shell. Differences that popped into my head in limited amount of time follow:

* ABS has CLI and NGS does not yet, CLI of NGS will be written in NGS itself, so it takes time. The CLI in NGS will be radically different [3].

* ABS runs on Windows.

* ABS has decorators, NGS does not yet, still thinking how to do it right and more generic.

* ABS has some functions that NGS doesn't and vice versa.

* Found inconsistently named functions in ABS (json() vs tsv() - json() parses JSON while tsv() generates tsv); given more eyeballs on NGS, such inconsistencies should come up.

* NGS has user defined types.

* NGS has many predefined types, ABS has few.

* NGS has multi-methods and multiple dispatch.

* NGS has exceptions.

* NGS has (partial but already very usable implementation of) Universal Pattern Matching [2]

Translating example in the docs:

    # ABS

    res = `curl -s 'https://api.ipify.org?format=json'`

    if !res.ok {
      exit(1, "An error occurred: %s".fmt(res))
    }

    ip = res.json().ip
    total = ip.split(".").map(int).sum()
    if total > 100 {
        echo("The sum of [$ip] is a large number, $total.")
    }

    # NGS

    ip = ``curl -s 'https://api.ipify.org?format=json'``.ip
    total = ip.split('.').map(Int).sum()
    if total > 100 {
        echo("The sum of [$ip] is a large number, $total.")
    }

In NGS the double backtick syntax above runs external program and parses the output. The check of `ok` is not needed because on error exception will be thrown.

[1] https://github.com/ngs-lang/ngs

[2] https://github.com/ngs-lang/ngs/wiki/UPM-Design

[3] https://github.com/ngs-lang/ngs/wiki/UI-Design

Author of another shell here. My syntax started out very similar to both ABS and NGS too but I found it cumbersome writing commands in C-style (strings quoted, parameters braced and comma delimited) for day to day CLI work. So I dropped the requirement for braces, then quotation marks, then commas. And before you knew it, you ended up with something that looked a little like Bash again.

There's obviously going to be a lot of subjectiveness around the design of shell languages but I've found this is one domain where a certain amount of ugliness is overall better than going for syntax purity because the majority of time you're writing shell code it's in a REPL, it's repetitive, and often it's because you're already trying to optimise on developer effort (otherwise you'd have written the thing in Go/Java/Python/whatever anyway). And while C-style syntax does offer some familiarity for developers that can help with readability, their primary function is really to provide hints to the compiler rather than aid development.

So ~7 years ago my shell went from looking a lot like yours, with the same methods and syntax, to fewer namespaces and more Bash-isms but using C-style braces only sparingly (eg to clearly denote different scopes of code).

To illustrate this, your same code for my shell would look something like the following:

  trypipe {
    get https://api.ipify.org?format=json | [body] | set resp
    
    let total=0
    $resp[ip] | jsplit: '\.' | foreach i { let total=$total+$i }
    
    if { = total > 100 } {
      echo "The sum of [$resp[ip]] is a large number, $total."
    }
  }

(I don't have a `sum` method so there is some ugliness there. But that's a pretty simple language addition should people want it.)

Your code is definitely more readable to your average developer. But the real question is how does it fair in an interactive shell? That, for me, is the real make or break of all these new alternative shell languages that are cropping up these days (and where I've focused most of my effort) because we already have plenty of write once read many languages. Where the industry is lacking is good write many read once languages.

Don't get me wrong, I think it's fantastic the work you're doing. This isn't a criticism in any way! More general curiosity how you guys have approached the interactive shell problem with a bit of back story about the journey I took when following a similar path as yourselves.

> cumbersome writing commands

In NGS, there are two syntaxes: "commands" and "expressions".

Commands is bash-like. It's for running external programs.

Need some fancy stuff? Switch to expressions and pay the price.

I didn't see (and still don't see) any way to make a "real" programming language based on bash-like syntax.

BTW if we remove error handling, I think ABS' code would look like:

    ip = `curl -s 'https://api.ipify.org?format=json'`.json().ip
    total = ip.split('.').map(int).sum()
    if total > 100 {
        echo("The sum of [$ip] is a large number, $total.")
    }

I would suggest implementing decorators in NGS. Not because you will need them, but because they're easily the most fun part I had to write in ABS :) That, and seeing stdin() working for the first time on my terminal!

Looks pretty close :)

What happens in ABS if curl fails in this example? Or JSON parsing fails? In NGS, it's an exception with a stack trace.

> fun part

NGS is mostly use-cases oriented - https://github.com/ngs-lang/ngs/wiki/Use-Cases

Decorators are not implemented yet because there are other things higher up the list. Currently working on deeply nested data structures because it's needed for our use case for FHIR - https://github.com/ngs-lang/ngs/wiki/Deep-Data-Structures-Ma...

Reply on news.ycombinator.com