Objective-Smalltalk | Hacker News Reader

Objective-Smalltalk

github.com

68 pointsjcla167 comments

Are there any smalltalk fans out here that can point out to the unenlightened the "interesting" aspects of Smalltalk? It seems to have quite the following.

Pros: Smalltalk is a very simple object oriented language, dynamically typed and GCed, it has closures (used everywhere!). It has NO keywords at all, and a very simple syntax. Smalltalk is very readable. It also has amazing IDEs/debuggers. It's very easy to learn. And it was born in 1972, just like me!

Cons: aging technology with very little traction, no fast VM (compared to JVM), no multithreading...

I switched to Java in 1996 because the future of Smalltalk was cloudy. I'd switch back to Smalltalk if it could run with the same performance as Java.

It's a really amazing language.

no fast VM (compared to JVM), no multithreading

Back in 1996 Smalltalk VMs were still outperforming Java VMs on real workloads, in large part due to not having multithreading. (Makes GC simpler and faster.) Also, there were multithreaded Smalltalks around.

Yes, Java had no JIT in 1996... But it had corporate traction, and good marketing ("it's an internet technology!"). Nowadays, I choose the language I want to work with, but I don't switch back to Stk because of speed.

Yes, I got to play with VisualWorks at the university that time, but then Java took over the enterprise.

Pharo and Squeak use the CogVM , its a VM that supports JIT compilation and as such is very fast. Its not as fast as Java because afterall Java is static typed. However there is a way to get even faster than JAVA code.

Pharo comes with a library named "Nativeboost". Nativeboost is essentially an inline assembler. But unlike C/C++'s inline assembler of using assembly syntax, the inline assembler of Nativeboost uses Pharo syntax as each assembly command is a Pharo object like everything inside Pharo. Also because VM will stop all execution when it executes assembly code, you can enjoy raw machine code speed. Thus you can have Pharo code that can outperform Java code. If Assembly is not your thing , Nativeboost can be used also as a FFI to call C dynamic libraries. Currently C++ is not support because of name mangling but its possible to compile a C++ library as C library to be used by Pharo. Also Nativeboost's FFI offers support for Objective C as well.

There are also two projects to run smalltalk on Java, one is called redline smalltalk, the other's name eludes me now. There is also another project to bring Smalltalk to Java including even the Smalltalk IDE called "RTalk". But that project seems to be vaporware for now.

Isn't Squeak VM very fast nowadays?

There's also redline smalltak for the jvm, but I'm not entirely sure of it's status:

http://www.redline.st

[edit: on the subject of performance, and interesting Smalltalks, I'd also recommend checking out Gemstone GLASS:

http://seaside.gemtalksystems.com/

They also made "maglev" ruby:

http://maglev.github.io/ ]

I am using Pharo myself.

http://www.pharo-project.org/home

What it offers that none other language offers AFAIK apart from lisp is foremost live coding. In case you are not aware live coding simple means to code an application while the applications runs. With other languages making mistakes is quite costly. With Pharo (and Squeak) if you make such a mistake the debugger will pop up and ask you politely :D to correct your mistake after that it wont punish you by restarting your app but rather allow you to resume where you were. Whats impressive is that this allow you to code entirely inside debugger and even introduce mistakes on purpose to see overall how your app is behaving. There are no files to compile, compilation takes place per method.

Another thing I like about Pharo is the distribution process. I have been burned by Python and really sucky distribution libraries and very buggy py2app and py2exe. If you want to distribute a pharo app, thats is very simple and require zero packaging. Pharo does not install in your OS, its a simple folder containing an executable that loads image files. Those image files is memory dumps of byte code which contain all you need to run the app. So all you have to do is zip the folder and share away. You also do not need specialized tools to run multiple versions and/or instance of Pharo. Just put Pharo in diffirent folders and voila. Also now PharoLauncher allows you with easy to download custom images and manage your existing ones with ease. PharoLauncher is again a Pharo folder containing an image containing the PharoLauncher tool and library :)

The IDE is also very , very nice. Again when I was coding in Python I was not happy with the IDE. The Pharo IDE is written in Pharo its easy to use once you figure out the main functionality and quite well documented. Most importanly the IDE is tailor made for Pharo instead of general purpose nonsense that will offer substandard support for your language of choice. I like the fact that it wont allow you that easily to make mistakes and that it comes with so many tools to make your life easier. Its the best IDE I have use so far.

Lastly I really love the community , they are very friendly with Begineers and newcomers and they really deeply care about Pharo. Its quite actively developed, bug get fixed and there is always new features coming in. There is also Amber , Pharo brother, that compiles to Javascript and can use any Javascript library.

