Second reason Realaxy Editor provides the comfort and speed of development never reached before

How do we achieve that? Any other AS editor is a text processor. You enter any text and editor suggests if code complies with the writing rules. Our editor does not offer such freedom. You make code, not fiction. So only the context allowed language constructions are allowed by our editor.

If it's possible to place a method in a specific point of code, you just need to press Enter and the whole method template will be created in a split of second. You only need to add its name, acceptable parameters and start creating method body.

If you write if (+space) then the whole condition block will be added. It's not necessary to enter condition parentheses, curly brackets and press Enter if it's obvious that according to ActionScript coding rules the code should be exactly like that.

Consequently, code writing speed increases dramatically.

Worth mentioning, such approach can be unusual at first. But in a few weeks of using Realaxy ActionScript Editor developers just can't understand how there can be any other way.

Limitations approach is widely used in the Editor. And the editor, being aware of language syntax, suggests exactly those choices, which are possible in a specific code point. You only can add method between methods, only add fields between fields, etc. In a method body rules are more complex and choices are more various, but in places, where they're limited, a new code element will be added automatically.

How is it implemented? The Editor does not operate with text, actually our editor is a very complex form for code filling, where you can add and delete elements (fields), move and transform them. In Realaxy ActionScript Editor code looks like familiar text and often behaves like text, but it is a GUI indeed. Incredibly advanced GUI for software development.

Third reason Low entry threshold for beginners

Not many modern developers remember the times, when AS was written in Normal Mode. In those good old days code was added by a mouse click. When Flash 5 exposed Expert mode, which allowed creating code as usual text, it was very unusual, but Flash developers accepted the thought, that it's more correct and it has to be done that way, because they were ready and they became developers.

But back then, I ask myself the question:

— Could I, professional graphics designer, learn how to develop, if at the beginning I was not allowed to code in Normal mode?

— I assume that I would not. I needed to break a designer inside me and start learning basics of development. Then I would need to learn ActionScript syntax and keep it in mind. Normal mode gave me the bridge to pass from simple constructions to more and more complex programs.

Flash Editors authors were absolutely right creating such way of making interactive Flash applications. This is the way, which brought thousands of thousands talented people from related areas to Flash, allowing them to implement their ideas on their own.

Of course, our Editor is not Normal Mode. It's a professional editor with a vast variety of possibilities. Refactoring, language extensions development, etc. But our editor will be the same easy start point for newbies, as the Flash editor was ten years ago.

Because, like that time, it's impossible to add a language construction in a place it does not belong to. If something is wrong — the Editor will point at the error. It's very convenient to learn programming in such a way. You add a construction — great, check the auto complete list — everything is clear, go on. Launch the Flash movie you've just created and understand "I can do it too".

We hope a lot that thanks to Realaxy ActionScript Editor we'll return the days when outrageously self-confident non-coders will stick with Flash, making though imperfect in terms of programming, but very interesting in terms of some other area, things of concept.

Fourth reason Language Oriented Programming (LOP)

Let's get back to us, professional developers longing for fun, money and free time.

When I decided to create an editor, I was thinking only about using language extensions in ActionScript. It's a revolution in programming. The future of programming. Period. This revolution was brewed by JetBrains company, represented by genius programmer Sergey Dmitriev. This is he, who invented these cells, these language aspects and others. MPS is being developed for more than 5 years now, and it quit the Beta phase after 4 years of development.

MPS. Meta Programming System. Our editor uses this platform.

I've got enthusiastic over this idea, when used LOP in one Java-project. I wanted to use extensible languages in ActionScript very much too. And, theoretically, it was possible to use MPS for other languages. But the reality showed that MPS was initially developed and optimized for Java. We had to spend a year to create ActionScript support in MPS. And while Java developers spoilt by good tools just look closely on MPS, we already created a real tool which can be used for Flash.

Now, every ActionScript developer can use that power. I'm sure, that Language Oriented Programming indeed will find mass support, and initially will develop not in Java community but among ActionScript developers.

What's the sense in Language Oriented Programming? It's good old Domain Specific Languages (DSL). Languages for specific data domains.

Language to work with collections? Here you are. Language to work with events — great. Language to work with 3D — challenging idea! We code on languages, specifically created for specific data domains. Now we're not limited by capabilities of universal, basic language. We can create convenient, compact and obvious languages that we need.

But as opposed to text DSL, we can provide top-level support within our editor. Autocomplete, refactoring, type system, etc. Easy to learn, easy to use. Because if DSL is a text, so to learn it we will always become that newbie, who need to remember everything, and no one, except compiler and debugger, can tell us, we coded something wrong. In Realaxy ActionScript Editor the limitation principle works: you may add only something you CAN add. No mistakes and no doubts.

But using our editor is not obligatory to create language extensions. That is advanced practice. You get a set of ready-to-use language extensions with the editor; they're aimed to make your development more effective.

Collection language — the language to work with collections.

Flash has lots of collections. Now instead of working with collections through dozens of cycles and conditions, you can just do it through requests. You may use one code line for something that needed tens of lines. It is clear and quick.

Object Language — language to construct objects.

This language in declarative style allows constructing objects, creating instances, describe their properties quickly. Easy to use, easy to support.

Flow Language — language of application state management.

The language lets you describe easily the state of your system. You describe the status map, subscribe and unsubscribe states depending on transition to some other state. It is a huge development pattern to simplify your life.

Performance Language — language of transformation to more productive code.

All language extensions are transformed to usual AS/MXML before the compilation. It is called generation. During the generation process using this language you can modify the code. It is easy — you just point the construction or condition, by which you search the construction, and specify what it needs to be substituted by.

There are lots of methods to drive-up the code implementation only by using simple replacements. For example, substitute division by multiplication, and you get 40 percent faster code. Using inline functions can increase the speed of implementation several times. There are tens of such methods, and you can create new ways to "pimp" your code. Besides, you may use ready-to-use transformation libraries, import them to your project and speed-up your applications performance.

GUI Language — language of interfaces description.

MXML — is a great thing. But sometimes we'd like to use some alternative GUI libraries. So you need either lightweight framework, or some specific framework, but you want to code your own GUI, using only principles.

GUI Language is based on MXML (it uses the MXMLs' principles of interface construction), but unlike the MXML it only describes interface. By default realization is MXML, but you can substitute it. You can code usual Flex applications on GUI Language and compile them into usual MXML, also you cal migrate from MXML to GUI Language. Also, GUI Language has more compact syntax, than MXML; we refused to use XML as interface description tool. GUI Languages' advantage is also its advanced facilities of code modification and refactoring. GUI Language is easier to extend, than MXML, and we hope, there will be new additional tools to work with it, created by our users.

Fifth reason We develop very fast

Our editor already has an unprecedential set of tools for code refactoring. We've implemented the most complex and important refactorings, available only for developers of most popular programming languages. And we will add more and more delicious things. Many and tasty.

During the programming process usually same activities are performed. We've created lots of "helpers" to simplify this process — intentions, allowing to generate the code quickly.

We don't want to stop. We have lots of ideas to implement. We have enough of these for years. We're going to launch micro-releases of our editor approximately once a month.

More tasks to do are in line now: creating visual tools for UI construction, plug-in architecture language support, compilation acceleration and network services deployment.