9 ms·

The eero programming language - a dialect of Objective-C

131 points by basil 14y ago

huragok 14y ago
I can definely see myself using this over objective-c if it proves stable enough for production usage.
- breckenedge 14y ago
  Agreed. Much nicer on my eyeballs.
angerman 14y ago
While it looks interesting and probably has some use cases, the syntax puts me off a little. YMMV. Yes, Obj-C has many brackets. But I find them supporting reading by grouping relevant elements together. I assume if you dislike lisp like languages, eero might help in this regard. What I particularly don't like are the tailing return types. I also assume apple is actively working to reducing the Obj-C verbosity to some extend. Regarding the website, I miss a "get started" link. How do I take it for a quick test-drive? EDIT: It sais: "Eero is a fully binary- and header-compatible dialect of Objective-C". Does this mean, I can write a module in Eero and have it derive the correct header files for me? Or do I need to re-write the header file to be consumed by (legacy) Obj-C?
- ams6110 14y ago
  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.
  - ken 14y ago
    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.
    - pirateking 14y ago
      Also, the string literal syntax for arrays, dictionaries, and numbers, and automatic property synthesis added in LLVM 4.0 - most welcome additions.
  - oemera 14y ago
    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!
    - ams6110 14y ago
      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.
  - deleted 14y ago
    [deleted]
  - robterrell 14y ago
    We're not assuming anything; they're actually doing it. For instance: http://joris.kluivers.nl/blog/2012/03/13/new-objectivec-literal-syntax/ 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.
    - aaronblohowiak 14y ago
      blocks and arc go a LONG way
- wsc981 14y ago
  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/ http://www.rubymotion.com/
  - deleted 14y ago
    [deleted]
  - jawngee 14y ago
    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.
  - jballanc 14y ago
    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.
  - randomdata 14y ago
    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.
- ender7 14y ago
  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.
  - cageface 14y ago
    In C++11 you can push the return type to the right, like this: auto foo(int x) -> bool;
    - akkartik 14y ago
      Ewww. WTF?! http://www.cprogramming.com/c++11/c++11-auto-decltype-return-value-after-function.html 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?
      - kzrdude 14y ago
        Yes there are much better reasons: http://www2.research.att.com/~bs/C++0xFAQ.html#suffix-return 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; }
        akkartik 14y ago
        Ah, that use case makes sense. I wish the syntax was congruent with C++, but that complaint has been done to death.
- flatline3 14y ago
  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?
- skue 14y ago
  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-for-error-management-in-c 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.
- introspectif 14y ago
  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).
franzus 14y ago
> Python-like indentation Oh god, please no.
- huragok 14y ago
  The syntax reminds me less of python and more like coffeescript. I loathe python but there's a certain .. je ne sais quoi with much of the operators and syntactic sugar removed. Almost like natural language!
  - stcredzero 14y ago
    That's the Smalltalk heritage of Objective-C shining through. Smalltalk was actually intentionally designed using Human Interface notions to be friendly -- even to the point of being used by grade school children.
- Xcelerate 14y ago
  I had the opposite reaction. I was initially thinking "another overly syntactic language", and then I went to the website and thought "Wow! This looks very nice!".
- tvon 14y ago
  Oh, but yes, yes! :)
- Quequau 14y ago
  This is something I completely agree with. However, at this point, having used things like gofmt, there should already be tools that enforce correct formatting. I don't use python very much... perhaps there already is.
basil 14y ago
The examples struck me as looking a lot like Go and I found a few similarities: - Local type inferencing (i := 100) is identical. - No parentheses for control structures. - Lack of semicolons. - Ranges in array enumeration (albeit with different syntax).
cageface 14y ago
The problem, as RubyMotion and Monotouch have both demonstrated, is that no matter how much you change the language your code is still dominated by calls into the Cocoa APIs, and that's where a lot of the verbosity and ugliness lies (IMO).
- ThePherocity 14y ago
  You get used to them, but they do have a tendency to look like someone from another planet wrote them, don't they?
- pirateking 14y ago
  You are entitled to your opinion, but I will disagree. The Cocoa/Cocoa Touch APIs are probably the best I have ever used. Rarely do I have to dive into the documentation thanks to the self documenting method names. The consistently and logically applied conventions (paired with autocomplete) mean I can usually use intuition to "feel" my way around. If ever I need to read the documentation, it is also some of the best around.
