Reputation: 51901
After reading Is a virtual machine for Cocoa programming inevitable?, I'd like know what is the language in your mind if the replacement really happens, and why?
Fixable complaints in the language and APIs include
- the lack of tuples, slices, maps or associations at a syntax level;
- the lack of template programming;
- the lack of namespaces;
- the lack of default parameters to methods;
- the lack of operator overrides/overloading;
- leaks and premature collection by the garbage collector;
- the wordy, camel-coded naming conventions;
- the lack of package management;
- the lack of out-of-the-box support for "business" APIs like REST, SOAP, SQL, etc.
- Even the commonly mocked square bracket method invocation syntax could be changed if the need existed.
p.s. one language per answer please.
Upvotes: 3
Views: 341
Reputation: 3074
Swift! Swift is already on it's way to replacing Objective C.
It is easy to learn, extremely OOP, and handles so many things that other languages should.
Once you get a feel for the language, you feel more powerful than almost any other language as far as what you are then capable of.
Garbage Collection is handled for you to where the only time you need worry about it at all is when running asynchronous code.
Virtually all of the points that were made are addressed completely or at least partially inside of Swift besides the wordy naming conventions of which I am a huge fan.
I have met many Objective C developers that don't see the advantage, but as far as I am concerned they are stuck in their old ways.
Final point.... Swift is around 4 times faster than python from my own personal simple math loop tests.
Upvotes: 0
Reputation: 86651
How valid are the complaints:
Fixable complaints in the language and APIs include
- the lack of tuples, slices, maps or associations at a syntax level;
So what?
- the lack of template programming;
Is this C++ templates? Then use Objective-C++. Personally, I think it's a plus point that we don't have them in Objective-C.
- the lack of namespaces;
This one is valid. I'd dearly love name spaces.
- the lack of default parameters to methods;
This is another feature I am glad is not in Objective-C
- the lack of operator overrides/overloading;
This is another feature I am glad is not in Objective-C
- leaks and premature collection by the garbage collector;
So fix the garbage collector bugs.
- the wordy, camel-coded naming conventions;
I like the wordy naming conventions. It makes the code easier to read. OTOH if you are a person who doesn't note thatthese are only conventions. The compiler doesn't force you to use them.
- the lack of package management;
Packages would be nice.
- the lack of out-of-the-box support for "business" APIs like REST, SOAP, SQL, etc.
There are plenty of libraries available for these.
- Even the commonly mocked square bracket method invocation syntax could be changed if the need existed.
Commonly mocked by people who don't really use the language. When I first started C I hated a lot about the syntax, but you get used to it.
I see no pressing reason to change anything about Objective-C except to add name space support. So that's my answer: Objective-C.
Upvotes: 5
Reputation:
Objective-but-not-C, a language that borrows a lot of syntax and methodology from Objective-C but does away with the direct access memory model and primitive arrays. It would be an entirely new language designed by Apple with compatibility (probably even binary compatibility) with the Objective-C runtime library.
The result would be a to Objective-C as Microsoft Managed C++.NET is to C++. In fact, if Apple were to use a VM like LLVM in the same way that Microsoft uses the .NET CLR, then other languages such as Ruby, Python etc. could easily interoperate with "Objective-but-not-C" code.
Upvotes: 0
Reputation:
MacRuby, an implementation of Ruby that uses the LLVM compiler and bases all of its objects on the Objective-C runtime library (and on normal Cocoa classes like NSString
, NSArray
). It's completely interoperable with ObjC so existing code can be integrated with MacRuby code. Indeed ObjC could be used as a systems programming language in the same way that the JVM and parts of the Java class library are written in C, not Java.
Essentially I think any replacement language must be interoperable with Objective-C, will be object-oriented, and will have completely managed access to memory.
Upvotes: 2