7 ms·

> The only reason I think they didn't design unix this way was because C was too low level, but we could write the OS in a "higher level" functional language.

> The only reason I think they didn't design unix this way was because C was too low level, but we could write the OS in a "higher level" functional language. You've already lost my interest. Bash/Shell is incredibly powerful and doesn't need a higher-level abstraction. That is what programming languages and CLI tools are for.

wlib 8y ago
That misses my poorly written point. Do you use a separate, awkward tool to call functions you wrote in python? Or do you call the function in python itself? The shell is a useless abstraction that was only necessary in unix because the alternative was c. Now that we have better languages, why not use them to write the OS bottom-up?
- minitech 8y ago
  Because writing new OSes is hard and writing new OSes where existing software that people want to use keeps working is even harder.
  - AnIdiotOnTheNet 8y ago
    And thus the tech industry piled abstraction upon abstraction, decade after decade, until finally all software collapsed into a singularity and destroyed the earth. Which, frankly, came as somewhat of a relief to all the people forced to use it.
- dfc 8y ago
  It's strange to me to imagine that there would be one language that was the best choice for OS implementation and day to day user interaction/automation. I'm curious what language do you think would be good for both use cases?
  - wlib 8y ago
    A more syntactically friendly Haskell-like language
    - int_19h 8y ago
      How would you deal with mutable state like, say, the current directory?
      - jrs95 8y ago
        When all you have is a Haskell everything starts to look like a monad
      - Risord 8y ago
        I think that if we use purish FP as our system language it doesn't make sense to just emulate imperative/mutable system. But mm... why you would want to mutable state like current directory in first place? Or even mutable filesystem? Why aren't those just immutable parameters of your program?
        adwn 8y ago
        > But mm... why you would want to mutable state like current directory in first place? Or even mutable filesystem? Why aren't those just immutable parameters of your program? Because that's how just about any OS, application, library, filesystem, device driver, database, nearly everything related to computing at all, works. Reinventing the universe has never, ever lead to success. If you want even the slightest hope for non-negligible adoption of your operating system, you need to be able to interface with the rest of the world. And that's why you don't want the filesystem to be an "immuatble parameter of your program".
        Risord 8y ago
        You can still build compatibility layer on top of immutable FS. Like being mutable from program(s) perspective while being able to control how these changes are capsulated from rest of the system. You could, for example, see what your > any OS, application, library, filesystem, device driver, database, nearly everything related to computing at all -is trying to actually do to your files and operation like reverting changes is trivial. Sure it's not performance optimal and effects what kind of software is ideal to work within such a system. It's just a different approach with different trade-offs. Anyway if I one day want to build new OS it's for trying different interesting approaches and not yet another 'successful any-OS'.
- algesten 8y ago
  The choice of python as your shell would surely be as arbitrary as bash? There is a long history of alternative shells csh, tcsh, zsh, fish, etc. All with various level of abstraction and various amounts of "programming language type constructs" (for lack of a better term). At the end of the day, long arguments have been had over which is the better shell. It's all just personal preference. Hence it can be set in /etc/passwd per user. You prefer python? chsh is there to change it.
  - wlib 8y ago
    My point wasn't about python, just an example of how a shell around python, made only for python function calls, would be a useless abstraction.
    - otabdeveloper2 8y ago
      Something like IPython, amirite? XD
- nurettin 8y ago
  I have a different theory; perhaps line printers (which terminals try to emulate) are to blame. Space on a line is limited and one directional, so thr tools naturally evolved towards strange single line incantations instead of full fledged programs. Commodore Pet did it right by introducing a navigable terminal where you could move between lines and don't need to open an editor to write multiline programs.
  - pmontra 8y ago
    I don't have time to Google now but I think that mainframe terminals worked like that. 3270 should be the model to search for.
    - TheOtherHobbes 8y ago
      This was already a solved problem in the 70s. IBM's 3270 series offered full buffered access to a character matrix display, and DEC's VT52 and later terminals added bi-directional scrolling. Modern CLIs can usually emulate at least a few of the old scrolling character matrix displays, but only a few bash commands (e.g. top) use the extra features.
- dragonwriter 8y ago
  > Do you use a separate, awkward tool to call functions you wrote in python? I use a separate tool to call a lot of functions written in C. That tool is called “Python”. Or “Ruby”. Sometimes I use a separate tool to call functions written in Python (or JavaScript, or...) and that tool is called PostgreSQL. Sometimes I use Ruby to call C to call Postgres to call JS. > Now that we have better languages, why not use them to write the OS bottom-up? What better languages for implementing an OS? Lisp? We had that before C. Rust? Either way—and I like both languages—I don't want to use either for a shell. Red? Maybe, but I don't think we're to the point of a Red OS yet, and while it's probably eventually usable for that purpose, I don't see it as necessarily ideal for OS implementation though it might be tolerable as a shell language.