I can go on and on and on, but thats the most important things for me. The rest you can discover by yourself, all I can tell you is that there is a lot more. Foremost coding in Pharo is a lot of fun and very productive.

> What it offers that none other language offers AFAIK apart from lisp is foremost live coding. In case you are not aware live coding simple means to code an application while the applications runs.

You can do the same in Ruby with (the very much Lisp and Smalltalk inspired) Pry, though probably not as advanced.

yes this looks definitely very close to live coding. If it can replace live objects on the fly even when already referenced by other live objects its live coding in its true form. You just gave me a big reason to add Ruby to my list of languages to learn next :)

I think IPython offers something similar for python too. Its makes me very happy to see live coding making its way through the dynamic languages as I am a huge fan of live coding :)

I don't think it can outright replace objects, but Ruby objects are extremely malleable, so you could e.g. override each and every method for a specific object to forward to a replacement. Replacing the object entirely wouldn't be impossible, but it'd likely require some more invasive changes.

yes those things Python can do too. Replace methods, recreate objects etc. And probably you can find tons of workaround for things it cant do out of the box. Its not bad, not bad at all :)

I really like Ruby :)

There is also a live coding environment for ObjST that I wasn't able to show during the FOSDEM talk. In this case, "live" means re-evaluation with every keystroke.

I'll upload a video of that later.

Which is one reason why Ruby Motion is such a nice environment for iOS development. You can query and send messages to live objects in the running system. You cannot change method definitions without recompiling, unfortunately.

What's next? "Functional lambda calculus"?

Creator here. Yes, the name is half joke, half serious. Gotta have some fun :-)

At one point I was going to call it just "Objective-", but that seemed like going a bit too far.

I would have called it Objective. That way, when the press asks, "What is your objective?" you just show them.

The readme has a typo: dervied should be derived

How about crappy PHP? :P

But you repeat yourself? :-P

I think they missed the opportunity for a pun with Self[1].

[1]: http://selflanguage.org/

"C with Pointers"

"Javascript for the Browser"

"Structured Query SQL Language"

> "Javascript for the Browser"

Unfortunately not so redundant these days.

StepTalk is another Smalltalk-ObjectiveC legacy framework, originally meant for Smalltalk-like scripting of ObjectiveC apps/tools. It was built for GNUstep but worked on early versions of Cocoa as well: https://github.com/stiivi/StepTalk. It is no longer maintained, therefore it might need a little bit of refreshment.

It is light-weight SmallTalk interpreter on top of ObjectiveC objects. See the examples for better idea of what it does: https://github.com/Stiivi/StepTalk/tree/master/Examples

Hi Stefan!

StepTalk was and is definitely a great addition, and I think the more we have of these the more likely it is that we will finally get to program in something better than we have now.

Maybe it's an idea whose time has finally come :-)

Thanks Marcel. Nice work with Objective Smalltalk too.

Irony is that at that time the Smalltalk people didn't see the advantages of frameworks like StepTalk. I got a few "Why don't you just use Smalltalk?" questions on ESUG conference in 2003 – on one hand they were not happy that Smalltalk use was a bit declining (or at least not thriving, compared to other languages/environments), but didn't wanted to see a compromise solution. Only the pure Smalltalk way was the proper way.

> Maybe it's an idea whose time has finally come :-)

... where web == one large distributed Smalltalk image? I'm all for that! ;-)

The given example for HOM is a bit unfair. From their docs:

   for ( NSView *aView in [[self view] subviews] ) {
      [aView setNeedsDisplay];
   }

They use this as an example to show that Objective-C is bad. However you can rewrite that with:

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

That being said: I think that Objective-C could move faster as a language. We have seen Apple to speed up the development of Objective-C during the last few years and I think that Apple will move even faster in the future.

Right, I used an example from real code rather than a made up example. The difference is that makeObjectsPerformSelector: doesn't handle non void returns, only handles limited argument numbers and types (and needs a separate version of the core method for each).

    #( 1 2 3 4 5 ) collect + 5

This also works with HOM, as does -ifResponds, -async etc.

I don't mind trying to come up with less boilerplate syntax, but how does the reader of the code know when something is a HOM or a normal message? The above example is valid syntax in existing Smalltalk, a Smalltalk developer would interpret it as collect returning a value that would be added to 5. I think this ambiguity is much worse than any advantage compactness might bring.

Just as an example, writing #( 1 2 3 4 5 ) + 5 would actually be even more compact and more intuitive. A Smalltalk developer would interpret this as #+ being implemented in Collection, and the expectation would be that the implementation of #+ would be something like

