8 ms·

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 arch

• 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.
• naasking 4y ago
  > What makes Objective-S more general than other languages? They describe that on the site. The notion is that most of our modern languages are more geared towards expressing algorithms and data structures, and not so great for expressing programs better suited to different architectural styles that don't necessarily follow a strict call/return type of semantics. That's not entirely wrong. You can build a library/eDSL in a call/return language that will implement other architectures, but it will still look and behave like a call/return abstraction. Ostensibly Objective-S's goal is to make programs written in other architectural styles look like they are expressed natively in those styles, rather than an embedding of that style in a call/return architecture. I'd like to see Objective-S implement Prolog or other logic programming to put that claim to the test. The other architectures they list aren't too far from call/return style, but logic programming certainly is.
  • mpweiher 4y ago
    Thank you for getting it and expressing it so clearly. > You can build a library/eDSL in a call/return language that will implement other architectures, but it will still look and behave like a call/return abstraction EXACTLY! We can build, but we cannot express. So it will look like a weird/complicated call/return abstraction, because it isn't "native". So you get a tradeoff between architecture and simplicity, a tradeoff that shouldn't be there. (And all sorts of other 2nd order effects). > Ostensibly Objective-S's goal is to make programs written in other architectural styles look like they are expressed natively in those styles, rather than an embedding of that style in a call/return architecture. EXACTLY! We need to be able to express those alternative styles natively and naturally, otherwise we are always going to be stuck in the tradeoff between architecture and simplicity, or as I call it The Gentle Tyranny of Call/Return. > I'd like to see Objective-S implement Prolog That's actually on the list, as a stretch goal. One of my (many) inspirations was this great 1988 article about adding support for backtracking to Smalltalk, without modifying the kernel: https://dl.acm.org/doi/10.1145/62083.62094 https://dl.acm.org/doi/10.1145/62083.62094 A tour-de-force. And yet...not really something you'd ever use. The other problem is that Prolog, in my understanding, is actually too "algorithmic" or "procedural" to expend too much effort on, at least when you consider its interface After all, the basic interaction with Prolog is to ask it a question and then it rummages around in its database of rules and facts and spits out an answer. I am personally more interested in constraints, particularly (one way) dataflow constraints. Those I am now able to get out of the other architectural components, and without significant algorithmic intermediation.