Pinderkent

Although meant in a humorous fashion, we do unfortunately see usage scenario descriptions very similar to those in the third image of this comic in the real world. Often times, we see these produced by analysts who have little to no programming experience. They end up providing a multi-level, point-form summary of the steps the software system needs to perform. But like shown in that comic's example, this quickly becomes unruly. Things often get even worse when such a scenario description accompanies a UML activity diagram or a UML sequence diagram.

We should first consider the role of a typical analyst. Their main task is to convey business concepts and processes, as well as the needs of the users, to one or more software developers. In many ways, this mirrors what the software developer eventually does. Namely, that's specifying a certain course of action that is to be performed by the computer. In the case of a computer being the target of the instructions, ambiguity is really not an option.

Over time, we have developed a variety of programming languages to help ease this task. At a higher level, UML has become one of the most common ways of modeling a software system. Unfortunately, it usually takes far too graphical of an approach. To properly convey all of the necessary information, the analysts must annotate the UML diagrams with the aforementioned point-form scenario descriptions. But like mentioned earlier, these textual descriptions often end up becoming difficult to work with. Even descriptions with just a couple levels of branching become awkward.

The analyst needs to be using a more rigorous textual medium to describe the problem to the software developers. In essence, what is needed is a form of pseudocode. Unfortunately, for analysts without much practical programming knowledge or experience, a very ad hoc approach is often taken. Sometimes this pseudo-pseudocode becomes just as difficult to work with as the point-form descriptions.

Some of the best analysts I've worked with were former developers. They were able to take a business problem, and rapidly break it down into pseudocode that was quite similar to C++ or Java, for instance. The more rigorous specification and syntax of languages like C++ and Java made them useful for describing high-level business or usage concepts in a consistent manner. Of course, the pseudocode itself wouldn't compile and couldn't be used directly, but the ideas were presented in a form that the developers could ingest very rapidly. They were able to in turn create a production-ready software system that better met the needs of the users.

I always feel weary working on a project where the analysts have limited hands-on programming experience. Those are the projects that often have the most communication difficulties between the developers and the analysts. In such situations, it is ideal to even have one of the developers come and work as an analyst. Instead of coding or designing the implementation itself, this person acts as a filter between the analysts and the developers. They take the ideas of the analyst, perhaps presented in point-form notes, and distill it down to a pseudocode more digestible by the developers.

It's unfortunate that despite all of the effort put into UML, little of practical value has been produced in this area. There have been some efforts put towards the Object Constraint Language, for instance. But OCL is somewhat limited in its scope. Perhaps the only real solution is, after all, to have analysts who were developers at one point, or who at least received much of the same training as a developer, and capable of writing code.

I read through an article today that suggested an idea for a Web site where a user can specify a task in a programming language they know, and the site tells them how to perform it in some other language.

This is an interesting idea, and no doubt could make for a useful site in some cases, but would likely run into problems creating the relationships between languages. Even something as crucial as string handling can differ significantly between different languages. C treats strings as arrays of characters. C++ treats strings similarly to C, but also has for example the std::string class for representing strings. Java treats strings as an object. Erlang treats strings as lists of integers.

So operations that are available in one language may not really have an immediate equivalent in another language. Likewise, the approach taken when using one language may be completely inappropriate, in terms of performance or memory usage, when using another language. Such a Web site would need to ensure that these differences and the potential risks were clearly stated. But otherwise, I think it might actually be useful, even if the article suggesting it was somewhat in jest.

Today I saw an article from a young developer asking whether there is merit in the arguments that suggest object-oriented programming can be considered harmful. Having watched the rise of OOP and having seen and used its techniques for many years, I have to say that it does pose a risk.

As with any tool, OOP has its dangers. One of the most significant is that it encourages a mindset that makes one think objects are the best, and to some extent the only, way of representing a software application. This is, of course, not true at all. If all you need is a function that takes some input values and returns some output values, there's no need to bring objects into the picture. While some languages, like C++ and Python make this possible, other widely used languages, notably Java, force the developer to create a new class.

The belief that classes and objects must always be used is a dangerous one. Add in design patterns, and we can end up with even more problems. Both can lead to code bloat, which leads to complexity and maintenance headaches. One of the best examples of object-orientation gone horribly wrong is that of the RequestProcessorFactorFactory class of the Apache XML-RPC codebase. It's pathetic to look at that code.

