A PLEA FOR PLUGGABLE

PROGRAMMING LANGUAGE FEATURES

Bernhard G. Humm

Darmstadt University of Applied Sciences, Darmstadt, Germany

Ralf S. Engelschall

Capgemini sd&m Research, Munich, Germany

Keywords:

Programming Language Features, Aspects, Flexibility, Evolutionary Prototyping, Plug-in.

Abstract:

Current programming languages are inﬂexible regarding their use of language features like typing, access

control, contracts, etc. In some languages, the programmer is forced to use them, in others he may not.

This article pleads for pluggable programming language features, a concept that allows greater ﬂexibility for

application programmers without losing control over the use of those features.

1 INTRODUCTION

Flexibility is one of the most basic and important

design goals in software engineering (Ghezzi et al.,

2002) (Sommerville, 2004). Flexibility allows for

adaptation of applications to different and possibly

varying needs. This not only applies to the resulting

application, but also to the tools for creating them.

However, when analyzing current programming

languages and their features concerning their ﬂexibil-

ity of use, the result is rather disappointing. Consider

just the following two examples.

• Current mainstream programming languages like

C/C++, Java, and C# are all statically typed. Static

typing is mandatory there and the programmer

has no ﬂexibility as to omit type speciﬁcations

where sensible. Contrarily, dynamic languages

like Smalltalk, Scheme, Python and PHP are all

dynamically typed and the programmer has no op-

tion whatsoever to explicitly specify type declara-

tions statically where sensible.

• Access control in Java is mandatory. For all

classes, interfaces and members, accessibility

must be declared (public, protected, private or

package local as default). The programmer has

no option of omitting access control speciﬁcations

where sensible. On the other hand, declaring ac-

cess control for packages is not possible at all in

Java. Also, in dynamic languages like Smalltalk,

explicit access control on class and method level

is not possible. The programmer has no option of

specifying access control where sensible.

This inﬂexibility causes a number of problems:

Coding Overhead: In many industrial software

projects, the implementation technology is pre-

deﬁned, e.g., Java. Implementing application

parts like scripts, code generators, or data migra-

tion routines — for which scripting languages are

most suitable — in Java result in unnecessary cod-

ing overhead due to mandatory language features,

whose use is not necessary in this context.

Poor Quality: Contrarily, implementing critical ap-

plication parts in a dynamic language like

Smalltalk may reduce quality — in this case

safety — due to missing compile-time checks

(Meijer and Drayton, 2005).

One might argue that in such a case, the language

choice is simply wrong and an industrial strength

language like Java should have been used. This

leads us to the next problem.

Incremental Development Impeded: In many

project situations it is sensible to develop soft-

ware incrementally (Martin, 2002), e.g., with

evolutionary prototyping (Floyd, 1984; Berger

et al., 2004; Gordon and Bieman, 1993; Hekmat-

pour, 1987). This means that an application or

a part of it is quickly prototyped ﬁrst and then,

G. Humm B. and S. Engelschall R. (2010).

A PLEA FOR PLUGGABLE PROGRAMMING LANGUAGE FEATURES.

In Proceedings of the Fifth International Conference on Evaluation of Novel Approaches to Software Engineering, pages 5-11

DOI: 10.5220/0002925600050011

 SciTePress

incrementally, the code quality is enhanced. If the

target application is critical and an industry-scale

language like Java is chosen, then quick prototyp-

ing is impeded due to many mandatory language

features.

The overall picture today is that programming lan-

guages deﬁne a ﬁxed set of features that are to be

used. The programmer has no ﬂexibility as to use

less strict features where acceptable or even to specify

more advanced features, e.g., access control on pack-

age level in Java, where necessary.

To alleviate those problems, we plead for a con-

cept that we call “pluggable programming language

features” and argue from the application program-

mer’s point of view, i.e., from the view of the user

of a programming language. In Sect. 2 we present the

concept. Sect. 3 and 4 present a sample application

and a research prototype of the concept. Sect. 5 dis-

cusses the results. Sect. 6 concludes this article.

2 PLUGGABLE PROGRAMMING

LANGUAGE FEATURES

Before introducing the concept of pluggable program-

ming language features, we need to distinguish two

kinds of programming language features.

Core programming language features are essen-

tial for implementing applications at all. Examples

are objects, classes, operations, variables, and control

constructs like loops.

Additional programming language features spec-

ify aspects of core language features. Examples are

access control for classes, type declaration of vari-

ables, and pre- and postconditions of operations. Ad-

ditional language features are not essential in the

sense that it is possible to implement applications

without using additional programming language fea-

tures.

Only additional programming language features

