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.

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.

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.

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

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.

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

I'll upload a video of that later.

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 really like Ruby :)

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

"Javascript for the Browser"

"Structured Query SQL Language"

Unfortunately not so redundant these days.

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

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

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

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

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

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

    #( 1 2 3 4 5 ) collect + 5

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

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

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

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

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.

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.

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

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

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

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.

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.

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.

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.

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

Otherwise known as Smalltalk.

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 

    nameRef value:'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}

    mem:0x10f := 23.

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.

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

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.

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

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

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.

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