Other [New idea] Super programming language - Super programming interface

  • Thread starter Deleted member 66267
  • Start date
D

Deleted member 66267

Guest
Let's imagine we dropped the ancient Unix shell but glued everything through a super glue programming language, just call it: Bython.

Python is very close to this, but not yet, and of course it must be BSD licensed, so call it: Bython.

Shell is not even a programming language, but a loosely way to put other small utilities together to form a script.

The shell will be replaced. The small utilities will be dropped in favor of one central controlled environment.

Imagine:

Instead of writing, ls -a, we would open our super glue programming language REPL and type this:

>>> SysUtils.list()

Another example:

Instead of writing sysctl vfs.zfs.min_auto_ashift=12, we would write something like this:

>>> SysCtl.set(vfs.zfs.min_auto_ashift, 12)

We could optionally provide compatible layer for old Unix shell scripts to continue running, but:

/bin/sh will be a Bython script:

#!/bin/bython

SysUtils.shell.exec()

/bin/ls, /bin/cp,... all of these small utilities will now be just a Bython script.

Bython will need to be part of the base system. But who care about the bloat? All of the small utilities now just plain text scripts, we really saved space! And the benefit of having a proper programming language rather than a "shell" is much bigger than that!

Completely integrated. We now have total control of everything!

Let's abandon the old outdated Unix's way, let's start doing it the failure's way!
 
The original basis of this thread is misaligned (for lack of a better word cause I just woke up).

It thinks that because "the shell" is old that it must be bad and needs replacing.
It states that the shell should be replaced with a programming language while, at the same time, states the shell is not a programming language.
 
The original basis of this thread is misaligned (for lack of a better word cause I just woke up).

It thinks that because "the shell" is old that it must be bad and needs replacing.
It states that the shell should be replaced with a programming language while, at the same time, states the shell is not a programming language.
I'm a coder have to do the job of a sysadmin. I only know some Python but no shell at all.
I prefer to solve problems the way a coder does. Everything via code, calling of functions...
I don't like shell. Which just a way to loosely glue other small utilities together to form a working script.
The shell's syntax is absurd and bizarre for me. Yes, it's not even a programming language.
In a nutshell, I like calling of functions, not calling of standalone utilities.
 
I'm a coder have to do the job of a sysadmin. I only know some Python but no shell at all.
I prefer to solve problems the way a coder does. Everything via code, calling of functions...
I don't like shell. Which just a way to loosely glue other small utilities together to form a working script.
The shell's syntax is absurd and bizarre for me. Yes, it's not even a programming language.
In a nutshell, I like calling of functions, not calling of standalone utilities.
This is why I prefer alternative shells like shells/fish or shells/rc that have saner syntax. I'm currently satisfied with rc, both as an interactive shell and as a scripting language. Of course, rc definitely has drawbacks of its own, and what works for me obviously may not work for other people.

That said, the entire point of a shell is to execute commands, so you're still going to be gluing things together in many shells, no matter how different they are in terms of syntax. Don't forget that when shell scripting fails you, you can still build/install a utility created with another language. I have a function in my .rcrc that uses misc/getopt; rc has no option parsing facilities, and getopt(1) did not meet my needs (I couldn't make it work like I wanted).

If you must use sh, then feel free to disregard this post.
 
Personally, I would opt for a Prolog shell. Maybe Erlang. Not shure. It's so logical...
Is forth or postscript not more natural for a shell?

In any case, perhaps any interpreted language can be used as shell:
just put the interpreter as login shell in /etc/passwd an test it. You
may make the interpreter call some definitions at startup, that is like .cshrc.

Well, see here the problems doing it:

 
Aw crud. Who forgot to lock the clown Car?
I'll let this run for the lulz, but everybody, please don't be offended too easily. This horse is so dead it missed the arc already.
So let the sparring begin.
 
I'm a coder have to do the job of a sysadmin. I only know some Python but no shell at all.
I prefer to solve problems the way a coder does. Everything via code, calling of functions.
Well, I'm a professional programmer--not a "coder"--and I don't have any issues using a shell language at all.

In a nutshell, I like calling of functions, not calling of standalone utilities.
You know, some of these functions you call are system calls that use these standalone utilities don't you? Do coders know that?
 
Bython will need to be part of the base system. But who care about the bloat? All of the small utilities now just plain text scripts...

I thought everything on a UNIX box was considered a file, text or other.

I don't know Python or think I want Bython. Snakes run from me because they know what will happen if I catch them. I already have control my machines and any commands entered through the usr sh or default root shell.
Let's abandon the old outdated Unix's way, let's start doing it the failure's way!

Some are born to it, others thrust into it. I'm working not to end up one and the light at the end of the tunnel now is the Sun rising. Which means the snakes will be harder to catch once it does.
 
Another example:

Instead of writing sysctl vfs.zfs.min_auto_ashift=12, we would write something like this:

>>> SysCtl.set(vfs.zfs.min_auto_ashift, 12)
Is that Bythonesque? It should really be:

Code:
freebsd.system.internal.get_sysctl.set(freebsd.system.internal.identifiers.vfs.get_zfs().get_min_auto_ashift().get_id(), value=12)

easy, efficient, effective. You get to choose exactly 0.

In some ways, this feels a little bit like Windows Powershell. It is too close to a programming language, making it a little too awkward to use as an interactive shell. And yet not a particularly good programming language either.
 
Back
Top