4 ms·

You might try reading further, because the claim is actually well-supported. Just because we call something "general purpose" doesn't mean it actually is.

EddySchauHai 4y ago
If you can build Objective-S in a language then isn't the language that contains the set of Objective-S and other languages in theory more general purpose? I'm not sure I get the definition.
- yellowapple 4y ago
  I guess it's the same question as whether the ability to implement an Erlang VM in C makes C a functional and/or concurrency-oriented language.
  - User23 4y ago
    C is a functional language[1]. That’s one of the finer examples of Haha, Only Serious I’ve seen for programming. [1] http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio...
KerrAvon 4y ago
I like what I've seen of Objective-S; I completely support and appreciate the thought you've put into it, but I don't think that's a great claim to make. Implicit is the claim that C, Lisp, Modula-2 are not general purpose languages, which is ridiculous. You may not want to deal with C's various problems, and it may take pages and pages of code to do in C what one line of Objective-S could do, but doesn't mean it can't be done.
munchler 4y ago
I read the rest of the About page and didn't see anything supporting this claim. What makes Objective-S more general than other languages? If it's the four architecture "styles" listed, I'm pretty sure other languages can do the same: * OO and Call/Return: Supported by every OO language. * Pipes and Filters: Supported by every functional programming language. * REST: Supported by many modern languages. (Go springs to mind as a typical example.) * Implicit Invocation / Event Broadcast: Supported by many modern languages.
- googlryas 4y ago
  I believe the argument is that this language has special syntax for these various "architectures", instead of other languages where you express those ideas with the syntax of calling/returning functions.
- Kuinox 4y ago
  You picked a different tool for each of the different entry, while the author is arguing their programming language is general purpose, because it allow to do each entry you listed, in a single language.
  - haimez 4y ago
    Right. A different _tool_ because they described paradigms aren’t language paradigms- they’re patterns or frameworks expressed more easily but also more commonly in some languages than others because of completely unrelated historical accidents. We have different languages because we do different things with them, and any Turing complete language can achieve any desired program. So what we’re left with is a misunderstanding about what is the “language”, “runtime”, and … “pattern?” There is no useful definition of “general purpose language” except to disqualify languages that are not general purpose. That’s a fine distinction to make when describing how SQL will never replace JavaScript, Java, or C- but a useless distinction when describing the characteristics of your new language that is also Turing complete. In particular item 4 “Implicit Invocation / Event Broadcast” is one of those things that hides an enormous amount of implementation complexity that arguably shouldn’t be made magical. Like async / await or go channels, the details make all the difference and there’s not a one size fits all approach that you can take without creating serious problems for other cases. It has to be an opinionated and therefore (sometimes/often) approach depending on what you’re attempting to accomplish.
    - mpweiher 4y ago
      Yes, exactly: these architectural styles should not be built into the language. And (mostly) aren't, in Objective-S. You should be able to build them yourself within the language and then they should have linguistic support that is as good / indistinguishable from built-in stuff. Just like Smalltalk does with, say collections: most languages have/had built-in support for one type of collection (or maybe two), typically arrays of a homogenous type. If you wanted to build your own collection, you could, but were limited with functional call syntax fora accessing that collection. With Smalltalk, collections yourself create are on an equal footing with collections that are in the base library. And that's an idea that has slowly percolated through the PL community and to practice. But not with architectural styles. Our mainstream programming languages typically support exactly one architectural style: call/return. That's the only one that allows abstraction. If you want a different one, you can build it, but you cannot express it. And that's a huge problem, as any non-default architectural style gets a huge expressiveness penalty. Previous languages that support alternative architectural styles usually have exactly the problem you've described: they offer exactly one implementation of that architectural style baked into the language, and that's it (Go channels are an example). And if you need something even slightly different, you're back in implementing + expressing with call/return, because that's the only style that allows abstraction. Sigh. With Objective-S, the idea is that you get to implement whatever you want in terms of architectural styles (connectors, components) and then get to surface it with syntax appropriate for architectural connection. And the implementation will usually also be call/return based, because that's what we currently have. Although I am starting to see places where I can actually implement a connector in terms of other connectors directly without mediating via procedure calls. (The one-way dataflow connector |= can be built from a storage combinator and a notification mechanism, and these can be pluggable. Very neat, particularly because building dataflow constraints naturally was one of my goals and this exceeds that goal). Of course there's a bit of a chicken/egg problem, in two variations: first, I must provide some "built-in" components and connectors that go outside the default set, otherwise the whole thing is useless. And there it turned out that the initial set (polymorphic write streams, storage combinators, dataflow constraints) turned out so useful and general that they sort of become "the thing", even though they aren't. The second, related chicken/egg problem is that both conceptually and from an implementation POV, we have to start somewhere concrete, because this is an abstraction mechanism that doesn't exist yet and thus nobody really has a clue how it should work. So things aren't as abstract/general yet as they should be.
