3 ms·

In that case would you please explain this apparent bafflegab? What we currently call general purpose languages are actually domain specific languages for th

by User23 4y ago

In that case would you please explain this apparent bafflegab? What we currently call general purpose languages are actually domain specific languages for the domain of algorithms.

mpweiher 4y ago
Hmm...not sure what you find gobbledygooky or jargon-y about this...it is about as clear as I can make it. I mean it is definitely a surprising even somewhat baffling insight, but once it is there it seems pretty clear. I gave a longer explanation here: https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p... (That paper is also linked from the publications page: http://objective.st/Publications/ http://objective.st/Publications/ ) Short summary: 1. Historically, computers were created to compute results (hence the name) using algorithms. So you have a function/procedure that you give parameters, it executes the algorithm, spits out the answer and terminates. 2. Programming languages reflect this. Heck, the granddaddy of most mainstream programming languages is ALGOL, the ALGOrithmic Language. https://en.wikipedia.org/wiki/ALGOL https://en.wikipedia.org/wiki/ALGOL 3. The majority of programs/system today are not like (1). See for example Chatty: https://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf or also Guy Steele's opening statement for the "Objects have failed" OOPSLA panel: https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html "Another weakness of procedural and functional programming is that their viewpoint assumes a process by which "inputs" are transformed into "outputs"; [...] Ongoing behavior, not completion, is now of primary interest." Happy to answer any more specific questions. Again, the insight is definitely somewhere between surprising and outright baffling, particularly because call/return is very much paradigmatic in the Kuhnian sense: a set of shared and implicit assumptions, so things we don't even think about but that form the basis of everything else.
- naasking 4y ago
  Let's put your claim that Objective-S can be used to implement different architectural styles to the test: implement Prolog or some other logic programming language as an architecture! I think the other architectures you've listed there aren't different enough from the typical call/return style of algorithm-centered languages, but logic programming certainly is.
  - User23 4y ago
    Incidentally implementing prolog in Common Lisp is, while not trivial, quite natural[1]. [1] https://github.com/norvig/paip-lisp/blob/main/lisp/prolog.lisp https://github.com/norvig/paip-lisp/blob/main/lisp/prolog.li...
  - User23 4y ago
    Forth is another good example. There’s no call and return, but it can be used to implement any algorithm.
    - mpweiher 4y ago
      > Forth is another good example. There’s no call and return Huh? Could have fooled...well, everyone, including Chuck Moore. Emphasis mine. https://web.archive.org/web/20060101073958/http://www.colorforth.com/cf.html https://web.archive.org/web/20060101073958/http://www.colorf... "The Data stack holds parameters for and results of subroutine calls. This distinction between control and data minimizes the cost of subroutine calls. https://en.wikipedia.org/wiki/Forth_(programming_language) https://en.wikipedia.org/wiki/Forth_(programming_language) "Forth is a procedural, stack-oriented programming language..." "...where the user interacts via subroutines called words. " "First a number (1 or 8) is pushed onto the stack, FLOOR5 is called,..." "This is the same as what a processor's call/return instructions do." https://www.forth.com/resources/forth-programming-language/ https://www.forth.com/resources/forth-programming-language/ "The benefit of having a stack reserved for return addresses was that the other stack could be used freely for parameter passing, without having to be “balanced” before and after calls" ...
- User23 4y ago
  Historically programming languages were designed to transform some initial state of the machine to some other state having some specified desirable properties. An algorithm is simply an “effective procedure” for instructing the state machine on how to go about modifying itself to achieve that end. Computing functions can and has been a use case sure, but it’s never been the only one. Simulation for example has a long history in computing. In the simulation use case there is no defined end, you just let it run and observe. Of course one can model each state transition as a function from machine state to machine state, but that’s just a mathematical way of talking about the machine and not a programming paradigm. You can see the legacy of the above in C, where many problems are best expressed directly as state machines. There is some confusion here because C chose to conflate functions, procedures, and subroutines, so code organization encourages use of C functions. The void return type is a workaround. It would also be idiomatic C to, for example, dispense with functions and use labels and switch/goto to organize state transitions. Your confusion is understandable since virtually every programming language in widespread use today is at least in some sense a spiritual successor to C in the sense of adopting many of its conventions. By the way I think Objective-S is interesting and I am glad it’s being developed. So please consider impressing readers with what actually is impressive about it.
  - mpweiher 4y ago
    > spiritual successor to C Pretty much every major programming language in use today is a spiritual successor to ALGOL. What is ALGOL? The ALGOrithmic Language. https://en.wikipedia.org/wiki/ALGOL https://en.wikipedia.org/wiki/ALGOL And then there's some Lisp descendants, though those can't really be considered mainstream. Lisp's core is eval/apply. Prolog is an interesting case, but in many ways it just embeds the algorithm in the language. From an outside perspective, you give it something to evaluate and it runs off and returns an answer. The main outlier is the Unix shell, which, like Objective-S, is connect + run: you configure a pipeline out of filters, connect them up and then run the whole thing. And this can and will continue running indefinitely. Call/return is sort of a (common) special case. And that's interesting, because it seems to actually be easier to make call/return a special case of connect+run, but we do it the other way around.

by User23 4y ago

In that case would you please explain this apparent bafflegab? What we currently call general purpose languages are actually domain specific languages for the domain of algorithms.

mpweiher 4y ago

Hmm...not sure what you find gobbledygooky or jargon-y about this...it is about as clear as I can make it. I mean it is definitely a surprising even somewhat baffling insight, but once it is there it seems pretty clear. I gave a longer explanation here: https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p... (That paper is also linked from the publications page: http://objective.st/Publications/ http://objective.st/Publications/ ) Short summary: 1. Historically, computers were created to compute results (hence the name) using algorithms. So you have a function/procedure that you give parameters, it executes the algorithm, spits out the answer and terminates. 2. Programming languages reflect this. Heck, the granddaddy of most mainstream programming languages is ALGOL, the ALGOrithmic Language. https://en.wikipedia.org/wiki/ALGOL https://en.wikipedia.org/wiki/ALGOL 3. The majority of programs/system today are not like (1). See for example Chatty: https://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf or also Guy Steele's opening statement for the "Objects have failed" OOPSLA panel: https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html "Another weakness of procedural and functional programming is that their viewpoint assumes a process by which "inputs" are transformed into "outputs"; [...] Ongoing behavior, not completion, is now of primary interest." Happy to answer any more specific questions. Again, the insight is definitely somewhere between surprising and outright baffling, particularly because call/return is very much paradigmatic in the Kuhnian sense: a set of shared and implicit assumptions, so things we don't even think about but that form the basis of everything else.

naasking 4y ago
Let's put your claim that Objective-S can be used to implement different architectural styles to the test: implement Prolog or some other logic programming language as an architecture! I think the other architectures you've listed there aren't different enough from the typical call/return style of algorithm-centered languages, but logic programming certainly is.
- User23 4y ago
  Incidentally implementing prolog in Common Lisp is, while not trivial, quite natural[1]. [1] https://github.com/norvig/paip-lisp/blob/main/lisp/prolog.lisp https://github.com/norvig/paip-lisp/blob/main/lisp/prolog.li...
- User23 4y ago
  Forth is another good example. There’s no call and return, but it can be used to implement any algorithm.
  - mpweiher 4y ago
    > Forth is another good example. There’s no call and return Huh? Could have fooled...well, everyone, including Chuck Moore. Emphasis mine. https://web.archive.org/web/20060101073958/http://www.colorforth.com/cf.html https://web.archive.org/web/20060101073958/http://www.colorf... "The Data stack holds parameters for and results of subroutine calls. This distinction between control and data minimizes the cost of subroutine calls. https://en.wikipedia.org/wiki/Forth_(programming_language) https://en.wikipedia.org/wiki/Forth_(programming_language) "Forth is a procedural, stack-oriented programming language..." "...where the user interacts via subroutines called words. " "First a number (1 or 8) is pushed onto the stack, FLOOR5 is called,..." "This is the same as what a processor's call/return instructions do." https://www.forth.com/resources/forth-programming-language/ https://www.forth.com/resources/forth-programming-language/ "The benefit of having a stack reserved for return addresses was that the other stack could be used freely for parameter passing, without having to be “balanced” before and after calls" ...
User23 4y ago
Historically programming languages were designed to transform some initial state of the machine to some other state having some specified desirable properties. An algorithm is simply an “effective procedure” for instructing the state machine on how to go about modifying itself to achieve that end. Computing functions can and has been a use case sure, but it’s never been the only one. Simulation for example has a long history in computing. In the simulation use case there is no defined end, you just let it run and observe. Of course one can model each state transition as a function from machine state to machine state, but that’s just a mathematical way of talking about the machine and not a programming paradigm. You can see the legacy of the above in C, where many problems are best expressed directly as state machines. There is some confusion here because C chose to conflate functions, procedures, and subroutines, so code organization encourages use of C functions. The void return type is a workaround. It would also be idiomatic C to, for example, dispense with functions and use labels and switch/goto to organize state transitions. Your confusion is understandable since virtually every programming language in widespread use today is at least in some sense a spiritual successor to C in the sense of adopting many of its conventions. By the way I think Objective-S is interesting and I am glad it’s being developed. So please consider impressing readers with what actually is impressive about it.
- mpweiher 4y ago
  > spiritual successor to C Pretty much every major programming language in use today is a spiritual successor to ALGOL. What is ALGOL? The ALGOrithmic Language. https://en.wikipedia.org/wiki/ALGOL https://en.wikipedia.org/wiki/ALGOL And then there's some Lisp descendants, though those can't really be considered mainstream. Lisp's core is eval/apply. Prolog is an interesting case, but in many ways it just embeds the algorithm in the language. From an outside perspective, you give it something to evaluate and it runs off and returns an answer. The main outlier is the Unix shell, which, like Objective-S, is connect + run: you configure a pipeline out of filters, connect them up and then run the whole thing. And this can and will continue running indefinitely. Call/return is sort of a (common) special case. And that's interesting, because it seems to actually be easier to make call/return a special case of connect+run, but we do it the other way around.