I was thinking if you have an interpreter that takes a program listing like this:
a(b(c,d,e), f("foo.txt", "sample.png", 1))
But a,b,c,d,e, and f are all stand-alone programs. They can execute by themselves taking certain numbers of arguments and returning something, but this interpreter I'm thinking of can recurse through this structure and feed the outputs from each program to an enclosing program.
For example in the above, f could be a program that writes the text in the first argument on the picture in the second argument if the third argument is 1. c,d, and e could be programs that output images, and b makes a composite image from them. Then A is a program that puts the result of all of those in one big composite picture, displays it and plays a song.
Anyway the idea is that using this interpreted language you could break a big program into a lot of small programs that the operating system can schedule and use all of the available processors of your computer. If instead you made one big program out of each of these small programs as say, functions inside the program, you would have to do a lot of work programming how to distribute the workload across all the cores or how to do the threads and all of that stuff is hard to program. But the operating system already does a good job of this for multitasking the various programs you might have running on your computer, so you just let it do the hard part.
The one I showed was just a one line interpreted program of programs but the language could have a lot more features.
No comments:
Post a Comment