may be pluggable. For a programming language to

adhere to the concept of pluggable programming lan-

guage features we postulate the following require-

ments.

Optional Language Features: The language must

allow for implementing applications without us-

ing any additional programming language fea-

tures at all. In particular, static typing must not

be mandatory.

Independent Language Features: The language

must allow for specifying additional program-

ming language features independently and to

check for their conformance at an adequate point

in time. In particular, static type checking must

be possible.

Extensible Language Features: The programming

language must be extensible to allow for the im-

plementation of new additional language features.

Language Feature Conﬁguration: The program-

ming language must allow for conﬁguring the use

of additional language features in an application

or parts of them. The use may be enabled manda-

tory or optionally, or disabled. Enabled language

features will be checked, e.g., by the compiler.

In total, the concept allows for plugging in additional

language features, either pre-deﬁned ones or new

ones. Arbitrary use of language features is avoided

via language feature conﬁguration.

We see two major use cases for pluggable pro-

gramming language features.

Customizing Features according to Requirements:

Pluggable programming language features allows

system architects to customize a programming

language with respect to the quality requirements

of an application to be developed. Depending

on the criticality, more language features may be

plugged in — even additional ones that have not

been pre-deﬁned in the programming language.

The conﬁguration enforces the use of those

language features by the programmers.

Customizing Features per Development Stage:

Pluggable programming language features allows

for efﬁcient incremental software development,

particularly with evolutionary prototyping. In an

early stage of development, additional language

features may be omitted completely by program-

mers. This allows for rapid prototyping. Such a

rapid prototype may be used to get user feedback

quickly, as well as checking for architectural

integrity of the application. Gradually, the code

quality of the application may be enhanced

by plugging in additional language features.

Language feature conﬁguration gives control

over this process. For different stages in the

development process, e.g., “Proof of Concept”,

“Alpha Release”, “Beta Release”, and “Final

Product”, speciﬁc language features may be

enforced.

We now demonstrate the concept via a research proto-

type and its use via a sample application that focuses

on the second use case.

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

3 EXAMPLE DOMAIN:

CUSTOMER MANAGEMENT

COMPONENT INTERFACES

3.1 Customer Management

We demonstrate pluggable programming language

features exemplary via interfaces for a customer man-

agement component of a business information sys-

tem.

Our example is the create-customer operation

with parameters name, address, and date-of-birth

for adding a new customer object to a customer man-

agement data store. The example seems trivial but

may be quite complex in practice. For instance,

address may be checked for validity syntactically as

well as semantically via city map data.

3.2 Interface Speciﬁcation Aspects

An interface is speciﬁed by a name and its operations.

An operation’s signature is minimally speciﬁed by its

name and the parameter names. Additionally, the fol-

lowing aspects may be speciﬁed:

• Access control, e.g., public, private

• Parameter mode: input, output, input/output

• Parameter obligation: mandatory, optional (e.g.,

expressed by null values)

• Parameter types, e.g., primitive types like

Integer and complex types like Customer

• Type restrictions, e.g., only positive Integer val-

ues for a bank transfer. Note: Type restric-

tions may be implemented as separate types, e.g.,

Positive-Integer

• Pre- and postconditions: constraints before and

after operation execution, respectively — e.g.,

date-of-birth < now. Note: parameter modes,

obligations, types and type restrictions may all be

speciﬁed as pre- and postconditions

• Exceptions: speciﬁcation of exceptional situa-

tions that are externally visible, e.g., duplicate

customer

• Side effects, e.g., read-only, modifying

• Semantics documentation: speciﬁcation of the op-

eration’s behavior and documentation of its pa-

rameters, usually informally in prose. Note: pre-

and postconditions are part of the semantic speci-

ﬁcation, too

• Non-functional characteristics: specifying (for-

mally or informally) performance and other non-

functional characteristics

Quality Level

Operation

Names

Parameter

Names

Parameter

Modes

Parameter

Obligation

Parameter

Types

Visibility

Exceptions

Type

Restrictions

Pre- /

Postconditions

Side Effects

Semantics and

Parameter

Documentation

Non-functional

Characteristics

Proof of Concept x x

Alpha Release x x x x x

Beta Release x x x x x x x x x

Final Product x x x x x x x x x x x x

Figure 1: Language Feature Conﬁguration.

Generally speaking, for a production-grade business

information system, the more complete the interface

speciﬁcation, i.e., the more intrinsic information is

speciﬁed explicitly, the better.

3.3 Language Feature Conﬁguration

For instance, consider the development stages “Proof

of Concept”, “Alpha Release”, “Beta Release”, and

“Final Product”. Then, language features may be as-

