oils VS ngs

I generally agree with this article in that PROGRAMMABILITY is the core of Unix, and it is why I've been working on https://www.oilshell.org/ for many years

However I think the counterpoint is maybe a weaker, programming analog of Doctorow's "Civil War on General Purpose Computing"

I believe the idea there was that we would all have iPads and iPhones, with content delivered to us, but we would not have the power to create our own content, or do arbitrary things with computers

I think that has largely come to pass

---

The Unix/shell version of that is that important logic will be hidden in cloud services, in a YAML interface.

And your job is now to LLM the correct YAML

Not actually do any programming, which can lead to adjacent thoughts that the cloud/YAML owners didn't think of

In some ways there is an economic sense to this, but personally I don't want to live in that world :)

Switching away from being bash compatible would be really unexpected. Maybe something like http://www.oilshell.org/ has a chance though?

If we were breaking away from the old style shells completely, then https://www.nushell.sh/ would be my preferred upgrade.

bash and readline - Chet Ramey. Both originally by Brian Fox https://twobithistory.org/2019/08/22/readline.html

maybe less of a bus factor now with OSH approaching feature/speed parity and having more maintainers https://www.oilshell.org/

All these programs will output ANSI color if `isatty(stdout)` is true (roughly speaking).

Most people didn't quite get that -- they thought we should use "nREPL" or something -- but my opinion is that you really need a specific protocol to communicate with a shell, because a shell spawns other programs you still want to work.

---

Here is a pure Python 3 implementation of the recv() side of FANOS in only ~100 lines

https://github.com/oilshell/oil/blob/master/client/py_fanos....

It uses the recvmsg() binding . I'm pretty sure node.js has that too? i.e. it has Unix domain socket support

---

Anyway, thanks for taking a look - we're interested in feedback!

This is similar to how https://www.oilshell.org/ is written

There are two complete implementations

1. one that runs under a stock Python interpreter (which doesn't use static types)

2. one that's pure C++, translated from statically typed Python code, and from data structures generated in Python

In the second case, everything before main() is "burned off" at build time -- e.g. there is metaprogramming on lexers, flag parsers, dicts, etc. that gets run and then into static C data -- i.e. pure data that incurs zero startup cost

Comparison to Pre-Scheme: https://lobste.rs/s/tjiwrd/revival_pre_scheme_systems_progra... (types, compiler output, and GC)

Brief Descriptions of a Python to C++ Translator - https://www.oilshell.org/blog/2022/05/mycpp.html

...

And related to your other point, I remember looking at Racket's implementation around the time it started the Chez Scheme conversion. I was surprised that it was over 100K lines of hand-written C in the runtime -- it looked similar to CPython in many ways (which is at at least 250K lines of C in the core).

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!

- https://ngs-lang.org/

> Applications should neither be concerned with what color codes the output device can render, nor should the terminal itself have to support hundreds of emulation targets.

If you have colour codes (et al) sent out-of-band then you need a new kind of terminal emulator which the application then also needs to support. So you do effectively create yet another standard.

Whereas the status quo, as much as it sucks, is largely just vt100 with a few extra luxuries, some of which are as old as xterm. We aren't really talking about having to deal with hundreds of emulation targets, nor even more than one, in most cases.

Where things get a little more challenging is if you want stuff like squiggly underlines or inlined images. There is the beginnings of some de facto standardisation there but it's still a long way from being standardised.

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 :)

The plan for UI is at https://github.com/ngs-lang/ngs/wiki/UI-Design

The site is at https://ngs-lang.org/

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

There are number of new ones coming out ...and I'm curious of https://github.com/ngs-lang/ngs. As a language nerd, have you seen that?