101–110 of 130 posts
Earlier quoted context omitted.
Yep. Still working on it. Suggestions?
General Purpose Language, since it is the world’s first general purpose language.
Arches? Arch? (There was ArchJava, so there's a precedent).
ArchTalk?
That is because we still don't have the equivalent of the Arch. That allows Notre Dame to have 3 times the volume of the keeps pyramid with a third of the mass."
Since it seems you are building such an arch I thing a good name could be:
NotreDameLang. ArchLang.
Earlier quoted context omitted.
`guard` has its time and place, which is to refactor pyramids of doom away. The number of nested `if let` statements I've seen, and written, is upsetting.
Perl's "unless" syntax, or allowing "if"s at the end of a statement, also solve this and are more flexible.
The developer not being made to do so, and just embedding conditions within conditions, is how the pyramids of doom are constructed to begin with.
Earlier quoted context omitted.
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…
> 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/eDS…
> 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 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.
Earlier quoted context omitted.
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-p... (That paper is also linked from the publications page: http://objective.st/Publications/ ) Short summ…
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…
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
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.
Earlier quoted context omitted.
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.
Maybe it appears so to people who have never heard of Lisp and or used it.
Earlier quoted context omitted.
General Purpose Language, since it is the world’s first general purpose language.
I was also thinking of Architectural Programming Language, but APL.. Arches? Arch? (There was ArchJava, so there's a precedent). ArchTalk?
Earlier quoted context omitted.
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…
> 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 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 ou…
This might be because you observably don’t know what an algorithm is. It has nothing at all intrinsically to do with call and return.
I’m afraid any further discussion will be fruitless, but on the off chance you tire of getting predictable responses to ridiculous assertions that promote what you believe to be a deep insight, then please refer back and search for the insight required to understand what you’re being told here.
Earlier quoted context omitted.
> 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 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 ou…
It doesn’t appear that you understood anything I said. This might be because you observably don’t know what an algorithm is. It has nothing at all intrinsically to do with call and return. I’m afraid any further discussion will be fruitless, but on the off chance you tire of getting predictable responses to ridiculous assertions that promote what you believe to be a deep insight, then please refer back and search for…
ALGOL. The ALGOrithmic Language.
https://en.wikipedia.org/wiki/ALGOL
Which is the ancestor of C (via never-completed CPL, subset to BCPL, B, then C).
Which part of this are you disputing?
1. That the inventors of ALGOL knew their language well enough to choose a correct name (or knew what an algorithm is)
or
2. That C is a descendant of ALGOL?
You might also want to check out "The use of sub-routines in programmes", 1952
https://dl.acm.org/doi/10.1145/609784.609816
"Sub-routines seem to have two distinct uses in programmes. The first and most obvious use is for the evaluation of functions, a simple example being the evaluation of sine x given x. The second use is for the organization of processes..."
Earlier quoted context omitted.
It doesn’t appear that you understood anything I said. This might be because you observably don’t know what an algorithm is. It has nothing at all intrinsically to do with call and return. I’m afraid any further discussion will be fruitless, but on the off chance you tire of getting predictable responses to ridiculous assertions that promote what you believe to be a deep insight, then please refer back and search for…
Let's try that again. ALGOL. The ALGOrithmic Language. https://en.wikipedia.org/wiki/ALGOL Which is the ancestor of C (via never-completed CPL, subset to BCPL, B, then C). Which part of this are you disputing? 1. That the inventors of ALGOL knew their language well enough to choose a correct name (or knew what an algorithm is) or 2. That C is a descendant of ALGOL? You might also want to check out "The use of sub-rou…
Stop chasing tangents and address your core misunderstanding. Algorithms are not call and return.
[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...