ilyash

Thanks!

I think it's about alignment of the project and how you think.

If it won't be it this time, I'm working on the user interface of Next Generation Shell now and I would like to encourage you to revisit the project once that is done.

Plan:

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

https://github.com/ngs-lang/ngs/wiki/UI-Chain-Design

Tldr: interactive objects on the screen, each interaction results "interaction record" (structured data about what happened), semantic understanding of what's happening, record/replay facility.

controversial

I did hear an opinion (somewhere else) that a shell shouldn't have associative arrays either and it was a mistake...

Nushell

Nushell is a candidate and some people use it and like it. I personally disagree with the design. Then again, I'm not objective. I created Next Generation Shell. It's a fully fledged programming language with domain specific facilities (for running external programs for example). I like this approach more than trying to improve over a shell. It fits my brain better.

Opinion. Likely controversial. The fact that we need jq highlights that we are missing this functionality in shells. I argue that these days (nested) structured data is as basic requirement as having scalars, arrays and associative arrays (which bash has). It hurts my eyes seeing five line of assignment to variables where each one runs jq to extract that particular field from a data structure.

More at "jq is a symptom" - https://ilya-sher.org/2018/09/10/jq-is-a-symptom/

Related and might be interesting - "JSON tools for command line" - https://ilya-sher.org/2018/04/10/list-of-json-tools-for-comm...

Thanks for the kind words. I phrase it as "fully fledged programming language with domain specific facilities". Hope it makes sense.

Hi. Author here.

I've actually already written a lot of the functionality I see here as bash (and other) functions

That's exactly the reason these are part of stdlib. No reason for everybody to reimplemnt these with slight variations and copy it around.

Make everyone use the metric system.

Hi. Author here.

The biggest difference between NGS and other shells is the UI. It's work in progress. Ideas are at https://github.com/ngs-lang/ngs/wiki/UI-Design

Another big difference is that NGS is a language designed ground up for DevOps-y tasks. The result, in my subjective opinion, is clear and concise scripting. That's due to better fit between the language and problems being solved.

Edit: Python for example "doesn't like" functional programming, while NGS supports it and using map() and filter() is idiomatic.

Edit 2: explanation why UI takes so long. That's because it is being implemented mostly in NGS itself so the language must be in shape (and now it is but it took time).

I don't think the structure is the problem. I think it's fine that the higher you go the bigger decisions and responsibility there is.

The part that I think is not working is that managers neglect one of the basic behaviors they should be engaging in. Weekly one-on-ones done properly. That's the place for information to go from directs to managers.

I would like to make my DevOps colleagues more productive and less frustrated. I'm actually already doing it, it's just way slower when you can't do it as a full time job.

I started working on Next Generation Shell in 2013. I have the programming language in quite a good shape and we use it at work.

I'm working on the UI now. The main idea of the UI is to get rid of telegraph-style communication paradigm of sending text and receiving text. We can actually use the whole screen now. We have text editing using full screen since 1976 (vi) but classical shells are ignoring this capability till this day. It's time to stop treating outputs of programs as if they are still printed on paper, allowing zero interactivity.

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

https://github.com/ngs-lang/ngs/wiki/UI-Chain-Design

Have a nice day!

Next Generation Shell because I refuse to believe that UI that is limiting the interaction to single line is the pinnacle of UX that we can have today.

Terminals introduced cursor movement feature in the 1970s. Bill Joy responded with releasing vi in 1976. Text editing as we know it today was born. It used ... the whole screen! How the shell responded to this new feature? It largely didn't.

Back to NGS. The programming language is in a good shape. Working on the UI.

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

Author of Next Generation Shell here. Questions are welcome.

Personal anecdote - I see spam is way up already. I assume some of the fired people were fighting spam.

Next Generation Shell. As a shell, it's a programming language and a UI. Half baked: programming language - pretty much done, we use it at work; UI - just starting to work on.

Ananlysis of what's wrong with current shells' UIs and how to fix it - https://blog.ngs-lang.org/2023/09/30/ui-in-ngs/

Project - https://github.com/ngs-lang/ngs

Any help would be appreciated of course :)

Full title: What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not

Thoughts:

Closest implemented thing that I know of that implements the solution to the stated problem: Raku's Capture - https://docs.raku.org/type/Capture

