Quick Reminder How to Develop DDT

As I ran in to problems as I tried to set up my Eclipse environment in order to develop the DDT plugin, I decided to make a quick reminder how the installation should look like. My development environment is Eclipse Indigo (3.7.x) on Windows.

  1. Make sure that the Eclipse is up-to-date completely. (Help/Check for software updates)
  2. First I need to install the PDE, the plug-in development plug-in for Eclipse. This is easy, however there are always problems with the naming. So, open up Help/Install New Software dialog from the menu, and select the repository Indigo – http://download.eclipse.org/releases/indigo. Untick the Group items by category and search for the phrase: “Eclipse Plug-in Development Environment”. Install it.
  3. DLTK 3.0: This is the default version line for Eclipse Indigo, so we should find it also in the eclipse repository. Help/Install New Software dialog, http://download.eclipse.org/releases/indigo. Untick the Group items by category and search for the phrase: ” Dynamic Languages Toolkit – Core Frameworks”. Install it.
  4. Since the original Descent project exists on an SVN repository, I need to install the Subversive SVN Client for Eclipse. In the same dialog as before, I check for the phrase:   “Subversive SVN Team Provider (Incubation)” and go.

As I expected EGit became part of the Eclipse Indigo project thus no additional installation will be required. Yet.

I need to be careful of the import order of the related projects. What I need accordingly to Bruno’s tutorial is to import the descent.compiler project from SVN. In the Package Explorer’s context menu click on the Import and select the SVN/Project from SVN repository. Stick the http://svn.dsource.org/projects/descent URL to the repository address and select on the resource page the trunk/descent.compiler project. Ta-dam! Oh, wait… the first time when you want to import from SVN, the subversive team provider plug-in will find that you don’t have a connector so, there’s a need to install one. After several try, I found that the SVNKit 1.35 works just fine to use.

Now comes the real deal, the source code of the DDT. Luckily, it’s really simple: Again, in the Package Explorer’s context menu click on the Import, select Git and in the upcoming dialog, click on the Clone… button.  There it is: paste the URL: https://code.google.com/a/eclipselabs.org/p/ddt/ and select the all the branches (well, the branches themselves is a bit funny, because it still seems that I need to add a new remote in order to get the other branches, but heck, it didn’t kill anything). Note, that the clone isn’t my google clone address, I’ll add that later as an upstream clone while Bruno’s one gonna be the downstream update site.

At the remote naming, I chose to use the bruno-* (* = branch name) format, so it’s gonna be easier to sort them. After all these, the package explorer gets littered with projects.

Why D?

This blog is dedicated my work on the D Programming Language. Though my self had not even worked on a project and coded serious stuff in D I can see the possibilities and the real need of such a programming language. If you don’t know what is D, please refer to the official website.

I think when Walter Bright  come to the conclusion that there’s a need for a multi-paradigm, imperative, native language, he made the right choice. As a C++ developer myself, I found several frustrating issue with my main programming language and with all the efforts of the recent C++11 standard these pains doesn’t seem to pass. I don’t want to bash C++: it’s a nice piece of language which stays prominent for many years if not decades, but I think today, in 2011 we need to prepare ourselves to learn from the mistakes of the past, and have a clear start. C++ is dragging many compatibility issues with it self along its long way, and therefore a new language design, free of such a heavy burden could mean a fresh start in the native development.

As of today, the most prevalent programming languages in the native arena is C and C++. C is good as it is, restricted system programming language which fit most of the hardware environment. C++ on the other hand, though it made an astonishing progress with the C++11 standard, has major flaw: it just doesn’t hold the challenge against the world of Java and C# world. These programming languages became success not because of their revolutionary new technology but from rather the fact that they can keep the developers happy and enthusiastic. All this is because it was easy to produce a wide variety of coding tools that makes the development fun. In order to maintain the momentum of the native development, we need to get the fun back to the native development.

C++ unfortunately can not offer such an easy entertainment. As a project is getting more and more complicated the build time grows enormously. It desperately calls for a module system. The parsing is difficult because the extent and ambiguity of the C++ grammar. The compiler can be hardly manipulated, the reflection system is partial, and a language level garbage collector would just make life easier for everyone if the coder can decide to not use it in certain, well limited scenarios.

In this series of blog post I document my experiments, understanding and contribution to the language D.