+ arg ^self collect: [:each | each + arg]

Objective.st has a very clean syntax. But this can also be done with Objective-C:

  [[@[@1, @2, @3] valueForKeyPath:@"@sum.self"] integerValue] + 5

This can be improved:

  @implementation NSArray (Private)
  - (NSInteger)collect {
    return [[self valueForKeyPath:@"@sum.self"] integerValue];
  }
  @end

And then you can write:

  [[@[@1, @2, @3] collect] + 5;

I know: HOM is a more abstract/generic thing. If it was built in the language you could just use it as is without reinventing the wheel all the time... I just want to point out that Objective-C can be made look nice as well :)

Yes, I first implemented HOM in Objective-C, back in 1997 or so...

However, collect + 5 doesn't first sum and then add 5 to the sum, it distributes the +5 to every element, and any other message you care to send.

Omg are you marcel weiher?

How can I do you something good? Beer? Candy? :) Back in the days I read your paper and obviously I forgot what "collect" means...

If you are Marcel then you are one of my heros.

How does this work? Seems like "+ 5" should be a block, but there's no square brackets.

Higher Order Messaging:

http://en.wikipedia.org/wiki/Higher_order_message

http://www.metaobject.com/papers/HOM-Presentation.pdf

http://www.metaobject.com/papers/Higher_Order_Messaging_OOPS...

Thanks! Those are very clear and thorough explanations.

As a long time Smalltalk lover, I can only UP this project ! I'll have no use for it immediately, but it's good to know where it can be found.

F-Script is another project that brings Smalltalk syntax (with extensions) to OS X. It has active forks and some neat array processing.

Project Etoile offers something similar, Pragmatic Smalltalk

http://etoileos.com/etoile/features/languagekit/

Project Etoile is awesome! It is also further along in the Obj-C/ST integration than ObjST.

What distinguishes ObjST is that it is taking the language further in terms of expressive power and adaptability, with Polymorphic Identifiers, (higher order) messaging mediated via first class references and dataflow connectors.

Etoile is great project with many interesting concepts. I always wished that Apple would somehow get inspired by the LanguageKit. I guess that AppleScript was good enough...

I miss the talks of pre-Etoile days on #gnustep.

Interesting.

I had a quick look, but I don't see any mention about memory management. Because it must have fully deterministic realtime aware architecture to replace or complement Objective-C, and memory management strategy is one of the most important stuff. If it's based on typical (non-deterministic) GC, then it won't be that much interesting anymore.

Also, I think using `<-` instead of `:=` would be better for a new Smalltalk dialect. With proper editor support, the arrow sign will look far better then colon-equal sign.

"deterministic [..] architecture"

Yes, important point and one of the fundamental design consideration.

Objective-Smalltalk uses the underlying ObjC runtime, so reference counting it is. No GC, unless you run it on Apple's deprecated GC or GNUStep with Boehm. Your choice.

The "<-" character pair is actually supported, Unicode left arrow would also be nice. As a matter of fact, assignment is not a built-in operator as with Smalltalk, but a family of dataflow connectors that includes constraints.

The right-arrow "->" is also supported for architectural connection, such as when connecting the IN and OUT ports of a flow-based system or up-/downstream composite scheme handlers:

   (ref:file:{env:HOME}/Sites -> (MPWCopyOnWriteScheme memoryCache) -> (MPWSchemeHttpServer serverOnPort:8081)) start:nil.

This creates a web-server with the "Sites" directory of your home directory, via an in-memory cache.

Oh it's getting even more interesting!

Do you have any plan to add hygienic macro and coroutines? AFAIK, coroutines were always supported in traditional Smalltalk, but if you're based on objc runtime, it may not possible. So I am asking this.

As an iOS programmer and long time Objective-C fan, I like the direction it is going. How is the memory management done? Since ARC is basically done by the compiler I wonder if that can be leveraged?

Yes, either ARC or something comparable is planned. Alas, significant parts of ARC are implemented in the ObjC frontend clang rather than the LLVM backend, so that will be a bit of work.

Fortunately, there are other ways of achieving largely the same effect, and in the end it's just ASMOP.

ASMOP - isn't that the solution to everything ;-)

So Objective-C with an unpolluted syntax. That could be nice!

So Objective-C with an unpolluted syntax.

Otherwise known as Smalltalk.

But then you give up the memory safety brought by C!

Running on the Objective-C runtime as a peer (methods indistinguishable), thus Objective-Smalltalk. :-)

what makes me skeptical is this "Generic raw pointers are not supported". The goal of C type languages are to offer performance not ease of use. So if that means loss of performance kinda defends the purpose. And if I want ease of use I rather use Pharo . But I support the effort, and I am certainly very interested to see what will come out of this :)