jballanc 14y ago
Programmers "liked" Java because they were told to by Sun. Programmers "liked" C# because they were told to by Microsoft. Now, programmers "like" Obj-C because they are told to by Apple. In that regard, this seems like a step in the right direction... But it's only a half step. If you look at what's happened to the other two languages mentioned above, they have evolved such that their runtimes are now more important than the languages they originally hosted. What really needs to happen to Obj-C is for people to wake up and realize that the runtime is actually really nice. Combined with LLVM, one could make the case that the Obj-C runtime could compete with the JVM or the CLR. (Of course, the one huge, massive, glaring omission is any sort of managed memory... Well, at least there was a garbage collector at one point.)
- nubela 14y ago
  I don't know about you, but I appreciate that I don't have a garbage collector with coding for mobile apps (Not done any for OSX apps yet). You'll know what I mean if you work with large images (Bitmaps) in Android, then you'd wish you have a better craft at release memory (instead of recycle())
  - stcredzero 14y ago
    I am wondering when someone will implement a good Ulterior Reference Count or an Age-Oriented GC for iOS/OS X. These are both hybrids of GC and reference counting that combine the strengths of both. Basically, new objects tend to die quickly, so the overhead of reference counting is generally redundant, and GC techniques like copying collectors tend to excel. Old objects tend to stick around, so reference counting overhead is low. By using a hybrid of both techniques where they are strong, you avoid a lot of overhead: pointless ref-count changing, and pointless scanning of object graphs. The result is something with the high throughput of generational GC with only a fraction of the maximum pause time. https://researchers.anu.edu.au/publications/29505 https://researchers.anu.edu.au/publications/29505 http://www.cs.technion.ac.il/~erez/Papers/ao-cc.pdf http://www.cs.technion.ac.il/~erez/Papers/ao-cc.pdf
    - jballanc 14y ago
akaru 14y ago
Looking through the docs, it does look incredible, perhaps the Perfect® language for my tastes. But the old man in me says it'll never stick.
Apocryphon 14y ago
Interesting, especially given how I was listening to John Siracusa's two Hypercritical talks from 2011 where he points out that replacing Obj-C (or any language) with bridges is insufficient. I hope he might weigh in on his thoughts of eero in the future.
gothy 14y ago
Finally!
SeoxyS 14y ago
Objective-C is hands down one of my favorite programming language: - It's compiled, not interpreted. Even Java and C# are compiled into bytecode for a massive VM to interpret. Objective-C has no VM, it's pure binary + a shared library to implement the runtime. It also uses the very best compiler, clang, which gives incredibly helpful error messages, warnings and suggestions. - It's a strict superset of C. Even C++ does not meet this criteria. This means any valid C is valid Obj-C and behaves exactly the same way, in any Obj-C file. You can drop down levels of abstraction for performance, and can even write assembly if that's what it takes. - It has an amazing and fully supported debugger in the form of LLDB. - It's fully dynamic, allows introspection, duck typing and even monkey patching (with a little effort; method swizzling). Everything is an object, except for native C types. - It takes the right approach to memory management. Realizes that garbage collectors are abominations, and that managing memory is really the job of either the developer or the compiler. - It has the most fantastic concurrency framework I've ever used, in the form of `libdispatch`. Now, to be fair, it's a C library that ought to work anywhere, but practically it only works well on Apple's platforms and using clang. - Apple is moving in the right direction, cleaning up the language, removing annoyances and making syntax more succinct. - Header files. I think I'm on my own in liking this—but I think headers are amazing. They're a succinct and standalone version of a documentation file that is extremely useful to both developers and the compiler. Use them to describe well the public interface to your class, and you don't even really have to write documentation anymore. - Solid design patterns and convention-driven. These are getting better by the day, with the recent addition of closures to the language. There's two major annoyances: - It's often needlessly verbose. Not in the syntax, mind you, which is just fine, but in the naming conventions. For example, `NSArray` has a method called `enumerateObjectsUsingBlock:` instead of simply `each:`. Add that up to every single name, and you get pretty ugly code—and good luck writing it with anything other than Xcode's context-aware autocompletion. - It's tied to Apple's platforms, and well not run on anything else. Now, I'm fine with Apple-specific frameworks and GUI frameworks (like QuickTime or UIKit) being Apple-only, but I'd really love to use the language to write a backend service, for which I'd only need Foundation & libdispatch, for example.
- rudiger 14y ago
  - It takes the right approach to memory management. Realizes that garbage collectors are abominations, and that managing memory is really the job of either the developer or the compiler. Please elaborate why Objective-C's approach to memory management is Right, and why GC is Wrong.
