11–20 of 208 posts
I agree that a filesystem as we know it in unix-like systems is a set of objects (directories) and files.
Would it not be preferable to retain this simple interface and instead conceive of interaction between programs and threads not as a stream of distinct objects in memory, but rather as a data tree within each program's control which can be exposed as input or output for other programs to map against and write into / consume?
(Only read the abstract). I’m learning Emacs and it’s making me think that we missed on the correct abstraction level of the operating system. There are programs that are OS-like (Emacs, browsers, Electron, anything that takes plug-ins). Maybe operating systems could have been lower level, and we could have developed more/better options on the pseudoOS level on top. This seems somewhat inline with the Smalltalk visio…
http://www.softwarepreservation.org/projects/LISP/interlisp_...
Then follow up with "The Interlisp Programming Environment"
https://www.computer.org/csdl/magazine/co/1981/04/01667317/1...
"Graphical Programming in Interlisp-D"
https://www.youtube.com/watch?v=wlN0hHLZL8c
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
Cedar was the very first graphical workstation for something like .NET and Java would later kind of try to become.
Unix generally has the correct basis for the design. I agree that a filesystem as we know it in unix-like systems is a set of objects (directories) and files. Would it not be preferable to retain this simple interface and instead conceive of interaction between programs and threads not as a stream of distinct objects in memory, but rather as a data tree within each program's control which can be exposed as input or o…
I can't help but think about what happened with graphics APIs - the older ones (DX9, OpenGL) held your hand more, and the new ones are super bare metal and not written for the faint of heart. I think most would agree this is better though; for an application developer you can simply use a much higher level library built on top, and for the library/engine developer you have a lot more power and control. The old APIs w…
The existing issues aren't technical, rather political, like the WinRT crusade that ended up bombing and now we have plenty of GUI toolkits to chose from on Windows.
Swift, Java, Kotlin and the .NET languages are more than high level enough.
On one had - yes please, screw OSes, gimme something like Smalltalk environment (in it's Pharo incarnation preferably). On other hand - define OS. Isn't that Smalltalk environment an OS if it runs bare metal?
Yes, there is a very blurry line between operating systems, programming languages, and we can include databases as well. Some operating systems as you point out are PLs. Some PLs are implemented as databases. They’re all just really complex accounting systems by nature. Look at the implementation of a lot of OSes, PLs and DBs they are really just made up of tables keeping track of relationships all the way down.
Unix generally has the correct basis for the design. I agree that a filesystem as we know it in unix-like systems is a set of objects (directories) and files. Would it not be preferable to retain this simple interface and instead conceive of interaction between programs and threads not as a stream of distinct objects in memory, but rather as a data tree within each program's control which can be exposed as input or o…
I can't help but think about what happened with graphics APIs - the older ones (DX9, OpenGL) held your hand more, and the new ones are super bare metal and not written for the faint of heart. I think most would agree this is better though; for an application developer you can simply use a much higher level library built on top, and for the library/engine developer you have a lot more power and control. The old APIs w…
Nah, Android, macOS and Windows are doing just fine, it is the classical UNIX desktop that cannot get their act together. The existing issues aren't technical, rather political, like the WinRT crusade that ended up bombing and now we have plenty of GUI toolkits to chose from on Windows. Swift, Java, Kotlin and the .NET languages are more than high level enough.
CDE? That hasn't existed for decades.
I can't help but think about what happened with graphics APIs - the older ones (DX9, OpenGL) held your hand more, and the new ones are super bare metal and not written for the faint of heart. I think most would agree this is better though; for an application developer you can simply use a much higher level library built on top, and for the library/engine developer you have a lot more power and control. The old APIs w…
Nah, Android, macOS and Windows are doing just fine, it is the classical UNIX desktop that cannot get their act together. The existing issues aren't technical, rather political, like the WinRT crusade that ended up bombing and now we have plenty of GUI toolkits to chose from on Windows. Swift, Java, Kotlin and the .NET languages are more than high level enough.
Unix generally has the correct basis for the design. I agree that a filesystem as we know it in unix-like systems is a set of objects (directories) and files. Would it not be preferable to retain this simple interface and instead conceive of interaction between programs and threads not as a stream of distinct objects in memory, but rather as a data tree within each program's control which can be exposed as input or o…
I think the problem with the unix model is that there isn't a rich enough array of types -- everything is just a stream of bytes and the closest thing you have to lists and records are strings with spaces and newlines. It was revolutionary in the 70s but compared to what you can do with something like powershell (which has its own issues) it's just not a rich or easy to use model anymore.
Complexity, particularly NOT-self-documenting complexity, becomes a nightmare.
Imagine instead that each program controls a special area under /proc/(pid)/ which behave like tmpfs to that program: named interfaces are subdirectories, messages are files.
Reflection of supported interfaces becomes easy. It integrates with existing software, and it's self documenting for both software and users.
Complexity can be opt-in rather than the only way to operate.