3 ms·

And Smalltalk. But this was a great article which highlighted some of the creativity that got me interested in computers in the first place. Building an operati

And Smalltalk. But this was a great article which highlighted some of the creativity that got me interested in computers in the first place. Building an operating system isn't "hard" but it is a lot of work the more you do. That is time consuming (but in a fun way, like reading books is time consuming) Off and on I've experimented with a small event driven real time OS for my robots that started as a Forth kernel, switched over to a C kernel, and then to a Rust kernel. The experimental part has been looking at "infinite asynchronous threading" and it was hugely influenced by Rodney Brook's subsumption architecture. My thesis being that organisms aren't driven by a single scheduler and a bunch of processes, why should an OS be. (there are arguments pro and con on that one :-)). Anyway, not everyone is an 'OS' type. At Sun we used to joke you were either an 'OS' type, 'Language' type, or a 'GUI' type. Those were the core areas of investigation in the software organization. I tend to be an 'OS' type with a bit of 'language' thrown in :-)

MaxLeiter 5y ago
I’ve been on a Smalltalk binge the last few days and have really been enjoying this two hour long interview / demo with Dan Ingalls on Smalltalk and the Alto: https://youtu.be/uknEhXyZgsg https://youtu.be/uknEhXyZgsg
kragen 5y ago
What's "infinite asynchronous threading"?
jazzyjackson 5y ago
> organisms aren't driven by a single scheduler and a bunch of processes, why should an OS be Sounds like neuromorphic computing, or clockless circuits in general. Really interesting stuff, I'm working on a programming language based on macro-expansion and dependency resolution with a scheduling model of "do everything as soon as you can, and not a moment sooner!" Have you happened upon Andy Clark's book, Being There -- Putting Brain, Body, and World Together Again ? It was very influential to me in how to think of computers as organisms that can process parallel stimulus.
- ChuckMcM 5y ago
  This sounds a lot like what I was considering. Initially I had a uC/OS kernel and added the equivalent of sleep()/wakeup() and the AmigaOS message ports. QNX took messaging to the extreme (in my opinion :-) but it makes a good way to delineate taskable data. Back at NetApp I was trying to accelerate file processing and realized that files (and mutations thereof) were just a state machine which (and this isn't new or anything, log file systems are an extension of this observation) but the interesting thing was how you could project a sequence of state transitions and reliably determine if it was possible to jump to the end state or not. (and yes this is basically optimizing non-directed graph traversal using robot state which can be reflected in external things like actuator position) The games people are doing these sorts of things to animate elements of their game environment which I find pretty cool too. Once my Tilt5 glasses arrive I expect I can play with this in 3Space using Unity and the SDK which will make it less of a thought exercise and more of a visualization exercise. Guessing that lookalive-software is your github, have you put up your thoughts anywhere? Would love to read through them.
  - jazzyjackson 5y ago
    thanks for the interest, the implementation has been in stealth mode but an old first draft description of the language is at https://lookalive.software/ https://lookalive.software/ Could you say what it means to 'project a sequence of state transitions' ? I am not hip to the CS lingo - you could say I am scanning the AST for tasks whose prerequisites include no further tasks, and replacing the branch of a completed task with its result. Essentially all I'm doing is asking the coder to write an AST directly, except expressions can be mixed in with literals. I was just doing a kind of handlebars/mustache templating engine with JSON before realizing I had all the pieces for a general purpose language. My hello world(s) looks like: {"body": [ {"#!cat planets.txt": [ {"h1": "#!echo hello :0"} }] ]} The interpreter scans the JSON for the #! token and checks if all the parameters are literals, so first it hits #!cat and sees the argument 'planets.txt', OK, nothing further to compute, pass it off to a subshell and get the result, say, `mercury\nvenus\nearth\mars`. Newline separated results get interpreted as an array, and arrays are mapped over the next branch of the tree to get: {"body": [ {"#= mercury": [ {"h1": "#!echo hello :0"} ]}, {"#= venus": [ {"h1": "#!echo hello :0"} ]}, {"#= earth": [ {"h1": "#!echo hello :0"} ]}, {"#= mars": [ {"h1": "#!echo hello :0"} ]}, ]} At this point, there are four branches of the AST that have no shared dependencies, so my interpreter can solve them in parallel: before `#!echo` is ready, the colon marks a named (in this case numbered) argument to lookup so "#!echo hello :0" gets replaced with "#!echo hello mercury", and now all four echo branches can be forked in parallel. (If you're asking why I have to use a subshell and the echo program just to concatenate two strings, it's because the language has no builtins except #=, #&, #!, and #? ((for label, lookup, solve, and switch)). You can define functions but I wanted to start off with builtins provided by the OS, communications overhead be damned.) The '#=' then collapses once it's children are all literal so the final state of the program is: {"body": [ {"h1":"hello mercury"}, {"h1":"hello venus"}, {"h1":"hello earth"}, {"h1":"hello mars"} ]} Which can then be translated to HTML by `github.com/lookalive-software/elementary` -- besides the parallelism and declarative/functional style, my selling point is being able to step through the process, so the editor is able to rewind the state, adjust something, and resume execution. Every state is a new valid program (valid JSON too), so if you want to pause the program, upload it to a bigger computer, and resume you can do that to. Not sure if those were quite the thoughts you were looking for, but I've been meaning to start writing docs for the current implementation anyway, so thanks for the push. If you want to know more details about the queueing / scheduler, I need to write the docs for that too ;)
lproven 5y ago
Thanks very much! Especially in the context that reading on as this thread rapidly tends towards "terrifying incomprehensibility", I take that as high praise.

MaxLeiter 5y ago

I’ve been on a Smalltalk binge the last few days and have really been enjoying this two hour long interview / demo with Dan Ingalls on Smalltalk and the Alto: https://youtu.be/uknEhXyZgsg https://youtu.be/uknEhXyZgsg

kragen 5y ago

What's "infinite asynchronous threading"?

jazzyjackson 5y ago

> organisms aren't driven by a single scheduler and a bunch of processes, why should an OS be Sounds like neuromorphic computing, or clockless circuits in general. Really interesting stuff, I'm working on a programming language based on macro-expansion and dependency resolution with a scheduling model of "do everything as soon as you can, and not a moment sooner!" Have you happened upon Andy Clark's book, Being There -- Putting Brain, Body, and World Together Again ? It was very influential to me in how to think of computers as organisms that can process parallel stimulus.

ChuckMcM 5y ago
This sounds a lot like what I was considering. Initially I had a uC/OS kernel and added the equivalent of sleep()/wakeup() and the AmigaOS message ports. QNX took messaging to the extreme (in my opinion :-) but it makes a good way to delineate taskable data. Back at NetApp I was trying to accelerate file processing and realized that files (and mutations thereof) were just a state machine which (and this isn't new or anything, log file systems are an extension of this observation) but the interesting thing was how you could project a sequence of state transitions and reliably determine if it was possible to jump to the end state or not. (and yes this is basically optimizing non-directed graph traversal using robot state which can be reflected in external things like actuator position) The games people are doing these sorts of things to animate elements of their game environment which I find pretty cool too. Once my Tilt5 glasses arrive I expect I can play with this in 3Space using Unity and the SDK which will make it less of a thought exercise and more of a visualization exercise. Guessing that lookalive-software is your github, have you put up your thoughts anywhere? Would love to read through them.
- jazzyjackson 5y ago
  thanks for the interest, the implementation has been in stealth mode but an old first draft description of the language is at https://lookalive.software/ https://lookalive.software/ Could you say what it means to 'project a sequence of state transitions' ? I am not hip to the CS lingo - you could say I am scanning the AST for tasks whose prerequisites include no further tasks, and replacing the branch of a completed task with its result. Essentially all I'm doing is asking the coder to write an AST directly, except expressions can be mixed in with literals. I was just doing a kind of handlebars/mustache templating engine with JSON before realizing I had all the pieces for a general purpose language. My hello world(s) looks like: {"body": [ {"#!cat planets.txt": [ {"h1": "#!echo hello :0"} }] ]} The interpreter scans the JSON for the #! token and checks if all the parameters are literals, so first it hits #!cat and sees the argument 'planets.txt', OK, nothing further to compute, pass it off to a subshell and get the result, say, `mercury\nvenus\nearth\mars`. Newline separated results get interpreted as an array, and arrays are mapped over the next branch of the tree to get: {"body": [ {"#= mercury": [ {"h1": "#!echo hello :0"} ]}, {"#= venus": [ {"h1": "#!echo hello :0"} ]}, {"#= earth": [ {"h1": "#!echo hello :0"} ]}, {"#= mars": [ {"h1": "#!echo hello :0"} ]}, ]} At this point, there are four branches of the AST that have no shared dependencies, so my interpreter can solve them in parallel: before `#!echo` is ready, the colon marks a named (in this case numbered) argument to lookup so "#!echo hello :0" gets replaced with "#!echo hello mercury", and now all four echo branches can be forked in parallel. (If you're asking why I have to use a subshell and the echo program just to concatenate two strings, it's because the language has no builtins except #=, #&, #!, and #? ((for label, lookup, solve, and switch)). You can define functions but I wanted to start off with builtins provided by the OS, communications overhead be damned.) The '#=' then collapses once it's children are all literal so the final state of the program is: {"body": [ {"h1":"hello mercury"}, {"h1":"hello venus"}, {"h1":"hello earth"}, {"h1":"hello mars"} ]} Which can then be translated to HTML by `github.com/lookalive-software/elementary` -- besides the parallelism and declarative/functional style, my selling point is being able to step through the process, so the editor is able to rewind the state, adjust something, and resume execution. Every state is a new valid program (valid JSON too), so if you want to pause the program, upload it to a bigger computer, and resume you can do that to. Not sure if those were quite the thoughts you were looking for, but I've been meaning to start writing docs for the current implementation anyway, so thanks for the push. If you want to know more details about the queueing / scheduler, I need to write the docs for that too ;)

lproven 5y ago

Thanks very much! Especially in the context that reading on as this thread rapidly tends towards "terrifying incomprehensibility", I take that as high praise.