jashkenas 14y ago
Pretty rad that eero forbids variable shadowing. It would be neat if more languages start doing that in the future... http://eerolanguage.org/documentation/index.html#noshadowing http://eerolanguage.org/documentation/index.html#noshadowing
- ufo 14y ago
  Err, sounds like a weird thing to do, and as they mentioned, is more likely just a limitation of their inferrence engine. Preventing variable shadowing leaks implementation details from inside functions/blocks and mos tlanguages do just fine with appropriate warnings and so on.
fusiongyro 14y ago
It looks nice, but I can't help but wonder why not go all the way to Smalltalk instead? helper := FileHelper new. "declare variable 'helper' via type inference" files := [] "empty array literal implies mutable" files addObject: (helper openFile: 'readme.txt'). "can group message in parens" files do: [ | FileHandle handle | "all objects are pointers, so no '*' needed" self log: 'File descriptor is %@', (Number)(handle fileDescriptor) ). self handle: closeFile ]. ^ 0 Of course, you'd still have to solve the lack of syntax for defining classes and methods, but there are a couple solutions to that problem out there already.
- tbe 14y ago
  A Smalltalk compiler for the Objective-C runtime exists here: http://etoileos.com/dev/docs/languages/smalltalk/ http://etoileos.com/dev/docs/languages/smalltalk/
  - fusiongyro 14y ago
    Cool. Does it work with Cocoa on OS X?
introspectif 14y ago
Most of the comments here are way off base, focusing on the relative worth of the objective-c language, rather than the value of Eero for developers who have no choice but to use objective-c, regardless of how good they think it is or isn't. If you haven't already - I highly recommend following the link. RubyMotion was somewhat interesting, but really didn't feel like a massive improvement over plain old objective-c, especially once you factor in all the Cocoa APIs. However, Eero looks amazing. The syntax used represents a vast improvement over straight objective-c or RubyMotion. Take a look - it's genuinely exciting.

131 points by basil 14y ago

huragok 14y ago

I can definely see myself using this over objective-c if it proves stable enough for production usage.

breckenedge 14y ago
Agreed. Much nicer on my eyeballs.

angerman 14y ago

While it looks interesting and probably has some use cases, the syntax puts me off a little. YMMV. Yes, Obj-C has many brackets. But I find them supporting reading by grouping relevant elements together. I assume if you dislike lisp like languages, eero might help in this regard. What I particularly don't like are the tailing return types. I also assume apple is actively working to reducing the Obj-C verbosity to some extend. Regarding the website, I miss a "get started" link. How do I take it for a quick test-drive? EDIT: It sais: "Eero is a fully binary- and header-compatible dialect of Objective-C". Does this mean, I can write a module in Eero and have it derive the correct header files for me? Or do I need to re-write the header file to be consumed by (legacy) Obj-C?

ams6110 14y ago
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.
- ken 14y ago
  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.
  - pirateking 14y ago
    Also, the string literal syntax for arrays, dictionaries, and numbers, and automatic property synthesis added in LLVM 4.0 - most welcome additions.
- oemera 14y ago
  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!
  - ams6110 14y ago
    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.
- deleted 14y ago
  [deleted]
- robterrell 14y ago
  We're not assuming anything; they're actually doing it. For instance: http://joris.kluivers.nl/blog/2012/03/13/new-objectivec-literal-syntax/ 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.
  - aaronblohowiak 14y ago
    blocks and arc go a LONG way
wsc981 14y ago
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/ http://www.rubymotion.com/
- deleted 14y ago
  [deleted]
- jawngee 14y ago
  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.
- jballanc 14y ago
  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.
- randomdata 14y ago
  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.
ender7 14y ago
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.
- cageface 14y ago
  In C++11 you can push the return type to the right, like this: auto foo(int x) -> bool;
  - akkartik 14y ago
    Ewww. WTF?! http://www.cprogramming.com/c++11/c++11-auto-decltype-return-value-after-function.html 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?
    - kzrdude 14y ago
      Yes there are much better reasons: http://www2.research.att.com/~bs/C++0xFAQ.html#suffix-return 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; }
      - akkartik 14y ago
        Ah, that use case makes sense. I wish the syntax was congruent with C++, but that complaint has been done to death.
