4 ms·

I don't agree with the assertion that "[Rust, C, etc.] are not general purpose languages but instead DSLs for algorithms". This is one of those "profound" state

by junon 4y ago

I don't agree with the assertion that "[Rust, C, etc.] are not general purpose languages but instead DSLs for algorithms". This is one of those "profound" statements that I simply find nonsensical, as if the semantics themselves somehow made a point. Conversely, I see Objective-S as just a batteries-included, insanely high level declarative language. How is that any less of a DSL, per the creator's logic? Plus, saying that your language is the "first [real] general purpose language" is a bit smug.

ducktective 4y ago
>is a bit smug. I choose unorthodox and provocative ideas over conservative bore of docile academic terms any day. You call it being smug, I call it scientific confidence needed for progress.
- mattgreenrocks 4y ago
  Perhaps the biggest problem with Objective-S is that it isn’t tied to a FAANG?
  - theamk 4y ago
    nah, there are tons of non-FAANG languages which don't try to redefine common terms and clearly explain their advantages. They get much better reception. (D and Nim immediately come to mind)
- junon 4y ago
  > unorthodox and provocative ideas Marketing drivel. You choose marketing drivel over science. That's how I read that sentence.
  - mpweiher 4y ago
    It ain't "marketing drivel". If it were, it would be an utter failure. It is a profound insight. It might be a wrong profound insight, but "drivel" it ain't.
    - Goawaydunny 4y ago
westoncb 4y ago
I agree it's a bit smug, but I can see an argument why something like that (not familiar with Objective-S itself in anyway) might be considered more general purpose—though it's a bit of a stretch still imo: To start, I think DSLs for algorithms is a bit off; it's more like DSLs for manual memory management. But I think the significant thing is that those languages are closer to a natural way of speaking about the "execution environment" of a computer vs that of human thought, which is essentially the gap or spectrum which programming languages attempt to span. And it makes a certain kind of sense to talk about generality of languages in terms of the set of human thoughts which they are effectively applicable to realizing. But this is very much against intuition when speaking of the generality of abstract structures since there are common, specific meanings in connection within them, and in computing that's typically what's meant. But, if you do look at it in the other sense, something higher level is going to have higher generality than something lower level. Just playing devil's advocate 'cause I was curious where they might be coming from with it (because it sounds like such nonsense at first).
xmonkee 4y ago
Also, even if you were to buy it's premise, the statement is still untrue. There is also stuff like Red and Wolfram language.
- Izkata 4y ago
  Yeah, Red's precursor, Rebol, is what I thought of. It doesn't have S3 support, but the rest of this example (using print or http post or something) would be about as small and simple. I suppose it would be using Rebol widgets though instead of native widgets, but that also means it'll work cross-platform with no changes.
mpweiher 4y ago
> I don't agree with the assertion that "[Rust, C, etc.] are not general purpose languages but instead DSLs for algorithms". The reasoning is given. How is the reasoning incorrect, other than colliding with beliefs and assumptions we make that are so implicit we don't even see them? But very briefly: ALGOL. > How is that any less of a DSL, per the creator's logic? Very simple, from a software-architectural POV: it includes call/return as one of the architectural styles it supports. But it also supports other architectural styles, ideally including building your own, though that is still a bit thin. So n = 1, vs n > 1. See also: https://blog.metaobject.com/2019/02/why-architecture-oriented-programming.html https://blog.metaobject.com/2019/02/why-architecture-oriente...
- wk_end 4y ago
  The reasoning is given, but - ironically - no “connection” is given between the idea that “other languages don’t have enough mechanisms for connection” and “other languages aren’t general purpose programming languages” or “other languages are DSLs for writing algorithms”. That connection isn’t really obvious. For one thing, lots of things I do on a day-to-day basis in languages that aren’t Objective-S don’t “feel” particularly “algorithmic” - for instance, when I’m modeling data in a class hierarchy or as a composition of types, using mechanisms built into the languages of choice, am I just “writing algorithms”? What about when I’m plumbing stuff between APIs and databases? Writing - or using - Lisp macros? Etc. It’s an issue of terminology, I’d say - you’re using very sweeping, imprecise language to describe your critique. “This particular mechanism is a useful feature other languages lack” would be received much better than “other languages are fundamentally only suited to writing algorithms, rather than general-purpose software” when we’ve got 60+ years of every kind of software imaginable written in them. Arguing about the criteria for what “general purpose” means, this far down the line, is vastly less interesting than actual features, and I’ve read two blog posts and I still don’t really see, specifically, what Objective-S has that’s so paradigm shifting. Reprogrammable literals, so I can embed URLs in my code without delimiters or anything? Syntax for “connecting” things?
  - mpweiher 4y ago
    > That connection isn’t really obvious. In what way is it not obvious? Here is something we need to express a lot, and our "general purpose languages" can't express it. I am not sure how it can get any more obvious than that. The use of the word "express" is important here. Of course we can implement everything and anything once our language is Turing complete. But if that's the criterion, why do we have high level languages? After all, we surely can implement everything by punching machine code into our hex editors. Or maybe get super-fancy and add an assembler. But we cannot express non-procedural concepts and systems, and we cannot abstract our way out of this problem the way we otherwise often can because it is the abstraction mechanism itself that is procedural. > What about when I’m plumbing stuff between APIs and databases? Exactly! That was precisely the use case where this became obvious to me, because in Wunderlist, for example, our iOS/macOS GUI clients were on the order of 140KLOC, and a large percentage was just plumbing, shuffling data between APIs, the persistence and the GUI. So what do you actually do when you create this plumbing? You write procedures, functions or methods to accomplish the plumbing. To either or both (a) set up the plumbing and (b) mediate the plumbing. So you can implement the plumbing by writing all these procedures, but you can't actually express the idea of plumbing, because it isn't itself procedural. As Andrew Black puts it: "The program's text is a meta-description of the program behavior, and it is not always easy to infer the behavior from the meta-description." (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.482.1265&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.48...) And the fact that (a) you can always kinda sorta get away with implementing what you need using procedures and (b) we have gotten so incredibly used to this that we don't see the indirection as a problem is exactly why I call this "The Gentle Tyranny of Call/Return". And the mismatch and indirection have a very real and significant cost. For example, WL had a significant chunk of code that translated the REST API of the backend into a "nice" set of methods. With callbacks. Which had to duplicated every time we introduced an abstraction. Huge mess, huge amount of code, and I've seen the same in every comparable system I've encountered since. With in-process REST, all that code goes out the window. It's not needed. Now you can make implement in-process REST using current languages, and we did. But it goes against the grain of what the language wants you to do. > you’re using very sweeping, imprecise language to describe your critique. Nah, the language is actually very precise, if apparently unfamiliar. That is something I obviously have to deal with, so thanks for the heads-up on that. From a software-architectural POV it is blindingly obvious. For example here is a taxonomy of software architectural connectors: https://www.researchgate.net/publication/3864292_Towards_a_taxonomy_of_software_connectors https://www.researchgate.net/publication/3864292_Towards_a_t... Call/return is in a tiny little corner. That is what our "general purpose" languages provide linguistic support for. Everything else we can build, but not express.
