Philosophy
From Reia
Contents |
Concurrent programming is the future
Multi-core computers are the norm. It's actually harder to purchase a single core system than a multi-core system nowadays. CPU manufacturers are committed to bumping up the number of cores in their CPUs, with Intel already showing a research CPU with 80 cores an a TeraFLOPS of aggregate computing power.
Most languages are not designed to embrace the multi-core future. Erlang has done an excellent job targeting multiple CPUs, and its VM now supports seamless load distribution across all available CPU cores. Reia leverages these same strengths and ensures that programming for one CPU is the same as programming for many.
Concurrent programming requires a paradigm shift
The bad news: the traditional way people program is not well-suited to concurrent systems. There is no way around this simple truth.
The good news: it can still be supported in concurrent systems with some modifications to the way the underlying language operates. If implemented properly, the concurrency tools Erlang provides can be seen as an extension of existing synchronous programming techniques, rather than something completely different.
Reia supports both the traditional synchronous object-oriented programming style as well as an asynchronous approach which allows for concurrent systems. The two can be used in tandem, with objects providing synchronous APIs to concurrent, asynchronous backend implementations.
A language shouldn't get in your way
As a programmer you should spend your time expressing your ideas, not jumping through hoops to accommodate a language. If you spend the majority of your time doing the latter, the language you're working in probably isn't very good.
Languages should be designed to minimize frustration to their users. Things that programmers do often shouldn't require a lot of syntactic clutter.
Most programmers are used to dealing with imperative languages. In the case of Erlang, a programmer is asked to make multiple conceptual leaps at once: from imperative to declarative, from procedural to functional, and from synchronous to asynchronous. Erlang has good reasons for asking you to make these leaps, but for most people this is too many leaps to make at once, and thus Erlang is too "weird" for them to understand.
Reia follows in the Algol / C tradition of languages, and as such, most operators and keywords should work more or less as a programmer of other languages in the same family expects them to.
You don't need an "everything is a..." language
...when you can have an "everything acts like a" language. The "everything is a..." approach has been tried in languages like Smalltalk and Ruby (everything is an object). There's also esoteric languages that push it to extremes, like Unlambda (everything is a function).
In the end, as a programmer you want a consistent experience no matter what type of value you're working with. To that end: you don't need everything to ultimately descend from some all-encompassing master type. You just need everything to be consistent.
Reia provides a consistent experience for the end user, even though the primitive types are separate and distinct from the tools programmers use to encapsulate their code.
Don't build what you can steal
Reia combines the strengths of existing language concepts. The goal isn't to invent new ones, but to provide a mix of existing approaches which provides an easy and painless approach to writing concurrent programs. To that end, Reia feels like Python with a dash of Ruby, and the concurrent programming ideas behind Erlang added to the mix.
Reia also leverages the highly mature Erlang VM and OTP framework. These both provide a bulletproof foundation for concurrent systems which has been highly optimized over the years, particularly in regard to SMP systems. There's no need to build a new VM when an awesome one like BEAM is available.