User23 4y ago
Maybe it appears so to people who have never heard of Lisp and or used it.
- mpweiher 4y ago
  Lisp's core is eval/apply.
  - User23 4y ago
    Yes and? EVAL isn’t call/return, it’s a mathematical function from type S-expression to type S-expression modulo some details. At least it was to start, Lisp now has side effects which considerably opens up the domain of easily expressed programs. Perhaps you’re confused because you’ve never done anything nontrivial in a modern Lisp and the word function is so heavily overloaded? Here[1] is an example of the Actor model expressed in Common Lisp. It shows a paradigm that is very much not call and return expressed cleanly and directly. [1] https://github.com/naveensundarg/Common-Lisp-Actors https://github.com/naveensundarg/Common-Lisp-Actors
    - mpweiher 4y ago
      Interesting. > EVAL isn't call/return, it's a mathematical function Hmm...a "function" you say. What do you do with a function in a computer system? I mean, for it to actually do something? Look at it? Digest it? Sing it? Or maybe...call it? And when that function is done, after you called it what does it do? Dissolve? Perambulate? Or maybe: return? Of course, a function that you call and that then returns has absolutely nothing to do with the call/return architectural style. Sorry, my bad, what was I thinking? And no, your example does not invalidate what I wrote, as it doesn't implement it "cleanly and directly", at least not to my standards. Maybe to yours, but not to mine. The problem with Lisp DSLs is that the result always just look like Lisp, and Lisp is eval/apply. So (send my-actor message_args) very much looks like a Lisp function call. It seems to be the function "send" with arguments "my-actor" and "message_args". (Of course the Actor model is close enough that it might not matter). Which is exactly the problem we have in other languages. At the very least, it would have to be my-actor async messge_args For it to qualify as resembling an actual send and not just another function call. I can also write: source.connect( target ); And to you that would apparently mean that I have implemented pipes and filters "cleanly and directly" in, say, C++ and Java. And it would be just as wrong.
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.

EddySchauHai 4y ago

If you can build Objective-S in a language then isn't the language that contains the set of Objective-S and other languages in theory more general purpose? I'm not sure I get the definition.

yellowapple 4y ago
I guess it's the same question as whether the ability to implement an Erlang VM in C makes C a functional and/or concurrency-oriented language.
- User23 4y ago
  C is a functional language[1]. That’s one of the finer examples of Haha, Only Serious I’ve seen for programming. [1] http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio...

KerrAvon 4y ago

I like what I've seen of Objective-S; I completely support and appreciate the thought you've put into it, but I don't think that's a great claim to make. Implicit is the claim that C, Lisp, Modula-2 are not general purpose languages, which is ridiculous. You may not want to deal with C's various problems, and it may take pages and pages of code to do in C what one line of Objective-S could do, but doesn't mean it can't be done.

munchler 4y ago

I read the rest of the About page and didn't see anything supporting this claim. What makes Objective-S more general than other languages? If it's the four architecture "styles" listed, I'm pretty sure other languages can do the same: * OO and Call/Return: Supported by every OO language. * Pipes and Filters: Supported by every functional programming language. * REST: Supported by many modern languages. (Go springs to mind as a typical example.) * Implicit Invocation / Event Broadcast: Supported by many modern languages.

