This blog reminds me of something John Carmack calls architecture astronauts. It talks about "glue" / connectors integrated with a programming language, which at a high level, sounds really nice. But I am skeptical of how well one could implement it in practice. Interoperating is far from standardized and I definitely want concrete examples illustrating what "Architecture Oriented" is in code and not theory. I hope there is a part two for this.
> Objective-S is the first general purpose programming language.
You should consider removing this claim, since it is a flat-out lie, or at least a willful disregard for the language that other people use. If you want to communicate what is novel about this programming language, you need to remove this. It heavily detracts from the architectural mechanisms that you start to explain on the "About" page (http://objective.st/About) which seems to be the actual meat, where you could flesh out further explanation.
It's not a lie, though it obviously is controversial.
The languages we call "general purpose" are nothing of the sort. They are Domain Specific Languages for the domain of algorithms.
We press them into service for all sorts of things they aren't actually very good at, hence the problems. We do so because we don't have any alternatives.
Took me a long time to figure this out. And an much longer time to communicate it concisely. So yes, I can deal with it not being immediately obvious.
Just my opinion: this sentence really does you no favors. I read it, then re-read it because I wasn't sure whether I missed a word, and then I closed the tab, because writing something like this seems incredibly dishonest.
I always thought CS theory misses out on the more interesting area of computation. As if algorithms are just one "dumb" way to map the giant reality of creative potential into itself. Practically speaking it often fails to do that, despite our theoretical understanding...
Even though your language may be "turing complete" like other "general purpose" languages in theory, if it elicits more interesting algorithms and creative expression, I do kinda get your point.
True. That doesn’t answer my question though. Can you give an example of a practical problem you can solve in Objective-S that you can’t solve in (say) C++?
1. Anything that can be solved in any one Turing-complete language can be solved in any other Turing-complete language.
2. Both of these are Turing-complete languages, so obviously anything that can be solved in one can be solved in the other.
3. Lots of domain-specific languages are also Turing-complete, so anything that can be solved in C++ or Objective-S can be solved in them and vice versa.
4. It thus follows that (a) "can be solved" vs. "cannot be solved" is not a useful criterion for distinguishing between Turing-complete languages. Or that (b) there are no relevant differences between Turing-complete languages.
