3 ms·

Right. A different _tool_ because they described paradigms aren’t language paradigms- they’re patterns or frameworks expressed more easily but also more commonl

by 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.
- c-cube 4y ago
  Alright then, what if the architectural style one wants is type-level metaprogramming? Or even just having a rich type system with inference, like Haskell? Can objective-S do that? What about monads, typeclasses, etc. which are arguably pretty extensible and DSL-y too (see Xmonad for example)? If not, maybe this whole definition of "general purpose" is just meaningless.
  - mpweiher 4y ago
    > what if the architectural style one wants is type-level metaprogramming? That's not an architectural style. ¯\_(ツ)_/¯

by haimez 4y ago

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.

c-cube 4y ago
Alright then, what if the architectural style one wants is type-level metaprogramming? Or even just having a rich type system with inference, like Haskell? Can objective-S do that? What about monads, typeclasses, etc. which are arguably pretty extensible and DSL-y too (see Xmonad for example)? If not, maybe this whole definition of "general purpose" is just meaningless.
- mpweiher 4y ago
  > what if the architectural style one wants is type-level metaprogramming? That's not an architectural style. ¯\_(ツ)_/¯