googlryas 4y ago
I believe the argument is that this language has special syntax for these various "architectures", instead of other languages where you express those ideas with the syntax of calling/returning functions.
Kuinox 4y ago
You picked a different tool for each of the different entry, while the author is arguing their programming language is general purpose, because it allow to do each entry you listed, in a single language.
- haimez 4y ago
  Right. A different _tool_ because they described paradigms aren’t language paradigms- they’re patterns or frameworks expressed more easily but also more commonly in some languages than others because of completely unrelated historical accidents. We have different languages because we do different things with them, and any Turing complete language can achieve any desired program. So what we’re left with is a misunderstanding about what is the “language”, “runtime”, and … “pattern?” There is no useful definition of “general purpose language” except to disqualify languages that are not general purpose. That’s a fine distinction to make when describing how SQL will never replace JavaScript, Java, or C- but a useless distinction when describing the characteristics of your new language that is also Turing complete. In particular item 4 “Implicit Invocation / Event Broadcast” is one of those things that hides an enormous amount of implementation complexity that arguably shouldn’t be made magical. Like async / await or go channels, the details make all the difference and there’s not a one size fits all approach that you can take without creating serious problems for other cases. It has to be an opinionated and therefore (sometimes/often) approach depending on what you’re attempting to accomplish.
  - mpweiher 4y ago
    Yes, exactly: these architectural styles should not be built into the language. And (mostly) aren't, in Objective-S. You should be able to build them yourself within the language and then they should have linguistic support that is as good / indistinguishable from built-in stuff. Just like Smalltalk does with, say collections: most languages have/had built-in support for one type of collection (or maybe two), typically arrays of a homogenous type. If you wanted to build your own collection, you could, but were limited with functional call syntax fora accessing that collection. With Smalltalk, collections yourself create are on an equal footing with collections that are in the base library. And that's an idea that has slowly percolated through the PL community and to practice. But not with architectural styles. Our mainstream programming languages typically support exactly one architectural style: call/return. That's the only one that allows abstraction. If you want a different one, you can build it, but you cannot express it. And that's a huge problem, as any non-default architectural style gets a huge expressiveness penalty. Previous languages that support alternative architectural styles usually have exactly the problem you've described: they offer exactly one implementation of that architectural style baked into the language, and that's it (Go channels are an example). And if you need something even slightly different, you're back in implementing + expressing with call/return, because that's the only style that allows abstraction. Sigh. With Objective-S, the idea is that you get to implement whatever you want in terms of architectural styles (connectors, components) and then get to surface it with syntax appropriate for architectural connection. And the implementation will usually also be call/return based, because that's what we currently have. Although I am starting to see places where I can actually implement a connector in terms of other connectors directly without mediating via procedure calls. (The one-way dataflow connector |= can be built from a storage combinator and a notification mechanism, and these can be pluggable. Very neat, particularly because building dataflow constraints naturally was one of my goals and this exceeds that goal). Of course there's a bit of a chicken/egg problem, in two variations: first, I must provide some "built-in" components and connectors that go outside the default set, otherwise the whole thing is useless. And there it turned out that the initial set (polymorphic write streams, storage combinators, dataflow constraints) turned out so useful and general that they sort of become "the thing", even though they aren't. The second, related chicken/egg problem is that both conceptually and from an implementation POV, we have to start somewhere concrete, because this is an abstraction mechanism that doesn't exist yet and thus nobody really has a clue how it should work. So things aren't as abstract/general yet as they should be.

User23 4y ago

Maybe it appears so to people who have never heard of Lisp and or used it.

mpweiher 4y ago
Lisp's core is eval/apply.
- User23 4y ago
  Yes and? EVAL isn’t call/return, it’s a mathematical function from type S-expression to type S-expression modulo some details. At least it was to start, Lisp now has side effects which considerably opens up the domain of easily expressed programs. Perhaps you’re confused because you’ve never done anything nontrivial in a modern Lisp and the word function is so heavily overloaded? Here[1] is an example of the Actor model expressed in Common Lisp. It shows a paradigm that is very much not call and return expressed cleanly and directly. [1] https://github.com/naveensundarg/Common-Lisp-Actors https://github.com/naveensundarg/Common-Lisp-Actors
  - mpweiher 4y ago
    Interesting. > EVAL isn't call/return, it's a mathematical function Hmm...a "function" you say. What do you do with a function in a computer system? I mean, for it to actually do something? Look at it? Digest it? Sing it? Or maybe...call it? And when that function is done, after you called it what does it do? Dissolve? Perambulate? Or maybe: return? Of course, a function that you call and that then returns has absolutely nothing to do with the call/return architectural style. Sorry, my bad, what was I thinking? And no, your example does not invalidate what I wrote, as it doesn't implement it "cleanly and directly", at least not to my standards. Maybe to yours, but not to mine. The problem with Lisp DSLs is that the result always just look like Lisp, and Lisp is eval/apply. So (send my-actor message_args) very much looks like a Lisp function call. It seems to be the function "send" with arguments "my-actor" and "message_args". (Of course the Actor model is close enough that it might not matter). Which is exactly the problem we have in other languages. At the very least, it would have to be my-actor async messge_args For it to qualify as resembling an actual send and not just another function call. I can also write: source.connect( target ); And to you that would apparently mean that I have implemented pipes and filters "cleanly and directly" in, say, C++ and Java. And it would be just as wrong.

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.