
Objective-Smalltalk - jcla1
https://github.com/mpw/Objective-Smalltalk
======
rtpg
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.

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

~~~
stcredzero
_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.

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

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

------
mseepgood
What's next? "Functional lambda calculus"?

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

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

------
stefanu
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](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](https://github.com/Stiivi/StepTalk/tree/master/Examples)

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

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

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

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

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

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

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

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

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

------
pjmlp
Project Etoile offers something similar, Pragmatic Smalltalk

[http://etoileos.com/etoile/features/languagekit/](http://etoileos.com/etoile/features/languagekit/)

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

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

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

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

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

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

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

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

~~~
stcredzero
_So Objective-C with an unpolluted syntax._

Otherwise known as Smalltalk.

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

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

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

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

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

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

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

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

------
stesch
See the last time this was discussed on Hacker News:
[https://news.ycombinator.com/item?id=6917740](https://news.ycombinator.com/item?id=6917740)

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

------
erikj
Is it dynamic language like Smalltalk-80?

