5

I don't know well Smalltalk, but I know some Objective-C. And I'm interested a lot in Smalltalk.

Their syntax are a lot different, but essential runtime structures (that means features) are very similar. And runtime features are supported by runtime.

I thought two languages are very similar in that meaning, but there are many features on Smalltalk that absent on Objective-C runtime. For an example, thisContext that manipulates call-stack. Or non-local return that unwinds block execution. The blocks. It was only on Smalltalk, anyway now it's implemented on Objective-C too.

Because I'm not expert on Smalltalk, I don't know that sort of features. Especially for advanced users. What features that only available in Smalltalk? Essentially, I want to know the advanced features in Smalltalk. So it's OK the features already implemented on Objective-C like block.

Kirk Broadhurst
  • 27,836
  • 16
  • 104
  • 169
eonil
  • 83,476
  • 81
  • 317
  • 516
  • This is something you might found interesting: http://objective.st/ – Sebastian Sastre Mar 08 '14 at 14:27
  • @SebastianSastre Ah I have checked it a few months ago. It's nice to have a strong typing system. But it seems it works only on Objective-C runtime, that means it's hard (of course, not impossible…) to run them on non-Apple platforms. And recently, I am losing interest on learning a new language… – eonil Mar 09 '14 at 02:01
  • Yeah, developing for Apple is one thing. Doing it cross-platform a whole different story. If that's what you're searching for, maybe it's worth looking at doing your app in html5+javascript with Amber and use this: http://www.appcelerator.com/blog/2011/09/introducing-titanium-desktop-sdk-1-2-release-candidate-4/ – Sebastian Sastre Mar 09 '14 at 22:35

3 Answers3

7

While I'm reasonably experienced within Objective-C, I'm not as deeply versed in Smalltalk as many, but I've done a bit of it.

It would be difficult to really enumerate a list of which language has which features for a couple of reasons.

First, what is a "language feature" at all? In Objective-C, even blocks are really built in conjunction with the Foundation APIs and things like the for(... in ...) syntax requires conformance to relatively high level protocol. Can you really talk about a language any more without also considering features of the most important API(s)? Same goes for Smalltalk.

Secondly, the two are very similar in terms of how messaging works and how inheritance is implemented, but they are also very different in how code goes from a thought in your head to running on your machine. Conceptually different to the point that it makes a feature-by-feature comparisons between the two difficult.

The key difference between the two really comes down to the foundation upon which they are built. Objective-C is built on top of C and, thus, inherits all the strengths (speed, portability, flexibility, etc..) and weaknesses (effectively a macro assembler, goofy call ABI, lack of any kind of safety net) of C & compiled-to-the-metal languages. While Objective-C layers on a bunch of relatively high level OO features, both compile time and runtime, there are limits because of the nature of C.

Smalltalk, on the other hand, takes a much more top-to-bottom-pure-OO model; everything, down to the representation of a bit, is an object. Even the call stack, exceptions, the interfaces, ...everything... is an object. And Smalltalk runs on a virtual machine which is typically, in and of itself, a relatively small native byte code interpreter that consumes a stream of smalltalk byte code that implements the higher level functionality. In smalltalk, it is much less about creating a standalone application and much more about configuring the virtual machine with a set of state and functionality that renders the features you need (wherein that configuration can effectively be snapshotted and distributed like an app).

All of this means that you always -- outside of locked down modes -- have a very high level shell to interact with the virtual machine. That shell is really also typically your IDE. Instead of edit-compile-fix-compile-run, you are generally writing code in an environment where the code is immediately live once it is syntactically sound. The lines between debugger, editor, runtime, and program are blurred.

bbum
  • 162,346
  • 23
  • 271
  • 359
  • 1
    +1 for that last statement, that is the one thing that stands out in SmallTalk head and shoulders above every other language I've touched. Not saying it's better that way just that it stands out like a sore thumb as the largest contrast between SmallTalk and anything else. – Jimmy Hoffa Jan 13 '14 at 23:50
1

Not a language feature, but the nil-eating behaviour of most Objective-C frameworks gives a very different developing experience than the pop-up-a-debugger, fix and continue of smalltalk.

Even though Objective-C now supports blocks, the extremely ugly syntax is unlikely to lead to much use. In Smalltalk blocks are used a lot.

Stephan Eggermont
  • 15,847
  • 1
  • 38
  • 65
  • Is there no nil-eating behavior on Smalltalk? – eonil Sep 23 '11 at 05:34
  • nil-eating behaviour is mostly not used on Smalltalk. From a development point of view, that is a good thing. You don't get the fast feedback loop with it. Of course there can be parts of your API where you want to use it. – Stephan Eggermont Sep 24 '11 at 06:27
  • The first part of this answer is wrong; the fix-and-continue features of Smalltalk are enabled because SmallTalk is effectively interpreted (interpreted byte code in a VM anyway), not because of nil-eats message (whether or not nil-eats-message is a a feature or bug is a matter of opinion). The second part of this answer is opinion (syntax is ugly) and wrong in that Blocks are used far and wide across both the system APIs and the implementations of both the system and 3rd party apps. – bbum Sep 26 '11 at 03:01
  • Huh? For fix-and continue you need both the compiler at runtime and stop when something goes wrong. Nil-eating means not stopping when trying to send a message to nil. That is where I often need to press the 'create class' button in my debugger. I don't have access to Apple system source, but block density in open source projects is low, at least compared to smalltalk source – Stephan Eggermont Sep 26 '11 at 21:40
0

Objective-C 2.0 supports blocks.

It also has non-local returns in the form of return, but perhaps you particularly meant non-local returns within blocks passed as parameters to other functions.

thisContext isn't universally supported, as far as I'm aware. Certainly there are Smalltalks that don't permit the use of continuations, for instance. That's something provided by the VM anyway, so I can conceive of an Objective-C runtime providing such a facility.

One thing Objective-C doesn't have is become: (which atomically swaps two object pointers). Again, that's something that's provided by the VM.

Otherwise I'd have to say that, like bbum points out, the major difference is probably (a) the tooling/environment and hence (b) the rapid feedback you get from the REPL-like environment. It really does feel very different, working in a Smalltalk environment and working in, say, Xcode. (I've done both.)

Frank Shearar
  • 17,012
  • 8
  • 67
  • 94
  • No offence but I am a little bit confuse with your first sentence. Non-local return is a term applicable only for block. It mean that you return from the outer lexical scope of the block(non-local return) and not from the outer scope of the function scope (local return). So in Objective-C 2.0 non local return is not supported (a part if you have some setjump, longjump which is what look the most of a non-local return ). – mathk Sep 30 '11 at 09:48
  • I wrote up the issue here: http://www.lshift.net/blog/2011/01/31/non-local-returns-and-compound-statements (or, my answer's too long for this comment field) – Frank Shearar Sep 30 '11 at 11:08
  • Yes that is why `return` in objective-c is not a non-local return – mathk Nov 22 '11 at 10:48
  • @mathk: Um, yes, given that {}s don't create a new activation record in C/Objective-C. However, `return` returns from the _method_ not from the _innermost lexical scope_ (the if clause/while loop/whatever), which mirrors Smalltalk's `^` inside a block, which is what I was trying to say. – Frank Shearar Nov 22 '11 at 13:14