3 ms·

@qznc that's an intriguing formulation. Could you elaborate a bit? 1) What do you mean by "image approach"? 2) What example are you thinking of for the "link

@qznc that's an intriguing formulation. Could you elaborate a bit? 1) What do you mean by "image approach"? 2) What example are you thinking of for the "link lots of libraries via function calls" approach? The trichotomy I am familiar with is to divide things up into lisp vs c/unix vs smalltalk schools, but that doesn't seem to map to what you are saying.

spc476 14y ago
For "image" read, a runnable core file that can be updated (from within the program) and saved. Seriously. Forth and Smalltalk are two languages that are typically "image" based. Because of that, the concept of a "program" might not make sense, because it's more of an operating environment. And even if you do buy the concept of a "program", each program is, in essence, a potential development environment (if the REPL is exposed---it can be sometimes be hidden or even modified). As such, a "program upgrade" is (in my opinion) insanely difficult to manage in such an environment, as the customer may have extended the program in an incompatible way with respect to the upgrade. Also, the concept of "source code" might not exist as we understand it (a human readable set of instructions the computer will carry out stored in a file or files). Forth will compile the code directly; Smalltalk (disclaimer: I have no experience with Smalltalk) might store the code you type somewhere, so it can be viewed and edited, but there's no guarantee it's a "file".
qznc 14y ago
As spc476 answered 1), I'll just expand on 2). Emacs would be an example of the link approach. It includes an editor and an email program, which are composed into a single program/image. In contrast, the Unix functionality (vim,sendmail) is split into separate programs. What is the difference between a function call and a program invocation? In both cases we have a name and maybe some arguments. In both cases the computer executes some code bound to that name parameterized with our arguments. The difference is primarily, how expensive is the name resolution. A shell command requires inspecting $PATH, looking through directories, fork/exec another program, which is a lot syscalls. A function call in the best case has been compiled to a "call" instruction, whose cost depends on the branch prediction. Of course, there are various levels in between (dynamically linked libraries, plugins, shell builtins, etc). There are more complex composition methods like SAAS or cloud computing. There are more efficient methods (inlining optimization). Semantically, it is interesting when a name is resolved. Compiled languages (C,Go) usually do this statically at compile time, where C is even more restrictive as it only looks above in the code. Dynamic languages (Python,Ruby) do it at runtime. In general, early binding is usually good for performance, while late binding is better for flexibility.

spc476 14y ago

For "image" read, a runnable core file that can be updated (from within the program) and saved. Seriously. Forth and Smalltalk are two languages that are typically "image" based. Because of that, the concept of a "program" might not make sense, because it's more of an operating environment. And even if you do buy the concept of a "program", each program is, in essence, a potential development environment (if the REPL is exposed---it can be sometimes be hidden or even modified). As such, a "program upgrade" is (in my opinion) insanely difficult to manage in such an environment, as the customer may have extended the program in an incompatible way with respect to the upgrade. Also, the concept of "source code" might not exist as we understand it (a human readable set of instructions the computer will carry out stored in a file or files). Forth will compile the code directly; Smalltalk (disclaimer: I have no experience with Smalltalk) might store the code you type somewhere, so it can be viewed and edited, but there's no guarantee it's a "file".

qznc 14y ago

As spc476 answered 1), I'll just expand on 2). Emacs would be an example of the link approach. It includes an editor and an email program, which are composed into a single program/image. In contrast, the Unix functionality (vim,sendmail) is split into separate programs. What is the difference between a function call and a program invocation? In both cases we have a name and maybe some arguments. In both cases the computer executes some code bound to that name parameterized with our arguments. The difference is primarily, how expensive is the name resolution. A shell command requires inspecting $PATH, looking through directories, fork/exec another program, which is a lot syscalls. A function call in the best case has been compiled to a "call" instruction, whose cost depends on the branch prediction. Of course, there are various levels in between (dynamically linked libraries, plugins, shell builtins, etc). There are more complex composition methods like SAAS or cloud computing. There are more efficient methods (inlining optimization). Semantically, it is interesting when a name is resolved. Compiled languages (C,Go) usually do this statically at compile time, where C is even more restrictive as it only looks above in the code. Dynamic languages (Python,Ruby) do it at runtime. In general, early binding is usually good for performance, while late binding is better for flexibility.