Tag - parnas

Entries feed - Comments feed

Last entries

Tue 09 Feb 2016

The need for a new editor mixing texts and graphics

Every time you do some programming, you need a text editor (except when you program in graphical languages like SCADE). Some long-time well-known ones are Emacs (which I use) or VI. Such editors are focusing on their editing capabilities (you can edit huge files without any issue) and their ability to be programmed, for example they have dedicated modes to edit C language files or OCaml files. They are very versatile, you can find modes for obscure languages or even have dedicated mode for proof assistant (e.g. ProofGeneral for Emacs).

But those editors are focusing on the text. I think most if not all the time, they are using regex to match some specific keywords of a program and then color or indent them in a specific way, but they don't understand the program, e.g. what is a variable, an expression or a method call. Therefore people have proposed another kind of text editor dedicated to programming languages, like Eclipse or IntelliJ IDEA. Such editors are very powerful: they understand the program structure, propose useful contextual helps (like giving parameters of a method call) or help in code refactoring (e.g. encapsulating an object field so it can only be accessed to getter and setter methods).

Of course the distinction is not so binary: textual editor like Emacs or VI have advanced modes than can understand program structure and do refactoring.

But both kind of editors have a strong limitation: they focus on programming language and most of the time they are unable to mix text, graphics or other layouts like tables. This is not entirely true for Eclipse, but I'll come to that later. So, why would you like to mix text and graphics when editing a program? Because a program is more than just text! Wouldn't be useful to use a quick drawing to explain an algorithm? If you program manipulates state machines, wouldn't be useful to directly draw state machines and automatically convert them into code? That would certainly avoid some kind of programming errors. One could also imagine tables to specify the behavior of a function like Parnas tables (which could be even considered as a formal, albeit readily understandable, specification). Or one could imagine graphically draw the architecture of the system, then dive into usual text code to edit the software modules.

Such kind of editor exists, like mbeddr for C code or some Eclipse plug-ins like Rodin for Event-B formal language. But again I see a strong limitation to their use: they are storing the edited source code into a model generally saved in an XML file. It is very difficult to handle such XML files with usual programming tools. For example handling them in source control tool like Git is a nightmare, with merges very frequently corrupting the XML files.

So what would be the ideal programming editor mixing text, graphics and tables? I won't give precise specification :-) but only sketch here some characteristics:

  • Versatile, programmable, so as to handle various programming languages like Emacs or VI;
  • Able to directly draw graphics and edit tables, in a WYSIWYG way. For me this is a crucial point. Wiki-like approaches with special markers are not user friendly and practical enough. The ability to program the editor would allow transforming graphics or table into code text and vice-versa;
  • Store edited programs only in text files (and of course probably some binary files for graphics). One would probably need some tags stored as program comment to reference graphics within the code text and display it properly within the editor;
  • Hyperlink capabilities, to be able to navigate within the code, e.g. jump from a graphic element to the corresponding code text, maintain index and reference tables (for code documentation), ...
  • Fast, low on memory, disk and CPU resources. Everybody that has already used Eclipse understands what I mean. :-)

As far as I know, such a tool does not exist yet. If you have hints or even tool name that would be able to do what I would like, I'm very interested. ;-) Tell it to me through this blog comments or directly.

Tue 02 Feb 2016

"Software Aging"

In 1994, David L. Parnas published a provocative paper called "Software Aging". I recently read this paper and found it remarkably accurate!

Software is digital, so how could it age? Parnas identified two different causes for software getting "older" when time passes:

  • "Lack of Movement", i.e. the inability for the software to match evolving user or environment expectations. A computer environment evolves constantly; language and compiler changes, operating system and library changes. But this is also true for user expectations: in the 70' people expected a text interface, in the 90' a graphical interface and now they want a web interface accessible from any device or an App usable on their mobile devices;
  • "Ignorant Surgery", i.e. the inability to correctly adapt the software as time passes. When somebody modifies the software, probably not the original developer(s), she/he won't probably understand its design and probably modify it as she/he understand the software. At this point understanding the software means understanding the original design as well as the introduced new design. After several of such modifications, nobody can understand the software and in some cases it should be rewritten from scratch.

Although this idea of Software Aging was proposed 22 years ago (and appeared 47 years ago, the famous "Software Crisis", according to Parnas), it is striking to see that it is still true. When I see it takes nearly one year to make a new release of the Debian system, I view it at software aging at work: the environment evolves in unexpected ways and each software should be adapted to match its new environment. And sometimes, applying those changes can be very difficult and lead to Ignorant Surgery, like the famous Debian OpenSSL bug.

How to avoid this software decay? Parnas gives some advises, I just summarizes them here:

  1. Design for change, i.e. apply usual Software Engineering principles like Information Hiding, abstraction, separation of concerns, proper use of object orientation, etc.
  2. Document! Document your design, your choices and document for the people who'll come after you work on the software.
  3. Review! Review the design, code or other software artifacts by other members of your team, by experts in the domain on which your software is applying, etc.

Even for actual software, above principles can be applied, retro-actively. Parnas gives some advises.

All current software are aging. Hopefully, 22 years ago, Parnas gave some very good advises on how to develop and maintain software to limit this phenomenon. Listen to him, apply them.