Lol I'm so used to bloated web pages these days. I wish more sites were like yours.

Didn't we just call it "slashdotting"?

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.

Static types, protocols, dot syntax, properties… I'll give you blocks, although that was strictly a C feature.

Java is pretty far away from Objective-C and it showed with how badly Cocoa translated to Java's static nature.

a more polished F-Script[1]

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.

nitpicks

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

http://www.metaobject.com/papers/HOM-Presentation.pdf (via https://en.wikipedia.org/wiki/Higher_order_message)

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:

    [[self.view.subviews do] setNeedsDisplay]
    [self.view.subviews makeObjectsPerformSelector:@selector(setNeedsDisplay)]

You can see more HOM examples in the README for the Docker container script: https://github.com/mpw/objective-smalltalk-container It is part of MPWFoundation: https://github.com/mpw/MPWFoundation (which also has the ifResponds examples)

   1 to: 100 | reduce + 0

(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:

   #!/usr/local/bin/stsh
   (stdin -> { $0 stringValue uppercaseString. } -> rawstdout ) run

(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:

    (receiver firstmsg
        secondmsg:arg1)
        thirdmsg:arg2.
        fourthmessage.

That also doesn't work quite right because unary messages bind stronger, so this is actually ... thirdmsg:(arg2 fourthmessage). Yikes.

      receiver firstmsg |
         secondmsg:arg1 |
         thirdmsg: arg2 |
         fourhtmsg.

The fact that you don't have to go back and add parentheses at the front if you add messages at the end is particular helpful in REPLs like stsh.

can I publish an app with Objective-Smalltalk in it to the App Store?

Yes. BookLightning is in Mac AppStore and written in part in Objective-Smalltalk. Objective-Smalltalk doesn't violate any AppStore rules.

And the syntax page doesn't talk about property paths at all, which generalise properties and allow you to easily create scheme-handlers for Polymorphic Identifiers. See https://github.com/mpw/Objective-Smalltalk/blob/master/scrip....

    /:table { 
     |= { self dictionariesForQuery: "select * from {table}". }
  }

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?

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!).

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.

Not too coincidentally, the author of Objective-Smalltalk, who said above that he wants to leverage Cappuccino, has also written up his criticism of React here: https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

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.

Not sure what's up with it now, but Etoile seemed to have a very interesting implementation of an Obj-C runtime: http://etoileos.com/etoile/features/runtime/

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? :-)