Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userObject-oriented programming: some history, and challenges for the next fifty years
149
0
0.0
(
0
)
Added by
Andrew Black
Publication date
2013
fields
Informatics Engineering
and research's language is
English
Authors
Andrew P. Black
Ask ChatGPT about the research
No Arabic abstract
Object-oriented programming is inextricably linked to the pioneering work of Ole-Johan Dahl and Kristen Nygaard on the design of the Simula language, which started at the Norwegian Computing Centre in the Spring of 1961. However, object-orientation, as we think of it today---fifty years later---is the result of a complex interplay of ideas, constraints and people. Dahl and Nygaard would certainly recognise it as their progeny, but might also be amazed at how much it has grown up. This article is based on a lecture given on 22nd August 2011, on the occasion of the scientific opening of the Ole-Johan Dahl hus at the University of Oslo. It looks at the foundational ideas from Simula that stand behind object-orientation, how those ideas have evolved to become the dominant programming paradigm, and what they have to offer as we approach the challenges of the next fifty years of informatics.
rate research
Read More
Context: Embedded Domain-Specific Languages (EDSLs) are a common and widely used approach to DSLs in various languages, including Haskell and Scala. There are two main implementation techniques for EDSLs: shallow embeddings and deep embeddings. Inquiry: Shallow embeddings are quite simple, but they have been criticized in the past for being quite limited in terms of modularity and reuse. In particular, it is often argued that supporting multiple DSL interpretations in shallow embeddings is difficult. Approach: This paper argues that shallow EDSLs and Object-Oriented Programming (OOP) are closely related. Gibbons and Wu already discussed the relationship between shallow EDSLs and procedural abstraction, while Cook discussed the connection between procedural abstraction and OOP. We make the transitive step in this paper by connecting shallow EDSLs directly to OOP via procedural abstraction. The knowledge about this relationship enables us to improve on implementation techniques for EDSLs. Knowledge: This paper argues that common OOP mechanisms (including inheritance, subtyping, and type-refinement) increase the modularity and reuse of shallow EDSLs when compared to classical procedural abstraction by enabling a simple way to express multiple, possibly dependent, interpretations. Grounding: We make our arguments by using Gibbons and Wus examples, where procedural abstraction is used in Haskell to model a simple shallow EDSL. We recode that EDSL in Scala and with an improved OO-inspired Haskell encoding. We further illustrate our approach with a case study on refactoring a deep external SQL query processor to make it more modular, shallow, and embedded. Importance: This work is important for two reasons. Firstly, from an intellectual point of view, this work establishes the connection between shallow embeddings and OOP, which enables a better understanding of both concepts. Secondly, this work illustrates programming techniques that can be used to improve the modularity and reuse of shallow EDSLs.
Class invariants -- consistency constraints preserved by every operation on objects of a given type -- are fundamental to building and understanding object-oriented programs. They should also be a key help in verifying them, but turn out instead to raise major verification challenges which have prompted a significant literature with, until now, no widely accepted solution. The present work introduces a general proof rule meant to address invariant-related issues and allow verification tools benefit from invariants. It first clarifies the notion of invariant and identify the three problems: callbacks, furtive access and reference leak. As an example, the 2016 Ethereum DAO bug, in which $50 million were stolen, resulted from a callback invalidating an invariant. The discussion starts with a Simple Model and an associated proof rule, demonstrating its soundness. It then removes one by one the three assumptions of the Simple Model, each removal bringing up one of the three issues, and introduces the corresponding adaptation to the proof rule. The final version of the rule can tackle tricky examples, including challenge problems listed in the literature.
There is often a sort of a protocol associated to each class, stating when and how certain methods should be called. Given that this protocol is, if at all, described in the documentation accompanying the class, current mainstream object-oriented languages cannot provide for the verification of client code adherence against the sought class behaviour. We have defined a class-based concurrent object-oriented language that formalises such protocols in the form of usage types. Usage types are attached to class definitions, allowing for the specification of (1) the available methods, (2) the tests clients must perform on the result of methods, and (3) the object status - linear or shared - all of which depend on the objects state. Our work extends the recent approach on modular session types by eliminating channel operations, and defining the method call as the single communication primitive in both sequential and concurrent settings. In contrast to previous works, we define a single category for objects, instead of distinct categories for linear and for shared objects, and let linear objects evolve into shared ones. We introduce a standard sync qualifier to prevent thread interference in certain operations on shared objects. We formalise the language syntax, the operational semantics, and a type system that enforces by static typing that methods are called only when available, and by a single client if so specified in the usage type. We illustrate the language via a complete example.
Object-oriented programming (OOP) is aimed at describing the structure and behaviour of objects by hiding the mechanism of their representation and access in primitive references. In this article we describe an approach, called concept-oriented programming (COP), which focuses on modelling references assuming that they also possess application-specific structure and behaviour accounting for a great deal or even most of the overall program complexity. References in COP are completely legalized and get the same status as objects while the functions are distributed among both objects and references. In order to support this design we introduce a new programming construct, called concept, which generalizes conventional classes and concept inclusion relation generalizing class inheritance. The main advantage of COP is that it allows programmers to describe two sides of any program: explicitly used functions of objects and intermediate functionality of references having cross-cutting nature and executed implicitly behind the scenes during object access.
Nowadays RPCs are in a booming phase: they are successfully used in many experiments, including LHC; there are ambitious plans to use them in several upgrade detectors and in some new experiments as well as in various applications. The aim of this paper is to highlight the main challenges which the RPC community may face in the next few years and which were addressed in talks presented at this conference. Examples could be: new and difficult requirements from experiments (and their upgrades) and applications, optimization and improvements of the existing traditional detector designs, improvement of their characteristics (timing /rate performance, aging, dark current and so on), implementation of new more sensitive electronics, investigation of new materials, development of large- area detectors. We will also review the fast and very promising developments of another type of resistive electrode gaseous detector -micropattern detectors having at least one of their electrodes made of resistive materials. These innovative detectors combine in one design the best features of RPC (spark protection) and micropattern detectors (high granularity-high position resolution).
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
