Earlier quoted context omitted.
Yep. Still working on it. Suggestions?
Objective-See? The tagline could be "Objective-See is like Objective-C without the C"
Already taken: https://objective-see.org
Objective-S: architecture-oriented language based on Smalltalk and Objective-C
81–90 of 130 posts
Re: Objective-S: architecture-oriented language based on Smalltalk and Objective-C
#82Re: Objective-S: architecture-oriented language based on Smalltalk and Objective-C
#83Oh. Sorry, the website is currently not in a very good state. Feel free to ask any questions here. Note: very pleased that the box serving the site is pretty consistently at less than 1% CPU during the HN hug of death.
It looks to me like the situation we have today is that architectural components are deployed as separate binaries ( queues, proxies, web server etc), with PL being used mostly as glue code passing data between them using client apis.
Provided i correctly understood Objective-S endgoal, what makes you think integrating them into a language runtime will lead to better results ?
Re: Objective-S: architecture-oriented language based on Smalltalk and Objective-C
#84Earlier quoted context omitted.
If you think that function name length doesn't matter you haven't written enough ObjC yet. It matters. Source code shouldn't read like Tolstoy. ObjC itself is not responsible, it's NeXT and Apple's fault for perpetuating that abominable naming convention for much too long. As for localisation, only a tiny fraction of strings in a software program are user visible. I don't think we should be designing language syntax…
I'm sure I've written more than most other people currently alive. ObjC is one of the most readable languages around. That's mostly because of the param:value syntax, which is much better than C-like syntax because you can see the parameter names. But the long method names aren't a problem once you have autocompletion. They also make it clearer what the best name for a method is - if you call something fmt() you star…
>if you call something fmt() you start needing to make up equally clever short names for everything else, and it becomes less principled.
Not necessary. There's a very sensible "huffmanization" principle created within Perl/Raku community which says that the need for a name/token to be overly descriptive is inversely proportional to frequency of its usage. So you can have short names and they still be human-parseable just because they are used often, and your brain used to register it. FWIW they will be easier human-parseable, because longer words take longer to read. With this approach one can has both fmt, and formatSomethingSomewhereSomeday
Re: Objective-S: architecture-oriented language based on Smalltalk and Objective-C
#85I still remember my horror when I saw the pain of something as simple as string concatenation in Objective-C. The community literally has to write special micros to make joining a string palatable [1]. I salute the brave souls who made OSX/iOS apps before Swift. NSString *myString = @"Hello"; NSString *second = [myString stringByAppendingString:@" World"]; [1]: https://stackoverflow.com/questions/510269/shortcuts-in-…
It’s been almost a decade since I did any ObjC, but I’m fairly certain that you want to use NSMutableString here :p
And, don’t forget to release your alloc’d objects (or use an auto release memory pool). There was no automatic memory management then!
Re: Objective-S: architecture-oriented language based on Smalltalk and Objective-C
#86I still remember my horror when I saw the pain of something as simple as string concatenation in Objective-C. The community literally has to write special micros to make joining a string palatable [1]. I salute the brave souls who made OSX/iOS apps before Swift. NSString *myString = @"Hello"; NSString *second = [myString stringByAppendingString:@" World"]; [1]: https://stackoverflow.com/questions/510269/shortcuts-in-…
Actually, I'm glad its a method with a long-ish name. Operator-overloaded string concatenation makes something that can ruin your performance look innocent. Also, I've never heard of any serious iOS/macOS dev complaining about this.
I can’t speak for other ObjC devs back when the iPhone SDK was released; but I remember just being so grateful that I had any tooling to develop for iOS that I was more than happy to overlook any ObjC weirdness/clunkiness.
ObjC is very simple (often confused with archaic), but also wildly complex. Once you wrap your head around the ObjC way of doing things, everything makes sense, is very consistent, and you could develop very effectively.
Re: Objective-S: architecture-oriented language based on Smalltalk and Objective-C
#87Oh. Sorry, the website is currently not in a very good state. Feel free to ask any questions here. Note: very pleased that the box serving the site is pretty consistently at less than 1% CPU during the HN hug of death.
> Note: very pleased that the box serving the site is pretty consistently at less than 1% CPU during the HN hug of death. The connection has timed out Tempt not the fates, for they are cruel -- or, alternatively, the "hug" is not one thing --- https://github.com/mpw/Objective-Smalltalk#readme is the repo linked from the Download page in Wayback, for those into such things (but based on a recent commit, it's not Open…
This project is at least 12 years old! Clearly you believe in it.
Re: Objective-S: architecture-oriented language based on Smalltalk and Objective-C
#88Earlier quoted context omitted.
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 misunders…
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), typical…
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.
Re: Objective-S: architecture-oriented language based on Smalltalk and Objective-C
#89Oh. Sorry, the website is currently not in a very good state. Feel free to ask any questions here. Note: very pleased that the box serving the site is pretty consistently at less than 1% CPU during the HN hug of death.
I agree with the Objective-S goals [1], and it is cool to see research in this direction. Are the mechanisms for defining architectural styles and some predefined styles (OO call/return, pipes & filters, REST and event broadcast) all that is new from Objective-S? Any other future goals? These seem relatively easy to implement as e.g. Lisp macros? Clojure supports many of these. Personally, I would like to see more re…
Marcel, it might help non-language design experts like me to wrap their head around Objective-S and the notion that "OO call/return, pipes & filters, REST and event broadcast" are just (higher-order?) styles that can be implemented in a truly general purpose language (i.e. Objective-S) by providing concrete examples of how Objective-S does this and other presumably-general-purpose-but-not-actually-according-to-you do not?
Is functional programming yet another style, or is it a subset of call/return, or a subset of pipes & filters? If it is its own style, how might Objective-S implement this style? What would map-reduce look like? What about higher order functions and currying?
Or is Objective-S itself at root a functional language? You've said very categorically in another comment that Objective-S is NOT just reinventing Lisp. Can you explain?
Perhaps my questions don't make any sense. As I said, I'm no meta-language expert.
Re: Objective-S: architecture-oriented language based on Smalltalk and Objective-C
#90Earlier 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.
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/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.