wlib 8y ago

That misses my poorly written point. Do you use a separate, awkward tool to call functions you wrote in python? Or do you call the function in python itself? The shell is a useless abstraction that was only necessary in unix because the alternative was c. Now that we have better languages, why not use them to write the OS bottom-up?

minitech 8y ago
Because writing new OSes is hard and writing new OSes where existing software that people want to use keeps working is even harder.
- AnIdiotOnTheNet 8y ago
  And thus the tech industry piled abstraction upon abstraction, decade after decade, until finally all software collapsed into a singularity and destroyed the earth. Which, frankly, came as somewhat of a relief to all the people forced to use it.
dfc 8y ago
It's strange to me to imagine that there would be one language that was the best choice for OS implementation and day to day user interaction/automation. I'm curious what language do you think would be good for both use cases?
- wlib 8y ago
  A more syntactically friendly Haskell-like language
  - int_19h 8y ago
    How would you deal with mutable state like, say, the current directory?
    - jrs95 8y ago
      When all you have is a Haskell everything starts to look like a monad
    - Risord 8y ago
      I think that if we use purish FP as our system language it doesn't make sense to just emulate imperative/mutable system. But mm... why you would want to mutable state like current directory in first place? Or even mutable filesystem? Why aren't those just immutable parameters of your program?
      - adwn 8y ago
        > But mm... why you would want to mutable state like current directory in first place? Or even mutable filesystem? Why aren't those just immutable parameters of your program? Because that's how just about any OS, application, library, filesystem, device driver, database, nearly everything related to computing at all, works. Reinventing the universe has never, ever lead to success. If you want even the slightest hope for non-negligible adoption of your operating system, you need to be able to interface with the rest of the world. And that's why you don't want the filesystem to be an "immuatble parameter of your program".
        Risord 8y ago
        You can still build compatibility layer on top of immutable FS. Like being mutable from program(s) perspective while being able to control how these changes are capsulated from rest of the system. You could, for example, see what your > any OS, application, library, filesystem, device driver, database, nearly everything related to computing at all -is trying to actually do to your files and operation like reverting changes is trivial. Sure it's not performance optimal and effects what kind of software is ideal to work within such a system. It's just a different approach with different trade-offs. Anyway if I one day want to build new OS it's for trying different interesting approaches and not yet another 'successful any-OS'.
algesten 8y ago
The choice of python as your shell would surely be as arbitrary as bash? There is a long history of alternative shells csh, tcsh, zsh, fish, etc. All with various level of abstraction and various amounts of "programming language type constructs" (for lack of a better term). At the end of the day, long arguments have been had over which is the better shell. It's all just personal preference. Hence it can be set in /etc/passwd per user. You prefer python? chsh is there to change it.
- wlib 8y ago
  My point wasn't about python, just an example of how a shell around python, made only for python function calls, would be a useless abstraction.
  - otabdeveloper2 8y ago
    Something like IPython, amirite? XD
nurettin 8y ago
I have a different theory; perhaps line printers (which terminals try to emulate) are to blame. Space on a line is limited and one directional, so thr tools naturally evolved towards strange single line incantations instead of full fledged programs. Commodore Pet did it right by introducing a navigable terminal where you could move between lines and don't need to open an editor to write multiline programs.
- pmontra 8y ago
  I don't have time to Google now but I think that mainframe terminals worked like that. 3270 should be the model to search for.
  - TheOtherHobbes 8y ago
    This was already a solved problem in the 70s. IBM's 3270 series offered full buffered access to a character matrix display, and DEC's VT52 and later terminals added bi-directional scrolling. Modern CLIs can usually emulate at least a few of the old scrolling character matrix displays, but only a few bash commands (e.g. top) use the extra features.
dragonwriter 8y ago
> Do you use a separate, awkward tool to call functions you wrote in python? I use a separate tool to call a lot of functions written in C. That tool is called “Python”. Or “Ruby”. Sometimes I use a separate tool to call functions written in Python (or JavaScript, or...) and that tool is called PostgreSQL. Sometimes I use Ruby to call C to call Postgres to call JS. > Now that we have better languages, why not use them to write the OS bottom-up? What better languages for implementing an OS? Lisp? We had that before C. Rust? Either way—and I like both languages—I don't want to use either for a shell. Red? Maybe, but I don't think we're to the point of a Red OS yet, and while it's probably eventually usable for that purpose, I don't see it as necessarily ideal for OS implementation though it might be tolerable as a shell language.