Ix: assumptions and limitations

Warning: this is superseded! Please visit the Ix site instead.

Here are some fundamental assumptions, with rationale.

Different languages fit different tasks and spaces. No language is truly universal, and it's best that Ix doesn't try to be universal either... At least not in v0.1.

These assumptions, then, can be given as sufficient reasons not to include a feature. (I still have to do a post on Ix goals and targets.)

1. Ix is imperative.
   Functional features are easier to add to an imperative language than vice versa. A pure functional algorithm can be written naturally in an imperative language with good support for functional programming, but an imperative algorithm is not at home in a functional language. And there are many imperative algorithms and data structures and programmers out there.
2. Ix does not promise to closely match the type system of any other language.
   While Ix should collect existing good ideas, it should also be bold in discarding existing methods if we can do better. Ix can include good FFIs, but they will probably have some performance penalty. Ix will not be able, at first, to trivially expose Ix objects to in-process code written in other languages.
3. Ix will attempt not to bind itself too tightly to any one runtime or platform (e.g. VM).
   New compiler backends will be welcome. Highly platform-specific features will be placed in platform-specific libraries rather than the standard APIs. Features that work on most but not all platforms will be placed in the main library, and will indicate to the user if they are unsupported. (This is the Python approach to the subject.)
4. Ix will not sacrifice usability for performance.
   Our performance goal is being able to replace the 95% of software that uses 5% of CPU time. In practice, good library and application design can do wonders for performance in any domain that does not have to run time-consuming calculations.
   
5. Ix will tend to use 'mainstream' syntax for mainstream features unless there is a cost to usability.
   The trivial things everyone is used to should not change without good reason: ';' for statement termination, quote marks for string literals, '.' for attribute access, {} for blocks of code, () for function invocation, <> or [] for metadata.
   Ix may introduce indent-delimited syntax in the future, but not in the very first versions. Such an addition would in any case not change the semantics of existing code, so it can be deferred. (Rationale: it's a pain to spec and code in the parser. Yes we know how to do it. That doesn't mean we have to.)
6. The Ix design will rely a lot on generating custom code at runtime.
   Any target platform must support that, ideally with the same performance as precompiled code (by using JIT compilation to begin with, or by running an offline compiler and loading the resulting module).