
Objective-Smalltalk: now serving its own web site - mpweiher
http://www.objective.st/
======
nielsbot
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/](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? :-)

------
pavlov
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.

------
saagarjha
Interesting project, but I have a couple of nitpicks about the examples page
([http://www.objective.st/Examples/](http://www.objective.st/Examples/)):

> A method that deletes a file and fades out the icon representing that file:
    
    
      -<void>deleteFile:filename {
         thumbs := self thumbsView subviews.
         viewsToRemove := thumbs selectWhereValueForKey:'filename' isEqual:filename.
         aView := viewsToRemove firstObject.
      
         UIView animateWithDuration:0.4
                animations: { aView setAlpha: 0.0. }
                completion: { aView removeFromSuperview. 
                              UIView animateWithDuration: 0.2
                                     animations: { self thumbsView layoutSubviews. }
                                     completion: { 3 }. 
                            }.
         url := self urlForFile:aFilename.
         NSFileManager defaultManager removeItemAtURL:url  error:nil.
         self thumbsView afterDelay:0.4 | setNeedsLayout.
      }
    

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

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

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?

~~~
mpweiher
> 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](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](http://www.metaobject.com/papers/HOM-Presentation.pdf) (via
[https://en.wikipedia.org/wiki/Higher_order_message](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](https://github.com/mpw/objective-smalltalk-container) It is part of
MPWFoundation:
[https://github.com/mpw/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...](https://github.com/mpw/MPWFoundation/blob/master/Documentation/Streams.md)).
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...](https://github.com/mpw/Objective-
Smalltalk/blob/master/scripts/sqlitescheme.stsh).

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

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

~~~
mpweiher
Cappuccino, Cocoa in the browser with a Keynote clone written in it.

 _Way_ ahead of its time when the idea of writing full-fledged desktop apps in
the browser still seemed ludicrous.

In a complete shock to me, the project is active and recently hit 1.0!

[http://www.cappuccino-
project.org/blog/2018/04/cappuccino-1-...](http://www.cappuccino-
project.org/blog/2018/04/cappuccino-1-0-is-announced.html)

So that's also one of the directions for Objective-Smalltalk: use Cappuccino
on the web.

~~~
danpalmer
> 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.

~~~
chenglou
Apple uses and maintains [https://sproutcore.com](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...](https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-
model.html)

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.

------
Apocryphon
One wonders what direction iOS development and Cocoa would have gone to if
Apple had replaced Swift with something less dissimilar to Objective-C.

~~~
protomyth
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.

1)
[https://en.wikipedia.org/wiki/F-Script_(programming_language...](https://en.wikipedia.org/wiki/F-Script_\(programming_language\))

~~~
mpweiher
> 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.

------
eggy
Sorry if I don’t know Obj-C well enough, but can you save state like you can
with a Smalltalk VM, since this does not have or need a VM?

~~~
armadsen
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.

~~~
eggy
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?

------
mpweiher
Let's see if it can survive the HN "new" page. :)

~~~
4thaccount
Is blazing fast for me...like instantaneous.

~~~
mpweiher
Thanks, good to hear it's working as intended.

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.

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