flatline3 14y ago
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?
skue 14y ago
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-for-error-management-in-c 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.
introspectif 14y ago
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).

franzus 14y ago

> Python-like indentation Oh god, please no.

huragok 14y ago
The syntax reminds me less of python and more like coffeescript. I loathe python but there's a certain .. je ne sais quoi with much of the operators and syntactic sugar removed. Almost like natural language!
- stcredzero 14y ago
  That's the Smalltalk heritage of Objective-C shining through. Smalltalk was actually intentionally designed using Human Interface notions to be friendly -- even to the point of being used by grade school children.
Xcelerate 14y ago
I had the opposite reaction. I was initially thinking "another overly syntactic language", and then I went to the website and thought "Wow! This looks very nice!".
tvon 14y ago
Oh, but yes, yes! :)
Quequau 14y ago
This is something I completely agree with. However, at this point, having used things like gofmt, there should already be tools that enforce correct formatting. I don't use python very much... perhaps there already is.

basil 14y ago

The examples struck me as looking a lot like Go and I found a few similarities: - Local type inferencing (i := 100) is identical. - No parentheses for control structures. - Lack of semicolons. - Ranges in array enumeration (albeit with different syntax).

cageface 14y ago

The problem, as RubyMotion and Monotouch have both demonstrated, is that no matter how much you change the language your code is still dominated by calls into the Cocoa APIs, and that's where a lot of the verbosity and ugliness lies (IMO).

ThePherocity 14y ago
You get used to them, but they do have a tendency to look like someone from another planet wrote them, don't they?
pirateking 14y ago
You are entitled to your opinion, but I will disagree. The Cocoa/Cocoa Touch APIs are probably the best I have ever used. Rarely do I have to dive into the documentation thanks to the self documenting method names. The consistently and logically applied conventions (paired with autocomplete) mean I can usually use intuition to "feel" my way around. If ever I need to read the documentation, it is also some of the best around.

jballanc 14y ago

Programmers "liked" Java because they were told to by Sun. Programmers "liked" C# because they were told to by Microsoft. Now, programmers "like" Obj-C because they are told to by Apple. In that regard, this seems like a step in the right direction... But it's only a half step. If you look at what's happened to the other two languages mentioned above, they have evolved such that their runtimes are now more important than the languages they originally hosted. What really needs to happen to Obj-C is for people to wake up and realize that the runtime is actually really nice. Combined with LLVM, one could make the case that the Obj-C runtime could compete with the JVM or the CLR. (Of course, the one huge, massive, glaring omission is any sort of managed memory... Well, at least there was a garbage collector at one point.)

nubela 14y ago
I don't know about you, but I appreciate that I don't have a garbage collector with coding for mobile apps (Not done any for OSX apps yet). You'll know what I mean if you work with large images (Bitmaps) in Android, then you'd wish you have a better craft at release memory (instead of recycle())
- stcredzero 14y ago
  I am wondering when someone will implement a good Ulterior Reference Count or an Age-Oriented GC for iOS/OS X. These are both hybrids of GC and reference counting that combine the strengths of both. Basically, new objects tend to die quickly, so the overhead of reference counting is generally redundant, and GC techniques like copying collectors tend to excel. Old objects tend to stick around, so reference counting overhead is low. By using a hybrid of both techniques where they are strong, you avoid a lot of overhead: pointless ref-count changing, and pointless scanning of object graphs. The result is something with the high throughput of generational GC with only a fraction of the maximum pause time. https://researchers.anu.edu.au/publications/29505 https://researchers.anu.edu.au/publications/29505 http://www.cs.technion.ac.il/~erez/Papers/ao-cc.pdf http://www.cs.technion.ac.il/~erez/Papers/ao-cc.pdf
  - jballanc 14y ago

akaru 14y ago

Looking through the docs, it does look incredible, perhaps the Perfect® language for my tastes. But the old man in me says it'll never stick.

Apocryphon 14y ago

Interesting, especially given how I was listening to John Siracusa's two Hypercritical talks from 2011 where he points out that replacing Obj-C (or any language) with bridges is insufficient. I hope he might weigh in on his thoughts of eero in the future.

