I would have hoped to see something with a more dynamic runtime than we ended up with with Swift. That said, while it feels like a big win to dynamically recompile, say, calls to retain/release into simple atomic increments/decrements, or dynamic calls into direct calls, in practice the wins never seem to appear. Is it just because no-one tried hard enough? :-)
Superficially glancing through the site, this sounds like my dream language: modern Smalltalk syntax with the immensely useful interop capabilities of Obj-C. Can’t wait to use this for something.
Reminds me a bit of Objective-J. What ever happened to that (it had a pretty nifty extjs-ish/Cocoa-like framework whose name my brain can't access right now)?
There were some attempts at that kind of development experience, most famously ExtJS. So you could just use JavaScript once the authors took care of the HTML/CSS in their component library. And one step farther some attempts at using another language to generate that JavaScript, eg Vaadin or Google Web Toolkit.
Right now we're seeming to approach that again, only not exactly in a better way (you don't have to type HTML/CSS, but still know it all!).
> In a complete shock to me, the project is active and recently hit 1.0!
I'm quite surprised too. My guess is that a large company, most likely Apple, have a bunch of internal applications built on it so keep the project active enough with contributions or donations.
Apple uses and maintains https://sproutcore.com, not Cappuccino. The latter was made by ex-applers a long time ago. Though Apple also isn't monolithic and has many teams independently evaluating Angular, React and others.
Related: I've talked to a Cappuccino founder recently too, and my casual observation (which he agreed with) was that had they done Cappuccino all over again, they should have probably dropped Objective-J. Imo it's just a bit too much of a language bikeshedding and I don't think it would have changed framework _that_ much (proof: Swift works well with UIKit and AppKit). Though my opinion was just based on practicality of adoption; if Objective-smalltalk wants to take its time exploring around more than anything else, then I'd say it + cappuccino seems like a nice fit.
I'm really looking forward to Cappuccino staying alive for another ten years (and I wish all the luck to Objective-smalltalk's author) =). Though the recent Cappuccino conf doesn't feature many younger programmers.
No, that's not a feature built in to the Objective-C runtime (which as you say is not a VM). There is of course support for serializing/deserializing objects in Objective-C Foundation in the form of NSCoding. Disclaimer: I don't know anything about Objective-Smalltalk. I'm speaking only about the (Apple) ObjC runtime itself.
Thanks for explaining this. I have been using Pharo, and it is really easy to pick up where I left off with something when starting up the saved image. I dabbled with Objective-C back in the day (I bought an Amiga instead of a NeXT machine!), but left the C world for other languages (J, python, etc.). Is Objective-C going to be buried in the OS by users adopting Swift?
> Blocks become significantly more readable with Smalltalk syntax.
I'm not really seeing this–the only thing you're missing is the caret and a parameter list, which is strange because it now seems like you can't name your parameters anymore? Are you forced to use the names that the headers suggest? What if there are none in the prototype? (Also, I'm assuming '|' is a separator to make up for the lack of brackets?)
> As shown in some of the previous examples, Higher Order Messaging (HOM) is fully supported and helps make code more compact and readable. Take as an example the following code:
self view subviews do setNeedsDisplay.
> This code iterates the subviews of the view controllers view and sends each one the setNeedsDisplay message. In Objective-C the code would probably look as follows:
for ( NSView *aView in [[self view] subviews] ) {
[aView setNeedsDisplay];
}
> While the code is not that much longer, it obscures the central point of the code, the setNeedsDisplay message, with the machinery for iterating the subviews.
Objective-C has -[NSArray makeObjectsPerformSelector:]:
Finally, can I actually use this to write an app? From your code examples, it looks like you can interact with UIKit, but can I publish an app with Obejctive-Smalltalk in it to the App Store?
Yeah, the examples page isn't very good right now. Also out of date. I actually didn't expect this to go to the front page quite yet. Ooops.
> [blocks]
There is http://fuckingblocksyntax.com ¯\_(ツ)_/¯ But yes, the block examples certainly aren't very revealing. One reason is that I wanted to take examples from actual Objective-Smalltalk "production" code, not just make up good-looking examples, and so the choices were more limited (not that much production code yet...).
One reason is that all these blocks are parameterless blocks, which is also why you don't see parameter lists.
> makeObjectsPerformSelector:
Yes, that was an inspiration for enum-filters, which then turned into HOM. See
However, this also obscures the central point of the code, forcing you to put it in an argument of the -makeObjectsPerformSelector: message (the MacHack presentation talks about this a bit). Note also that it says "HOM is fully supported". HOM is actually implemented in/for Objective-C, so you can also use it there:
> (Also, I'm assuming '|' is a separator to make up for the lack of brackets?)
No, you can always parenthesise expressions:
(1 to:100 ) reduce + 0
The | is actually a bit deeper, Objective-Smalltalk integrates support for pipes and filters, via Object Streams/Object Filters (https://github.com/mpw/MPWFoundation/blob/master/Documentati...). This also means that "nested" expressions are treated as chained "expression filters", with the result of the previous expression being "piped" into the next expression as the receiver.
This isn't fully integrated yet, but here's an example of a filter as a script:
(Yeah, it uses '->' instead of '|', as I wrote, it isn't fully integrated yet).
The | also solves an oddity/asymmetry in the Smalltalk syntax, which is that the cascade "operator" (;) doesn't have an equivalent for message chains.
receiver firstmsg;
secondmsg:arg1;
thirdmsg:arg2;
All these messages go to the receiver. Let's try the same thing with chaining, meaning each subsequent message goes to the result of the previous message:
receiver firstmsg
secondmsg:arg1
thirdmsg:arg2.
The first message works as expected. However, due to the keyword message syntax, the rest gets interpreted as the single message -secondmsg:arg1 thirgmsg:arg2. Not what we wanted. So you have to use parentheses to disambiguate:
(receiver firstmsg
secondmsg:arg1)
thirdmsg:arg2.
You didn't need them for the unary message -firstmsg and also not for the final one because it's not chained. But let's add another:
I would imagine a more polished F-Script[1] or a Ruby with selector syntax. Swift still feels to me like a language designed by people who hate Objective-C.
F-Script was one of the many inspirations for Objective-Smalltalk, it is way cool!
In fact, my first plan was to just extend that, but looking at things more specifically, I noticed it didn't really match up with what I wanted, which was always to have a full-fledged programming language that's a peer.
And after a bit ObjST diverged more into an architecturally-oriented programming language.
Mind you, it has no good reason not to be blazingly fast, as it is only serving static HTML+CSS (was previously fully static), but good to see that I didn't screw it up, which is also easy enough.
I would have hoped to see something with a more dynamic runtime than we ended up with with Swift. That said, while it feels like a big win to dynamically recompile, say, calls to retain/release into simple atomic increments/decrements, or dynamic calls into direct calls, in practice the wins never seem to appear. Is it just because no-one tried hard enough? :-)