New Generation of Software Development

Transcription

1 New Generation of Software Development Terry Hon University of British Columbia Main Mall Vancouver B.C. V6T 1Z4 ABSTRACT In this paper, I present a picture of what software development will be like ten years down the road. I believe software development will continue to move towards higher level of abstraction, closer to human languages and communication. I envision a seamless integration of aspect oriented programming, domain specific languages, generative programming and intentional programming, along with more sophisticated development tools to complement the changes. 1. INTRODUCTION Software development practices have moved towards a higher level of abstraction as compared to ten or twenty years ago. Programming languages are more high level; development tools are becoming more sophisticated and more integral in the process of software development; crosscutting concerns are addressed more effectively and in a more modular fashion. I believe that the trends from the past ten years will continue, integrating aspect oriented programming, domain specific languages, generative programming and intentional programming seamlessly. Tools will continue to evolve and ultimately become an indispensable part of software development. I will try to support the above claim in the rest of the paper. The rest of the paper is organized as follows. Section 2 gives a brief description of software development trend in the past ten years. Section 3 describes my vision for the future in programming languages. Section 4 describes my vision for the future in software development tools. Section 5 describes adoption process I envisioned for what I have proposed in Sections 3 and 4. Finally Section 6 gives a summary. 2. PAST TRENDS To get a better view of the future in software development in the next ten years, let us first look at the innovations of the past ten years. 2.1 Aspect Oriented Programming Object oriented language only allow one core decomposition of a Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.. piece of software into a hierarchy of packages and classes; however there are many features of the software that crosscut the core decomposition, causing code implementing this feature to be scattered throughout the software. Aspect Oriented Programming surfaced to provide a solution to this scattering problem. It uses aspect, which consists of advices that apply to code that is matched by the corresponding pointcuts. These advices are woven by the provided weaver to the base source code wherever pointcuts are matched. If location to weave an advice is undecidable statically, dynamic checks are added to all probable location in the base code. Aspect Oriented Programming provides effective modules for crosscutting concerns, as specified with aspects and pointcuts). It also provides an automated weaving process. The woven code, along with the help of any optimizations that a sophisticated compiler will perform, is expected to perform as good as if a programmer was to write the base level code himself. Also woven code is compatible with base language executable, making adoption of this technology easier, since no additional software or hardware is needed to incorporate the change. Even though having aspects to separate crosscutting concerns from the code of the core decomposition is ideal in most cases, there are still time when a developer would like to actually see what the woven code would look like, or at least to have an idea of what it will look like. Without adequate tool support, woven code can not be easily displayed. Even with tools that are available today, where there is an indication (an arrow) at locations of code that match an advice pointcut, it can still be quite tedious to navigate through all the codes that an advice affects. I believe that better tool support can solve this problem, and will be discussed further in Section Intentional Programming Intentional Programming can be credited to Charles Simonyi. He proposes that programmers should be able to express their intentions explicitly in their code, rather than being limited by the language features, implicitly expressing their intentions through layers of unnecessary code [1]. Intentional Programming uses intermediate language as the canonical representation of code. Instead of storing plain ASCII text, Intentional Programming stores AST structure [2] that represents intent. Developers interact with these specialized ASTs, which more closely correspond to how a human thinks about a program. Since the code more closely reflects the design, there is no need for extra documentation, which requires extra resources to create and maintain and usually becomes outdated after code/design modification.