gothy 14y ago

Finally!

SeoxyS 14y ago

Objective-C is hands down one of my favorite programming language: - It's compiled, not interpreted. Even Java and C# are compiled into bytecode for a massive VM to interpret. Objective-C has no VM, it's pure binary + a shared library to implement the runtime. It also uses the very best compiler, clang, which gives incredibly helpful error messages, warnings and suggestions. - It's a strict superset of C. Even C++ does not meet this criteria. This means any valid C is valid Obj-C and behaves exactly the same way, in any Obj-C file. You can drop down levels of abstraction for performance, and can even write assembly if that's what it takes. - It has an amazing and fully supported debugger in the form of LLDB. - It's fully dynamic, allows introspection, duck typing and even monkey patching (with a little effort; method swizzling). Everything is an object, except for native C types. - It takes the right approach to memory management. Realizes that garbage collectors are abominations, and that managing memory is really the job of either the developer or the compiler. - It has the most fantastic concurrency framework I've ever used, in the form of `libdispatch`. Now, to be fair, it's a C library that ought to work anywhere, but practically it only works well on Apple's platforms and using clang. - Apple is moving in the right direction, cleaning up the language, removing annoyances and making syntax more succinct. - Header files. I think I'm on my own in liking this—but I think headers are amazing. They're a succinct and standalone version of a documentation file that is extremely useful to both developers and the compiler. Use them to describe well the public interface to your class, and you don't even really have to write documentation anymore. - Solid design patterns and convention-driven. These are getting better by the day, with the recent addition of closures to the language. There's two major annoyances: - It's often needlessly verbose. Not in the syntax, mind you, which is just fine, but in the naming conventions. For example, `NSArray` has a method called `enumerateObjectsUsingBlock:` instead of simply `each:`. Add that up to every single name, and you get pretty ugly code—and good luck writing it with anything other than Xcode's context-aware autocompletion. - It's tied to Apple's platforms, and well not run on anything else. Now, I'm fine with Apple-specific frameworks and GUI frameworks (like QuickTime or UIKit) being Apple-only, but I'd really love to use the language to write a backend service, for which I'd only need Foundation & libdispatch, for example.

rudiger 14y ago
- It takes the right approach to memory management. Realizes that garbage collectors are abominations, and that managing memory is really the job of either the developer or the compiler. Please elaborate why Objective-C's approach to memory management is Right, and why GC is Wrong.

jashkenas 14y ago

Pretty rad that eero forbids variable shadowing. It would be neat if more languages start doing that in the future... http://eerolanguage.org/documentation/index.html#noshadowing http://eerolanguage.org/documentation/index.html#noshadowing

ufo 14y ago
Err, sounds like a weird thing to do, and as they mentioned, is more likely just a limitation of their inferrence engine. Preventing variable shadowing leaks implementation details from inside functions/blocks and mos tlanguages do just fine with appropriate warnings and so on.

fusiongyro 14y ago

It looks nice, but I can't help but wonder why not go all the way to Smalltalk instead? helper := FileHelper new. "declare variable 'helper' via type inference" files := [] "empty array literal implies mutable" files addObject: (helper openFile: 'readme.txt'). "can group message in parens" files do: [ | FileHandle handle | "all objects are pointers, so no '*' needed" self log: 'File descriptor is %@', (Number)(handle fileDescriptor) ). self handle: closeFile ]. ^ 0 Of course, you'd still have to solve the lack of syntax for defining classes and methods, but there are a couple solutions to that problem out there already.

tbe 14y ago
A Smalltalk compiler for the Objective-C runtime exists here: http://etoileos.com/dev/docs/languages/smalltalk/ http://etoileos.com/dev/docs/languages/smalltalk/
- fusiongyro 14y ago
  Cool. Does it work with Cocoa on OS X?

introspectif 14y ago

Most of the comments here are way off base, focusing on the relative worth of the objective-c language, rather than the value of Eero for developers who have no choice but to use objective-c, regardless of how good they think it is or isn't. If you haven't already - I highly recommend following the link. RubyMotion was somewhat interesting, but really didn't feel like a massive improvement over plain old objective-c, especially once you factor in all the Cocoa APIs. However, Eero looks amazing. The syntax used represents a vast improvement over straight objective-c or RubyMotion. Take a look - it's genuinely exciting.