We’ll start by creating all the infrastructure for this project — the source repository, bug tracker, nightly builds, update sites, and the initial application that can automatically update itself.
We’ll also have to learn more about your language and the people who will be using it, so expect a lot of communication.
Before we can provide anything useful to you, we’ll need a parser for your language im- plemented in Java. If you happen to already have it, we can start by reusing it.
Error recovery is an issue, however. An interpreter can stop at the first error it encoun- ters, but if IDE does the same it won’t be able to provide any code assistance below the place of the first compilation error (and in many cases, won’t provide any code assis- tance at all because the code which is being typed is not yet valid). We can get away with this at first, but on later stages it’s best to modify (or rewrite) the parser to handle error recovery.

A typical DLTK-based IDE looks like this.

When we have a parser, we can implement syntax highlighting, outline view, code fold- ing, a non-type-inferenced (textual) search, and code editing assistance (brace match- ing, auto-closing of braces, automatic indenting, templates).
When all of this is done, you’ll have an Eclipse-based IDE that is as good as (or better than) any good text editor with proper highlighting configured.
To run your programs from inside the IDE and output the results to the console view, we need to build a launching support. This is one of those things Eclipse makes easy — takes less than a week.

A special view that allows to interact with the interpreter interactively, with code assis- tance and documentation access.
An interactive console allows quick experimentation with language constructs. Also, using “Paste to Console” command, it is possible to execute the program code in the console, and then interact with the results.
We also have our own “worksheet” concept which we can use instead of the interactive console. It’s a very promising solution which merges an editor with a console, allowing to quickly test any code you are typing (just like what Maple/MATLAB does for mathe- matics code).
This will be a major step, allowing us to implement smart code completion. The com- plexity of type inferencing implementation depends a great deal on the trickiest details of the language, so we’ll need a complete manual (and, better yet, the sources of the interpreter) to estimate this more or less accurately.
This step includes implementation of code completion and smart navigation facilities based on the type inferencing engine. Smart navigation includes ability to navigate to method/class declarations, to view call hierarchies and type hierarchies.
Documentation access (displaying class/method comments) will also be implemented on this step.
Code assistance is the first thing that brings a major advantage to using an IDE over editing the sources in a text editor. However there are more features that help boost the productivity and quality of the developments, and differentiate a modern IDE from ordi- nary text editors.



The next big step is to implement code manipulation facility based on the AST (abstract syntax tree) of your language. This means that our IDE will be able to modify the source code, and enables us to implement convenient local refactorings called “quick fixes”.
Examples are:
“assign this expression to a new local variable”
“assign this argument to a new field”
“convert this local variable into a field”
“add this extra argument to the signature of the called method”
There are many more possible quick fixes, some of them being language-specific. Ideally we should watch your developers work, take note of repeated operations, and turn them into quick fixes. We cannot do that from here; however we’ll do our best by talking with your existing developers (if any) and using our own experience with similar languages.

Unlike quick fixes, global refactorings affect the whole program, and thus each refactor- ing needs special processing to determine what changes need to be done.
Examples of the global refactorings are:
“rename method”
“rename class”
“move static method to another class”
“extract some methods and fields into a new base class”
“pull up some methods and fields into a base class”
“push down some methods and fields into derived classes“
“create a new factory method and turn all class instantiations into calls”
Similar to quick fixes, the exact set of refactorings is a question to study and discussion.
Each refactoring needs special careful coding to make sure it leaves the code with exactly the same semantics, so the length of this stage greatly depends on what refactorings we’ll decide to do.
A usual problem with dynamically-typed languages is that most programming errors are often only found at run time. However, employing the type inferencing engine, the IDE can calculate missing type information and diagnose many error conditions without running the program.
Here are a few out of many examples of the error conditions an IDE might be able to
detect:
“the called method does not exist in that object”
“incorrect method arguments”
“unreachable code”
“a conditional expression always evaluates to false/true”
“the reference might be null”
“the thrown exception is never caught”


IDE debugging support is a very nice thing to have.
If you are doing / planning to do automated tests for your scripts, we can integrate a test runner into the IDE that would allow the developers to quickly launch tests, glance through the execution results and analyze failure stack traces.
There are Eclipse plugins for many version control systems, but they are of varying quality. We can include a plugin for the version control system you’re using into our application. If you happen to be using a rare or in-house custom version control system (we actually had customers who did), we can implement a plugin for it. Or, if the existing plugin for your favorite VCS is missing some important features, we can implement the necessary changes.



The application we’ll build will be able to update itself from a central location. If you are going to have a small to moderate install base of the IDE, this should cover your update needs.
We will of course also properly package the application on all platforms (build a Windows installation program and a Mac OS X .dmg for the application, optionally also Linux packages if you need them).
We can also create a custom enterprise deployment solution should you need one.
Depending on how the language fits into the activities of your company, the IDE might serve as a platform for integration with the entire toolset you are using. We can implement various levels of integration, starting with a simple menu items that runs an external tool with configurable parameters (already part of Eclipse), and ranging to a custom user interface seamlessly (and invisibly) communicating with a specific tool.
We can also handle any other features you might need from the IDE.
We don't know a thing about your language at this point. However we want to give you an idea of what to expect, so here's a very, very rough estimation assuming that:
| Feature | Man-weeks |
|---|---|
| Parser | 0–6 |
| Syntax Highlighting, Outline, Folding, Search | 2 |
| Automatic Indenting, Bracket Matching | 1 |
| Code Templates (Snippets) | 1 |
| Launching | 1 (actually less) |
| Debugging | 6–20 |
| Testing Integration | 1–3 |
| Type Inferencing | 6–16 |
| Code Completion, Documentation Access, Smart Navigation | 2–4 |
| Interactive Console | 1–4 |
| AST Rewriting (required for quick fixes and refactoring) | 4–8 |
| Quick Fixes | 2–4 |
| Refactoring | 4–12 |
| Static Checking | 4–12 |
Your specific case might significatly differ from what is listed here.
Contact us to discuss how we can help.