6

Syntactically it's superset of C. But since messages are sent and processed at runtime this means it cannot be a pure compiled language like c but it needs a runtime like Visual Basic or .Net runtime.

Then what prevents it to be portable to other platforms by transforming this runtime to something like .NET Framework or Java JVM ?

Note: when I say VB it's of course last version 6 which compiles to Bytecode so why do you pretend that Java or .Net are different fundamentally from VB6 except for portability it's the same principle: see Similar to Java, Visual Basic is compiled into an intermediate language called "bytecode." The bytecode is translated into x86 machine language by the Visual Basic runtime module.

Read more: http://www.answers.com/topic/visual-basic#ixzz19iJd3wjA

Similar to Java, Visual Basic is compiled into an intermediate language called "bytecode." The bytecode is translated into x86 machine language by the Visual Basic runtime module.

Muhammad Hewedy
  • 29,102
  • 44
  • 127
  • 219
user310291
  • 36,946
  • 82
  • 271
  • 487
  • Read about the [GNU Objective-C Runtime](http://www.gnustep.org/resources/documentation/User/GNUstep/faq_1.html#SEC27). – Josh Lee Dec 31 '10 at 17:50
  • I have already read about Objective C Runtime before asking the question thanks. – user310291 Dec 31 '10 at 18:08
  • VB6 and VB.NET/C# *are* fundamentally different. For starters, most VB6 programs were actually compiled to native code - the runtime was limited to supporting routines, loaders, wrappers, etc. But more importantly, the VBVM used by earlier P-Code VB compilers was incredibly limited compared to the JIT-compiling .NET runtime - the goal was primarily smaller executable size, while the .NET VM aims for multi-platform, multi-CPU, multi-language support (similar to the Java VM, although multi-language compatibility was not a priority for the JVM until fairly recently). – Shog9 Dec 31 '10 at 18:48
  • It's just because VB6 wasn't designed to be crossplatform since at that they were no real competion for windows desktop. JIT Compiling itself is just optimization which I wouldn't call "fundamental" change. – user310291 Jan 02 '11 at 12:07

3 Answers3

15

You appear to be confused between the need for runtime support for language features, and the difference between a native-compiled and VM-compiled (or interpreted) language.

Most high-level languages need some sort of run-time support. Even C has a run-time library, although on many platforms you can choose not to use some or all of it. Modern operating systems provide even more runtime support, and many languages provide OS-specific extensions that integrate these - consider dynamic loading of libraries...

Furthermore, there's nothing stopping you from building a message-passing system on top of a language that doesn't support it intrinsically. Since this is extremely common (especially for programs written for event-driven platforms), integrating it into the language can be looked at as simply factoring some error-prone busywork out of the high-level code and into the language and runtime.

Finally, both Java and most .NET languages are actually compiled - they just compile down to a bytecode that no machine implements natively, requiring the use of a Virtual Machine to actually execute them. The most performant VMs compile the code again prior to executing it - this can be such an effective technique that it has been used to build fast and efficient compiler tool-chains!

Visual Basic is a red herring here - some versions are interpreted, others are compiled, and VB.NET - like other .NET languages - is compiled to bytecode and then JIT-compiled again during execution (while superficially similar, this tends to be implemented very differently from the earlier VB VMs). If nothing else, this should tell you that a language and the means by which programs written in it are executed are not as tightly coupled as is commonly-believed...

In answer to your last question: Objective-C has never not been portable, at least in the sense that C is portable (that is to say, source-code portability). Apple uses the GCC compiler, which has been ported to a dizzying array of platforms... However, once you start taking advantage of platform-specific APIs (probably one of the best reasons for using Obj-C on Apple platforms to begin with...) you're limited to platforms that implement those APIs. Binary portability is possible in theory, but I know of no implementations.

Community
  • 1
  • 1
Shog9
  • 156,901
  • 35
  • 231
  • 235
  • When I say VB it's of course last version which compiles to Bytecode so why do you pretend that Java or .Net are different fundamentally from VB6 except for portability it's the same principle: see Similar to Java, Visual Basic is compiled into an intermediate language called "bytecode." The bytecode is translated into x86 machine language by the Visual Basic runtime module. Read more: http://www.answers.com/topic/visual-basic#ixzz19iJd3wjA – user310291 Dec 31 '10 at 18:05
  • Objective-C has never not been portable: sure that's why I ask the question :) I'm not asking if it exists, I'm asking if it is technically possible. – user310291 Dec 31 '10 at 18:10
  • 2
    @user310291: you're using a very unfortunate reference for that assertion... VB could be compiled to native code as of version 5; previous versions compiled to bytecode ("P-Code"), which was then interpreted by the runtime VM. The early versions of Java also interpreted bytecode at runtime, but today both Java and the .NET bytecodes are generally JIT-compiled for speed and efficiency. – Shog9 Dec 31 '10 at 18:37
  • 1
    @user310291 If you say portable in the sense of binary compatible, it have the same compatibility with C programs (as it is compiled into native code). In the code-compatible sense, Objective-C have a better compatibility than C. Personally I maintained several projects that compiles under both Apple and GNUstep implementations of Foundation and libobjc and the code is almost 100% shared. – Maxthon Chan Nov 04 '13 at 03:39
14

It does not follow at all that message passing cannot be compiled. It merely implies that the message must be resolved to a method call at runtime. Objective-C is certainly a compiled language.

The process is described here. It is true that the initial call to a method is slower than a C++ method call, but the resolution is cached so subsequent calls are faster. Such non deterministic behaviour would make Objective-C unsuited to some applications.

Objective-C is provided as a front-end for GCC, so is highly portable. However only OSX and its predecessor NextSTEP, and iOS have an OS API for which Objective-C is the preferred language (i.e. the language the OS API is written in/for). So while it can be used on any OS that supports GCC, its usefulness on such platforms is limited.

Clifford
  • 88,407
  • 13
  • 85
  • 165
4

But since messages are sent and processed at runtime this means be a pure compiled language like c

Why not ? You can send and process messages in a compiled language, a compiled language could provide reflection and dynamically dispatch calls as well, if that would be needed.

Obj-C, as implemented on OSX/iOS is compiled to native code. Here's a small introduction to the Obj-C runtime, here's another

nos
  • 223,662
  • 58
  • 417
  • 506
  • Similar article: http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/ – Josh Lee Dec 31 '10 at 17:45
  • You can send and process messages in a compiled language ? I can't see how: message means you can broadcast to ANY TYPE of objects that would be very difficult to do in a compiled language without runtime like .NET. – user310291 Dec 31 '10 at 18:12
  • Thanks for the article seems interesting – user310291 Dec 31 '10 at 18:12
  • @user310291: as nos noted, you can actually implement objects and reflection on top of a compiled language as well... – Shog9 Dec 31 '10 at 18:50