The thing is that it is possible to have both, like the Pascal branch of languages proves.

Or if Apple had kept investing into Dylan, for example.

yes definitely , I am not saying its not possible. Afterall Objective C itself supports manual memory management and GC . I was just wondering if Objective Smalltalk has something similar.

> The thing is that it is possible to have both, like the Pascal branch of languages proves.

Do you recommend any particular languages for this purpose, nowadays?

It is a bit hard to recommend any besides Ada.

Thanks to Ada Core, the issue with Ada compilers costing a small fortune is no nonlonger true. Given its support for Ada compiler in GCC.

At least in Europe, Ada seems to be having an increase in usage, specially in areas where human lifes are at risk. I don't have a real measure for that, just by watching how Ada presence has been growing at FOSDEM.

For remaining Modula, Oberon and Pascal dialects, there is no industry support any longer, except a few niche places.

An important point.

ObjST does offer different variations of the concept of a "pointer". The first is a ref:. This is a reference to a resources, so a generalization of what a pointer is. Specific scheme providers can return refs that are effectively pointers, so for example a reference to the name of a person:

    nameRef := ref:var:person/name

This eliminates the need for string-based techniques such as Key-Value-Coding (KVC), for example when binding user-interface elements. A text-field can just take a ref, and manipulate that:

    nameRef value:'Pascal'.

This will set the name of the person to 'Pascal'.

A ref:file: is a reference to a file. Storing that in another file creates a symbolic link:

    file:linktohome <- ref:file:{env:HOME}

In addition, scheme providers are extensible. So for example if you need to access a hardware register at a specific address, you could have a mem: scheme provider:

    mem:0x10f := 23.

Assuming you have the correct permissions :-)

In terms of performance, that is often better provided by bulk collections. Pointer indirections are actually a major drain on processor performance these days.

So the broad idea is to provide performance via bulk primitives, hardware access via scheme-providers and aliases/references via first class references ('ref:'). "Generic raw pointers" should then be largely unnecessary, specific pointers can be provided as necessary.

ah nice , similar to what I expected. Its also very nice to see a new way of doing things. I will have to look more deeply into your implementation. I really hope you keep up with this and not abandon it. I would love to have an objective C alternative.

Is there support "out of the box" for obj c libraries , or wrappers will be needed to do so ?

I see you support the to: message for loops, is there also a do: message for iterations ? I really prefer it instead of for loops :)

I see the syntax really looks like smalltalk and that for me is a huge plus compared to Objective C, well done and as I said I really hope you keep working on this. I am definitely going to try it :)

"obj c libraries"

Any library in the image can be accessed via messaging without wrappers, that's the "peer" idea. C functions currently have to be wrapped, one of the reasons I did an Objective-C wrapper for CoreGraphics: https://github.com/mpw/MPWDrawingContext

The REPL / command-line script interpreter also has a convenience method for loading frameworks, so `context loadFramework:'AppKit' will load the AppKit and also parse the scripting-bridge definitions so you have access to constants.

Combined with the ability to drop back into the REPL, this has made it possible for me to trivially create custom shell, for example pdfsh <filename> loads a PDF into memory and then drops me at the command prompt with an object representing the PDF bound to the variable `pdf`.

"iteration"

Most normal Smalltalk collection/block iteration protocol is supported, so #to:do: is just shorthand for first #to: , creating an Interval, and then #do: iterating that interval. In addition to the ones taking a block argument, you also get the equivalent ones taking a message.

very well done. Its seems you have created something that has a lot of potential. Being able to use obj c libraries out of the box and yet use smalltalk syntax is a huge win for me. I only hope the best for your project :)

Fantastic! The only question is, will Apple be able to evolve Objective-C faster than this can be made into a production ready tool?

Alas, Apple can't really evolve Objective-C in the direction of simplicity at this point due to backwards compatibility concerns, and the complexity of (a) 2 language syntaxes and (b) the history of some unfortunate decisions leaves little room in the syntax for some of the more interesting enhancements.

I did not take this step lightly, being an old Objective-C hacker myself (did my own implementation on an Amiga with Aztec C in 1987...)

Interesting. Does this support/run on/with alternative platforms like gnustep, or does it require os x for development and only target ios/osx? Would it be feasible to port?

See the last time this was discussed on Hacker News: https://news.ycombinator.com/item?id=6917740

This is pretty unhelpful as this (your) submission wasn't discussed at all.

Is it dynamic language like Smalltalk-80?

Reply on news.ycombinator.com