6 ms·

Blows my mind how so much really is text manipulation. Not every thing though!

by ianai 7y ago

keyle 7y ago
What does he mean by text manipulation?
- ianai 7y ago
  Writing email. Viewing logs. Configuring servers. Setting reminders can be done in cron. Probably lots I don’t know about offhand too.
- monocasa 7y ago
  So, like how in Linux, a lot of system manipulation is presented as psuedo text files in /proc and and /sys, but expanded to the rest of the system. So like the window manager is manipulated by creating fake files (fake as in they don't exist in any persistent storage device) and writing text to them that describes the state of the windows. Rather than socket() and setsockopt(), under the hood it's opening something like /dev/net/tcp/google.com/80/ctrl and reading and writing text about the state of the connection. Because of this the whole system is introspectable via cating interesting files.
  - deleted 7y ago
    [deleted]
smabie 7y ago
But, honestly, should it be? I personally find the idea of programming through text editors and files to be archaic and primitive. Superior models have been presented (Smalltalk, Lisp), but unfortunately have never caught on.
- disposedtrolley 7y ago
  I agree. Program execution is rarely linear too in a codebase of any real size, so viewing the source of a program as a linear page of text doesn't make much sense. I think there's an opportunity for a big player in the dev tools space to create a mainstream visual programming language and associated tooling. Many are trying, like Luna (https://github.com/luna/luna-studio https://github.com/luna/luna-studio) and Dark (https://darklang.com/ https://darklang.com/) but I'm worried they're not established enough to gain traction. Unfortunately programming with a text editor has become so mainstream that investing time in learning potentially better tools nets a lot of friction and not to much gain.
  - pjmlp 7y ago
    IDEs, shader editors, game design languages like Blueprint, LabVIEW are examples of mainstream tooling that aren't purely text based.
    - disposedtrolley 7y ago
      True, but I don’t think there’s a general purpose programming language whose tooling expresses source code as visual flows of data, that people would use in place of Go, Python etc.
      - lonelappde 7y ago
        You mean like Scratch? Everybody thinks they want that until they try it on a real non-toy problem. https://en.m.wikipedia.org/wiki/Intentional_programming https://en.m.wikipedia.org/wiki/Intentional_programming
        pjmlp 7y ago
        As someone that also has a background in digital circuits tooling, I think that the problem is the spaghetti codding that usually leads to monoliths. While on text based languages, lack of modularity is kind of hidden and only jumps at you when you try to actually change anything, on visual languages it jumps right at you when you open a project. Ideally, anything that requires panning or zooming, should be packed into their own little reusable building block, instead many try to package as much as they can into a single screen.
        disposedtrolley 7y ago
        > While on text based languages, lack of modularity is kind of hidden and only jumps at you when you try to actually change anything, on visual languages it jumps right at you when you open a project. I've worked on some projects using Node RED (https://nodered.org/ https://nodered.org/) and have found this to be very true. It's painfully obvious that you're in for a fun ride when the code is literally spaghetti.
- pjmlp 7y ago
  Sure they have caught on, among the C++, Delphi, Java and .NET communities, less so among other ones. IDEs are the continuation of those models.
- rodgerd 7y ago
  Excel does just fine.
  - disposedtrolley 7y ago
    Excel is too easy to abuse. Spaghetti formulas is just as bad as spaghetti code, especially if your business happens to run on Excel. Spreadsheets would be much more maintainable if people separated data from the view.
- MisterTea 7y ago
  > I personally find the idea of programming through text editors and files to be archaic and primitive. You have to think about 9p as an RPC protocol with files representing objects within the file server program. Reading/writing those files is how you interact with said objects. And it doesn't have to be text, it can be binary. Though text is used when a human has to interact with something. This is why you can do a lot of neat tricks using just a shell script as you can directly interact with a program using a standardized interface. No other operating system can claim such a high level of homogeneity. As a hypothetical example, take the game Doom. We modify it to serve a file system to expose all of the players stats as a file tree. So a file called health is an rpc call to read and write the players health. This means you can '% echo 100 >/n/doom/player/health' to set your health to 100. It also means you eliminated the need to reinvent the wheel and integrate a console shell in the game. This saves the programmer invaluable time and eliminates duplicate code. Now we can use shell scripts or helper programs to interact with the game. And they can be in any language as all they have to do is open(/path/to/file) and read() write(). Imagine how much code you can eliminate and how much flexibility you gain by exposing your programs innards in such a standard manner? At this point, you might be thinking "So, if it's a file server, does that mean I can export it to the network?" Yes. You can have another computer mount that doom file server and interact with it. You can also export your USB controller or other hardware using the same method. The level of flexibility is intoxicating and I don't care if it doesn't play youtube (that's what archaic and primitive 70's os's running in vmx(3) are for :-). Modern plan 9 and resources: http://9front.org/ http://9front.org/ (highly active community and recommended if you pan to investigate) http://ants.9gridchan.org/ http://ants.9gridchan.org/ (pop on the grid and say hello! also recommended) http://postnix.pw/ http://postnix.pw/ (resources) Legacy and Labs stuff (some activity still): http://9legacy.org/ http://9legacy.org/ (labs 9 and patches) http://9p.io/ http://9p.io/ (labs mirror, needs updating)
m463 7y ago
so... does plan 9 do emojis?
- kick 7y ago
  It does: Plan 9 was one of the first operating systems (probably the first) to go all-in on UTF-8
  - Shugyousha 7y ago
    Actually, it was Ken Thompson and Rob Pike working on Plan9 who invented UTF-8.
prodip002 7y ago
Good
skocznymroczny 7y ago
It's an interesting concept, and probably appeals to the Bash wizards, but I don't think it's the way forward. I think a more modern alternative would be to have all system components expose a standarized API, kind of like REST endpoints for the OS. The reply could be standarized binary or even JSON. It would still be better than text, and much easier to parse.
- throwaway5d097 7y ago
  9p is perhaps a bit more advanced/clean/general? than REST endpoints/HTTP. You can still use whatever serializable formats you want.

Blows my mind how so much really is text manipulation. Not every thing though!

by ianai 7y ago

Blows my mind how so much really is text manipulation. Not every thing though!

keyle 7y ago

What does he mean by text manipulation?

ianai 7y ago
Writing email. Viewing logs. Configuring servers. Setting reminders can be done in cron. Probably lots I don’t know about offhand too.
monocasa 7y ago
So, like how in Linux, a lot of system manipulation is presented as psuedo text files in /proc and and /sys, but expanded to the rest of the system. So like the window manager is manipulated by creating fake files (fake as in they don't exist in any persistent storage device) and writing text to them that describes the state of the windows. Rather than socket() and setsockopt(), under the hood it's opening something like /dev/net/tcp/google.com/80/ctrl and reading and writing text about the state of the connection. Because of this the whole system is introspectable via cating interesting files.
- deleted 7y ago
  [deleted]

smabie 7y ago

But, honestly, should it be? I personally find the idea of programming through text editors and files to be archaic and primitive. Superior models have been presented (Smalltalk, Lisp), but unfortunately have never caught on.

disposedtrolley 7y ago
I agree. Program execution is rarely linear too in a codebase of any real size, so viewing the source of a program as a linear page of text doesn't make much sense. I think there's an opportunity for a big player in the dev tools space to create a mainstream visual programming language and associated tooling. Many are trying, like Luna (https://github.com/luna/luna-studio https://github.com/luna/luna-studio) and Dark (https://darklang.com/ https://darklang.com/) but I'm worried they're not established enough to gain traction. Unfortunately programming with a text editor has become so mainstream that investing time in learning potentially better tools nets a lot of friction and not to much gain.
- pjmlp 7y ago
  IDEs, shader editors, game design languages like Blueprint, LabVIEW are examples of mainstream tooling that aren't purely text based.
  - disposedtrolley 7y ago
    True, but I don’t think there’s a general purpose programming language whose tooling expresses source code as visual flows of data, that people would use in place of Go, Python etc.
    - lonelappde 7y ago
      You mean like Scratch? Everybody thinks they want that until they try it on a real non-toy problem. https://en.m.wikipedia.org/wiki/Intentional_programming https://en.m.wikipedia.org/wiki/Intentional_programming
      - pjmlp 7y ago
        As someone that also has a background in digital circuits tooling, I think that the problem is the spaghetti codding that usually leads to monoliths. While on text based languages, lack of modularity is kind of hidden and only jumps at you when you try to actually change anything, on visual languages it jumps right at you when you open a project. Ideally, anything that requires panning or zooming, should be packed into their own little reusable building block, instead many try to package as much as they can into a single screen.
        disposedtrolley 7y ago
        > While on text based languages, lack of modularity is kind of hidden and only jumps at you when you try to actually change anything, on visual languages it jumps right at you when you open a project. I've worked on some projects using Node RED (https://nodered.org/ https://nodered.org/) and have found this to be very true. It's painfully obvious that you're in for a fun ride when the code is literally spaghetti.
pjmlp 7y ago
Sure they have caught on, among the C++, Delphi, Java and .NET communities, less so among other ones. IDEs are the continuation of those models.
rodgerd 7y ago
Excel does just fine.
- disposedtrolley 7y ago
  Excel is too easy to abuse. Spaghetti formulas is just as bad as spaghetti code, especially if your business happens to run on Excel. Spreadsheets would be much more maintainable if people separated data from the view.
MisterTea 7y ago
> I personally find the idea of programming through text editors and files to be archaic and primitive. You have to think about 9p as an RPC protocol with files representing objects within the file server program. Reading/writing those files is how you interact with said objects. And it doesn't have to be text, it can be binary. Though text is used when a human has to interact with something. This is why you can do a lot of neat tricks using just a shell script as you can directly interact with a program using a standardized interface. No other operating system can claim such a high level of homogeneity. As a hypothetical example, take the game Doom. We modify it to serve a file system to expose all of the players stats as a file tree. So a file called health is an rpc call to read and write the players health. This means you can '% echo 100 >/n/doom/player/health' to set your health to 100. It also means you eliminated the need to reinvent the wheel and integrate a console shell in the game. This saves the programmer invaluable time and eliminates duplicate code. Now we can use shell scripts or helper programs to interact with the game. And they can be in any language as all they have to do is open(/path/to/file) and read() write(). Imagine how much code you can eliminate and how much flexibility you gain by exposing your programs innards in such a standard manner? At this point, you might be thinking "So, if it's a file server, does that mean I can export it to the network?" Yes. You can have another computer mount that doom file server and interact with it. You can also export your USB controller or other hardware using the same method. The level of flexibility is intoxicating and I don't care if it doesn't play youtube (that's what archaic and primitive 70's os's running in vmx(3) are for :-). Modern plan 9 and resources: http://9front.org/ http://9front.org/ (highly active community and recommended if you pan to investigate) http://ants.9gridchan.org/ http://ants.9gridchan.org/ (pop on the grid and say hello! also recommended) http://postnix.pw/ http://postnix.pw/ (resources) Legacy and Labs stuff (some activity still): http://9legacy.org/ http://9legacy.org/ (labs 9 and patches) http://9p.io/ http://9p.io/ (labs mirror, needs updating)

m463 7y ago

so... does plan 9 do emojis?

kick 7y ago
It does: Plan 9 was one of the first operating systems (probably the first) to go all-in on UTF-8
- Shugyousha 7y ago
  Actually, it was Ken Thompson and Rob Pike working on Plan9 who invented UTF-8.

prodip002 7y ago

Good

skocznymroczny 7y ago

It's an interesting concept, and probably appeals to the Bash wizards, but I don't think it's the way forward. I think a more modern alternative would be to have all system components expose a standarized API, kind of like REST endpoints for the OS. The reply could be standarized binary or even JSON. It would still be better than text, and much easier to parse.

throwaway5d097 7y ago
9p is perhaps a bit more advanced/clean/general? than REST endpoints/HTTP. You can still use whatever serializable formats you want.