Many Cocoa programmers, myself included, want a more modern programming language than Objective-C, and a more modern programming environment than Cocoa. There's been some talk about what would better fit the bill, and engineers are ready to build that solution, but the question first needs to be answered – what are the most important problems to solve?
I've created the following unordered list of hypothetical goals for improvement to Cocoa/Objective-C, and would like to see how important each one is to the community. If you're interested in sharing your opinion, please fork this gist and order the below list. Feel free to add anything that you think might be missing.
Thanks!
- Functional programming, where function application is the main way to invoke code. This does not refer to using objects in a functional style.
- Referential transparency, also sometimes known as purity or immutability.
- Easy parallelization, meaning it should be easy to make code run concurrently without ill effect.
- Algebraic data types, in addition to or instead of Objective-C objects and inheritance.
- Statically typed, to catch type errors at compile-time. This does not necessarily imply a C-like type system – many modern languages support type inference, among other things.
- Powerful metaprogramming, to automate code generation or extend the language with itself.
- Easy to learn (although subjective, it's still interesting to rank it against other goals).
- Self-hosting, where the toolchain is written in the language/environment itself.
- Compiled, instead of interpreted. This could mean compilation to an intermediate language (like Objective-C, C, or LLVM IR), not necessarily machine code.
- Performant – in other words, how important is performance relative to expressiveness and flexibility?
- Not Cocoa-specific, so that it is easy to port or slightly modify code to run without Cocoa frameworks. This mostly just implies the use of a language that already exists and is used for other purposes.
- An existing body of open source code, available for use within a Cocoa project.
- Can be invoked from Cocoa code – not having this implies always invoking Cocoa instead.
- Can invoke Cocoa code – not having this implies always being invoked from Cocoa instead. Note that invoking Cocoa and being invoked from Cocoa are not mutually exclusive (but one is necessary).
- Can define Objective-C classes, protocols, categories, etc. in the language itself. This doesn't imply anything about being able to link to custom Objective-C code.
- Usable for AppKit/UIKit GUIs, in addition to being usable for a model layer (which is a requirement).
Note that this list does not, and is not meant to, capture the advantages and disadvantages of each line item.
@jonathanpenn Thanks!