Select text to annotate, Click play in YouTube to begin
00:00:00
to be very brief now I introduce the session chair it's tiny Singh thank you so the first speaker today is Oscar
00:00:13
Anitra's Oscar finished his PhD in 1984 at the University of Toronto and he is currently a professor of computer science at the Institute of computer science in the university of bern where
00:00:27
he he founded the software composition group in 1994 he is a co-author of more than 200 publications and among other things he's the co-author of open source
00:00:40
the open source book object-oriented re-engineering patterns and followed by example please welcome Oscar nice runs my honor to be here today
00:00:53
I especially given my situation so I've done a lot with a lot of different object-oriented languages over the year but actually Simula was not one of them
00:01:09
so I apologize in advance if I say something foolish or out like outright wrong please forgive me in advance what I want to do today is give you a bit of I want to give a bit of a historical
00:01:22
perspective but it's a very personal historical perspective coming from my own experience so I wanted to give some highlights over the years of things that I found important and influenced me I'm sure there are lots of things that I've
00:01:34
left out some on purpose and some out of ignorance but bear with me please so this story it's kind of a saga I've broken it up into four parts with a little prologue and the prologue is
00:01:47
there because from my point of view of for me personally the story did not start in Norway but in Canada where I started working on a PhD in
00:02:00
actually masters with Dennis secretss at the University of Toronto in 1979 and Dennis at the time was working on office information systems what we
00:02:14
called at that time the electronic office or the paperless office and I was brought in I started working as a master student after doing a mathematics degree
00:02:25
at the University of Waterloo and I decided actually the math I was interested in was happening in more in computer science in Dennis's group in the 1970s they did a lot of work on
00:02:37
relational databases and they built the first relational system for UNIX called mrs micro relational system then Dennis who made many career changes over the years he got more interested in the
00:02:51
electronic office and he had another couple of master's students built oh by the way mrs eventually turned out to be a product and I think it's still a product today in a very niche market then with a couple of other master's
00:03:04
students they built ofs which was the office form system and the idea was here that you could have a distributed collection of nodes where users would
00:03:16
have graphical very simple graphical representations of office documents forms which would be mapped to this relational system and then when I joined
00:03:27
Dennis's group he gave us this project to build an automated form system so to add automatic procedures on top of this so the idea was that users would be able
00:03:41
to specify procedures that would be automatically triggered when certain forms would arrive in their inbox what today would be called a workflow system and he gave this job to me and John
00:03:53
Hogue to build this thing and we thought great also by the way we called it tli and never told anybody what TLA stood for there all these prototypes in the group like mrs and ofso well we have to have a
00:04:05
three-letter acronym oh sorry so we opened up the box to me it seemed like this is should be straightforward I know exactly what we have to open up the box and what we saw was like a Jackson
00:04:25
Pollock painting I asked myself that's me a long time ago where are the objects so this stuff was all written in C and
00:04:38
the domain the lovely domain objects that we had these office forms they were nowhere in the code I couldn't find them they were smeared all over the place we built our prototype but I was felt very very uncomfortable okay so this is a bit
00:04:52
of a prologue now the tour story switches back to Norway so this is part one where we start seeing the beginnings of object-oriented programming with a
00:05:04
couple of different languages we've already heard and we've seen outside a bit of the history of Simula won't tell you too much about it but some things
00:05:17
that really struck me particularly there are a number of very nice historical surveys that was one that I liked so Johan Dahl and mr. Nygaard developed
00:05:30
similar over a number of years and basically over a period of four years they identified four or five years that have identified a number of fundamental concepts that seemed important to them
00:05:43
so they as we've heard they were interested in having better support for building simulation programs and they found that the current language is especially how ago were not really appropriate so apparently one of the first things
00:05:58
that that they felt was problematic was this focus on the stack as the basic data structure in the programming language and they identified especially for simulations that cues with a very important for scheduling events I
00:06:12
imagine and also for for scheduling processes and and for messaging so this was one of the first abstractions that seemed to be very important the second thing that
00:06:24
emerged over time was the unifying notion of an object actually at the time they focus on the concept of a process but we recognize that today as an object or even of classes of objects so this was the second fundamental concept and
00:06:38
then fairly late in the game they realized they needed some way of sharing or reusing specifications of objects objects bundled together behavior and
00:06:51
attributes but sometimes you had very similar classes so this notion of of layering or what they called prefixing at the time allowed one to take an existing specification and add stuff to it which was pretty cool and later on
00:07:05
this was called inheritance but at the time it was referred to as prefixing now we've also heard that well originally Simula was intended as providing a
00:07:17
better support for simulation but quickly people began to realize this idea of simulation is actually pretty cool and we can use it for other things so you could say they didn't actually
00:07:31
say this but maybe they could have said it to me they were saying programming is a simulation this is this is something that's fundamentally important and I think this is a theme that will keep
00:07:43
coming back word back back again from my perspective as well though simulation is a form of of modeling it's saying that we can if we want to do if we want to
00:07:56
build any kind of application we build our own virtual world in software and this is kind of a model that that is executable so you could also say as far as I know they didn't say that but you can read between the lines and say that
00:08:09
oh Leon and Kristen were saying program in a sense is modeling but what struck me when I was reading about the history is something that Kristin actually did
00:08:23
say which is programming as understanding and in some sense I feel that's the same thing the idea that programming is modeling also saying
00:08:35
that having having a program where the model is explicit in the code that really helps you understand not only the program but how it's related to the application okay this is all pretty cool
00:08:50
round about the time that Simula 67 was being put together Alan Kay came along and he noticed that hardware we was getting cheaper and faster and more
00:09:01
powerful and he imagined that very soon down the line you would have computers that people could own themselves and maybe Lee eventually down the line computers that people could hold in
00:09:14
their hands multimedia devices crazy idea so that's a mock-up that's just a piece of cardboard I think or a piece of wood I don't know that's the mock-up of the Dynabook from from around 1970 Alan
00:09:28
Kay said you know if we're going to build this stuff we can't do it with the existing programming languages and technology we really need this notion of objects but it's not just a programming
00:09:40
language issue this is something fundamental that goes deep so he wanted to build a system not just a not just a
00:09:51
programming language operating system all the way down to the hardware which was codenamed small talk which we build
00:10:03
object-oriented all the way down so essentially he was saying it's objects all the way down in some versions of this history legend goes that people
00:10:20
would ask him well what are the objects made of and he would say it's objects and what are those objects manor there are objects again what about those objects and he'd said listen it's objects all the way down until you reach Turtles
00:10:33
I don't think he said that but in one story it's it's told that way in fact if you do who here has worked with small talk if you're a number of people if you do
00:10:46
program with small talk you you you do get the feeling that it is objects all the way down and eventually you do bang into the turtles however let's see now
00:10:58
another thing that Alan Kay said later on in that article from 1977 which really fits very nicely with with Nygaard and Dolls vision is that he
00:11:13
really had the sense that computation is simulation so you want to think of any kind of computation as a set of interacting objects they're actually
00:11:24
simulating something I found on the website of eulogies to Kristin Nygaard there was also a comment by Alan Kay and he said that he had met with earlier on
00:11:40
doll and explained his ideas met with dead silence he said the feeling he was very unhappy and felt uncomfortable about this that they didn't seem to understand his ideas and at a later time
00:11:54
he met with Cassini guard and explained his ideas and immediately Christmas I oh yeah and you do that you do that it's like he was anticipating what he was going to say so I found that very
00:12:04
interesting and touching Dan Ingalls was one of the people who was been working with small talk for many years and still is was one of the architects of really
00:12:18
the the guts of the system he also likes to say that programming is objects talking to objects he really believes in this metaphor that you want to think at a deep level that an object-oriented
00:12:30
system is you want to think of it in terms of this interaction of objects sending messages to each other oh it's really objects all the way down maybe that it's the only picture that I could find that evokes that to some extent
00:12:42
interestingly enough at Al Goldberg who was so working on small talk-- more or less from the beginning I was one of the architects of the of the language she said in small talk
00:12:56
everything happens somewhere else is not a good thing or a bad thing so if you have programmed with small talk sometimes if you're trying to understand a piece of code that somebody else has
00:13:11
written or maybe even some code that you've written yourself you start following the message and bouncing things so where is it actually happening you say okay this object says okay please says to another object please do that so okay
00:13:23
that object must do it you look at that object and you look at his methods no it's talking to other objects so you keep following the trail and at some point you get lost so when you try to understand a complex oriented system
00:13:36
sometimes you can get lost on the other hand there's a very positive side to this if you can if you can get into the Zen of it and fundamentally behind this statement is the intuition the insight
00:13:49
that delegation is one of the fundamental concepts of good object-oriented design you aren't the the the master of the universe where you say everything that
00:14:01
has to be done it's not programs are algorithms plus data you don't control everything you have your data that you're responsible for and when you want something done you find the object that
00:14:13
has that data has those responsibilities then you kindly ask that object to do it for you objects talking to objects everything happens somewhere else that other object then has to take care of it
00:14:24
in terms of understanding I think there's another nice quote from Alan Knight who's a longtime small talk program he said that one of the great
00:14:36
leaps in object orientation is to be able to answer the question how does this work with I don't care I think there's a lot of insight that it's a
00:14:48
strange statement but if you think about it it's there's a lot going on there okay well in 1981 there was a very influential
00:15:01
issue of bite magazine all about small talk who remembers when that came out yeah a bunch of people I had four I've lost my copy I had a copy for many years
00:15:14
when I got that in my hot little hands I said a 1981 on the PDF this actually download link you can actually get the
00:15:26
whole PDF of the of the volume I think it was August 1981 but there I'm not sure it was about small talk ad so the language that they presented to a small talk ad but the byte issue came out the
00:15:38
following year when I saw that I got excited oh wow this is what I'm looking for this is what we need we need some language that allows us to express the main objects in the code where we can
00:15:51
make this link all the way down and I read that and I saw all about the prototypes and then I got disappointed it ran on something called a Dorado I had no idea what that was and I said
00:16:05
well we'd love to use object-oriented languages but we don't have any compilers for any of them any tools nothing that will run on the hardware we have so I went and talked to Dennis about this and he said well why did you grab it his typical solution why don't
00:16:18
you grab a couple of master students and implement an object-oriented language so that's another story that I don't want to go into today but that's more or less
00:16:28
where my story here ends but what I want to tell you now about is some other stories related to what happened in the years after that other things that I found very interesting and influential
00:16:44
so now we entered the Golden Age so the Golden Age is where all sorts of new object-oriented languages and ideas were being developed and it was a very
00:16:56
fruitful period of time so around 1979 be honest roadtrip was encountering a very similar problem that dollar Nygaard did in the in the 60s he had to build a
00:17:10
bunch of simulation applications at Bell Labs and he was an old-time simular programmer and thought oh gee it would be nice to have Simula but I don't have a similar compiler for these machines
00:17:22
and we're doing everything with C well why don't I do what Dahl did is and I just add objects and classes and inheritance to C should be pretty easy to do so he did that he he basically
00:17:36
used macros to develop the first version called C with classes and basically he said object-oriented programming is programming using inheritance and in
00:17:50
this paper from a coop 87 which you can also find online he summarized object-oriented programming for from his point of view as being an approach in which you decide which classes you want
00:18:02
provide a full set of operations and make commonality explicit using inheritance that's pretty down-to-earth so I mean it's a very nicely defined chopped-up
00:18:15
this is what object-oriented programming is just a little bit different from what we were hearing from the small talk guys but okay it's not entirely incompatible
00:18:26
however when you ask be honored if C++ is an object-oriented language he says no it's not designed as an object-oriented language it's a multi paradigm language you can
00:18:40
program in an object-oriented way with C++ but you don't have to so in fact it supports a lot of features which support different styles of programming particularly generative programming with
00:18:51
the help of templates yes there's a nice book based on the PhD thesis of James cope lean on this whole aspect of that multi-paradigm programming and design
00:19:04
for C++ now moving ahead what else now he's skipping ahead to 1985 and so in during the 80s there were a lot of things happening this is one of
00:19:19
the things I found particularly influential so dr. Maier introduced the Eifel language with a variety of interesting features but I think the most fundamental and
00:19:31
most influential of those was the idea of design by contract so the Eiffel was designed in such a way that it actually had syntactic features supporting design by contract but people realize this is
00:19:43
actually can be supported in a fairly straightforward way in other languages too simply by the addition of a search assertions so it's on the one hand a mechanism but on the other hand a
00:19:57
methodology in which every object has a clearly defined contract that that formalizes what services under what condition it provides to other objects in terms of preconditions pose
00:20:10
conditions and also invariance which explain what are the the actual valid states of the object I would very interestingly I would think virtually
00:20:23
every mainstream object-oriented language and also non mainstream ones provide some support for design by contract now so this is something that's that's pretty much accepted as as sound
00:20:36
methodology also in that book Bertrand Meyer had a somewhat different view of what object-oriented programming is in fact he didn't just talk about programming that object-oriented software construction so he's not just
00:20:51
thinking about the language but about the software engineering aspects of object-oriented programming and he said object-oriented software composition is based on the objects that are manipulated rather than the functions
00:21:02
performed now why is this profound it's profound because if you look at applications that evolve over time and any useful application does evolve well what is it that changes its the
00:21:16
functions the features they're not stable they change what is it that stays stable pretty much the domain concepts the objects so if you build your application in a functional way around
00:21:29
the functions you can expect it to be less stable as it evolves over time where as you build it around the objects you can expect more stability it's hard to prove
00:21:40
to carry out an empirical study to prove this but I think you can see that object or that since people got excited about using object oriented development in industrial project since the 80s we've
00:21:53
seen object oriented systems that have grown and grown and been have evolved over many many years without having to be thrown away and started over again so I think there's pretty much acceptance
00:22:07
in industry that this idea of stability that comes from object-oriented design really pans out so I think this insight was right on the mark okay then during the 80s and 90s lots
00:22:24
and lots of languages were developed I just list a few of them here so we had C lost which added objects to common lisp we had Objective C which took a
00:22:39
different approach to extending C with objects basically by adding small talk style message passing we had languages like beta which were tried to reinvent the basic concepts of
00:22:50
similar by reducing two fundamental concepts in this case the notion of a pattern we have languages like Python that grew out of scripting and languages
00:23:04
like self which tried to be a next-generation small talk by reducing the basic concepts of inheritance and classes and reducing them to prototypes and delegation and of course we have
00:23:15
Java and then dozens and dozens of other languages developed over the years so why so many languages and what's the
00:23:30
basic idea of object-oriented programming so people started thinking about this what's actually going on here and Peter Wagner wrote a very I wrote an
00:23:46
influential paper in the in the 80s that was sly 87 there go away and he essentially said well if we look at all the languages the fundamental
00:23:59
concepts if we want to distinguish what's an object-oriented language and what is not well in our language should have objects and classes and inheritance and he went further on to distinguish object based and class based and object
00:24:11
oriented so some languages have objects we don't have classes some of classes but don't have an inheritance and then you have the the full monty and then he further tried to analyze inheritance and
00:24:24
also put delegation in the tree here so you can see there's a large number of different variations in fact if you look at UML you have this one concept which is specialization which is modeled in
00:24:38
different object-oriented languages by inheritance but every single object-oriented language does inheritance in a different way there are no two that have the same semantics another influential paper from a coop
00:24:52
eighty-eight inheritance as an incremental modification mechanism or what like is and isn't like it's a great title Peter and stands donek basically
00:25:05
said inheritance is an incremental modification mechanism and then they dived in this paper into a number of different variants of inheritance and
00:25:16
how it supports incremental modification and reuse one of the feelings that I got in retrospect was in the 1980s there was a huge obsession and hype about reuse
00:25:32
that object-oriented programming was great because you didn't always have to implement or something from scratch if you saw something that was similar you could just inherit from it and incrementally modify the things you
00:25:43
didn't like or you wanted to add which is not really the way it works and if we look at methodologies later they take a very different particularly Rebecca
00:25:56
Varys Brock had a very different view on inheritance and how it comes into the picture she said think about inheritance very late in the process it's not just a question of reusing code and actually what I tell my students
00:26:08
inheritance is there for three things one it's for conceptual modeling modeling is a two it's there for polymorphism so for plug-in architectures and three if things work
00:26:19
out you also get some reuse but at the time I think people were focusing far too much on reuse interestingly in that paper Wagner and Sonic proposed the principle of substitutability
00:26:32
which should look kind of familiar to you so an instance of a subtypes can always be used in any context in which an instance of a super type was expected that's pretty similar to what's now known as the Liskov substitution principle that was proposed about five
00:26:46
years later by barbara lista Liskov and jeanette wing they had a more formal notion of this but I think essentially the same thing is going on there now I
00:27:00
stumbled across this fairly recently this was in a Annie coupe talk by James Nobel and there's a paper by him called
00:27:13
the myths of object orientation in which he refers to this I the original sources are nowhere to be found on the net anymore so I consider that to be the basic reference so Ralph Johnson looked
00:27:27
at all these languages and he had I thought a very insightful way of explaining what's different between these languages so he says that there are three views of object-oriented programming so the Scandinavian view is
00:27:42
that an object-oriented system is one whose creators realize that programming is modeling the mystical view guess which one that is is that an object-oriented system is the one is one
00:27:53
that is built out of objects that communicate by sending messages to each other and computation is the message is flying from object to object and the software engineering view is that an
00:28:05
object-oriented system is one that supports data abstraction polymorphism by late binding of function calls and inheritance so I think this sort of fits very nicely and explains well the
00:28:17
very different views that we've seen over time and also explains well the different motivations of the different language designers I know I find that very cool then all sorts of
00:28:30
object-oriented principles were being proposed many of these have been taken and rephrased by Uncle Bob but he never claimed that he invented them he just
00:28:42
repackaged them and I think that's fine separate interface from into implementation open closed principle which was proposed by by Bertrand Meyer of course single responsibility
00:28:53
principle which is closely related to responsibility driven design and object oriented methods start appearing starting around 1988 and moving on to 93
00:29:07
those were I think some of the most influential books that came out you should recognize a number of those for me I think the two that I found
00:29:17
personally most influential were the book by Rebecca ver spark and her colleagues on responsibility driven design basically it says that if you
00:29:30
have a well-designed object-oriented system every object has clear responsibilities and it provides you with guidelines and methods for for doing that for realizing such a partitioning and the other one that I
00:29:43
think is very influential was Eva Jakob syns work on use cases where he really provides a very nice methodology for getting from the user requirements
00:29:56
towards an object-oriented design to making this bridge from the non object-oriented world to the object oriented world with use cases now one of
00:30:07
the things that you can maybe glean from all of these different books is a kind of an underlying subtext that not programming is modeling but modeling is programming or something like that the
00:30:22
other thing which I did not believe at the time is that its objects all the way down but not in the same Allen came and but in the sense that when you're really doing object-oriented
00:30:35
development all the way the full stack you use object-oriented modeling for your domain and requirements you use it for the design of the system and you use it in the code as well and you will find
00:30:48
it's not exactly the same object but you will find the same objects all the way down and I always thought no that can't be true that's too good to be true at some point you're going to have some translations of mappings and it's not going to be the same but in retrospect I
00:31:01
think that actually really is true in an ideal world and that's what you should strive for object-oriented diagrams is I just spent half an hour collecting from
00:31:14
various most of these are from Uppsala 86 just random diagrams I found so dozens in the late mid to late 80s dozens of these different diagrams were developed and arrows going every which
00:31:26
way with classes represented as ellipses or boxers or hexagons or clouds everything so this was pretty pretty messy there's a nice anecdote from Bertrand Meyer he was been used and
00:31:40
bewildered by this he said if people so obsessed with all these different diagrams for him the best modeling tool is an object-oriented language itself
00:31:52
why are you just directly model stuff in the code I mean you can build a model you can actually do this rather you can just start writing your specification in the language even if the code doesn't do much so at least that's that's his
00:32:06
belief and then he said that well one day was in the shower and it hit him bubbles and errors don't crash that's why people like them and that's better'n
00:32:18
snake so now we've had this growth of object-oriented ideas and we're getting to the late 80s early 90s and now we start seeing some splitting off some
00:32:33
different different factions being being established so one of the things that you may recall is starting around the late 80s people you're saying objects are not enough it's not just enough to have
00:32:47
object-oriented programming because we're missing something we're missing notions of architecture were missing notions of software components at different granularities and so on so
00:33:00
this is the Gang of Four and I think a lot of different trends can be traced back to some the group or some of them individually particularly the work on frameworks that started already in the
00:33:13
mid to late 80s and Erich gamma was working on the et plus Blas framework object-oriented framework around that time people around very late 80s Early
00:33:27
90s tarted thinking in terms of components and actually in the design patterns book third various design patterns which are which are revolve around the idea of having plug
00:33:39
compatible components that you can plug into and out of frameworks which also led to a different notion of a framework classical object-oriented framework works by inheritance you specialize the framework by inheriting with a component
00:33:51
oriented framework you develop components based on interfaces and you can just plug them in without inheritance and then of course in some sense they were it also led to the idea that programming has to do a lot with
00:34:04
design patterns so this was one trend that or actually several trends that were related around that time somewhat later starting I guess around the mid to
00:34:18
late 90s we have Kent Beck and colleagues who started this agile movement and interestingly they were focusing more on the processes hey it's
00:34:31
not just about the language but it's how do you interact with the customer how do you really get the leverage from the object-oriented concepts in a in a very productive way so Kent back saying okay I we didn't invent these concept but
00:34:44
they're a bunch of best practices out there which are very useful and can work together well to improve this this iterative design and implementation together with the customer
00:34:56
a lot of these ideas so refactoring for example started already in the late 1980s as a concept bill Opdyke and and Bill Griswold and others pioneered that
00:35:09
and Sean Robertson Don Brandt Don Roberts and John Brant built the first refactoring browser for small talk in the mid to late 90s so a lot of these ideas were coming from various places
00:35:25
the testing framework came first from Kent Beck and Erich gamma no yes and eventually moved was supported to lots
00:35:38
of other languages then another trend that came so we saw that there were dozens of different diagramming notations that were being developed in the 80s then in the early mid 90s UML
00:35:53
was developed at rational by the three amigos who came up with a very nice balanced proposal that unified a lot of other
00:36:06
diagramming techniques and that was eventually given to the object Management Group so that a consortium could standardize this but then coming out of that was the notion that well you'd actually like to use this
00:36:19
object-oriented modeling and use it to drive the generation of the code so instead of having a software developer building a code by programming it manually what you'd like it that person
00:36:31
to do is to build a model ideally using UML or something like that or whatever and then you have what I would call is a model compiler that automatically translates from the platform independent
00:36:45
model to platform specific models so this is the whole model driven model-driven architecture model driven fill-in-the-blank movement that started in the late 90s and was really driven by
00:36:59
the object management group and led to a lot of work on model transformation I personally think this makes sense especially if you have lots of different specific platforms so when you make a change and the change
00:37:11
is well understood then you can write a model compiler if the changes are arbitrary then you can't have a model compiler that knows how to handle them all it really pays off big when you have kinds of changes that can be anticipated
00:37:24
like changes in the in health insurance policies or changes in financial instruments and so on you say oh well we can specify these at a high level and then compile them to lots of different
00:37:38
platforms so that we can react fast so if you have anticipated changes that makes a lot of sense anyway this was one big another big trend and then a more
00:37:50
recent trend is the dichotomy whether it's real or false between statically typed languages and dynamically typed languages so some people complain argue
00:38:05
we are much more productive with all this all this noise in our programming languages we don't need the types and we have tests they protect us and so on and in the end you find that even in the dynamically typed world people are doing
00:38:18
a lot of type inference one for making their virtual machines or compilers or whatever produce much more efficient code or they're using type inference to
00:38:30
support the developer in a program understanding so there's I mean the types are useless but there are many different views of understanding what types are therefore and how they can be
00:38:41
used productively well I'm pretty much
00:38:59
at the end of my story but for me I at some point I looked at all of the different kinds of technologies that are out there you have
00:39:14
api's for component models plugging components together you have its metamodeling and model driven approaches that give you tell you how to develop specific models and you have
00:39:26
domain-specific languages which which can be used to express at a high level a particular configuration for a specific domain and if you look at them it's sort
00:39:40
of kind of the same thing as going on in all of these so you can think that a configuration so you're getting from the meta level down to the concrete application level you can think of an
00:39:52
application as a configuration of components that are plugged together or it can be a specific model that conforms to a particular meta model or it's a script written in a particular DSL that expresses how that all works together
00:40:05
and if you look at all the different things that people were trying to do over all these years with the different languages and methodologies and then approaches and so on what I tell my
00:40:19
students programming is modeling what you want to achieve an object-oriented programming achieves that well wise object-oriented programming so in any programming language you're building
00:40:31
some kind of a model and giving a particular paradigm that paradigm says well it's a functional paradigm I want to think of applications in this way it's logic programming are constructed in terms of facts and rules and so on
00:40:43
they always give you a particular tool to model what's different about object-oriented programming it's fundamentally different from other paradigms because it's not just a paradigm it's a meta paradigm what do I
00:40:57
mean if you think of the previous picture object-oriented programming works at a different level it says to you as a developer you decide what the meta model is you decide what the components are going to be what are the
00:41:09
domain concepts so that when you program with those in a sense you're building your own virtual world and putting those objects together to build your model so you build not just the models but also the meta models so that's why
00:41:22
object-oriented programming goes a step further in supporting this paradigm which leads me back to what Kristin said programming is understanding if you do it right if you do object-oriented
00:41:36
programming right you'll eat that leads to better understanding in the whole process and leads to application code which is easier to understand
00:41:46
programming is understanding thank you [Applause]
00:42:03
is this on yes we have time for some questions and discussion discussion hey come on
00:42:18
that's the question back there
00:42:20
okay - in the back don't ask me well as
00:42:57
we as L told us seamless zero and Salem one was in 65 and 60 K in fact to read the similar compiler in something like 69 70 and then understood what object
00:43:12
orientation was by reading the runtime system of the Simla compiler in 66 which
00:43:32
would then probably be similar one yes so it was it was not object-oriented programming because it didn't have inheritance read object based
00:43:42
programming there was one more question there's another question at the left there yes yes go ahead oh wait for the
00:43:55
mine indeed it was a great talk thank you for your words and after the functional programming and then the object-oriented concepts do you see any
00:44:08
major paradigm shift in programming a major paradigm shift from object-oriented concepts yes I think this is constant struggle to try
00:44:21
and make programming languages better at modeling and make it easier to to recognize recognize concepts all the way down the stack and there are things that are definitely missing so for me one of
00:44:35
the biggest things that's missing the elephant in the room is in that one of the most fundamental concepts in the design of any object of any large system
00:44:49
is its architecture and the architecture is not in the code it is nowhere it's in people's heads or it's in a specification what we're missing is some way to reflect the architecture in the
00:45:03
code so that's just one example so they're things that are missing and I expect that somewhere down the line we'll see better ways of addressing those issues making making language is
00:45:13
better at modeling what is an architecture for you you are trying to implement something for it but not so
00:45:28
sure what it is okay do you want the one-minute version so what what I tell my students architecture I mean there's the syntax and there's the semantics so
00:45:43
syntactically architectures but the course-level design what are the coarse grained components in the software system but that's just the syntax what's the semantics the architecture is there for a good reason
00:45:55
it's there to provide you with very strong properties in the system leading to non-functional requirements for example if you have a fat client
00:46:07
architecture the fat client the coarse grain architecture says this stuff goes in the client that goes in the server why is it there just the syntax doesn't tell you it's there so that more stuff
00:46:19
can go in the client so that the customers the users can get fast feedback and you offload a lot of stuff that doesn't have to happen the server so the application is more responsive and and the users are happier that's just one example
00:46:32
so architecture is always about the course level design and is there to satisfy certain properties which are important for the success of the application not just functional
00:46:41
requirements hello just a comment on the
00:47:05
issue of model you said to Kristin Egor programming is about understanding but he was really concerned about modeling of course also even twenty years after
00:47:18
symbol of 67 in the mid 80s he was my supervisor and he still was discussing was is real a model we were sitting and together willing when he was also a
00:47:31
supervisor at home at Kristin's home for eight hours just discussing what is a model and we had the full table of difference encyclopedia to really understand what is it and of course many
00:47:45
terms over the model is it not I mean it's not a photo model or a car model it's about same structure structure equivalence and things like that my point is that that even twenty years
00:47:58
after his language he was still interested in finding out what is really a model and what does modeling means means in terms of software development programming yes thank you I did you
00:48:11
notice that I didn't touch that topic at all so yeah sure there are models for different reasons their prescriptive models for things you want to build their models that are descriptive
00:48:22
specifies things that you want a reason about models can be there for many different reasons and I think all of those reasons fit into the story there's no one answer one last question
00:48:38
we're on time I am really appreciate your retrospective in into the past and you kind of stopped at modeling and so
00:48:54
and I was wondering what do you think what would be the next big thing and what to think about ideas on software
00:49:06
product lines that actually systems can be described using modeling but approaching it from the other end and of looking at the models and the family of
00:49:20
the products from the point of view that they have commonalities and and differences so what do you think about
00:49:30
this or from your point of view what's the next big thing in the sort of attempts to to improve understanding
00:49:43
your programming yeah so I mean there are lots of things which aren't in programming languages I mentioned architecture as an example but I've moved in I didn't talk about my research
00:49:57
at all today except what I my very first experience moved a little bit away from programming language design because I'm not sure what to do there what we've done instead the last few years is we've been looking a little bit more about
00:50:10
what support does the developer actually need so when developer is working on a system working on existing code extending it and so on that person has a lot of questions about the code and
00:50:22
about what other people have done but if you look at the development environments that we have today they're not much more than glorified text editors there are lots of various tools around that can help you perform software analysis and
00:50:35
so on but a lot of these things are not very well integrated so what we're doing is we're looking at a lot of these different aspects of what can help developers about modeling and analyzing the system that they're working on
00:50:48
and looking at the ecosystem deriving information from that to help to better answer questions about what might be potential problems and so on there are a lot of things which are that can happen
00:51:01
in a modeling environment that is missing in the code itself another thing that you aside from architecture which is not in the code is any knowledge about different versions a single application is always written in one
00:51:12
version is refers to one version of the system not to other versions and also refers to one version of that programming language the programming language evolves to over the time that knowledge about versions of the system
00:51:24
and versions of the language and so on is is not in the language and maybe is not a programming language issue at all but maybe it should be I just have no idea so these are some of the things we're looking at I think there's a lot
00:51:37
of stuff to do but I don't have the crystal ball I've always been terrible at at crystal balls and if you look at the things that I said or others said about what life would be like 20 years
00:51:50
later what I said 20 years ago so way off target so I've given up on seeing foreseeing the future one last question oh wait a second we
00:52:02
need the mic for the recording okay thanks how important is the concrete syntax of their language in contrast to
00:52:16
the abstract concepts behind them what I mean they say can someone somewhat awkward concrete syntax be an obstacle when it comes to the acceptance of a
00:52:28
language I mean the best example is sitting in the corner there I mean James developed Java with a syntax similar to C++ to make it easy for C++ developers
00:52:41
to learn the language that if you look at what's going on in the language in spirit is much closer to small talk so and people are still frightened of small talk today because of its weird syntax I love it but lots of people are are very
00:52:54
confused by it so yeah syntax is important but I guess we'll hear more about that later - okay I guess not - concludes the discussion thank you very much we have a
00:53:08
small present for you thank you thank you
End of transcript