signed to the development stages as shown in Fig. 1.

In the following section, we describe language

features for specifying some of the interface speciﬁ-

cation aspects exemplary.

4 LANGUAGE FEATURES FOR

INTERFACE SPECIFICATION

4.1 Research Prototype in Lisp

We have chosen Lisp

(McCarthy, 1960) as the im-

plementation language for our research prototype to

demonstrate pluggable programming language fea-

tures. Lisp is dynamically typed but contains a pow-

erful type system as well as a built-in macro processor

for implementing new language features.

We have implemented a custom macro

define-function that extends the basic built-

in defun macro for deﬁning an operation.

define-function is a real extension of defun

in the sense that it accepts all declarations of defun

but, additionally, optional aspects.

In the next sections, we show some of the lan-

guage features exemplary step by step by means of

the example create-customer, thereby incremen-

tally enhancing code quality by the use of pluggable

language features.

4.2 Operation and Parameter Naming

In the simplest form (development stage “Proof of

Concept”), the name of an operation and its param-

More speciﬁcally: Allegro Common Lisp, a profes-

sional implementation of the ANSI Common Lisp standard

A PLEA FOR PLUGGABLE PROGRAMMING LANGUAGE FEATURES

eter names are speciﬁed only.

(define-function create-customer

(name address date-of-birth))

This expression declares the operation

create-customer with input parameters name,

address, and date-of-birth. No additional

language features need to be speciﬁed at this stage.

4.3 Parameter Typing

The type of an input parameter (necessary for devel-

opment stage “Alpha Release”) is speciﬁed via the

keyword :type in a list per parameter. The type of

the operation result (out parameter) is speciﬁed via

the keyword :result-type in an options list follow-

ing the parameter list.

(define-function create-customer

((name :type Structured-Name)

(address :type Structured-Address)

(date-of-birth :type Date))

(:result-type Customer))

The parameter name is of type Structured-Name, the

parameter address of type Structured-Address,

etc.

4.4 Pre- and Postconditions

Pre- and postconditions (necessary for development

stages “Beta Release” and “Final Product”) are spec-

iﬁed via the keywords :pre and :post in the options

list, followed by a Lisp boolean expression that can

be evaluated at run-time.

(define-function create-customer

((name :type Structured-Name)

(address :type Structured-Address)

(date-of-birth :type Date))

(:result-type Customer

:pre (is-valid? address)

:pre (lies-in-past?

date-of-birth)

:pre "No duplicate of

previously created

customer"

:post (get-id result)))

The ﬁrst precondition is satisﬁed if the operation

is-valid? with the actual parameter address eval-

uates to true (non-nil). This checks for valid ad-

dresses. lies-in-past? checks whether the birth

date is plausible. The third pre-condition regarding

duplicate checking is treated as an informal com-

ment. The postcondition speciﬁes that the resulting

Customer object contains a non-nil identiﬁer.

4.5 Documentation of Semantics

To document the semantics of the operation and

the input and output parameters, the keywords

:documentation and :result-documentation are

used in the options list and the parameters lists.