2 The idea of coding using intent is a great idea, since it gives user a higher level of abstraction to reason with, reducing time to translate a human thought into code and also the time to translate from code to human thought (in the case of reasoning about design from code). One of the reasons I believe that Intentional Programming has not become more widely adopted is because it stores code in its specialized AST structures. This means that once a team of developers adopt this technology, they cannot change their mind about the technology without losing everything that they worked on when they were using the IP technology. In other words, there is no incremental adoption for this technology, which is integral factor in the decision process of adoption in industry. 2.3 Domain Specific Language Domain Specific Language allows developers to reason in a higher level of abstraction. Since domain specific knowledge is already incorporated in the construction of the domain specific language, it is unnecessary for a developer to reiterate domain information again in his/her own code. This, similar to Intentional Programming, allows developers to reason and understand programs written with a domain specific language quickly, since they more closely relate to how they reason about the problem. There is no doubt that given a domain specific language, programming does become easier, especially for novice or interim programmers. Code becomes more concise and, like intentional programming, it reflects more closely what the programmer s thoughts were when he/she was trying to solve the problem. However, designing and implementing an adequate domain specific language is very difficult. A good domain specific language deals with common cases easily, but also tries to keep the language syntax as simple while relating to the domain as closely as possible. Also this language has to be general enough that more than one project can take advantage of the domain knowledge. This can cause the language implementation to explode in size; therefore it is unrealistic for each project team to design its own domain specific language from scratch. 2.4 Generative Programming Generative Programming involves a generator, which takes a set of input and generates code (usually at a lower level of abstraction then the input language) according to the specification of the input. The idea of generative programming incorporates a subset of domain specific languages. The input file to the generator is written in a language (the domain specific language) so that the generator can have enough information, along with its built in domain knowledge, to generate adequate base level code that achieve what the input file specified but without developers having to reiterate information that the generator already knows. Generative Programming is an ingenious idea if the generatoroutputted code does not have to be edited by the developer, meaning it fits perfectly with what the intents of the programmers are. However, to build a generator that can incorporate all possible scenarios of its domain is very difficult. This dilemma is similar to the difficulty in building an extensive domain specific language. If we allow the generator to generate code that leaves some of the work to the developers, meaning the developers might have to fill in some parts of a method, or edit code that the generator generated, then we have to deal with the issues that arise when codes are regenerated after modifications have been made to the old generated code. What should happen to the changes made to the generated code? I will try to come up with a solution to this problem in Section PROGRAMMING LANGUAGE I believe that programming languages will continue to evolve, incorporating the advantages of aspect oriented programming, domain specific language, intentional programming and generative programming and also improving on the disadvantages of these programming paradigms. 3.1 Generators Even at a high-level language, it is inevitable to write code that has many repetitive parts; usually these repetitive parts are spread out all over a piece of software. Generators are used occasionally to solve this problem, and I believe they will become more widely used than they are nowadays. For example, to implement the visitor pattern, the visit and visitchildren methods need to be implemented in every class that a Visitor will visit. Most of the time, the body of the visit methods just involve calling the correct visit method of the Visitor class. Similarly the body of the visitchildren method simply involves calling the visit methods of its children, which are usually stored as the private fields of the class. This can be easily generated if the fields that represent children of a class can be corrected annotated. In Java 1.5, metadata can be added to code and these information remains in the source file even after compilation, easing the process of debugging and lessening the work needed to incorporate a generator. These metatdata tags are quite similar to the idea of intentional programming, except that the metatdata tags can only describe very limited intent. However I believe this illustrates the probability that generative programming will become an integral part of programming in the future. As long as all the adequate information can be annotated in source code, a generator can be easily implemented to take advantage of the annotations. Since there are already well known patterns that many developers follow while they program, these patterns can be easily simplified to incorporate generative programming, along with the corresponding generator so that developers can all take advantage. To take these patterns and generators to the next level, domain specific languages can be created that use these patterns and use the accompanying generators in the background. For example there might be a domain specific language for building a piece of software that deals with code, like a compiler or a type checker. Then this domain specific language can lessen the work of a developer by providing easy syntax for writing AST classes and the visitors that are used to actually do the compiling or type checking. As discussed in Section 2.4, one inevitable problem that arises from generative programming is the interaction between developers and generated code. Should a developer be allowed to alter the output of a generator? If so, what happens to the changes if codes are regenerated after input to the generator is changed? I believe the output of a good generator would not need to ever be altered by a developer, at least not directly. The reason for a developer to edit generated code is that the code generated is too

