A farewell to soul-crushing code

Video thumbnail (Frame 0) Video thumbnail (Frame 1167) Video thumbnail (Frame 3296) Video thumbnail (Frame 6837) Video thumbnail (Frame 8555) Video thumbnail (Frame 13340) Video thumbnail (Frame 15161) Video thumbnail (Frame 17412) Video thumbnail (Frame 18661) Video thumbnail (Frame 20123) Video thumbnail (Frame 21779) Video thumbnail (Frame 23227) Video thumbnail (Frame 25421) Video thumbnail (Frame 26721) Video thumbnail (Frame 28246) Video thumbnail (Frame 30139) Video thumbnail (Frame 31394) Video thumbnail (Frame 32658) Video thumbnail (Frame 33888) Video thumbnail (Frame 35078) Video thumbnail (Frame 38001) Video thumbnail (Frame 39177) Video thumbnail (Frame 40823) Video thumbnail (Frame 42261) Video thumbnail (Frame 43594) Video thumbnail (Frame 46311) Video thumbnail (Frame 48400) Video thumbnail (Frame 49900) Video thumbnail (Frame 51635) Video thumbnail (Frame 52950) Video thumbnail (Frame 54115) Video thumbnail (Frame 55291) Video thumbnail (Frame 56518) Video thumbnail (Frame 58615) Video thumbnail (Frame 60115) Video thumbnail (Frame 62242) Video thumbnail (Frame 63840) Video thumbnail (Frame 65042) Video thumbnail (Frame 67867) Video thumbnail (Frame 69369) Video thumbnail (Frame 70893) Video thumbnail (Frame 72070) Video thumbnail (Frame 74302) Video thumbnail (Frame 76966) Video thumbnail (Frame 85980) Video thumbnail (Frame 90694)
Video in TIB AV-Portal: A farewell to soul-crushing code

Formal Metadata

Title
A farewell to soul-crushing code
Subtitle
Towards correct software that enriches our lives
Title of Series
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
A major part of software development is maintenance, i.e. tinkering with software that should already be completed but still somehow does not work as it should. Software developed by tinkering is the antithesis to resilient technology, and a growing threat to our profession and our lives. Working on this kind of software crushes the soul. Yet this is exactly how most IoT devices (and computers in general) are programmed these days. We need to replace the dead technology-oriented objects of the past with supple models enriching our domains and our souls. This talk shows how it is done.
Keywords Resilience

Related Material

