Snakebitten: Danger and Misfortune in the Evolution of Programming Languages
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50584 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201438 / 170
2
3
5
6
8
11
12
16
21
22
23
27
31
35
37
42
43
45
47
48
49
50
52
54
56
57
58
61
65
66
67
71
74
77
80
81
83
84
85
87
88
89
90
91
94
95
96
97
98
100
102
107
108
112
114
115
116
118
120
121
122
123
126
127
128
130
133
135
137
138
139
140
141
142
143
144
145
147
148
149
150
153
155
156
157
158
159
160
161
162
163
166
169
170
00:00
Functional programmingProgramming languageType theoryNumberComputer animation
01:08
Time evolutionFrequencyExtension (kinesiology)Pascal's triangleObject-oriented programmingGraphical user interfaceLocal area networkNeumann boundary conditionComa BerenicesHash functionClient (computing)Procedural programmingRule of inferenceFunctional programmingJava appletVisual systemProgramming languageRight angleComputer hardwareHill differential equationJava appletLevel (video gaming)Programming paradigmFamilyMulti-core processorActive contour modelObject-oriented programmingSoftware developerTrailPoint (geometry)Multiplication signComplete metric spaceGroup actionExterior algebraElectronic mailing listComputer programDecision theoryWave packetTerm (mathematics)Arithmetic meanComputer clusterComplex (psychology)2 (number)Open sourceTheorySystem callUltraviolet photoelectron spectroscopyDifferent (Kate Ryan album)SpacetimeSet (mathematics)Process (computing)Execution unitElectronic data interchangeBitState of matterComputer animation
08:00
Rule of inferenceComputerNeumann boundary conditionStatisticsMenu (computing)12 (number)Assembly languageFamilyVirtual machineLevel (video gaming)Programming languageMachine codeComputer animation
08:42
Maß <Mathematik>Menu (computing)HTTP cookieRead-only memoryLogicMathematicsControl flowExecution unitoutputFunction (mathematics)Computer programMultitier architectureDatabaseReverse engineeringKeyboard shortcutFamilyType theoryProcess (computing)Electric generatorComputer programComputer hardwareNeuroinformatikMachine codeMathematicsEvent horizonPrisoner's dilemmaAssembly languageNumberLine (geometry)Multiplication signCoprocessorProgramming languageFrequencyRevision controlDirection (geometry)Variable (mathematics)Client (computing)Keyboard shortcutFlagValue-added networkSoftware developerElement (mathematics)Electronic mailing listSelf-organizationSemiconductor memoryLevel (video gaming)Perfect groupRight angleArtificial neural networkAxiom of choiceEvoluteMatching (graph theory)Execution unitDisk read-and-write head1 (number)Ring (mathematics)Functional programmingFigurate numberHeat transferVideoconferencingGame controlleroutputSpeicherbereinigungRepresentation (politics)BitSymbolic computationBlock (periodic table)Flow separationClosed setFitness functionAlgebraic closureIdentity managementState of matterEndliche ModelltheorieUsabilityTrailTerm (mathematics)Different (Kate Ryan album)Digital electronicsHigh-level programming languageStatement (computer science)Core dumpShared memoryObject-oriented programmingBefehlsprozessorOdds ratioIterationMixed realityComputer architectureFunction (mathematics)Declarative programmingMereologyDistanceSet (mathematics)Order (biology)Atomic numberComputer animation
17:46
Graphical user interfaceLocal area networkTelnetServer (computing)Pascal's triangleControl flowProcess (computing)Computer programJava appletString (computer science)Tape drivePhysical systemProgramming languageCartesian coordinate systemWindowBitType theoryRight angleWeb browserWeb pageMedical imagingSoftware developerData structureSystem callProgramming paradigmAxiom of choiceVirtual machineRevision controlJava applet19 (number)State of matterDatabaseObject-oriented programmingGradientWell-formed formulaUnit testingHTTP cookieClient (computing)Functional programmingComputer programFamilySpreadsheetDiagramPhysical systemLine (geometry)Decision theoryPoint (geometry)Electronic mailing listMultiplication signSet (mathematics)Macro (computer science)2 (number)Level (video gaming)Bridging (networking)Form (programming)Message passingBus (computing)NumberBuildingEncapsulation (object-oriented programming)Game theoryGame controllerMatching (graph theory)Field (computer science)Self-organizationCodeInterface (computing)Semiconductor memoryDistribution (mathematics)Goodness of fitInterior (topology)Office suiteData managementExpressionGroup actionProcess (computing)Parallel portProjective planeTouchscreenExterior algebraCASE <Informatik>Greatest elementComputer architectureMoving averageMusical ensembleResource allocationMathematicsTesselationExecution unitElectric generatorVisualization (computer graphics)Strategy gameCycle (graph theory)TheoryNear-ringTask (computing)Product (business)Video gameLatent heatMereologyComputer iconPortable communications deviceScheduling (computing)Observational studyMachine visionINTEGRALReal-time operating systemArithmetic meanVotingNeuroinformatikComplex (psychology)Operating systemInjektivitätLibrary (computing)System programmingDivisorTerm (mathematics)Logische ProgrammierspracheStack (abstract data type)Cellular automatonDoubling the cubeProcedural programmingTorusFile formatInternet forumUniqueness quantificationHigh-level programming languageSpeicherbereinigungJava Virtual MachineControl flowConcurrency (computer science)Active contour model1 (number)Neumann boundary conditionInternetworkingChief information officerErlang distributionMultitier architectureArithmetic logic unitBefehlsprozessorBlock (periodic table)LOTUS 1-2-3Constructor (object-oriented programming)Computer hardwareFrequencySummierbarkeitComputer animation
Transcript: English(auto-generated)
00:00
the first year. So today we're going to talk about language adoption. How many of you are already using a functional programming language? Just a very small number of you. And how many of you are considering that prospect? Okay, if I can ask a simple question
00:24
and just shout out a short answer to that question. Why are you considering functional programming? Why not? That's not quite the answer I was looking for. We'll use that to start. What else? Bugs, yes. I have some strong opinions about language adoption and actually my next couple of
00:49
talks at the next couple of conferences you'll see a bunch of talks and I don't want to say it in quite this way but they're mainly because those are the types of talks that
01:03
the speakers that the venues would like to see. So most of my talks are about language adoption and we're going to talk about language adoption from the standpoint of how we got to the
01:29
place that we are in the industry and this is how I would characterize it right now. Would you guys say that or how many of you are from Norway to start with? Okay, most of you. How many of you believe that Java is the dominant language that's used in Norway today? A few,
01:47
what about the family of Java and C sharp? More of you? Okay, so that family of language, that family of languages you would consider dominant right now. And I see very much the same thing. Actually, I was a Java writer for a long time and actually came to speak with you
02:06
a couple of times at the at the Oslo Java users group and also the Java development conference and then I disappeared for a while and the reason was that I had basically learned a language called Ruby that I like. I'd used Ruby to build a couple of startups and I thought my learning
02:26
days are over, I'm happy. And after a while, I recognized that though Ruby had a different set of issues, it has the same the same major problem, the same freight train that is coming
02:42
down the tracks and that's called multi-core. You see, I believe that in the object-oriented family of languages, we are not prepared well to solve the problem of multi-core and that means that this industry is in a bad place and that's what I want to talk about with the talk today.
03:02
Okay, so why do I call this talk snake bitten? Well, a couple of, I guess about a year and a half ago, I was on this bike path and you can see that crack and it looks flat but it's more like a hill about this steep and I'm a mountain biker. I'm actually less of a mountain biker
03:25
than I was because I'm old and I get injured more often than I used to but I was coming up this hill and you can see that there's a little eddy maybe in the crack and hiding and I was coming up this hill and normally my goal is to make it to the hill without putting my feet
03:43
down and normally I blow the climb almost at the top of the hill and so I normally step my foot off and put it right in that eddy, right in that space, really the only place to put a foot and this particular day I was feeling tired, much like running from the hotel today after
04:05
told no it's not a 10-20 talk it's a nine o'clock talk. I was a little tired and I got off my bike to walk and as I was walking up the bike is here and heard a buzzing sound next to me and there was a big fat rattlesnake beside me and I looked at him for a while,
04:22
I mean after screaming and my heart stopped beating so I looked at the snake for a while and he looked at me and I decided that I didn't want to ride my mountain bike in quite this way anymore and I think that much the same thing is happening to our programming that programming
04:41
paradigms change every 20 years ago or every 20 years or so like the swinging of a great pendulum every 20 years you go from hardware oriented languages to structured languages to higher I'm sorry to higher level languages to structured languages to object oriented languages
05:00
and about 1996 or almost 20 years ago we moved as an industry to object oriented programming so my theory is that two things are happening right now the first one is the advent of multi-core which means that we're going to have to treat programming in a different way
05:21
and the second is we're always adding complexity and always reducing the manpower that it takes to solve a particular task and as that happens the ability of the last programming paradigm to solve a problem is dramatically reduced does that make sense so that's where I that's
05:41
where I'd like to go with the talk today so in Texas we have this term called snakebitten only if you were in Texas you would say it like this snakebit ain't nothing good ever happened to him he's snakebit meaning nothing good happens to that person because that person
06:06
is unlucky of course we know those snakebit people and they're usually not unlucky they usually do things to earn the title of unlucky so what I'd like to talk about is
06:23
that sometimes we as an industry make a decision that seems like a good decision at the time and sometimes we are burned by the consequences of such decisions because we are not forward looking forward thinking enough so this is a list of languages and it's not necessarily a
06:49
complete list of languages and most of the developer conferences that I speak at are typically open source Java oriented conferences they're not Microsoft oriented
07:04
conferences but you can see that even when the Microsoft alternative isn't there they're analogs of many of these languages but the point that I want to make today is that these languages don't evolve because they're cool or because they do something that's
07:25
interesting they evolve because they solve important business problems on the right hand side so the languages and the paradigms on the left hand side are evolved because of the business
07:42
problems and the inventions that cause different ways of thinking on the right hand side so we're going to start in the best place to start any journey at the very beginning I'm going to apologize for a second I'm going to I have lost my speaker notes because I was
08:03
not prepared so I will delay you further preferences okay so we're going to start with assembly languages and this is the family of languages that basically evolved because we were not
08:27
we were not organized enough in our brains to handle machine level got to start with where
08:41
got to go from here okay we'll go without speaker notes so we moved from machine languages to to hardware level to assembly languages because we couldn't maintain the ones and zeros in our head that makes perfect sense right and this is the same reason that we move from any language to the next language we can't we need more organization to process what's going on in our
09:05
programs in our head so this is an interesting computer this is actually not a von Neumann computer it's called a mark four is it oh no the mark one another version of the mark four
09:22
and you can see lots of little knobs and cranks on this on this computer and basically what happens is you may have some variables like course direction or wind direction or elevation or target distance and you would throw all of these variables into the computer with these various cranks and it would output a solution right one set of inputs got you one solution
09:46
that doesn't sound like a procedural computer to me what does that sound like and if you know your languages so with a functional language you'll always get the same the same type of input or output if you give it the same inputs that's not necessarily true
10:04
of um of our family of languages of object-oriented languages and by the way i'm an object-oriented programmer for the most part so the computer that generally won um the first inter the um the first iteration of i guess the hardware battles is called the
10:25
von Neumann architecture now this is a pretty academic term but bear with me for a little while on the right hand side you'll see the um the cpu type features that um that provide different instructions like math and arithmetic your ands and ors and things like that but on
10:43
the left hand side you'll see something called the control unit and the control unit is interesting because it its idea was that you do something and then you advance the program counter and then you could check the values of the registers and they could be something different
11:01
does that make sense so that in your control unit what we decided very early on in the evolution of computers and languages is that when the program counter counter change the values of your registers change so the value of a register isn't the same once you set it to something
11:23
it changes over time and this is a dangerous thing there's another way to say that and you'll hear that a lot at this conference especially if you stay in the functional programming tracks you'll hear this called mutable state and um the mutable state
11:45
had a lot to do with the languages on the left hand side again right um so now we're done with the hardware languages we're decided we've we've moved into we can't fit assembly language in our head the same way that we couldn't fit ones and zeros in our head
12:04
so we needed a higher level representation of a language so we have something called a high level language and there were a couple of them that were interesting there um of course there was algol for a lot of the business computation and that um i think many of the ibm computers used and then there was fortran for the science community um and
12:22
and cobalt for the business community and then you had lisp and we did a lot of interesting academic things with lisp like um you know the start the start of artificial intelligence exploration the start of symbolic processing and things like that and if you looked at this list and you were to pick a winner based on the language features that you know about today
12:45
and everything but the ease of processing the closing parentheses you'd have to pick lisp as the winner there so often in the course of language history
13:02
and when you see a block of languages that were developed at a period in a period of time you should look at them and say who were the winners and who were the losers and why i don't know if you guys ever followed mtv was mtv popular here a little bit um well
13:22
next door to um us in austin texas and my wife and i are boring people um we're boring we go to bed at nine o'clock at night and um we don't drink much and um you know pretty much anti norwegian fun couple right well next door to us moved this guy named adam curry
13:43
and adam curry was a big shot in the days of the early mtv he was what they call a vj or video jockey and he used to rave about this show called celebrity death much when they had clay figures and you might pit like britney spears against madonna and then watch them beat
14:00
each other up in a boxing ring we're going to have our own version of the celebrity death match today in programming languages and the first death match is going to be between lisp and then um which was actually the more symbolic of the language choices and fortran and cobol which is um basically the business-oriented um lower level language
14:27
and if you look at lisp it has everything that a language designer dreams about at this stage in development think about it it had symbolic processing it had garbage collection it had uh gosh it had just about all the elements of functional programming
14:44
back in the 1950s we're finally coming back to lisp as an industry but the problems languages aren't chosen based on the cool features that they have languages are chosen based on the business problems that they solve so
15:07
we have this declarative language where you can look at the intent of the program and you can tell exactly what it's supposed to do gone gone to sleep for 50 years and with it we replaced
15:28
something that looks like this is can anybody tell what language this is in you have your comment flag over here you have your line numbers um seven blank columns this is cobol
15:43
hey we actually yeah nice good job there um and what does this program do pretty simple swaps x and y right any problems with this program well not if you wrote it 50 years ago when there was one processor and we kind of time
16:02
shared across one processor probably less powerful than what we've got on the iphone and you know we had to share this program with um with 50 people or so we time share across it but now you might put the same program um on several cores or we'd like to today um because i mean we're we're basically we can't make computers faster by making them
16:26
more dense anymore the reason is that um when when computers are as dense as they can get the pathways the circuits um have to get smaller too and right now they're one to three atoms thick we can't make them any more dense so rather than making them dense this way we're stacking
16:43
them right and that means that these kinds of programs have to make the assumptions that these kinds of programs aren't true anymore right so that we can do um like for example this program assumes that there's going to be one user and even that these statements are going
17:03
to be executed in order and neither one of those things might be true if i'm working in a c sharp or java right now the memory models are different so this is mutable state and it's snakebite and if i were to talk to the father of what we call the modern lisp or the closure
17:24
language his name is rich hickey and he would say it this way we are binding identity to value right but this changes over time so that when you check x you have to check it more than once you can't say x once i've assigned it x is always the same like it would be in a
17:42
functional language and that is more dangerous than you can possibly imagine when it comes to building parallel concurrent systems which is what we have to do with the next generation
18:00
of programming languages so what's happened is we have this cycle of von neumann architectures and since we have these von neumann architectures remember we had the program counter and then the cpu then the alu the arithmetic logic unit those things they would build languages to optimize that
18:23
architecture and then they would build computers that would reinforce those language structures and we got into the cycle and so the question i have for you is do you really believe that language designers maybe 15-20 years later actually thought about this architecture
18:42
how many of you uh we everybody has to vote now okay so there are two possible votes the first one is that language designer said ha i don't care i'm building cool language i don't care what the architecture is the second vote is yeah i believe they were absolutely thinking about von neumann okay so the first choice i don't care what the architecture is
19:03
the second choice von neumann i really cared about von neumann okay i was in the first camp and then i was looking doing research for this talk and i found this diagram on the second page of a language manual and i'm not going to say the name of the language
19:24
but i found it dated 1980 1980 on page two page two title page this this image of what
19:41
is a computer right from the creators of a language that was based on this architecture so you know being an american we we love conspiracy theories that i thought yeah i we're onto something here but basically i believe that that first family of languages
20:02
was absolutely influenced by von neumann architecture and then i believe that after that happened we were basically going to head down that path for quite a long time and that that in fact is what happened let's look at the next family of languages here again we have a a new programming
20:24
paradigm and this paradigm so far we've moved from the hardware oriented languages to the higher level languages and then we have this paper that was written um the go-to paper does anybody remember the title of a paper on the go-to programming
20:41
constructs yes go-to considered harmful yes which had a candy bar i could throw to you or something um or what i'm in norway so what a salmon or something like that um so um yeah the go-to considered harmful and basically this was one of the most
21:03
influential papers in the early format formation of programming languages that paper actually ushered in a new programming paradigm called high level languages where instead of saying um you know if x is greater than four go to line 10 i would say while x is greater than or while x is less
21:21
than four do this block of things so i basically broke down bigger problems in the procedures and broke down those procedures into control structures and go to um was gone and if i look in this family of languages i've got some really cool stuff happening here i have the fourth language which
21:42
is um a stack based language it's a concatenative language we actually have a book coming out called seven more languages in seven weeks um basically about learning languages to learn them because the first seven languages was so popular um but in seven more languages we introduced factor because it's a great way of thinking about programs and you find yourself rather than writing quick
22:05
functions you do a quick computation and then that's automatically pushed on the stack and then you can use that in the very next computation or you can do four quick computations and then you could say sum those up and so you find that it's a lot more concise for doing
22:20
things like complex math and things like that and then you have pasco um which i think is a very wise language it's a language that i learned to program in um maybe it's not um as um as high level with something like a lisp um you know or an ml where they teach k-merge and mit programmers but i think that it's it has a great way of helping you organize the way that you
22:42
think and then there's one of the first objects were in languages um one of the most popular logic-based languages um there's the cnc plus family of languages and then there's a language that um is actually a functional language that we base most of business finance on what's that language
23:01
well it's buried it's it says visiCalc there but it's the spreadsheet if you think about it that's a functional language it's never unit tested and it's running many of the world's currency systems today right that's how we calculate um many of the formulas it's amazing to me that the world economy survives the way it does with the amount of code that's out there
23:24
and that says to me that was a pretty good programming language but what was the winner of the day we'll do another death match what's the language on the top anybody recognize it
23:44
there's a transcript that's a hint it looks like a send message so it has to be object oriented right so it's a small talk program on the top so what's interesting is one of those is a language
24:00
that was built to build business applications and one of those languages was a language that was built to write an operating system so we have our death match it's a very quick very painful death match for the small talk people and what we found was that it's not enough to have
24:23
a cool language or even the better language for a particular task you have to have the language that is solving the problems that are interesting at the time small talk was far and away a better applications language always has been but see roundly clobbered everyone because it was fast
24:44
and we paid for that decision and we're still paying today how many of the top seven languages or so are based on a c syntax let's count them so i see c c plus plus javascript c sharp
25:04
that's about it well objective c is down there also further on down so what five of the top seven or eight languages are still in the c syntax today even though language popularity is driven by applications programming not systems programming and um and we're not doing most of us
25:25
aren't writing systems programs with c you see the features that you need to build an operating system and business applications are necessarily different instead of explicit allocation you need garbage collection instead of bit level control you need reliability instead of weak
25:42
flexible types which allow you to put any value in any cell memory you need strong and secure right and all these things aren't academic features they're about control versus productivity and if you're building something with a very large team that's going to be used across the industry like a spreadsheet something that has to run the world economies
26:06
you want it to be fast and you want absolutely perfect control but when you're working with business applications time to market is everything and so you'd rather pick the languages that are better for productivity
26:24
or you can say it another way i want performance there are other trade-offs there's performance versus expressiveness these requirements are not the same so the languages that run them should not be the same snakebite so before we leave this group
26:42
i want to look at the last couple of languages in this group is any well you've all heard of c++ did we actually write in the early stages object-oriented programs with c++ how many vote yes how many vote no i vote no
27:04
yeah so really what we had was a c++ minus minus right so um but c++ filled a very important very effective role and that's the role of a bridge language
27:21
ada was another language that was a bridging language it was actually commissioned by the u.s government maybe military maybe nasa i don't quite remember but the language introduced things like encapsulation and um even though they weren't the eventually the eventual languages to
27:43
take us to a more object-oriented approach as an industry they were very important in that they introduced those concepts to us and made them more familiar so that when it was time to move we were ready so um we're about to move on from the procedural world to the
28:06
object-oriented world and there's another family of problems and another family of languages to choose from and you know if you're here for the functional programming to try to learn what this
28:21
is all about i think it's a first i think it's a great place to be and second this particular group of languages is going to make you very very sad because there's some really cool stuff that's happening here first there's a probably the most comprehensive general purpose functional language was introduced here and that's called Haskell second probably the most widely used
28:45
you know near real-time language in production right now that probably runs one of every three or four messages every cell phone messages in this room right now and that's Erlang you have a great language for embedded systems in Lua you have Ruby which is a
29:04
higher level language for for doing scripting type type things and we've actually pushed it probably or well beyond what is what what it was intended to do and then you have more C++ family of languages so there's a lot of death matches that are happening but let's set let's
29:24
kind of set the stage for what was happening at the time so this would be about the time or maybe a few years after the time well Java was 96 right and the first major release revision of Windows was Windows XP and then followed by Windows 95 right so we're kind of in
29:45
in the fragile Windows stage and we haven't really solved the management or deployment problems yet at this time I worked at IBM in sales and we were well I was actually I went back and
30:03
forth between sales and the lab it's kind of a career choice but we would tell the customers that you know you don't have to build with two tiers things are too complicated to build in two tiers what's better is to build in three tiers or end tiers that's much simpler right and
30:24
we could build very simple and clean interfaces that way we could not manage the problems very well that way and what would happen was that we could build a pretty effective system and we and we also could not build those systems very quickly because what happens is that when you're
30:44
building things with a waterfall process when all of the when you basically build a specification and then build your part of the system and you say I'm done and then there are two other parts to integrate to it pushes your schedules way out and that's what happened and large customer said we can't keep up with the demand and so I might be a CIO and I might
31:10
and then a business a line of business developer says hey I need to be able to calculate the GDP or or the you know the profits for our company this way and I might have to tell
31:21
them no I can't do that I can get that to you in two years and the line of business guy might say I'm out of business in two years I'm going to build it myself and they went to a language called Visual Basic to go do so and then all of a sudden on top of all the the development strategies we also had the strategy we challenges we also had the challenge
31:47
of integrating all these C++ online and business applications right and it wasn't just Visual Basic it was things like DBase you know to do a roll your own database it was you know all these spreadsheets which was at the time Lotus 1-2-3 and Excel and the macros
32:03
that sat on top of these and then I had this unholy brew of a line of business application and then they were built by non-programmers and then the CTO would hold up his hands and say I don't know how to integrate this stuff I didn't choose these technologies because I didn't know how to I don't know how to integrate these things and on top of that we had a deployment problem
32:26
where we had thousands of clients we had to roll those things out tomorrow and then you roll them out and they say oh well the next fix pack for the database is out and then you roll them out again probably with sneakers and discuts and they say oh well now it's the database engine
32:41
that has to be upgraded or the LAN engine that has to be upgraded and all these fix packs had to be compatible and then you throw in third-party vendors and things broke we didn't know how to do it so really the thing that pushed the industry into object-oriented development wasn't the cool feature called object-oriented development it was a language called Java which
33:03
built in the internet right and so you had to deploy one thing if you could figure out how to deploy the browser then you could figure out how to deploy your applications and that's what ushered in the object-oriented age so we had Java versus Visual Basic but Visual Basic
33:23
did not have the rigor to organize the code that we needed so I might have an application which looked beautiful and hanging off of this beautiful beautifully designed screen this magic okay push button was about 10k of code right and so the design became
33:43
the organization for the application and then you had the small the the poor small talk guys that say hey this time around we're really going to win it's object-oriented technology right we're ready for them we have the we have the best system we have the proven productivity we have all these studies about how small talk is going to be better
34:06
but it really wasn't about the object-oriented feature it was about deployment that's what that's the problem that the industry had to solve at the time and then the functional languages didn't have a chance because it was too much too soon there had been no bridging language
34:24
there had been no exposure to the functional programming paradigms then we had another problem which was an icon of the C family of languages the integration problem C is a great technology
34:42
but it's one that's difficult to integrate to to third parties or at least was at the time before we had all of the portability libraries and java comes around with all with this this library that runs everywhere and with a relatively decent story for talking to C and says hey build all of your stuff in java and you might give away some productivity but in the end you're
35:09
going to win because everything will be homogeneous integration will be easier that's kind of funny to say in retrospect isn't it with C sharp and with java that integration is the easy part
35:21
and particularly from the java world where we went through gosh ejbs one two and three like three or four flavors of dependency injection containers all kinds of unit testing strategies really these are integration strategies or you can look at look at them as workarounds
35:41
for things in java that suck right but it's the winner and probably the biggest winner of all time maybe cobalt is close but you could probably say that there's there's been no more dominant period than to have a family of languages with java and c sharp that's completely
36:04
held down everything else so in this particular talk my premise is that we have made some bad decisions right there's another talk that i go to that talks about the motivation of what's going to
36:21
move us beyond as an industry what's going to move us beyond this point you'll see some undercurrents of that today but but predominantly i want to talk about what how we got here so we're going to run about seven minutes late because i was 10 minutes um late to your show sorry if you miss your cookies um so anyway with java we had all the old snake bites to
36:48
deal with we had mutable state and all those c choices and we had a type system the same with c sharp by the way where the types are based on name rather than the structure we explicitly declare rather than um rather than implicitly declare things so that the types show up everywhere
37:06
it's pretty repetitive so strong typing turns into strong typing right and then i have the static versus dynamic problems that could have remediated some of these problems a little bit all these things are not just academic names they have business values these things make them
37:25
language languages more verbose tightly coupled and dumb they don't have the intelligence built into the systems that they could and they've led to some unholy unions that are making
37:42
both of these languages more and more complex so i'm going to gloss over these pro these some of these type problems but i have the java alternative at the top and the functional alternative at the bottom in this case ruby versus versus java where i could say
38:01
object dot blank and the object that i'm dealing with knows exactly what i'm dealing with and then i also have the problems inherent with object-oriented programming in code organization the encapsulation of mutable state and behavior turns out to be precisely the wrong way to code if you want to build for concurrency and transparent distribution
38:26
i talked about interop a second ago but let's talk about the next family of languages and where we're going from here so the challenges now are we're building distributed and cloud oriented systems we're
38:42
starting to see some bridge languages in fact scala is an excellent example of a bridge language it takes java and layers on strong functional concepts will that be the end game i don't know but it has many of the things that we're looking for in the next functional language so we have
39:02
a number of death matches that are coming up now that are going to be important ones so is java the best that we can do is the c-sharp this the c++ syntax family of languages the best that we can do is object-oriented programming the best paradigm for solving
39:22
problems related to concurrency is it best to have one true language one true programming paradigm across the whole industry is the java virtual machine or the the clr the best that we can do in terms of the next generation of languages is javascript the best that we can do
39:44
on the client or are we going to continue to live with the same set of snake bites or are we going to look for the languages that have the anti-venom and the reason that i'm giving these talks in these places is that you guys get to vote and we're going to be choosing
40:06
a language really soon now we're actually we're actually choosing them as we speak at conferences like this one and that's all i have to say so i probably have time for a question or two if you guys want to leave go ahead i was late um if anybody has some
40:23
questions i'd be happy to answer them okay thank you thank you so much for being patient and i'm sorry so much that i was late