3 general to deal with a special case he/she is trying to deal with in the code. I believe that a good generator should deal with these special cases by accepting parameters in the input that indicates what to do in these special cases. This way, if the generated code is not as specialized as the developer wished, he/she should update the input of the generator rather than changing the generated code. But this specialized generator would mean that each project would require its own specialized generator. Then how can we take advantage of the off-the-shelf generators which have been well researched and well optimized from past experience? This problem can be solved if we allow output of a generator to be part of the input to another generator. This way, all the work that deals with general cases are done by the off-the-shelf generator, and minimal work would need to be done in the second generator, which injects specialized information to the code. This second generator can then be developed by the developers who know these specialized details the best. All this generator has to do is to inject specialized information to the generated code from the off-the-shelf generators, which should not be any more work than to actually edit the generated code to incorporate the specialized details by hand; therefore, no extra work is really needed to incorporate generators into a project as compared to coding by hand. 3.2 Aspectual Improvements I believe that the idea of using pointcuts and weavers in Aspect Oriented Programming is ideal for dealing with crosscutting concerns; however the mechanism in which pointcuts and advice bodies are declared can still be improved. An advice body can get very complicated depending on the application. It can also get tedious to define poincuts as the system grows bigger and more code needs to be affected by an advice. I believe that one of the reasons why pointcuts are difficult to understand is because they actually perform multiple rolls in the weaving process. Some pointcuts are only used to describe locations in code that the corresponding advice affects, but some pointcuts are also used to gather information for the body of the corresponding advice. As advice body changes (for example one more action needs to be taken in the advice body, meaning additional information needs to be gathered by the pointcuts), the poinctcuts that are used to gather information can also change, even though the locations that the advice affects remain exactly the same. This violates the principles of modularity, and I think this duality of role that a pointcut plays should be omitted. If the advice body is where the gathered information is used, why not leave the gathering to the body as well? One problem that arises from advice body being responsible for gathering information is that there are some repetitive codes that arise, because the pointcuts would be responsible for type checking a certain data, and similar code would be needed to actually remember what the data was. This is where domain specific language can come into play. As long as we keep the syntax for getting these information simple (similar to a variable declaration) then this task can become much simpler. For example if we limit all data that can be gathered in the advice body to be the variables that are checked in the pointcuts, then the syntax can be kept at a relatively simple level. With the knowledge to actually gather the data hidden in the definition of the domain specific language, this is plausible. 3.3 Higher Level of Abstraction Even though domain specific languages can be tedious to design and implement, I believe it is an integral part to move forwards in the improvement of programming language. As we have seen in Section 3.2 and 3.3, I believe domain specific language plays an important role in both generative programming and aspect oriented programming. We are programming in a higher level of abstraction as we did ten years ago, but there comes a certain point when additional abstraction means losing vital information in the finish product of a piece of software, even though the hidden information may be trivial to developer of a certain project. This is where domain specific languages come in; we can hide some of these details in the implementation of the language, leaving developers to express only the highest level of details that the language cannot know about (for example, parameters to pass into a generator). This is plausible because these trivial details are specific to the domain of the project. In order for domain specific languages to be effective in this process, it needs to be well developed and also general enough that not everyone that uses the language has to modify it drastically to incorporate his or her uses. This involves several domain experts and developers to develop this language, but I believe that if such a language does exist, many developers can benefit from the well established domain knowledge and will help fund the development, refinement and optimization needed for such a large scale project. For example, domain specific language can be developed for each generic pattern. If these languages are developed properly, it will be very easy to modify them slightly to have specialized languages that incorporate the specialized use of the pattern by any developers. Initially domain specific languages will remain small and private to developers involve in certain projects. As more developers become interested in a certain domain, they can join forces in developing a large language. I believe this process will be incremental and eventually an equilibrium of large and small specialized languages will be reached. As far as coding by intentions is concerned, I believe that as we move towards higher level of abstraction in source code, we are moving towards programming with intents. The reason why intents become lost in translation from design to implementation is because there is much code needed to express an intent from design. But with higher level of abstractions, these useless codes will be abstracted away, leaving only the intents in the code. 4. SOFTWARE DEVELOPMENT TOOL I believe that many innovations in programming languages cannot be fully appreciated until there are corresponding improvements in software development tool that help maximize the benefits of the programming language innovations. I believe that the key to effective and helpful software development tool is to give developers as much options as

