[enricozb]

Check out Kakoune[1] for a different take on an editor’s scripting language. It offloads as much as possible to existing Unix tools such as bash, sort, fmt, etc. It uses a clever system of string substitutions that’s a bit unintuitive at first, but not too difficult to grasp quickly. I spent two weeks trying to fix a bug in a Vim plugin that ended up being a 3 line change. After that I felt like I barely understood just a small section of vimscript.

I ended up switching to Kakoune after trying it for a bit because I realized that in the two weeks of me exploring it I had entirely understood it’s “scripting language”, or at the very least understood how to use the onboard docs to write any plugin I wanted to.

[1]: https://github.com/mawww/kakoune

[timeattack]

Sorry, but I find this to be very bad design.

Check this out [1]: kak script evaluating sh script which in turn call perl which constructs kak script commands and output them to stdout to be evaluated by kak.

Or this one [2]: same, as before, but now it's calling awk, which calls `date` binary (so it's kak → shell → awk → date → kak).

It seems that it's done this way because sh is not good programming language to use for manipulating text. Moreover, sh is not good programming language to write complicated programs, which later can be successfully maintained & tested.

For me, kak approach is past the border of unmaintainability.

Also, it raises question of why not to use embedded language like python or lua instead of creating such a limited editor-specific language.

[1]: https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c... [2]: https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c...

[mawww]

To give a bit of context, the idea behind this design is that those scripts should ultimately only be glue scripts that convert from some editor agnostic tools into Kakoune commands.

I do agree that sh is not a nice programing language, and forking programs all the time is not very efficient. I think that there is a tradeoff between the different approaches, and Kakoune's has proven to make quick'n'dirty very easy while being suboptimal for complex tasks.

I am okay with that tradeoff because I still believe most complex tasks do not need to be editor specific, and should be provided by separate tools written in a more maintainable language.

Another reason is that I've been trying to design Kakoune in a minimalistic way, and one thing I tried to unify was the user and scripting interface, which means I needed a command language that was easy to write interactively (`edit filename` vs `edit("filename")`). This is again a tradeoff that helps with simple things (as users already know the scripting language if they know how to use the editor), while making complex things harder.

[dmos62]

I'm interested in seeing a response to this. I sympathize with wanting to use unix tool composition, but I've personally found shell languages inadequate for more interesting applications.

[coldtea]

Small staple unix programs, pipes, job control etc are all great ideas.

POSIX shells languages however, are awfully designed (including zsh/fish for historical compatibility with POSIX concepts reasons).

Something close to TCL as a shell would be much better.

[dmos62]

I wouldn't say that they're badly designed. They make it easy to deal with text, the bread and butter of shell, while neglecting other data structures, which is fine 99% of the time, unless you're using these shell languages as general purpose.

They also neglect parallel, concurrent, async programming. Which agan is fine for a shell language. The shell does have use cases for simple parallel processing and you can delegate to dedicated unix tools for that and it works great. If you need more, you're expected to jump into a more powerful environment.

So they're poor in data structure variety, and more interesting (nonsequential) ways of executing programs, which, again, is fine for a shell language, but those were exactly the things I wanted. I wanted to pipe and tee a bunch of programs programs into one "executable graph" a la dataflow programming using bash or something similar, but quickly understood that due to the above reasons I need a different environment. I'm still on the lookout for good dataflow programming environments.

[coldtea]

My issue is not that shell scripting languages have constraints and are not general purpose programming languages.

My issue is their tons of subtle points (e.g. behaviour of [ vs [[ blocks), blatant disregard for the principle of least surprise, lack of some very basic items (not parallel, async etc programming -- a mere list and a mere map with an obvious syntax and no BS caveats would do), inelegant ad-hoc accretion of features, bad error handling, and so on. Those things can (and frequently do) trouble programmers even an one-liner.

I don't with e.g. something like bash supports writing a full 10K program with it.

But I wish it didn't make a 100-line shell script so clumsy and frail.

[fwip]

You can definitely do parallel / concurrent / async programming directly in the shell, without any helper programs. It's not exactly ergonomic, but with a few patterns it's not too difficult.

Async:

    long_running_cmd & > results.txt
    cmd_pid=$!
    # other stuff
    wait $cmd_pid
    # do something with results, if you want

Parallel:

    for script in "${scripts[@]}" ; do
      "$script" &
    done
    wait

Dataflow:

    mkfifo my_channel
    mkfifo another_channel
    my_cmd > my_channel &

    tee my_channel \
      >(cmd1) \
      >(cmd2 > another_channel) &
 
    another_cmd < another_channel

But if you want a useful dataflow environment, I really recommend checking out [Nextflow](https://www.nextflow.io/). I use it at work for constructing bioinformatics pipelines, and it's really natural. The "preview" DSL2 is worth looking at, as well.

[dmos62]

Thanks you for the recommendation, Nextflow looks exactly like what I was looking for! Thanks for the bash examples as well.

[floriol]

I was dismissing powershell for a great deal of time until I eventually looked into it more and I have to say, I'm impressed by it. Though it can be used on linux, it doesn't feel like a first-class citizen, but non-the-less I would like to have an object-based shell environment for linux with old tools rewritten for it (like top would output a list of objects with properties like CPU usage, name etc and a later grep could be used to sort them by whatever we want. No more awk/sed the nth column hack)

[timeattack]

IMO shell which require developers to write code like this [1] to implement mere syntax highlighting for command you're entering has bad design.

I don't know which level of intellect is required here for a newcomer to fix a bug.

[1]: https://github.com/zdharma/fast-syntax-highlighting/blob/mas...

[dmos62]

I burst out laughing. I've not seen spaghetti code like that in a serious program before. Why is syntax highlighting being implemented in a shell language anyway?

[epage]

Sounds like you also couldn't run these plugins on windows, if kak even supports windows :(

[TeddyDD]

Kakoune works fine with WSL and you need POSIX environment for any serious work anyway.

[y4mi]

While I personally wouldn't use anything but Linux for .. basically anything, you're definitely living in a bubble if you truly think do.

c# a viable language with great tooling, and there is a lot of enterprise software available which only runs on Windows.

Even a few big websites are running on it, like stack overflow for example

[mawww]

Coming from a video game industry background, I have been running Kakoune in Windows since its early days, but always in a posix environment (cygwin, then WSL).

It was a concious design decision to rely on posix extensively, one reason being that if you do not care about not having posix available, you are probably not that interested in what Kakoune provides.

[wbl]

Or Lisp (ducks)