General-purpose multiparadigm programming languages : an enabling technology for constructing complex systems

Multiparadigm programming languages have been envisioned as a vehicle for constructing large and complex heterogeneous systems, such as a stock market exchange or a telecommunications network. General-purpose multiparadigm languages, as opposed to hybrid multiparadigm languages, embody several prevalent programming paradigms without being motivated by a single problem. One such language is Leda, which embodies the foundational paradigms of imperative, functional, logic, and object-oriented programming. We explore aspects of solving complex problems using Leda, in order to illustrate the benefits of using a multiparadigm language in expressing solutions to complex systems. We claim that general-purpose multiparadigm programming languages like Leda greatly expedite solutions to a variety of complex problems

C++ exam methodology

The C++ programming language supports multiparadigm programming. We can write programs in procedural, object-oriented, generic way at the same time. However, it is difficult to figure out exercises for the terminal examinations since not easy to separate the algorithmic cogitation from the knowledge of the programming language. There are some basic elements that programmer students have to know: constructors, parameter passing, objects, inheritance, standard library, handling constants, copying objects, functions and member functions, etc. Exercises must be multiparadigm according to the C++ language. Using only one paradigm in C++ is not enough. This results in that we have to distinguish the different linguistic constructs on the basis of its complexity. Many questions are arisen in connection with the exercises of terminal examinations. How can we gauge the procedural, the object-oriented, and the generic paradigms at the same time? How can we gauge students’ C++ knowledge when we do not lay stress on the algorithmic cogitation? What kind of exercises may be interesting by the Standard Template Library? Which C++ constructs are reckoned to be more difficult and which ones considered to be easier? What are the most important ones? In this paper we give answers to the previous questions, we describe our methodology to assessment of students’ C++ knowledge in a semi-automatic grading way. We also present exercise examples that worked out according to our methodology. We take stock of students’ results in the paper

Model for Software Reuse in a Multiparadigm Environment

Computer Scienc

Resolving feature convolution in middleware systems

Middleware provides simplicity and uniformity for the development of distributed applications. However, the modularity of the architecture of middleware is starting to disintegrate and to become complicated due to the interaction of too many orthogonal concerns imposed from a wide range of application requirements. This is not due to bad design but rather due to the limitations of the conventional architectural decomposition methodologies. We introduce the principles of horizontal decomposition (HD) which addresses this problem with a mixed-paradigm middleware architecture. HD provides guidance for the use of conventional decomposition methods to implement the core functionalities of middleware and the use of aspect orientation to address its orthogonal properties. Our evaluation of the horizontal decomposition principles focuses on refactoring major middleware functionalities into aspects in order to modularize and isolate them from the core architecture. New versions of the middleware platform can be created through combining the core and the flexible selection of middleware aspects such as IDL data types, the oneway invocation style, the dynamic messaging style, and additional character encoding schemes. As a result, the primary functionality of the middleware is supported with a much simpler architecture and enhanced performance. Moreover, customization and configuration of the middleware for a wide-range of requirements becomes possible

Improving interoperability in distributed multi-tier software stacks

Distributed multi-tier software stacks organise and deploy software components as a hierarchy of interacting tiers. The components are typically heterogeneous, i.e. each component may be written in a different language and may interoperate using a variety of protocols. Tiered software is modular but leads to a range of interoperability challenges including the following. (1) Interoperating components in multiple languages and paradigms increases developer cognitive load since they must simultaneously reason in multiple languages and paradigms. (2) There must be correct interoperation of components, e.g. adherence to the API or communication protocols between components. (3) Interoperation between different components can lead to diverse modes of failure as each component can fail in unique ways. Many of these challenges are the result of contributing factors like tight coupling or polyglot programmming. This thesis investigates techniques to improve heterogeneous interoperability in distributed multi-tier software stacks. Some common approaches include microservices and tierless languages. Microservices are perceived to offer better reliability than components in multi-tier software stacks through the loose coupling of services. The reliability of microservices is investigated by combining the established properties of dependence and state with reliability. This defines a new three-dimensional space: the Microservices Dependency State Reliability (MDSR) classification with six classes. The feasibility of statically identifying MDSR classes is demonstrated with a prototype analyser that identifies all six classes in Flask microservices web applications. The reliability implications of the different MDSR classes are evaluated by running three case study applications (Hipster-Shop, JPyL & WordPress) against a fault injector. Key results are as follows. (1) All applications fail catastrophically if a critical microservice fails. (2) Applications survive the failure of individual minor microservice(s). (3) The failure of any chain of microservices in JPyL & Hipster is catastrophic. (4) Individual microservices do not necessarily have minor reliability implications. In a tierless language, the compiler generates the code for each component and ensures their correct interoperation. They are mainly used to implement web stacks. However, their use in implementing IoT stacks is less common. This investigation compares interoperation in tiered and tierless IoT stacks through the systematic evaluation of four implementations of the prototype UoG smart campus IoT system: two tierless and two Python-based tiered. Key results of the study are as follows. (1) Tierless languages have the potential to significantly reduce the development effort for IoT systems, requiring 70% less code than the tiered implementations. (2) Tierless languages have the potential to significantly improve the reliability of IoT systems. (3) The first comparison of a tierless codebase for resource-rich sensor nodes and one for resourceconstrained sensor nodes shows that they have very similar functional structure and code sizes - within 7%. Tier elimination is a technique that removes a tier/component by integrating two tiers. Specifically, this thesis investigates the implications of eliminating the Apache web server in a 4-tier web stack: Jupyter Notebook, Apache, Python, Linux (JAPyL) and replacing it with PHP libraries in the frontend webpage to get the 3-tier (JPL). The study reveals the following. (1) The JPL 3-tier web stack requires that the developer uses fewer programming languages and paradigms than JAPyL, i.e two compared with four languages and two compared with three paradigms. (2) JPL requires 42% less code than JAPyL. (3) In JPL, some of the functionalities can be automated due to the decreased abstraction levels at the upper layers of the stack. (4) However, the latency in JPL is two to three times greater than that of JAPyL. So while tier elimination reduces developer effort and semantic friction the tradeoffs are high performance overhead & resource consumption and increasing code complexity