Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

  (email not shown publicly)

Journal of Alias (5735)

Monday January 04, 2010
09:28 PM

Padre in 2010 - The year Padre becomes a team player

[ #40077 ]

In 2008 the Padre project was about building a large development team, with the actual writing of the editor being almost a secondary task (albeit an important one). We knew the actual coding job was utterly immense and too hard for just the few people initially involved to deal with.

A lot of the work on heaviest work on the editor in 2008 was on deep subsystem stuff so that we could more easily recruit more people, like the Config/DB API, the Plugin API, the Locale API, and the basic distribution structure and code layout. And in the process we made enough of the actual editor that people could Understand what we were building.

In 2009 the Padre project took that team building success and built the editor into something we can now honestly call an IDE without our inner pedants cringing.

There are still various problems to solve, lots of rewriting of shitty first implementations to do, and "essential" features to add. An IDE is an Open Problem, and so that is never going to change and there will always be More Things To Do.

But I think it's reasonable to say that we've now built an IDE that the Perl community can call its own, and an IDE that you won't want to leave once you get used to some of the ways in which it excels at Perl development.

In another few months, we should be at something we can reasonable use as a part of the default Strawberry install for the upcoming all-in-one Strawberry Professional distribution.

However, for the most part Padre still lives in a mythical fantasy world where there is only one developer, only one host, and only one desktop. It is still, primarily, a tool for the individual developer. And now we're finally in a position to do something about it.

In 2010 the Padre project will evolve from an IDE into a Collaborative IDE. This isn't something that will happen by fiat. Nothing in Padre happens by fiat, and there is no roadmap.

But if you use Padre on a regular basis, you can see that the place where the most development time is being "wasted" now has now clearly moved from working with Perl code to working with projects, teams, and the internet.

In 2010 you will start to see some of the following:

1. The rise of Policy

One of the biggest themes in Padre is the concept of "Intuition", that your editor should recognise (reliably) what you are doing and adapt to it without having to be told, and in a way that doesn't remove freedom in the process.

Padre already can recognise projects without being told where they are, identify the files and assets in a project without being told where they are, and save files without you saying where. It knows about tabs vs spaces warfare, it knows what language you speak, and it knows how to distinguish things you personally prefer from things you happen to be doing on the current machine.

In 2010 Padre will learn about when it is that the needs of the team outweigh the needs of the individual, and how to selectively apply preferences and intuition differently in different open files, based on the specific preferences of different projects.

You will be able to define, at a project level, rules for your project that Padre will automatically follow, such as spaces vs tabs, perltidy rules, perlcritic preferences, and so on.

This is especially important for making Padre more relevant in corporate environments, where adherence to coding policies and standards are essential.

2. The demise of the host

Even though it hasn't been used to any great effect as yet, Padre has always understood that some configuration is about the user, and some is about the system.

In 2010 Padre will finally start to use that information. A 4th year student team from the University of Western Ontario is currently implementing a synchronisation client/server for configuration data, similar to Mozilla Weave or Google's older bookmark sync.

This will allow all your personal preferences to migrate across multiple installations automatically, without getting mixed up with data that only refers to the machine you are currently working on.

3. The push towards Portable

Another area that I hope to see movement on this year are configuration and GUI improvements to make Padre much more tolerant to changes in the underlying operating system.

While many applications do not support this, I'd like to see Padre automatically adapt to changes in screen position and resolution, mounting and dismounting of drives, and a variety of other crazyness that developers often do in the process of creating applications.

This tolerance and adaptation to screen geometry errors should also allow better configuration of windows and dialog positioning, so that you can more easily tailor the layout of Padre to your particular multi-screen developer setup.

4. The swarming of Collaboration

Finally, the experimental Swarm plugin is (after a long gestation) starting to get closer to producing a usable collaborative communications subsystem that can be used as the basis for chat, file sharing, remote peer review, and other collaborative goodies.

In 2010 Padre should start to take advantage of some of these new capabilities to add new and interesting real-time "Intuitive Collaboration" abilities (which should be quite interesting at conferences and hack-fests).

In summary, it's looking like a great year for Padre, and by the end of the year Padre should hopefully be starting to become the corporate Perl editor of choice.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.