dan-robertson 4y ago
I don’t really consider rust/c to be general purpose fwiw. The term I’d use is ‘systems language’, though that’s also a bit I’ll-defined. Specifically, I think rust/c do a pretty poor job of the kind of programming people often do in languages like python where e.g. worrying a lot about memory allocations or data structures or whatever is not a great use of the programmer’s time. One can also see e.g. the ongoing efforts to figure out the nice way to do user interfaces in rust: it seems that the language isn’t yet particularly suitable for that. I think Java better fits the conventional notion of a general purpose language but it still feels a bit too much work to do simple things in a lot of cases.

by junon 4y ago

ducktective 4y ago

>is a bit smug. I choose unorthodox and provocative ideas over conservative bore of docile academic terms any day. You call it being smug, I call it scientific confidence needed for progress.

mattgreenrocks 4y ago
Perhaps the biggest problem with Objective-S is that it isn’t tied to a FAANG?
- theamk 4y ago
  nah, there are tons of non-FAANG languages which don't try to redefine common terms and clearly explain their advantages. They get much better reception. (D and Nim immediately come to mind)
junon 4y ago
> unorthodox and provocative ideas Marketing drivel. You choose marketing drivel over science. That's how I read that sentence.
- mpweiher 4y ago
  It ain't "marketing drivel". If it were, it would be an utter failure. It is a profound insight. It might be a wrong profound insight, but "drivel" it ain't.
  - Goawaydunny 4y ago

westoncb 4y ago

I agree it's a bit smug, but I can see an argument why something like that (not familiar with Objective-S itself in anyway) might be considered more general purpose—though it's a bit of a stretch still imo: To start, I think DSLs for algorithms is a bit off; it's more like DSLs for manual memory management. But I think the significant thing is that those languages are closer to a natural way of speaking about the "execution environment" of a computer vs that of human thought, which is essentially the gap or spectrum which programming languages attempt to span. And it makes a certain kind of sense to talk about generality of languages in terms of the set of human thoughts which they are effectively applicable to realizing. But this is very much against intuition when speaking of the generality of abstract structures since there are common, specific meanings in connection within them, and in computing that's typically what's meant. But, if you do look at it in the other sense, something higher level is going to have higher generality than something lower level. Just playing devil's advocate 'cause I was curious where they might be coming from with it (because it sounds like such nonsense at first).

xmonkee 4y ago

Also, even if you were to buy it's premise, the statement is still untrue. There is also stuff like Red and Wolfram language.

Izkata 4y ago
Yeah, Red's precursor, Rebol, is what I thought of. It doesn't have S3 support, but the rest of this example (using print or http post or something) would be about as small and simple. I suppose it would be using Rebol widgets though instead of native widgets, but that also means it'll work cross-platform with no changes.

mpweiher 4y ago