(define-function create-customer

((name :type Structured-Name

:documentation "Customer

name consists of ...")

(address :type Structured-Address

:documentation "Postal

address consists of ...")

(date-of-birth :type Date

:documentation "Customer

birth date"))

(:result-type Customer

:result-documentation

"New Customer object"

:pre (is-valid? address)

:pre (lies-in-past? date-of-birth)

:pre "No duplicate of previously

created customer object"

:post (get-id result)

:documentation "Creates

a new Customer object"))

4.6 Additional Language Features

Analogously, we have implemented the follow-

ing additional language features: access control,

modes, obligations, exception speciﬁcation, and non-

functional characteristics. None of those are natively

provided in the core language feature set of Lisp.

With our extensions, application programmers may

optionally and independently use all of those addi-

tional programming language features.

4.7 Conformance Checking

It is not enough to provide language features for spec-

ifying interface aspects — the speciﬁcation confor-

mance has to be checked, too. Therefore, we have

implemented the macro define-function to gener-

ate conformance checks. Type speciﬁcations are, if

possible, checked at compile time. Pre- and post-

conditions are checked at runtime. All speciﬁcation

aspects are compiled into the built-in function docu-

mentation of Lisp.

But checking the speciﬁed aspects is only one kind

of conformance check. The macro also checks the

conformance of the application code with the lan-

guage feature conﬁguration during compilation. In

case of violations, warnings are being generated. For

example, static parameter type checking is enforced

from development stage “Beta Release” on as in any

statically typed language like Java.

Note: not all all conformance checks can be fully

automated. For example, a conformance checker can

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

not decide whether or not there are meaningful pre-

conditions for an operation.

5 DISCUSSION

5.1 Evaluation

This article is a plea for pluggable programming lan-

guage features. We cannot empirically prove the

usefulness of the approach. However, our conﬁ-

dence stems from our long-time experience in devel-

oping large-scale business information systems and

the promising results of our research prototype and

sample implementation. Furthermore, we qualita-

tively justify our approach by evaluating it and the

sample implementation against the problems identi-

ﬁed in Sect. 1.

Coding Overhead: Pluggable programming lan-

guage features allow to reduce coding overhead

by omitting unnecessary language features in

certain application contexts, like scripts, code

generators, or data migration routines. A lan-

guage switch towards a scripting language is not

necessary since the programming language itself

offers the necessary ﬂexibility.

Poor Quality: Pluggable programming language

features allow critical applications to be imple-

mented in a strict manner thus improving code

quality. Not only language features common in

industrial-strength programming languages can

be used. Additionally, even more strict language

features may be plugged in. Examples are pre-

and postconditions or advanced access control

which extends towards packages and components.

Incremental Development Impeded: Pluggable

programming language features particularly boost

incremental application development, e.g., with

evolutionary prototyping. An application or a

part of it may be quickly prototyped ﬁrst and

then, incrementally, the code quality may be en-

hanced. Language feature conﬁguration prevents

arbitrary use of language features at the program-

mers’ goodwill. Certain quality levels at certain

development steps can be enforced.

5.2 Language Support Today

Current programming languages, both in industry and

academia, support pluggable programming language

features very poorly. Today, there is a strict demar-

cation of languages focusing either on rapid applica-

tion development (RAD) or on industry scale devel-

opment.

Industry Scale Languages, Statically Typed:

Languages like Java and C# are currently in

mainstream use for developing large-scale, high-

quality applications. They are all statically typed

and are not well suitable for rapid application

development (RAD). Some language features like

visibility (public, private) are, indeed, optional.

However, more advanced quality features like

pre- and postconditions are not directly pro-

vided and can only be indirectly injected at the

byte-code level.

RAD Supporting Languages, Dynamically Typed:

RAD supporting languages like Smalltalk, Perl,

Python, Ruby, Groovy, Scala and F#, conversely,

are currently not in mainstream use for devel-

oping industry-scale applications. They are

either used for throw-away prototyping or for

developing special-purpose applications like web

sites. Most of them are dynamically typed and do

not allow for static typing. Quality features may

be added as we have shown with Lisp macros in

this article but this is not commonly done.

Hybrid Typing Languages: A few languages like

VisualBasic, Perl 6 and Lisp (partially) exist that

allow for static as well as dynamic typing. They

also allow, in limited ways, for extending the lan-

guage by new quality features. Neither is in main-

stream use. However, with C# 4.0, now in beta re-

lease, the ﬁrst mainstream programming language

will incorporate dynamic typing optionally — one

important step towards pluggable programming

language features.

5.3 Related Work

In their article “Static Typing Where Possible, Dy-

namic Typing When Needed: The End of the Cold

War Between Programming Languages” (Meijer and

Drayton, 2005), Meijer and Drayton plead for typ-

ing as a pluggable programming language feature.

Though typing is only one of many features of pro-

gramming languages, the difference between static

and dynamic typing are sometimes exaggerated as

“language war”. We fully agree with Meijer and

Drayton — language wars are not at all necessary.

We extend their point of view in three ways.

Firstly, we regard typing as one language feature only.

Although most important, it represents only one point

in a whole spectrum between ﬂexible prototype devel-

opment and extremely strict development of critical

applications. Secondly, we allow for true plugging

A PLEA FOR PLUGGABLE PROGRAMMING LANGUAGE FEATURES

of programming language features in the sense that

new features may be added to the language. Finally,

we add the concept of language feature conﬁguration

which gives control over the use of language features.

The comparison with Bracha’s article “Pluggable

Type Systems” (Bracha, 2004) is similar. His imple-

mentation of Strongtalk (Bracha and Griswold, 1993)

on the basis of Smalltalk is an example of a pluggable

language feature, namely typing.

With the Scala programming language (Odersky,

2004), Odersky targets at scalability and ﬂexibility,

too. He tries to reduce the set of language features

as much as possible and, instead, provides features

in libraries. However, on the level of additional lan-

guage features like typing and access control, Scala

is still inﬂexible. Scala uses type inference to ease

the programmer from the burden of specifying types

unnecessarily often but is still statically typed at any

time.

Finally, we see a strong relationship be-

tween Aspect-Oriented Programming (AOP) (Kicza-

les et al., 1997) and pluggable programming language

features. While not inherently tied to it, AOP in

practice is used for implementing functionality for

the end-user like, e.g., logging. On the other hand,

pluggable programming language features target the

application programmer by addressing internal code

quality like maintainability, stability, reliability, etc.

Hence, our approach follows the tradition of AOP, but

with a different focus.

6 CONCLUSIONS AND FUTURE

WORK

In this article, we plead for pluggable programming

language features, a concept that adds ﬂexibility to

programming languages. It allows for using or omit-

ting programming language features with full control

via programming feature conﬁguration.

We demonstrated the concept via a research pro-

totype and a sample application in Lisp. While the

concept has obvious beneﬁts, it is not well supported

by current programming languages. Furthermore, we

agree with Meijer and Drayton, who identify a “huge

cultural gap” between the communities of statically

and dynamically typed languages (Meijer and Dray-

ton, 2005).

However, we see a new trend towards dynamic

programming languages in the last decade that are im-

plemented on top of mainstream platforms. Exam-

ples are implementations of Python, Ruby, Groovy,

and Scala on the Java Platform or F# and C# 4.0 on

the .NET platform. Furthermore, there are a number

of Lisp implementations on the Java platform, e.g.,

ABCL, Clojure, Jatha, and CLForJava.

This may allow for pluggable language features to

eventually break through — for two reasons. Firstly,

the technical integration of languages of different

styles eases the implementation of pluggable lan-

guage features. Optional typing in C# 4.0 is a perfect

example for that. Secondly, a growing community

of programmers who are proﬁcient in both language

styles will help closing the cultural gap. Addition-

ally, if mainstream languages already had real support

for pluggable programming language features, the ne-

cessity for numerous special languages would be re-

duced.

Our plea for pluggable programming language

features is from the application programmers’ point

of view. We see future work in the following ar-

eas. Pluggable programming language features need

to be implemented in programming languages on top

of mainstream platforms. Integrated development en-

vironments need to support pluggable programming

language features, particularly their conﬁguration.

Experience needs to be gained in industrial projects

of different sizes. Finally, a development method-

ology that best utilizes pluggable programming lan-

guage features needs to be developed.

REFERENCES

Berger, H., Beynon-Davies, P., and Cleary, P. (2004). The

Utility of a Rapid Application Development (RAD)

approach for a large complex Information Systems

Development. In Proceedings of the 13th European

Conference on Information Systems (ECIS 2004),

Turku, Finland.

Bracha, G. (2004). Pluggable type systems. In OOPSLA

Workshop on Revival of Dynamic Languages, 2004.

Bracha, G. and Griswold, D. (1993). Strongtalk: Type-

checking Smalltalk in a production environment. In

Proc. of the ACM Conf. on Object-Oriented Program-

ming, Systems, Languages and Applications (OOP-

SLA’93).

Floyd, C. (1984). A systematic look at prototyping. Ap-

proaches to Prototyping, pages 1–18.

Ghezzi, C., Jazayeri, M., and Mandrioli, D. (2002). Funda-

mentals of Software Engineering. Prentice Hall PTR,

Upper Saddle River, NJ, USA.

Gordon, V. S. and Bieman, J. M. (1993). Reported Effects

of Rapid Prototyping on Industrial Software Quality.

Hekmatpour, S. (1987). Experience with evolutionary pro-

totyping in a large software project. SIGSOFT Softw.

Eng. Notes, 12(1):38–41.

Kiczales, G., Lamping, J., Mendhekar, Videira Lopes,

C., Loingtier, J.-M., and Irwin, J. (1997). Aspect-

Oriented Programming. In Proceedings of the Eu-

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

ropean Conference on Object-Oriented Programming

(ECOOP’97). Springer-Verlag LNCS 1241.

Martin, R. C. (2002). Agile Software Development, Princi-

ples, Patterns, and Practices. Prentice Hall.

McCarthy, J. (1960). Recursive Functions of Symbolic Ex-

pressions and Their Computation by Machine, Part I.

Communications of the ACM, 3(4):184–195.

Meijer, E. and Drayton, P. (2005). Static Typing Where Pos-

sible, Dynamic Typing When Needed. In Workshop on

Revival of Dynamic Languages.

Odersky, M. (2004). An Overview of the Scala Program-

ming Language: EPFL Technical Report IC/2004/64.

Sommerville, I. (2004). Software Engineering, 7th Edi-

tion (International Computer Science Series). Addi-

son Wesley.

A PLEA FOR PLUGGABLE PROGRAMMING LANGUAGE FEATURES