cqfn/eo
1
1
Fork 0
mirror of https://github.com/cqfn/eo.git synced 2024-10-04 12:19:02 +03:00
Code Issues Projects Releases Wiki Activity

intro

Browse Source
This commit is contained in:
yegor256 2021-06-13 10:22:51 +03:00
parent 0a7cb0e8d1
commit 5f6340f464
No known key found for this signature in database
GPG Key ID: 2A9EEFF323C2244F
2 changed files with 116 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
paper/eolang-paper.tex
View File

@ -93,7 +93,12 @@ programming language based on \phic{}.
\maketitle
\section{Introduction}
\label{sec:intro}
\input{intro}
\section{Overview}
\label{sec:overview}
\input{overview}
\section{Syntax}

111
paper/intro.tex Normal file
View File

@ -0,0 +1,111 @@
It's difficult to define what exactly is OOP, as
``the term has been used to mean different things,'' according to~\citet{stefik1985object}.
\citet{madsen1988object} claimed that ``there are as many
definitions of OOP as there papers and books on the topic.''
\citet{armstrong2006quarks} made a noticeable observation: ``When
reviewing the body of work on OO development, most authors simply suggest a set
of concepts that characterize OO, and move on with their research or discussion.
Thus, they are either taking for granted that the concepts are known or implicitly
acknowledging that a universal set of concepts does not exist.''
\subsection{Lack of Formal Model}
The term OOP was coined by ~\citet{kay97keynote} in 1966~\cite{kaymaster68}
and since then was never introduced formally.
Back in 1982, \citet{rentsch1982object} predicted: ``Everyone will be in a favor
of OOP. Every manufacturer will promote his products as supporting it. Every
manager will pay lip service to it. Every programmer will practice
it (differently). And no one will know just what it is.''
There is a fundamental problem in OOP---the lack of a rigorous formal model,
as was recapped by~\citet{eden2001principles}: ``Unfortunately, architectural
\nospell{formalisms} have largely ignored the OO idiosyncrasies. Few works recognized the
elementary building blocks of design and architecture patterns.
As a result of this oversight, any attempt to use \nospell{formalisms} for the specification of OO
architectures is destined to neglect key regularities in their organization.''
There is no uniformity or an agreement on the set of features and mechanisms
that belong in an OO language as ``the paradigm itself is far too general,'' as was
concluded by~\citet{nierstrasz1989survey} in his survey.
OO and semi-OO programming languages treat OOP differently and have variety of
different features to follow the concept of \nospell{object-orientedness}. For
example, Java has classes and types (interfaces) but doesn't
have multiple inheritance~\citep{alpern2001efficient};
C++ has multiple inheritance but doesn't directly support mixins~\citep{burton2014using};
Ruby and PHP don't have generics and types, but have traits~\citep{bi2018typed};
JavaScript doesn't have classes, but has prototypes~\citep{richards2010analysis}.
Language designers usually don't formally explain the features they introduce.
\subsection{Complaints of Programmers}
Although the history of OOP goes back for more than
50 years to the development of Simula~\citep{dahl1966simula}, OOP is under heavy
criticism since the beginning to nowadays, mostly for its inability
to solve the problem of software complexity.
According to~\citet{graham2004hackers}, ``somehow the idea of reusability
got attached to OOP in the 1980s, and no amount of evidence to the contrary
seems to be able to shake it free,'' while
``OOP offers a sustainable way to write spaghetti code.''
\citet{west2004object} argues that the contemporary mainstream understanding
of objects (which is not behavioral) is ``but a pale shadow of the original idea'' and
``anti-ethical to the original intent.''
\citet{gosling1995java} notes that
``unfortunately, `object oriented' remains misunderstood and
over-marketed as the silver bullet that will solve all our software ills.''
\subsection{High Complexity}
\citet{nierstrasz2010ten} said that ``OOP is about taming
complexity through modeling, but we have not mastered this yet.''
Readability and complexity issues of OO code remain unsolved till
today. \citet{shelly2015flaws} claimed that ``Reading an OO
code you can't see the big picture and it is often impossible to review all the
small functions that call the one function that you modified.''
\citet{khanam2018} in a like manner affirmed: ``Object oriented programming
promotes ease in designing reusable software but the long coded methods makes
it unreadable and enhances the complexity of the methods.''
The complexity of OO software is higher than the industry would expect, taking
into account the amount of efforts invested into the development of
OO languages. As was concluded by~\citet{bosch1997object}, ``OO frameworks have
number of problems that complicate development, usage, composition and
maintenance of software.''
For example, the infamous legacy code has its additional overhead associated with OO
languages---inheritance mechanism, which ``allows you to write less code
at the cost of less readability,'' as explained by~\citet{carter1997oopvsr}.
It is not infrequently when ``inheritance is overused and misused,''
which leads to ``increased complexity of the code and its maintenance,''
as noted by~\citet{bernstein2016legacy}.
The lack of formalism encouraged OOP language creators to
invent and implement language features, often known as ``syntax sugar,''
which are convenient for some of them in some special cases but
jeopardize the consistency of design when being used too often
and by less mature programmers. The most obvious
outcome of design inconsistencies is high complexity due to low readability,
which negatively affects the quality and leads to functionality defects.
\subsection{Solution Proposed}
\eo{} was created in order to eliminate the problem of complexity of
OOP code, providing
\begin{inparaenum}[1)]
a formal object calculus and
a programming language with a reduced set of features.
\end{inparaenum}
The proposed \phic{} represents an object model through
data and objects, while operations with them are possible
through abstraction, application, and decoration. The calculus
introduces a formal apparatus for manipulations with objects.
\eo{}, the proposed programming language, fully implements
all elements of the calculus and enables implementation of
an object model on any computational platform.
Being an OO programming language, \eo{} enables four key principles of OOP:
abstraction, inheritance, polymorphism, and encapsulation. On top of that,
the design of \eo{} guarantees lower complexity of programs,
comparing with other languages like Java or C++.