> I don't agree with the assertion that "[Rust, C, etc.] are not general purpose languages but instead DSLs for algorithms". The reasoning is given. How is the reasoning incorrect, other than colliding with beliefs and assumptions we make that are so implicit we don't even see them? But very briefly: ALGOL. > How is that any less of a DSL, per the creator's logic? Very simple, from a software-architectural POV: it includes call/return as one of the architectural styles it supports. But it also supports other architectural styles, ideally including building your own, though that is still a bit thin. So n = 1, vs n > 1. See also: https://blog.metaobject.com/2019/02/why-architecture-oriented-programming.html https://blog.metaobject.com/2019/02/why-architecture-oriente...

wk_end 4y ago
The reasoning is given, but - ironically - no “connection” is given between the idea that “other languages don’t have enough mechanisms for connection” and “other languages aren’t general purpose programming languages” or “other languages are DSLs for writing algorithms”. That connection isn’t really obvious. For one thing, lots of things I do on a day-to-day basis in languages that aren’t Objective-S don’t “feel” particularly “algorithmic” - for instance, when I’m modeling data in a class hierarchy or as a composition of types, using mechanisms built into the languages of choice, am I just “writing algorithms”? What about when I’m plumbing stuff between APIs and databases? Writing - or using - Lisp macros? Etc. It’s an issue of terminology, I’d say - you’re using very sweeping, imprecise language to describe your critique. “This particular mechanism is a useful feature other languages lack” would be received much better than “other languages are fundamentally only suited to writing algorithms, rather than general-purpose software” when we’ve got 60+ years of every kind of software imaginable written in them. Arguing about the criteria for what “general purpose” means, this far down the line, is vastly less interesting than actual features, and I’ve read two blog posts and I still don’t really see, specifically, what Objective-S has that’s so paradigm shifting. Reprogrammable literals, so I can embed URLs in my code without delimiters or anything? Syntax for “connecting” things?
- mpweiher 4y ago
  > That connection isn’t really obvious. In what way is it not obvious? Here is something we need to express a lot, and our "general purpose languages" can't express it. I am not sure how it can get any more obvious than that. The use of the word "express" is important here. Of course we can implement everything and anything once our language is Turing complete. But if that's the criterion, why do we have high level languages? After all, we surely can implement everything by punching machine code into our hex editors. Or maybe get super-fancy and add an assembler. But we cannot express non-procedural concepts and systems, and we cannot abstract our way out of this problem the way we otherwise often can because it is the abstraction mechanism itself that is procedural. > What about when I’m plumbing stuff between APIs and databases? Exactly! That was precisely the use case where this became obvious to me, because in Wunderlist, for example, our iOS/macOS GUI clients were on the order of 140KLOC, and a large percentage was just plumbing, shuffling data between APIs, the persistence and the GUI. So what do you actually do when you create this plumbing? You write procedures, functions or methods to accomplish the plumbing. To either or both (a) set up the plumbing and (b) mediate the plumbing. So you can implement the plumbing by writing all these procedures, but you can't actually express the idea of plumbing, because it isn't itself procedural. As Andrew Black puts it: "The program's text is a meta-description of the program behavior, and it is not always easy to infer the behavior from the meta-description." (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.482.1265&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.48...) And the fact that (a) you can always kinda sorta get away with implementing what you need using procedures and (b) we have gotten so incredibly used to this that we don't see the indirection as a problem is exactly why I call this "The Gentle Tyranny of Call/Return". And the mismatch and indirection have a very real and significant cost. For example, WL had a significant chunk of code that translated the REST API of the backend into a "nice" set of methods. With callbacks. Which had to duplicated every time we introduced an abstraction. Huge mess, huge amount of code, and I've seen the same in every comparable system I've encountered since. With in-process REST, all that code goes out the window. It's not needed. Now you can make implement in-process REST using current languages, and we did. But it goes against the grain of what the language wants you to do. > you’re using very sweeping, imprecise language to describe your critique. Nah, the language is actually very precise, if apparently unfamiliar. That is something I obviously have to deal with, so thanks for the heads-up on that. From a software-architectural POV it is blindingly obvious. For example here is a taxonomy of software architectural connectors: https://www.researchgate.net/publication/3864292_Towards_a_taxonomy_of_software_connectors https://www.researchgate.net/publication/3864292_Towards_a_t... Call/return is in a tiny little corner. That is what our "general purpose" languages provide linguistic support for. Everything else we can build, but not express.

dan-robertson 4y ago

I don’t really consider rust/c to be general purpose fwiw. The term I’d use is ‘systems language’, though that’s also a bit I’ll-defined. Specifically, I think rust/c do a pretty poor job of the kind of programming people often do in languages like python where e.g. worrying a lot about memory allocations or data structures or whatever is not a great use of the programmer’s time. One can also see e.g. the ongoing efforts to figure out the nice way to do user interfaces in rust: it seems that the language isn’t yet particularly suitable for that. I think Java better fits the conventional notion of a general purpose language but it still feels a bit too much work to do simple things in a lot of cases.