I've never understood why people like frontal return types. It seems to me that the most important piece of a function is its name, which 50% of the time will make it obvious what its return type is anyway. Also, certain languages such as C++ (and occasionally Java) have a habit of involving incredibly long return types that push the actual function name far off to the side, if not onto a second line.

In C++11 you can push the return type to the right, like this:

    auto foo(int x) -> bool;

Ewww. WTF?!

http://www.cprogramming.com/c++11/c++11-auto-decltype-return... provides a rationale: so you don't have to type in ClassName:: twice. Is that really worth this monstrosity? The function name is still not at the start of the statement. '->' is being horribly misused. Anybody know if there's a better reason for this? Did the committee really have nothing better to think about?

Yes there are much better reasons: http://www2.research.att.com/~bs/C++0xFAQ.html#suffix-return

        template<class T, class U>
	auto mul(T x, U y) -> decltype(x*y)
	{
		return x*y;
	}

Ah, that use case makes sense. I wish the syntax was congruent with C++, but that complaint has been done to death.

I agree regarding the syntax. Most of differences as compared to ObjC seem to be focused on simply removing characters, increasing ambiguity for the reader, without any adequate justification for their removal.

The ugliness of ObjC has little to do with brackets and semicolons, and a lot to do with the lack of higher-level functional constructs and type-system features.

A language that was ObjC-compatible and yet could succinctly express LINQ/Rx-level type/api complexity would be a genuinely interesting successor to ObjC.

Syntax aside, however, the emergence of ObjC-compatible languages is contributing to the pool of knowledge on how to produce one, provides a set of possibly re-usable code to do so.

[edit] Dug into the code. It looks like the author is actually forking clang outright. This is an interesting approach, as it allows you to swap in a new compiler that supports both your language, and objc, possibly interchangeably.

The way that clang is designed (and as I understand it, I haven't looked in great detail), it's pretty much impossible to use it as a library to backend your own front-end parser/lexer atop -- you have to fork clang itself to inject your own code in.

I'm undecided as to whether tying yourself to clang (instead of the underlying llvm) is a net win for an alternative language implementation. Thoughts?

I think Apple might want to switch to Ruby in the future. Some Apple employees are still actively working on MacRuby and it is actually possible now to create iOS apps with Ruby through RubyMotion.

http://www.rubymotion.com/

I won't decry having options, but I am not sure what Apple would stand to gain by switching the first-class language of their platform to Ruby. If you look at any RubyMotion code, it ends up being an almost line-per-line copy of the equivalent Objective-C code.

Given that the languages come from the same lineage, it is not even a big jump to switch between them from a developer's point of view. The thing that really stood out when I was learning Objective-C is that it essentially was Ruby, just with some C thrown in. I often wonder if people go in thinking Obj-C is some kind of worse version of C++ and then miss what the language really has to offer. While it is certainly not perfect, I'm constantly amazed at how elegant the design of the language really is.

Ruby could shine if Apple were to create a whole new set of APIs based around the language, but that would mean throwing away nearly 25 years or work. It would be a tremendous undertaking for what could be positive gain, but is just as likely to introduce a whole new world of problems, especially in the early years.

Official support for Ruby would certainly be welcome, but I don't see benefits in outright switching; not without also removing the Objective-C APIs from the equation and creating a whole new platform that centres around Ruby.

Actually, all of the Apple employees working on MacRuby have since left. Apple will not be moving to Ruby in the near future unless something drastic happens. That said, so long as the Obj-C runtime is documented and well designed (and it is!), then anyone that cares to can interoperate with Obj-C with a bit of work, a la RubyMotion.

I think it's more like you want Apple to want to switch to Ruby.

But it ain't going to happen. They need the drop down to C without the run around.

I also find the syntax a bit odd, including the return types. Plus the brackets for multiple arguments that appear in the interface but not in the implementation are inexplicably inconsistent. (Update: See below.)

I would also be very curious how well eero adapts to pure C code. Many of Apple's performance-critical APIs are C, as our many third party libraries. So being able to effortless invoke C within Objective-C is essential.

eero's design seems to neglect this. For one, goto is outright banned, eliminating a rather effective tool for elegant C based error handling. (http://stackoverflow.com/questions/788903/valid-use-of-goto-..., but please let's avoid a long tangent on the proper use of goto)

Update: My mistake, the brackets apparently define an argument as optional, which might be a convenient shortcut in some cases.

I thought 95% of the syntax was a dramatic improvement over straight obj-c, which I actually don't mind at all.

I admit, the one time I paused was when I saw the trailing return types. It was the only part that felt unintuitive.

By mere convention it felt odd, but I'm willing to explore a break with convention. Seeing how well-designed the other 95% of the syntax is, I'm giving the architect the benefit of the doubt, and hoping that this trailing return syntax ultimately proves MORE intuitive, despite my initial recoil.

I'm really curious now about the practical issues of putting Eero into real-world use (which, since we're talking obj-c here, means OSX or iOS development).

Why would you assume Apple is working to reduce Obj-C verbosity? The language has been around for decades and they seem to be doing pretty well with it as-is.

We're not assuming anything; they're actually doing it. For instance:

http://joris.kluivers.nl/blog/2012/03/13/new-objectivec-lite...

The language may be decades old, but clearly Apple is continuing to advance the compiler to improve the language's syntax and verbosity without breaking the runtime.

blocks and arc go a LONG way

The language is almost 30 years old with remarkably few changes, but we've seen a (relative) burst of improvement in the past 5 years. Properties, fast enumeration, and automatic refcounting all reduce the verbosity of Objective-C code.

Also, the string literal syntax for arrays, dictionaries, and numbers, and automatic property synthesis added in LLVM 4.0 - most welcome additions.

They add every year new features to the language like blocks and a lot more which is currently under NDA so I can't tell.

Why do you assume that Apple isn't working on his language? They are heavily developing it!

I'm not assuming anything... "assume" was used in the post I responded to, and asked why. I don't use ObjC myself, though I would say that "add new features" does not imply "reduce verbosity" in any sense that I can see.