Objective-Smalltalk: now serving its own web site | Hacker News Reader

Objective-Smalltalk: now serving its own web site

objective.st

64 pointsmpweiher26 comments

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

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

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

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

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.

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.

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?

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?

Interesting project, but I have a couple of nitpicks about the examples page (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?

> 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}". }
  }

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

On the other hand... basically every addition made to ObjC since NeXT adopted it (30 years ago!) has made it less like Smalltalk.

Which features are you thinking of? Blocks, GC, and new syntax for literals and boxing all seem very Smalltalk-y to me.

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

Such as... Java? (Hint, they tried that)

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

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

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

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

Is blazing fast for me...like instantaneous.

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.

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

I still prefer the name from the slashdot-era.

Hug of Death.

Didn't we just call it "slashdotting"?

Reply on news.ycombinator.com