> there is no interop between powershell and nushell

FWIW I wrote a post about this design issue:

Oils Is Exterior-First (Code, Text, and Structured Data) - https://www.oilshell.org/blog/2023/06/ysh-design.html#survey...

That is

- Powershell and nushell have an "interior" design (within a process/VM)

- while POSIX shell, bash, OSH, and YSH have an "exterior" design (between processes)

And I'll claim that the exterior design is the glue you need in large, heterogeneous systems. Making the shell "interior" and "easy to use" is at odds with the role as essential glue -- it creates pressure for something else to be used instead.

---

Maybe the more pithy statement is here:

A Sketch of the Biggest Idea in Software Architecture - https://www.oilshell.org/blog/2022/03/backlog-arch.html

The lowest common denominator between a PowerShell, Elvish, Rash, and nushell script is a Bourne shell script (and eventually a YSH script)

I also claim this isn't theoretical -- there are probably a non-trivial number of bash scripts gluing together PowerShell and other shells. IMO it's better to have 1 type of glue, than 2 or more types, which I call "Unix sludge / Cloud sludge".

---

And I disagree with this part, which references protocol buffers:

> how do you get a schema? well, you establish in-band communication. RPC is ...

Protocol buffers transmit schemas OUT of band, usually via a monorepo. The data sent over the wire can't be interpreted without the schema information compiled into the binary.

The monorepo works well enough within Google, but even there it failed to scale (probably around the time of "Alphabet", e.g. Waymo and other companies)

Also, protobufs are biased toward C++; users of other languages feel this friction to varying degrees. In general, they'd rather use .gob for Go, pickle for Python, JSON for JS, Java serialization, etc.

> And I'll claim that the exterior design is the glue you need in large, heterogeneous systems.

Yes, but the specific format (and the way that the data transmission between processes and other pieces of the system is working) for the "exterior" design is an effect of the operating system. A different operating system might have a different way.

Whether it is interior or exterior, there is going to be different data types and other differences between structures, used in different ways. (One example of a difference which does not merely involve the interpretation of byte sequences, is transmissions of capabilities in systems that use capability-based security.)

I think that it is helpful to have a combination of interior and exterior functions, although most things will be exterior. However, for some things it is more helpful to do them internally within a process, for various reasons (including efficiency, requirements according to the specific operating system in use, security, and others).

> IMO it's better to have 1 type of glue, than 2 or more types

It might depend on the specific use. For some uses, it might be necessary to do it differently.

I also think that it is a mistake to assume one character set or one operating system for everything, though. However, even then, you probably wouldn't need more than one type of glue for many things, even if this "type of glue" is not the same as you would use in a different system.

> The data sent over the wire can't be interpreted without the schema information compiled into the binary.

A program is unlikely to be able to do much with data that the program is not designed to handle, regardless of how the schema is tramsmitted, so in-band communication of the schema probably wouldn't help much.

However, there can be multiple levels; e.g. with DER format, a program that does not understand the specific schema would still be able to read most of the values (with some exceptions if implicit types are used), sequences, etc, but does not know what any of that stuff means.

(I use DER format in some programs and formats that I do, because I think it is better than JSON in many ways.)

These issues are also things that my own ideas of operating system design would hopefully improve some of this. The command shell has a combination and data format would hopefully be more helpful.