Twenty to twenty-five years ago, we were told that OOP would make our lives as programmers easier. Representing our world in terms of classes and instances of those classes would allow for our software systems to become less complex, more easily managed, and developed more rapidly. To some extent, this is true. The abstractions OOP provides us can often be useful. But far too many developers have fallen victim to the mindset that design patterns are a must, and objects are a must. And in the end, I think we are worse off in many cases. What should be simple and straightforward becomes muddled by the introduction of object-oriented programming. Unfortunately, some of the most widely used programming languages today have made it difficult to avoid the unnecessary object-orientation. And what's worse, the much of the codebase we have around today will be around decades from now, making it a problem that will be with us for generations of programmers.

A few days back a colleague forwarded me a link to an article entitled Attacking PHP. It goes through a list of the problems associated with PHP. And based on my past experiences dealing with PHP in corporate environments, the analysis in that article is spot on.

In short, PHP is just not a suitable language for serious Web application development. I've seen it used for a wide variety of Web apps at numerous companies, but the results have always been negative.

As the article mentions, one of the main problems with PHP is that it's sloppy. The standard library naming scheme is one particularly problematic area. This in turn promotes sloppinesss elsewhere, namely for those developers who use PHP to developer their own applications. Try as a developer might to keep his or her code clean, the use of standard PHP functions will begin to introduce inconsistencies.

The mixing of content and presentation is of course another very sore point when using PHP. Although it is possible to avoid this, we don't always see this in reality. It becomes very convenient in the short term to mix those two distinct layers. But once an application starts to mature, nothing but problems arise. For instance, one team I worked with would continually break the logic of their PHP Web application when making cosmetic changes, since the business logic was so intertwined with the presentation code.

And when dealing with the Web, security is paramount. The Web is a very hostile place, and so we need to use programming languages that help enforce good software design. In this respect, PHP's dynamic nature is unacceptable. While it allows programmers to rapidly create Web applications, these applications are often full of security glitches. Furthermore, type-related errors all too often cause problems when using a PHP application. Users are not impressed when an application crashes due to a failed type conversion because the PHP developer wrote sloppy code.

When you combine the factors above, you end up with a language that also promotes the development of near-unmaintainable code. Even if a PHP application is initially developed by somebody with patience and discipline, this level of care must be maintained throughout the entire lifetime of the PHP application. If the development standards drop for even the slightest of code, it is quite likely the PHP application will become a mess quite soon. Although languages like Java and C++ are not immune to such problems, they do tend to be far more resilient than PHP.

In short, PHP is just not a language that should be used for most large-scale applications. Although it may have its place for small Web sites, bringing it beyond that is just looking for trouble and heartache. Basically every time I have seen PHP used for real software development, the result has been spectacularly horrid.

Although it hasn't (yet?) caught on much in industry, anyone who follows modern computing trends will no doubt have heard of D. Its Web site describes it quite nicely: D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. The D language is statically typed and compiles directly to machine code. It's multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It's a member of the C syntax family, and its appearance is very similar to that of C++.

There exists a listing of the language features of D. One thing we should notice rather quickly is how it acts as a solid bridge between the worlds of procedural, object-oriented and functional programming.

Although it may not have the rigorous mathematical backing of a functional language like Haskell, it does bring over many of the most practical features. For instance, it offers garbage collection, closures, nested functions, type safety, lazy function argument evaluation, compile-time function evaluation, generics, implicit type inference, and a lot more.

But unlike Haskell, it also offers a C-like syntax that is no doubt familiar to a great number of C, C++, Java and C# developers. This is where a lot of D's power lies. It brings many of the benefits of functional programming, while also allowing developers to continue to use the syntax they're familiar with.

A number of people within the functional programming languages community say that syntax is irrelevant; the semantics are what truly matter. That's a shallow view to take. When it comes to developing large software systems in a rapid manner, reuse becomes a necessity. That includes not only code reuse, but also the reuse of previously-acquired skills, such as the quick comprehension of code with a C-like syntax.

It's becoming clear that we will need to start making use of some of the features traditionally offered by functional languages if we want to continue developing more complex software. D will surely allow this to happen, likely to the degree initially necessary to truly realize the benefits of such an approach. But we have to ask, will a transition to purely functional languages ever be necessary if languages like D offer the functional features in a manner that is sufficient for most developers?

When considering the software development landscape at this point, I'd have to say that many developers will be swayed towards D, rather than going all the way to Haskell, Standard ML, OCaml, Erlang, Common Lisp, or a host of other functional languages. D may very well offer the best trade off between code/skill reuse and productivity increases from functional language features.

If D keeps improving as it has been as of late, we may very well begin to see its adoption on a far greater scale. It took a number of years for languages like Ruby and Python to really start to take off. D may be just around the corner.