4 possible. Tools should give developers choices in the way they view their code, and choices in the way they edit their code. Furthermore, tools should not lock users in a single way of doing things. It should allow users to change their mind any time they see fit. For example, a developer can choose to edit his/her code using a graphical view of the code, and then choose to edit it in plain text mode. These options do not mean that multiple copies of a piece of software need to be stored, reflecting each model. I believe that only one effective model of the code needs to be stored (ASCII texts or some other representation of an effective model). As long as the model is effective, all other information needed in other models can be derived. In language nowadays, this statement might not be true yet, because there are intents of developers that are lost in the translation to base language code. I believe that with the aid of domain specific languages, programming with intents and aspect oriented programming, the design details will not become lost when a developer actually starts coding. With this in mind, there is a direct correlation between any models with the base model that a tool used to store code; therefore, any change a user makes in one model can be stored in the base language, and if he/she changes his view to another model, the changes can be easily reflected. To give an example of my vision of software development tool, one model would be something similar to a class diagram, but instead of only having only method and field signatures, more information is needed to make this model effective. Inside each method, there must be some more information about the body of the method. A collapsible body would be perfect in this situation. If the user really does want to see the class diagram, he/she can choose to view the model with all the method bodies collapsed. This distinguishes this model from a normal class diagram, in which the class diagram is not yet effective. Interacting with this model can involve adding/removing a method or a field. A red cross or an error message is shown if no body is given for a new method. There are also options for adding domain specific languages or generators to lessen the work a user needs to do to implement a piece of software. For example, if the visitor pattern is selected, user would not need to implement the visit or visitchildren methods. Anything that deals with the pattern would be automatically inserted into each model where appropriate, according to the specification of the domain specific language or the generator. Sometimes users might still want to see non-effective models (for example a plain class diagram) without all the additional information. This can still be allowed in tools except that no modification can be made to these non-effective models. If users do want to make modification to a non-effective model, there will be links that lead them directly to the corresponding effective model where he/she can then make the appropriate modifications. To incorporate aspect oriented programming or any programming language features that deal with crosscutting concerns, choice of multiple views also help developers reason with aspects. For example an option for user to view AOP code would be to look at each aspect on its own (looking at each crosscutting concern separately). Another user might then want to know how the woven code would actually look. He/she can then select the woven code model/view to learn more about the woven code. This feature can be hard to implement if there are many dynamic pointcut in the implement of a crosscutting concern, but I believe that this view can still be helpful, if only for letting the user know that many areas can be affected in the woven code if the dynamic test does succeed, triggering the user to narrow the static pointcut instead of leaving all the work to the dynamic tests, improving efficiency in the executable. To incorporate generators and generated code, similar to AOP, views of input to the generator and the generated code can be chosen whenever the user chooses. As discussed in the previous section, generated code would not be encouraged to be edited. If there were changes that user wants to make to the generated code, he/she should change the input to the generator instead. An ideal generator would actually provide link between generated code and the part of the input to the generator that is responsible for that part of the generated code. 5. TECHNOLOG ADOPTION Technology always takes time to be adopted. I believe that development tool adoption is going to affect what programming language paradigm gets adopted first. If there is not enough adequate tool support for a certain programming language innovation, nobody will want to use it. On the other hand, a beautifully designed tool for a useless language would also not be used by many people. I believe that the usability and the novelty of features of a tool is what is going to attract people to try out a tool, and the usefulness is what is going to keep people using the tool continuously. Another big factor in swaying people to adopt a tool is if it allows incremental adoption. Developers like to have the option of changing their mind about a technology after trying it out. A tool that is backward compatible, which let developers back track to their old tool easily and without losing all the work that they did when trying out the new tool, will increase the probability of the tool being adopted. I believe that another key role in getting a tool adopted is that the choice of editing code with EMACS or VI must still be an option to the developer, if he/she so chooses. Because of this, I believe that no matter what models are available to users through the tool, plain ASCII text should still be what is used to store the code. In spite of this, there is no limitation on what a user can use when manipulating an effective model of the system, including graphics, or high level languages (languages that are close to our everyday speech). This is because the model is effective, which means there is a direct translation between the model and the ultimate executable byte codes. Therefore there is always a translation between the model the user is interacting with and ASCII text. Small start-up companies will probably be the first ones to take the challenge of trying out new tools, since they are in search of something that can help them compete with the larger, more wellestablished companies. As everything else in life, as a tool becomes more widely-used, more funding will become available for the improvement and maintenance of the tool. Gradually more developers and companies will start to adopt the tool. And the tool will then be able to improve by incorporating more

5 programming language innovations, which will maintain their customer support. 6. SUMMARY I do not believe there will be any drastic changes in the next ten years of software development. I believe there will be many extensions to already existing innovations and paradigms, including aspect oriented programming, domain specific languages, generative programming and intentional programming. I also believe that software development tools will become a more integral part of software development in the near future, simply because a human mind cannot envision what code will look like without tool support, because languages are becoming more and more abstract, there are more options to developers to decide how they would like to view code. And it is becoming harder for them to be able to simultaneously keep track of what each of these views look like. 7. REFERENCES [1] Cunningham & Cunningham Inc., Intentional Programming. [2] Lutz Roeder. Transformation and Visualization of Abstractions using the Intentional Programming System.