Maybe Python can go in that direction.

Subjectively, it doesn't feel right to mix positional and named containers in Python.

Hi. I'm Ilya Sher, author of Next Generation Shell. That's the only shell that I'm aware of that plans to do something "radical" about the UI/UX. By radical I mean something out of the telegraph style communication paradigm.

https://ilya-sher.org/2022/12/31/telegraph-and-the-unix-shel...

https://blog.ngs-lang.org/2023/06/08/the-shell-vs-the-web/

Not the same ergonomic.

The language doesn't "understand" it's a section (no opportunities listed in the original comment).

Comments Section

In Next Generation Shell I've experimented by adding

    section "arbitrary comment" {
      code here
    }

    # blah section - start
    code here
    # blah section - end

Symbols

I've decided not to have symbols in NGS. My opinion (I assume not popular) is that all symbols together is one big enum, instead of having multiple enums which would convey which values are acceptable at each point.

Yep. What bothers me is when you start looking at list comprehension is that you don't know if it's filter(), map(), or a combination. You have to read the list comprehension till the end to understand.

I worked with Python for quite a few years but at 2013 it became too painful for "DevOps". The more I was thinking about how things could/should be the more frustrated I was. Python and bash were the "inspiration" that pushed me to start working on Next Generation Shell.

Particularly annoying in Python is running external programs (yes, I know there are libraries) and manipulating structured data (list comprehension is not aligned with how I think, which is map() and filter() and lambdas not limited to single expression).

Since you brought up JetBrains, I use no products made by them, at all, any more.

Just curious. Why?

While not as thorough solution as mentioned here in comments, UFCS goes a long way in this direction. In Next Generation Shell, I've designed the methods so that the first parameter is something that is likely to come from "the pipeline". Hence mylist.filter(...).map(...) just work. Combined with multiple dispatch and the fact that methods don't belong to a particular type/class, it allows creating user-defined methods with same convention to work with any existing and new types/classes.

UFCS - https://en.m.wikipedia.org/wiki/Uniform_Function_Call_Syntax

OOP implementation in Next Generation Shell was inspired by CLOS but it's way simpler.

Defining a type: type MyType.

At any point one can declare method: F myMethod(..., mt:MyType, ...) some_code()

Anything defined by F is automatically a multimethod. When invoked, all methods in the multimethod are searched bottom up. The first one where the call arguments match the parameters (by type, with inheritance) is invoked.

That's roughly it.

I might have issues later. For now, in Next Generation Shell peg/leg parser is doing fine (with limited scripting around to avoid repetition).

https://piumarta.com/software/peg/

https://github.com/ngs-lang/ngs/blob/bdfb2fd70162cd7183ac8d4...

After over a decade of professional experience using bash, in 2013 I've started developing Next Generation Shell. I'm still on it. Probably not the size of project that you were looking for :)

tldr: better programming language (syntax, error handling, data structures - full blown but still domain specific programming language), better interactive mode (at least that's what I think).

One of the reasons I created Next Generation Shell. It has exceptions. So "if $(grep ...)" works correctly as opposed to bash. grep exit codes: 0 - found, 1 - not found, 2 - error. bash can not handle this correctly in if. There are just two branches for 3 exit codes. NGS has two branches and exception that can be thrown. Yep, every single "if grep ..." in bash is a bomb.

Whenever I encounter 20 lines bash script, I rewrite it as 15 lines Next Generation Shell script. It is more correct because of better error handling, more concise because of stdlib, more readable because of saner syntax. Disclosure: I'm the author.

For that, there is Next Generation Shell. Also works like a charm even before 100 lines. For example when structured data is needed. Some other advantages over bash are error handling, automatic command line arguments parsing (similar to Raku, btw), standard library with functions like warn(), log(), debug(), retry(), etc that you have likely implemented hundreds of times in your bash scripts.

Disclosure: I'm the author.

Here is my take on pattern matching. Tldr: generalize.

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

The idea of JSON output is brought up regularly.

Very interesting project that helps with that is https://wiki.freebsd.org/LibXo

Meanwhile, there is jc so that

jc df

returns JSON. See https://github.com/kellyjonbrazil/jc

Hope this helps.