The following resource is accompanying material for the video
Video is cited by the following resource
Computer program Goodness of fit Group action Roundness (object) Software Software developer Independence (probability theory) Musical ensemble Event horizon
Data model Presentation of a group View (database) Code Run time (program lifecycle phase) Object (grammar) Factory (trading post) Code Core dump Bit
Computer program Service (economics) Open source Code Translation (relic) Instance (computer science) Shape (magazine) Mereology Flag Library (computing) Physical system Social class Context awareness Projective plane Constructor (object-oriented programming) Code Line (geometry) Variable (mathematics) System call Windows Registry Software Query language Factory (trading post) Interpreter (computing) Right angle Quicksort Object (grammar) Recursion
Surface Computer program Facebook Asynchronous Transfer Mode Facebook Object-oriented programming Code Computer configuration Different (Kate Ryan album) Personal digital assistant Googol Formal language
Point (geometry) Surface Asynchronous Transfer Mode Divisor Code Multiplication sign Real number Function (mathematics) Number Object-oriented programming Computer configuration Term (mathematics) Googol Divisor Binary multiplier Social class Capability Maturity Model Inheritance (object-oriented programming) Open source Category of being Word Facebook Configuration space Right angle Object (grammar) Game theory Capability Maturity Model
Component-based software engineering Component-based software engineering Divisor Code Computer configuration Military operation Open source Pattern language Pattern language Divisor Object (grammar) Social class
Context awareness Divisor Code Code Voltmeter Line (geometry) Likelihood-ratio test Mereology Shift operator Object-oriented programming Universal product code Operator (mathematics) Chain Right angle Codec Divisor Absolute value Figurate number
Functional programming Monad (category theory) Sound effect Bookmark (World Wide Web) Morphismus Arithmetic mean Mathematics Funktor Funktor Formal verification Computer programming Arrow of time Formal verification Right angle Monad (category theory) Arrow of time Functional (mathematics)
Angle Software Right angle Disk read-and-write head Mereology System call
Information management Dependent and independent variables Code Software developer Open source Collaborationism Interactive television Hidden Markov model Unicode Process (computing) Software Robotics Software Design by contract Circle Pattern language Quicksort Figurate number Agile Softwareentwicklung
Software engineering Complex (psychology) Software engineering Dependent and independent variables Multiplication sign Collaborationism Machine code Software maintenance Surface of revolution Root Software Software Design by contract Source code Right angle Agile Softwareentwicklung
Complex (psychology) Slide rule State of matter Code Open source Computer simulation Software maintenance Message passing Programmer (hardware) Object-oriented programming Object (grammar) Normed vector space Speech synthesis Hill differential equation Right angle Object (grammar) Quicksort Imperative programming Resultant
Computer program Message passing Goodness of fit Ferry Corsten Right angle Object (grammar) Endliche Modelltheorie System call Sequence
State observer Mathematics Message passing Polygon mesh Object-oriented programming State of matter Pattern language Object (grammar) Game theory Endliche Modelltheorie Field (computer science)
Computer program State of matter Code Semiconductor memory Consistency Multiplication sign Order (biology) Right angle Object (grammar) Quicksort Endliche Modelltheorie Sequence
Data model Game controller Game controller Mathematics View (database) Direction (geometry) View (database) Pattern language Circle Right angle Endliche Modelltheorie
Computer program Object-oriented programming Revision control Endliche Modelltheorie
Point (geometry) Complex (psychology) Functional programming State of matter Student's t-test Attribute grammar Product (business) Formal language Software bug Power (physics) Object-oriented programming Average Radius Software testing Physical system Kolmogorov complexity Gradient State of matter Student's t-test Category of being Type theory Number Message passing Circle System programming Social class Software testing Object (grammar)
Software engineering Functional programming Kolmogorov complexity System programming Electronic mailing list Codec Software testing Right angle Software testing Cycle (graph theory) Category of being Computer
Functional programming Computer program Greatest element Observational study Divisor Java applet Code Line (geometry) Multiplication sign Relational database Set (mathematics) Student's t-test Formal language Number Different (Kate Ryan album) Software Programming language Dialect Observational study Software developer Expert system Code Sound effect Chaos (cosmogony) Semiconductor memory Formal language Right angle Prototype
Right angle Client (computing)
Microprocessor Code Different (Kate Ryan album) Factory (trading post) Projective plane Virtual machine Bit Circle Right angle Product (business)
Computer program Trail Code Multiplication sign Virtual machine Sequence Declarative programming Microprocessor Military operation Factory (trading post) Operator (mathematics) Right angle Process (computing) Representation (politics) Routing Data type
Trail Trail Poisson-Klammer 1 (number) Electronic mailing list Virtual machine Sequence Disk read-and-write head Process (computing) Military operation Function (mathematics) Operator (mathematics) Process (computing) Representation (politics) Routing
Boolean algebra Functional (mathematics) Poisson-Klammer Electronic mailing list Disk read-and-write head Mereology Disk read-and-write head Electronic signature Element (mathematics) Type theory Roundness (object) Different (Kate Ryan album) Personal digital assistant Military operation Function (mathematics) Operator (mathematics) Factory (trading post) Telecommunication output Pattern language Nichtlineares Gleichungssystem Data type Routing Social class
Slide rule Computer program Code Constructor (object-oriented programming) Expert system Subset Type theory Computer configuration Computer configuration Operator (mathematics) Right angle Object (grammar) Data type Routing Row (database) Social class
Computer program Trail Functional (mathematics) Java applet Electronic mailing list Bit Disk read-and-write head Disk read-and-write head Type theory Process (computing) Computer configuration Computer configuration Military operation Function (mathematics) Operator (mathematics) Formal grammar Arrow of time Routing Writing
Functional (mathematics) Computer configuration Computer configuration Military operation Function (mathematics) Operator (mathematics) Electronic mailing list output Arrow of time Routing Tuple Number
Boolean algebra Code Multiplication sign Electronic mailing list Virtual machine Line (geometry) Element (mathematics) Computer configuration Personal digital assistant Military operation Function (mathematics) Summierbarkeit Nichtlineares Gleichungssystem Routing
Operations research Slide rule Frequency Multiplication sign Time zone Set (mathematics) Endliche Modelltheorie Mereology Sequence Physical system
Time zone Multiplication sign Time zone Virtual machine Electronic mailing list System call Sequence Element (mathematics) Element (mathematics) Military operation Operator (mathematics) Representation (politics) Right angle Routing
Point (geometry) Trail Time zone Trail Information Code Time zone Electronic mailing list Similarity (geometry) Element (mathematics) 2 (number) Element (mathematics) Type theory Process (computing) Military operation Operator (mathematics) Queue (abstract data type) Right angle Process (computing) Quicksort Routing
Time zone Trail Time zone Electronic mailing list Element (mathematics) Element (mathematics) Military operation Operator (mathematics) Queue (abstract data type) Right angle Process (computing) Endliche Modelltheorie Routing
Computer program Addition Functional programming Functional (mathematics) Information Code Time zone Electronic mailing list Mereology Element (mathematics) Element (mathematics) Type theory Military operation Energy level Endliche Modelltheorie Object (grammar) Routing Physical system
Time zone Trail Functional (mathematics) Multiplication sign Electronic mailing list Disk read-and-write head Element (mathematics) Disk read-and-write head Element (mathematics) Process (computing) Computer configuration Personal digital assistant Military operation Function (mathematics) Queue (abstract data type) Routing
Point (geometry) Time zone Code Multiplication sign Time zone Limit (category theory) Element (mathematics) Element (mathematics) Process (computing) Computer configuration Military operation Operator (mathematics) Queue (abstract data type) Routing
Time zone Randomization Trail Code Multiplication sign Time zone State of matter Electronic mailing list Public domain Limit (category theory) Element (mathematics) Element (mathematics) Military operation Operator (mathematics) Order (biology) Queue (abstract data type) Process (computing) Routing
Point (geometry) Dialect Functional programming Computer program Information Code Multiplication sign State of matter Public domain Limit (category theory) Element (mathematics) Type theory Military operation Telecommunication Queue (abstract data type) Energy level Game theory
Internetworking Multiplication sign Musical ensemble Line (geometry) Mereology Wave packet
Point (geometry) Functional programming Programming paradigm Different (Kate Ryan album) Internetworking Multiplication sign Endliche Modelltheorie Formal language Vulnerability (computing) Number
Point (geometry) Functional programming Slide rule State observer Presentation of a group Functional (mathematics) Code Multiplication sign Parameter (computer programming) Number Computer hardware Endliche Modelltheorie Data structure Imperative programming Descriptive statistics Dependent and independent variables State transition system Electronic mailing list Interactive television Bit Software Interrupt <Informatik> Pattern language Musical ensemble Abstraction
Torus Computer program Functional programming Context awareness Code Java applet Multiplication sign Mereology Order of magnitude Formal language Computer configuration Formal verification Imperative programming Algebra Physical system Vulnerability (computing) Electronic mailing list Sound effect Bit Variable (mathematics) Electronic signature Microprocessor Type theory Proof theory Category of being Right angle Reading (process) Spacetime Slide rule Functional (mathematics) Number Revision control Goodness of fit Object-oriented programming Queue (abstract data type) Monad (category theory) Nichtlineares Gleichungssystem Default (computer science) Validity (statistics) Chemical equation Projective plane Interactive television Line (geometry) Limit (category theory) Compiler Integrated development environment Allgemeine Algebra Spectrum (functional analysis) Abstraction
Functional programming Slide rule Implementation Functional (mathematics) Code Multiplication sign Control flow Public domain Client (computing) Number Formal language Mechanism design Mathematics Roundness (object) Object-oriented programming Different (Kate Ryan album) Modul <Datentyp> Social class Module (mathematics) Bit Lattice (order) Instance (computer science) Variable (mathematics) Wiki Process (computing) Telecommunication Right angle Object (grammar) Routing
Sic Cartesian closed category Musical ensemble Semiconductor memory
[Music] so our first talk is going to be presented by two speakers Michael River and Nicole well Michael is the CEO of active group he's been developing software and teaching programming for over 30 years and Nicole is an independent software developer focusing on domain-driven design and event streaming and she she's been organizing software craftsmanship conferences so please give them a big round of applause for this time good
morning everyone ah this thing is on so hey it works excellent cool so so crossing code I think before we say farewell we should think about what it actually is and so I thought I'd maybe get a presentation first haha okay so first maybe we should talk a
little bit about what soul-crushing code is and so I brought something for you for your entertainment and here we go
this is some code I found in an Eclipse tutorial if you know a little bit about eclipse you can see this by looking at this icing here yeah and this actually I mean I have no idea what that this does you know you have this adapter Factory which is really like okay and then we get an adapter and there's lots of stuff going on but what actually is this doing so there's two do okay this gives a hunch at this might be this famous to do example but then I have no idea what's happening here but maybe that's just eclipse right in Eclipse everything as an adapter for
yeah okay maybe so okay I had expected you to say something like this so I thought I'd bring another example and this actually is from an open source project and this actually isn't native
query interpreter initiator I also want an interpreter initiator who doesn't and also it's a session factory service initiator wow I'm getting impressed so and then it also does lots of stuff and then okay we have initiate service and then we have another initiate service and then at the end Wow we have this get service initiated well okay so fine but I mean that's just a bunch of kids doing open source software right yeah those are all hobbyists right so I mean what would you expect from something like that right okay I brought I brought a professional example oh I so here's a here's a professional example so this is from a system that does queries of some sort I think there's a shape and translation from German to French to English in here somewhere so you can see that it does either full-text search or it does non full-text search or something like that and so obviously in the initialization of some C++ class it checks that flag and instantiate some object either to the full-text variant or the non full-text variant right and you would think this is object-oriented design you just go and call methods yeah that one instance variable that you have there if an else is so object-oriented yeah well that's just the constructor right this is not the bad part the bad part is that every single method that actually does something like this one looks like this right it checks that flag again and it either calls for text oh sure which is I guess also has something to do with full-text search you can see that there's lines commented out and nobody nobody remember to leave a comment as to why it's commented out and you can see that this code is really fragile right if you want to maintain that kind of code every method looks like this you always need to remember to check that flag before you do anything to be sure that oh I'm here or I'm there okay yeah so I mean okay so the fact that somebody uses an object oriented programming
language does not necessarily imply they actually understand what object orientation is all about right so maybe they are just crappy programmers okay so k happen to use this and then they messed it up on the way you know many non crappy programmers can produce crappy code and now you're getting me confused I think you I have you have another example yes I have a much better example here a real object-oriented
example so this is finance finance right so here we have options in this case just call options and so the the financial guys want to talk about those options but there are so many different kinds of options so they cannot talk about each of them individually and so they want to group them together in something they call a basket so up here you can see this basket and it contains Google and Facebook because they are sort of like the same you know so they just grouped them together in this basket and then they want to talk about
properties of this basket of all those options that are contained in it and for
example here they implement this market data and so this is standard object oriented business like everything is a class right and there we have two methods in there because that's also standard object oriented business we have a class and then we have methods in there and one of the first method gets but just gives us the spot price so all of these options have a number in the real world and that's why they number this year and for the fun they call this C column I have no idea why this seems to be a French word for I don't know what it means but yeah just go with this so so this maturity thing that's the date at which point the option expires yeah so that's for the volatility so you get the volatility for an option and option is defined by the underlying asset and by the date it's due and also by the price it's supposed to have them and that's what is encoded here so we have the option with this long and then we have the maturity which is a point in time so we can properly use a double for this I think and then we have the strike which is a price and probably some of you know that it's not a very good idea to deal with money in terms of doubles but on the other hand it's fairly common in banking so let's do this here as well okay fine so yeah that's it yeah and then what what they actually want to do so they don't only want to look at the world as it is but you know those guys with the suspenders you know they want to and I love analyze and see what what might happen if something would happen you know so they want to play what if games and for this what-if game here and they take the spot price and they actually want to shift it so they want to say what if the spot price were different and what would happen then with my options right and here they just you know so if you want to modify something in object orientation you write a derived class and this is the derived class spot shifted market data and this derived class overrides the get spot method and it takes the value of the of the parent class and multiplies it with factor okay sounds straightforward so far and then of course they don't only want to multiply this with a factor but they also want to do other modifications and I want to be able to do all these modifications without recompiling so they want to play around with these and they don't want to recompile their code every time they change something so they want to have a dynamically configurable code base so to speak or dynamically configurable market data and if you look this up in the object-oriented literature you come up with the
decorator pattern and so the decorator pattern is something that allows you to dynamically modify your code so you have a component and then you derive a
decorator and the decorator as a delegate to something else you want to plug in basically and this is how they
implemented the delegate so they wrote the decorator as a derived class and then they have their there they have the the real object in there and for the get spot method here they just ask the get spot method of the underlying object fair enough and now going back to the
baskets where I started out initially so what they did in this one derived modification here they multiplied with a factor and now in the basket they they get here here they get a bunch of of options say or a bunch of assets and now that I want to calculate this for all of them and they go into this recursively and it's very hard to see here but what
actually happens is they go into this recursively and and do this this modified operation for all of them and because of late binding it happens that they keep getting through this upper method again and again so adding the factor again and again and of course they did not figure this out by looking at the code because like I said really hard to understand and of course this is all just small snippets of the code but this is the essence but they found this because the values were incorrect right and so what
they did is they compensated for this and for example here is the most
interesting part I think does the first market data derive from the second one so they check whether they have this chain going on and then they do something differently well I mean this is production code right and this is still in operation and probably this method by now is like hundreds of lines long because they had so many educators they need to compensate for well yeah so you can imagine that but but I mean it's obvious they just shouldn't have done this in C++ or using object-oriented programming right so absolute lights on
this you have people should have used functional programming right which is great I forget this yeah functional programming person here on stage so function programming has all these advantages right it you can you can have an immutable data immutable data means
you have less coupling you don't have these complicated effects going on that you saw earlier maybe you can function program he's very close to mathematics so you can apply formal verification and that's carry yeah and you can use all these great mathematical things in there you can have kettle morphisms you can have by functors that's my new favorite thing monads monadic pro functors is also something that we've been using lately that's great twice the arrows there's all these wonderful things in functional programming and they solve all of these problems yes I could why are you laughing who's laughing I should have imagined you saying
something like this so but have you ever considered that you're tackling the
problem from the wrong ankle angle I mean you and your horde of IT tech nerds you're sitting in your cave hacking away having your hood over your head and just sitting there and hacking and hacking so that problem solved okay yeah and I mean really just throwing tech up the
problem is not a solution it's actually part of urban Andy call we're a producing software we are producing tech right have you have you gone through this thing here there's check outside everywhere that how do you make that probably not by sitting in the corner and just writing hacking away okay so have you considered that there is more to it that does not
only just tech that you need to talk to each other mmm-hmm yesterday I saw this robot walking around in a circle and it said I need new code please talk to me right this is something like this okay so we need to talk to each other it's not only tech tech it's nice and and everything is the worst sort do you have like a pattern manual for that a pattern manual yes of course there are talking patterns actually for people like you okay hmm so go ahead so educate me okay so I mean there were many approaches over the years right some approaches were for
example looking at agile software development you know and it says individuals and interactions over processes and tools tools tech okay so let's talk together and let's figure out things okay well then does say working software also write one of for you now
says working software because of course we also want working software right yeah I mean just talking and no coding is also not the answer so anyway so last year we were at this conference right and you were probably talking to
somebody but I actually attended the keynote and it was by by somebody who talked about what worked and what were the ongoing problems in software engineering and this was an agile company right they do everything in an agile manner so supposedly they communicate all the time but still when they look at where they spend all of their time and all of their work and effort they say that they still spend 53% on maintenance and complexity and not on new features or I have no idea what that professionalization thing is actually but it takes up 1849 so so so let's get back to the technical problem shall we okay yeah so I mean we already saw this right on the market data example I think much of this
maintenance and complexity problems is caused that we're in a world consisting
of objects and so everybody jumps on this object-oriented bandwagon right what they actually end up with is
something like this okay and this is sort of not helpful so maybe but I I would like to explain this maybe in a different way so modern
object-oriented programming well you can all laugh of that slide before but we really need to understand the problem right the technical problem is this right so so at the at the heart of more
object-oriented programming something called imperative programming where all these objects that you showed on the previous slides they have what's called encapsulated state okay there's some state in there and what happens is the world progresses by all these objects sending messages to each other and as a result of a message some code gets executed that modifies that encapsulated state now the thing was I mean object-oriented anning was originally developed to support simulations of the real world and the problem is that the real world just does not work like that the real world is not a bunch of object sending messages to each other so one simple example that maybe can help explain that is there is an elephant speaking of elephants right yes great elephant slide so so there's an elephant
and the elephant comes in from the jungle and walks into some kind of room right and the object-oriented model for this as well all the entities get models get good objects so the the elephant has an object the jungle has an object and the room that the elephant enters has an object that represents them and you have the sequence of method calls or message a sense that that to reproduce that sequence as well you know the junk that the elephant exits the jungle and the elephant enters the room right the problem is that the exiting of the jungle and the entering of the room are one at the same act so the real world has dependencies is not just a bunch of isolated entities that are sending messages to each other things hang together in the real world so if so I think a more useful model for thinking about programs and how programs should model the real world has to do with has
to do it should really go through the
way that we perceive things so if you watch a soccer game these days there's lots of objects that you see right so you see 22 players maybe you see a ball you see the referees and you see lots of people in the audience and they all move now
so they all changed their internal state if that's the model that you use now if you want to know what's going on in the football field you need to observe all of these changes but do you know what the object oriental is for observing changes something called the observer pattern which means that you register which each of these objects and tell them well you know if anything changes with you send me a message you know your ball sent me a message if you move you know you do that with all the players supposedly you do that with all the twenty thousand audience members and so and of course when you leave the stadium you all sent the messages oh no I'm no longer interested in what you're doing right the odd the world doesn't work like that it has another problem is that all these meshes messages will arrive in
some sort of sequential order and that also would mean that with all of these objects move around moving around we would observe inconsistencies all the time the same way that we observed it with the elephants going into the room right if you remember there was an there was an inconsistent state in the middle here which was that that after the first
step the elephant is for a brief amount of time is nowhere right it has exited the jungle but it has not entered the room yet and the same is true of course
if we have many moving objects but yet we never observe like one person getting up and suddenly appearing in another place or two people appearing in the same place at the same time and that's because our perceptive a brightest creates consistent snapshots of what we observe right we look at something and it gets stored in memory and we can think about it for a little a little amount of time and analyze what's going on and so and of course you know we remember things that were in the past which is also something that an object-oriented model cannot do so I think there's fundamental problems with this object oriented model of programming and that's one of the fundamental things that leads to that soul-crushing code that we've been talking about yeah that actually reminds
me of a very interesting thing that lots of people are using and that's in the UI and it's called the MVC pattern or Model
View controller and if you have ever worked with this you can see here that this all goes in circles and you can go in any direction and then you end up here again or you go this way around or anything or follow this dashed line and and so you can go from anywhere to everywhere and this leads to the obvious
problem that if you have changes in the model and changes in the view they need to hopefully be corresponding or maybe not and what do you do about this so what you end up with if you do this enough and if you aren't very very careful you end up with this right
certain inbc fraught programs have always looked like that right yes Wow repeals really familiar doesn't it yeah yes and I think that's also what Alan Kay was talking about back in the day so
this is a quote from 1996 but I think the the paper just appeared then but the original quote is as much older and so he said okay oh he had those motivations that we described here but eventually we need to overcome this model and we need
to find something better and eliminate it altogether is what he says here okay but that never happened right no I don't think so it never happened so if these days if you look for exam
bowls of hot object-oriented programming works it always is about encapsulated state that Alan Kay wanted to to get rid of so I think that's the first thing when I searched for object-oriented examples was something with students and you can immediately see that a lot of
attributes that you have there go through some kind of some method that modifies them my favorite one is that you have the student and you can set the grade point average of the student so you can just yeah so if you're not happy with the grades that your kid is getting you just sent the object a message you know get your get a get a perfect GPA there so and and and let me reiterate me call of course people should have used
functional programming which has all these simple languages less complexity higher productivity less bugs you know
we have all these powerful type systems we can do property based testing we can
do well goes on and on we get more predictable behavior generally testing is easier because we don't need you know setup and teardown methods you get lower couplings you have fewer dependency cycles so so I didn't I didn't even say monad right here in this list so you get all that we agree you get all these concrete advantages from doing functional programming right and so that's what people should do to solve those problems so do you remember Fred Brooks he said there is no silver bullet
okay so an old guy right yeah and what about you yeah I guess I am too I'm getting there yeah well so book said that but he's an old guy so let me let me get you
one one example of why that maybe is not true so in the early nineties actually there was a big study conducted by the US Navy on the effectiveness of different programming languages and they had one set problem that was about determining the regions of influence of warships and they had different teams write solutions for their problem in different languages and what they ended up doing is also is is they gave that
also to people who were using functional programming specifically in the Haskell programming language which was still pretty young back then and you can see well the solution Haskell is much shorter than the solution you know C++ definitely you know less than ten times as short then the C++ solution I think Java wasn't as big then but I think the factor would also be around between three and ten somewhere also what's maybe interesting is that there are two Haskell solutions one at the top and one at the bottom and probably they just split the code so the numbers look nice yeah yeah you would need a cannot that would be interesting but what they did is they had they had a Haskell expert write a solution and then there also gave the solution to a student I think will learn Haskell for two or three weeks and was will also wrote a solution and you if you look at development time so somebody took ten hours and somebody took eight hours and the eight hours is this student that's because the the Haskell expert Haskell expert tried to put many interesting flourishes and super cool programming techniques into the program but the student was actually doing pretty well so if that is not a silver if that's not what a silver bullet looks like I don't know what would okay so the Yale study right yeah they got a fixed set of instructions and they just had to code those instructions do I remember I remember that yeah yeah okay so do you ever experience that in the real world getting a fixed set of instructions from
your client and then just implementing this and they never change their mind they never come up with new ideas they never like say oh I forgot something well I actually don't experiment and say let me think about it maybe you can
that's what we need to consider as well
coming back to the elephant right okay talking to each other everybody has different ideas start with that agile stuff again everybody has different ideas when they look at something and everybody describes things differently
and so what we need to do is to figure this out together you know coding a bit talking a bit looking a bit coding a bit and so this needs to go hand in hand and this is sort of agile you know so that doesn't mean scrum and you know standing in a circle every day as something relaxed okay so so I I personally I like to communicate with code yeah so you think
example that we that we were working on their project oh it wasn't a semiconductor Factory so this was how so
really is that serious business I think anyway so when we started this I don't
know well you all know this right when we started this I thought well semiconductor the way it gets made there's a big machine you put in a piece of silicon and you go like this and and junk and out comes a microprocessor and it doesn't doesn't really work that way one of the reasons is just that a modern the modern chip consists of many layers another one is that there's just many different production steps that are necessary for making even a single layer and some of the machines that make a layer are so expensive that you can't
just make an assembly line and also a lot of things break tend to all the time in a semiconductor factory so it makes no sense to just have an assembly line and pushes things through that but things just move around among the different machines in a semiconductor factory right and so what's important is that each chip under or each wafer undergoes a sequence of steps in the factory and that needs to be managed and those steps it's it's typically for for big microprocessors that might be like a thousand steps so you need to manage
something that's that's called a route which is well just a sequence of operations and now here there's a bunch of Haskell code atha is great because the programs are so short that they fit on slides but if there is something unclear about that code then I invite you to interrupt me and ask so first of all you can read that declaration at the beginning says data operation and what that's just a simplified data type that describes what an operation would be and
it says and you can read that vertical bar as or so it says an operation is either track in or process or track out and tracking in just means putting away for into a machine and processes you do something inside the machine and track out as you do take it out of the machine okay and then the next thing is that the route is just a sequence of operations and these brackets that you see there they mean list off so what it says as a route is a list of operations and down here you have an example for a route for a very simple route that says well one route route number one might be a list of the following operations you put away for into a machine you process it you process it some more and then you take it out again there so far everybody nod everybody was still awake nod okay so don't don't be don't be afraid to ask
so one thing that you do is is when you
have data types as you just saw is you define functions on them that describe some aspect of what happens in a fab and a semiconductor Factory so in fact what happens of course is you need to execute the next step the next operation that happens as part of making a semiconductor and for that we're making a function called route head the head of the route and what you do is you write a type signatures and type signatures are
very good for communication actually so you put in a route and you get out a single operation and then you write equations that describe what that function would do on different aspects or different classes of input so in this case you remember a route was a list of operations and lists there are two different kinds of lists one Kuip of lists is the empty list and the other kind of list is a list that has what's called a head or a first element and arrests and because there's two kinds of Lists you write two equations and so that's why you see two things where it says round had something equals to something else and the first equation is for the empty list why that's this is why that you have these two empty brackets and the second one that says well it's a non empty list and the first thing in that list is is some operation up so there's something called pattern matching you match this on to the actual list that you see and up then gets bound to that first operation and we don't really care about what comes after that first operation and so the second equation is pretty clear if you want the head of a route that is not empty you just take the first element of that okay so far and the other equation says well what do we do with an empty list right an empty list does not have an operation so you're saying you're into
the second slide of your beautiful Haskell code and you already don't down our to write them well so we're communicating right okay okay so okay so you're talking you're talking to some of the expert and you say well you have got an empty route what's the first operation of an empty row and these days with empty routes they don't really have the first operation they only maybe have an operation sometimes they don't so for that we can create a data type that says
that something might sometimes be there and sometimes it's not and we'll just call it option if they're a hat are they anything Haskell programmers in this room oh okay so this is built-in of course that's the maybe type but but I'm just making a separate type called the option type and that says well the a says it can be anything right anything an option a means it can either be there or not and for that it has two constructors or two different classes of maybe objects and one are called the some objects and the other one are called the none objects maybe we'll start with none so anything can be a nun it just says that anything is not there right so anything can be of type option of a and it means it's that something is not there and that is the type of that particular constructor the other constructor says well that thing actually is there and so the constructor has to accept something of type a and then give us something of type option of a okay so you're saying it wraps the
subject yeah I wraps the object okay and so if you're not that's grammar but maybe maybe an f-sharp programmer or we're an ml programmer then that is what it looks like there and I believe it's even built into a Java these days something called optional yeah so and now that means we can change our road
head function a little bit because our first attempt didn't work out and instead of saying route arrow operation rewrite route arrow option operation may seem trivial to you but it already communicates a tiny little bit of something so and then we can write route head of the empty list is none so there's no there's no head of the empty route or if we have an operation coming out we just write some in front and so if we use that example route that you saw earlier where our one was tracking process process track out what we get is is some tracking ok so so that type communicates a little bit of what we do because always it's already
calling the shots very good the next thing that we might want to do is we don't want to always know only the first operation we also want to know what happens after that so we can use that option and we already know that of course an empty route will not have something coming after that first operation so we could write another function called route advance and it takes a route as input that's to the left of the arrow and it gives us both an operation and a route that's why there's these two things in parentheses
with a comma in between so that's a tuple so it gives us an operation in a route but only sometimes when that actually exists which is why there's an option wrapped around that so what we want to do is if we take our route number one we want to split it into that first operation in a list of the rest so it should split out the track in and then give us a list of the remaining or a route of the remaining operations that are in there okay so far so it gets technical don't be does anybody have a question ok so don't don't hesitate to ask I'm looking at the clock ah so and then this is actually pretty easy to write now again we need to make two
equations because a route is a lists and lists always need two equations so we can say route advance or the empty list has none and route advance of up and the rest is we just return a sum off op and the rest because the list already splits exactly along the line that we wanted to between the first and the remaining elements right so this is just very simple code or at least a short code that communicates what routes are hmm right I see and so if I remember
correctly I mean you said you put the wafer into the Machine and then it processes it if I remember correctly some of these processing steps can be chemical reactions or something and so it might be the case that they must happen in a certain amount of time or something that's not sure yeah okay so what we could actually do is we could
model something like this yeah I sneaked at you're part of the slide so I check the same okay so what we actually could do is we could model something like those three steps here need to happen together in a set period of time yeah so that's yeah so the chemical reactions mean that your wafer might go bad if you don't if you know if you start the sequence of steps and you don't finish on time then your wait for those like acting and watching for example if you H too much then yeah okay it's always that's always a problem in existing systems okay cool so maybe I can try and see how I can model this into your
existing code okay cool so let's have a look so what we first need is we we had
this rod element here with this operation right and now we need another representation for a route element and let's call this route QT zone for Q time zone and there of course we have the duration that means the amount of time this step needs to be finished in or the sequence of steps needs to be finished in and then we have this list of operations here we saw this before right the list of the operations and then what this gives us is of course again a route element so we can combine like ordinary steps like putting the wafer into the machine doesn't matter how long it takes maybe it blocks the machine but other
than that no no issues come from that but if we do the etching and the washing for example we would need to have a few times around because we need to restrict the time that that this takes in conjunction right it's that correct so far yeah good and then if we look at our
example this is the previous example we had here we could create another example where is my there are - and here we have a route queue time zone say it may only take five whatever seconds say and then we have two processes here that need to be finished within five seconds and then we do the track out again okay so far so clear good and then if we look at this
and we discover that here we have this route element list and here we have this operation list this is actually sort of similar isn't it so maybe we can make something out of this and maybe we can actually turn this down here into route elements as well oh so that's what you were doing before right before they are it said up there it also said list of operation up there yeah up there when it's a type route when you start at my code my code had route equals list of operation right and now you did the same thing oh yes yeah right so now it's now it's the same okay again right so it's both route route elements yeah good point and now if we look at this again so maybe this actually means that this year is not just a list of route elements but maybe this is actually a list of routes it's actually a route down there so I actually derive some some information here from the code so we discover that our out queue time zone actually contains a route so what oh all
right so if we look at this here what we then can do here with this route element
so here we could plug in any route element right for example we could plug in a route queue time zone which is also a route element so coming from this
example here where we have just a flat list that just contains some route operations and a route queue time zone and then a route operation we could
also stack them into each other so a route queue time zone could again contain a route that contains the route queue time zone that's for you know what happened because know we can nest queue time zones and that's something that occurs in reality oh really does it and so you're on your model has suggested that but now something that our old IT
systems based on object oriented programming couldn't model from its pre 8 so now I understand why you're aiming at function approach that you can model exact better with it yeah and this is pretty cool so we discovered this in the code and then we were able to get back to the to the business people and check back with them whether they would actually see this in practice and whether it's a valuable addition here and we just covered that just from looking at the type information we had yeah and then we can continue this and
because now we have this list of route elements down there we could actually say oh yeah a list of route elements we know what that is this is actually a route and now we like go one level up so whenever we we learn more about routes or whenever we change this here this route thing it will automatically be reflected in here because we we abstracted it right and that's what functional programming is all about abstracting things and figuring out what the common common parts are right I noticed you bring with me very good excellent so and now we can also of
course check how our functions will be modified because now we need to go to all of our functions and see you or that I still work and here we have this route head and also route element head and now we need to extend this because the route element had works on the route element and now we have a new route element which is the route queue timezone and of course if we want the route element head of the queue timezone this is of course the head of the containing route and we have this neat function up here already routed which gives us the head of the route and so we can just reuse this year so even this has become simpler for us to implement because we have discovered that there is a route in there instead of just a list so no special handling we can just revert to the standard function we already have and if we look at the route
advanced so if we want to proceed our route to the next operation and and you know proceed to the next step then of course we also need to add this year the queue timezone and now the question is what happens if we if we advanced into a queue timezone process because somehow we need to keep track of when does it need to be finished so we initially we said ok it may only take like X time or D time and now we need to keep track of whether this time is already taken up or not and so in this case what we actually
do is we need to add another route element and that's a route queue time limit which which defines when a started operation needs to be finished so it has an actual time which is the point in time like now duration or something just the finishing point in time and then it's just the same as the route queue time zone so this limits our process up to this end point of time and now we can
we can imply and our route advance because whenever we have a queue time zone that's where we didn't know what to write before so whenever we advance this route then we know that we need to come up with a route queue time limit here and whenever we have this queue time limit and we advance over that one then we know that we just need to basically behave like before we need to split this up and also keep our time limit of course and then just proceed into this this limited while while keeping the time limit and here if we if we start this out then we need to determine the the end point so we take the current time which we now need to pass in here at the top so we take the current time add the duration and then we know when we need to be finished with this process and then in here yeah we just we just work on on every step while keeping the time limit so the your code suggested that there was a gap in your understanding of what needs to be represented right yes so I
didn't know what to put to the what to implement for the year out advance yeah and now I know that yeah watching this I'm thinking that there's still a little if I look at it with the eye of a domain person I think there's still a little problem in there Oh which is yeah if you
look at this right remember a route element is something that can occur anywhere in the middle beginning at the end of a route so it has these three things obviously we can have queue time zones anywhere we can have operations anywhere but the thing is we can only enter a queue time zone when it's at the beginning right oh I see so so you know
here we could have a random list in a random order yeah that's right it points oh so you can't so this suggests that the queue time zone has been entered because there's your out queue time limit but there is even though there's still an operation there in front of it okay that doesn't make sense yeah that makes no sense so we if we could go back from the domain knowledge to the code now
we could refine that type further and we could pull out the queue time limit from that type down there because these are all the things that occur in the middle of a route and and pull it up to a top level type and introduce an immediate intermediate type that distinguishes between what's in the middle and what's at the beginning oh is he that's neat so that's what we now have is we have this back and forth between the code which yields insights about the domain and the domain and from the domain back to their code and we can play that game we can use the code for communication yeah so that's what I intended so that you can understand this yeah so that code no longer crushes my soul actually I can say that yeah right same here so cool okay so that's what
the point we wanted to make so if you take functional program programming and if you add communication and discussions and this going back and forth and learning from both sides and enriching both sides with the information coming
from from the other part then you actually end up at a silver bullet everybody's looking confused that's a so that's a bullet train a silver bullet train okay we're done [Applause]
[Music] for a very entertaining talk we have
some time for questions Q&A so if you have any questions please line up next to the microphones we have four microphones but across the room and we'll start from a question from the internet from the internet as an FP big
nerve with a weak p??kerman MF would it be preferable to learn functional programming in a pure functional language over languages they are multi-paradigm so I'll take that one okay so so I think the point is that there I mean there's many there's many different functional programming languages and Haskell happens to be what's called a pure one but there are also languages that are hybrid between object-oriented and functional programming Scala I think is a prime example right now and I mean these are
Scala is a fine language the problem is if you want to combine these two paradigms you typically get something that's pretty complicated so Scala is a complicated language that takes more time to master also because you have all of you have both paradigms available to you at both times at all times it's sometimes it you often get confused about what paradigm you should use in a in a given situation so I think both of us we haven't really seen the great advantages you get from that hybrid model also the problem is if you're a learner in FP and you try to tackle this with something like Scala you will inevitably fall back to what you know if you run into problems and so maybe just jump into the deep end and try to swim and see where you get at and get help on the Internet yep number two
[Music] yeah I was a good presentation thank you every time I see some functional programming it it it's refreshing and it's interesting but the description of your presentation was talking about using functional programming in IOT so
there was nothing specific to IOT in this presentation there was no interaction with the hardware no interrupt handling no nothing how do you handle that for example a good point I think we drew I think we had a bunch of slides of that that we ended ended up dropping because of time but so my argument would be that IOT is the LTS the software is the same software is the same software as any other software what's special about IOT is the risk that emanates from IOT obviously so if you do things like so if you want to do things like interrupt handling I think my response to that would be to convert it into into functional data structures and this gives you a deterministic model for handling that kind of stuff so so we talked about that I think we talked a little bit about the observer pattern which is analogous to what usually happens with interrupt handling which is what you were talking about and and the way to do that really is to have of course we have a tiny bit of imperative code that hooks your functional code to the hardware or whatever it is but to convert your interrupts into a list and you can ask Lashley's pretty good at that and that then gives you all the advantages of functional programming the testability the funny the the funky abstractions and you can use that even on the interrupts and it turns into software just like any other functional software microphone number one hi thank
you for your talk I have to write code
for microprocessors and most of the time I only have a C compiler and if I'm lucky I get a C++ compiler where can I get a silver bullet the the old Haskell compiler used to compile to see nowadays it doesn't do that anymore by default but probably you can make it to that still yeah there's a number there's a number of function languages that compile to C so it's kind of difficult to give one a one-shot answer we've also done a project for example where we get a lot of the advantages from functional programming by writing code in Haskell that generates the C code right and so there's a whole space difficult to give you like one one answer without knowing more details about what it is that you're doing but there's certainly a lot of spectrum of options available in that context so functional programming is pretty concise and pretty compact so no one really wants to use large variable names and I saw in your examples like a D and TTL or T's and I don't think that there's so much better than the long versions you showed earlier like what is your take on that yes so the general so I'm also struggling a little bit with this one thing is that this was was fairly concrete code right but often you you go into the abstractions and and in the abstraction there it's it's arbitrary what you have so you can use short names because because you're not talking about concrete things anyway so that's why it's easier to use also more like abstract variable names but what I actually do is I also use longer names so I would not always use D and RT and something like that to get a better grip on this but one one important thing you must not forget is that this you have a function right and it's two lines three lines and so if you start out and you understand D and RT for example from the from the signature and reading three lines of code with a D and RT in it it's not that bad right and in in object-oriented or Java or whatever you sometimes have hundreds of lines and then you have a DNA arty and you read this for half an hour and then of course you forget what it means and so you know it's a it's a bit of a balance so I would use longer names as well probably but sometimes also shorter because yeah just the code is so so so short okay if I could add one one details I find myself using longer names and dynamically typed languages right they're dynamically type functioning which isn't there you don't have the type that spells out what that thing is all right and then you need to put it in the variable name microphone number one yeah in one of the slides you made the claim that a functional programming lends itself to proving how would you actually do this good question so that's another talk right we in practice so there's various ways of doing that so first of all as you saw right a Hasker program is a bunch of equations so you can use algebra as a mathematical technique to reason about functional programs so first of all going from going to the abstract aspect of that question which is something well you can sort of do it with your java program but it is much harder to establish an algebraic way of talking about Java programs there's also plenty of tooling available to to write to prove aspects of your programs and functional languages starting with a classic tool called AC l2 we can talks on something called Idris so there's a newer breed of functional languages where you can put more proofs into the types of your of your languages so it just turn it turns out and tends to be just a magnitude of an order of magnitude easier to prove properties of functional programming because you can use algebra and equational reasoning as you would about Java programs does that answer your question a little bit a bit but I think it rests uses like dependent types and doesn't isn't it possible to use it in imperative programming as well maybe I don't know so is that specific to a functional programming dependent types or could it be used in even the way that it has talked about imperative programming is functional right using monads by the way so so there's that and there's this whole spiel about reasoning about effects but but the thing is effect side effects it you have an imperative programming right they don't make it impossible to reason about programs but they make it much much harder and so in a functional program you tent you in a proper functional program that doesn't crush your soul you tend to have large parts that are purely functional and that allow functional that allow equation or easing and and you have smaller parts that may be making that might be a little bit more difficult that are about the interaction with the imperative environment also the thing that we did was a type system you know you remember first we had the list and we had the the RTR the the queue time limit in the middle and that was an illegal state and so we changed the type system to disallow this and so actually already the compiler tells us hey this is forbidden code right and and it's not syntactically wrong but it's semantically wrong and that's what what it's also a like a weak kind of validation or verification in my opinion yeah so we could talk about all this about this all day sorry another question from microphone number two I I
noticed that you didn't present any
mechanism to hide your implementation or to make things private but things that you can do in C++ and I don't miss those mechanism but I would like to know your take on why I think you don't miss them so why do you you don't miss them either no they exist in functional languages as well right and so the mechanisms that you're familiar with private things modules partially I would just tend to not use objects and classes for modularization I think that's the primary difference but function languages tend to always have mechanisms for doing that they're just differed between languages so it's it's difficult to talk about this in a talk we could have told you how to do this in Haskell and write a module and hide things but what if mate would have put more quotes on the coat on and the other aspect is that you don't really have to hide things because everything is pure so if you call this function I don't care you know you can't destroy anything whereas in object-oriented programming you have this change my object to really bad something you know and you don't want anybody else to call this because it will really break things and in functional programming checking some variables get something out do this as much as you want I don't care that last one is they take I love and I endorse fully microphone number three you had some slides on the importance of communication I have a hard time to see myself communicating with business people using Haskell code how would you do the communication was like normal people this actually I mean we we we clean it up somewhat but this actually happened so it's sometimes a device sometimes a little bit of a process to get there and sometimes but what you could all I mean what you notice may be in the inner coat with the routes was that playing with the Haskell code yielded domain insights that you could have also explained to somebody in a meeting right without enjoying the code yeah and so that's so the communication goes through the Haskell code maybe it not it doesn't happen you know by the Haskell code but all I can tell you is that that actually happens is we sometimes communicate with clients showing them code and talking to them about is this really what you're doing is this what your domain is like that happens something to me as well yeah so it depends on your clients you know they need a bit have a bit of resilience so they can you know and they can accept that they wouldn't understand everything but if you like to talk them through and say look here is this and this goes in and that comes out and what do you think about this and then so you just not throw the code at them but you have a informed communication say this can also be contractually enforced and I remember one instance where we did that big round of applause for this
[Applause]
[Music] [Music]
Feedback