Succeeding with Functional-first Languages in Industry
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 | 150 | |
| 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/51413 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Principal idealVideoconferencingCoding theoryComputer programmingAnalytic setCalculationErlang distributionCorrespondence (mathematics)Perspective (visual)Focus (optics)Product (business)Personal identification numberStandard deviationMereologyRepeating decimalProcess (computing)Endliche ModelltheorieComputing platformSystem programmingAlgorithmNeuroinformatikComponent-based software engineeringPresentation of a groupMathematical analysisCodeParallel portInformationKolmogorov complexityService (economics)CASE <Informatik>MereologyOrder (biology)Formal languageAreaSoftwareMultiplication signComplex (psychology)Principal idealEntire functionConnectivity (graph theory)Information engineeringTranslation (relic)MathematicsWeightComputer programmingOcean currentRow (database)Different (Kate Ryan album)Fundamental theorem of algebraView (database)Electronic data processingParameter (computer programming)Heegaard splittingGreen's functionPhysical lawHand fanService (economics)Point (geometry)Presentation of a groupComputerObservational studyComputer programmingSound effectBitCartesian coordinate systemRight anglePerspective (visual)Instance (computer science)Range (statistics)Metropolitan area networkProduct (business)SpacetimeQuicksortSelf-organizationNeuroinformatikBit rateNumberLevel (video gaming)FrustrationProgramming languageDecision theory1 (number)AlgorithmLine (geometry)Software developerPhysical systemClosed setAnalytic setFunctional (mathematics)Moment (mathematics)VacuumCalculationCodeLie groupEndliche ModelltheorieVideoconferencingInternetworkingOpen sourceComputing platformReal numberData conversionState observerFocus (optics)Extension (kinesiology)InformationSystem callProgrammer (hardware)CodeActuaryDomain nameCore dumpKey (cryptography)MappingReading (process)XMLUMLComputer animation
09:56
Product (business)Endliche ModelltheorieService (economics)Kolmogorov complexityInsertion lossScale (map)Repeating decimalComponent-based software engineeringEnterprise architectureAnalytic setComputer programmingFormal languageCore dumpCodeDisintegrationSoftwareProcess (computing)MereologyComputer programmingSoftwareComplex (psychology)Formal languageFunctional (mathematics)Enterprise architectureGoodness of fitDisk read-and-write headImplementationObject (grammar)Entire functionCloningCore dumpOrder (biology)CodeIntegrated development environmentSemantics (computer science)Multiplication signPoint (geometry)Valuation (algebra)WindowDomain nameLevel (video gaming)Product (business)QuicksortInsertion lossCASE <Informatik>Connectivity (graph theory)Service (economics)Translation (relic)NumberNP-hardPhysical systemEndliche ModelltheorieParallel computingSet (mathematics)Absolute valueUser interfaceGroup actionProjective planeAlgorithmIntelligent NetworkProcess (computing)Software developerKey (cryptography)Programmer (hardware)Observational studySoftware bugExtension (kinesiology)ApproximationSpacetimeFunctional programmingAnalytic setProgramming languageArithmetic meanProper mapWritingPlotterRight angleSocial classResultantReal numberComputer fileScaling (geometry)Sound effectComputer programmingMaizeOperator (mathematics)Limit (category theory)DreizehnDifferent (Kate Ryan album)Cross-correlationData miningSynchronizationIncidence algebraMacro (computer science)Confidence intervalOnline helpMoment (mathematics)Computer animation
19:48
Analytic setProcess (computing)SoftwareJava appletSoftware developerPhase transitionCodeMereologyCASE <Informatik>Observational studyKolmogorov complexityAddress spaceCalculationBroadcast programmingFood energyAlgorithmFormal languageMathematical analysisSet (mathematics)Gamma functionClefVector graphicsReduction of orderParallel computingSoftware testingFunctional (mathematics)Programmer (hardware)Computer programmingRange (statistics)Complex (psychology)Interactive televisionCorrelation and dependencePhysical systemSpreadsheetParsingComputing platformMatching (graph theory)Ewe languageParsingSystem programmingLocal GroupData managementMaß <Mathematik>Interface (computing)Line (geometry)Network topologyError messagePrototypeBargaining problemRankingFormal verificationEndliche ModelltheorieThermodynamic equilibriumDerivation (linguistics)Data analysisCore dumpAxiom of choiceWaveConstructor (object-oriented programming)Phase transitionProgrammer (hardware)Pairwise comparisonEquivalence relationMultiplication signSoftware developerBit rateGame theoryCodeRankingNumberInteractive televisionSoftware bugPhysical systemJava appletInformationIntegerQuicksortLink (knot theory)Generic programmingBuildingSimilarity (geometry)AlgorithmExpected valueAreaOperator (mathematics)Strategy gameExploratory data analysisDecision theoryFormal languageSoftwarePoint (geometry)Core dumpOrder (biology)Complex (psychology)Image resolutionBusiness modelImplementationData analysisUser interfaceMaß <Mathematik>Connectivity (graph theory)Mathematical analysisoutputCASE <Informatik>Parallel portBoundary value problemCalculationSpreadsheetMatching (graph theory)Modul <Datentyp>Parallel computingComputer iconObservational studyGroup actionActuaryEndliche ModelltheorieSampling (statistics)Functional programmingSet (mathematics)Cartesian coordinate systemOptical character recognitionComputer programmingSlide ruleProgramming languageView (database)Exterior algebraInformation engineeringPower (physics)Execution unitLevel (video gaming)BitResultantFood energyExtension (kinesiology)Computer simulationWeb pageRepresentation (politics)SubsetPredictabilityType theoryRange (statistics)HoaxOrder of magnitudeSocial classHand fanProcess (computing)2 (number)Computer configurationLine (geometry)PrototypeMeasurementAnalytic setRight angleInstance (computer science)ArmWorkstation <Musikinstrument>Sound effectPerspective (visual)Regular graphComputer programmingMathematicsNatural numberSystem administratorElectronic mailing listFitness functionDressing (medical)FamilySource codeGreen computingArc (geometry)Unit testingOnline helpForm (programming)FeedbackGoodness of fitThermal conductivityComputing platformTraffic reportingProduct (business)Optical disc driveNeuroinformatikComputer animation
29:40
Formal languageExecution unitMathematical singularityCodePartial derivativeElectronic signatureSimilarity (geometry)CompilerDebuggerGeneric programmingFunction (mathematics)Software testingCompilation albumProduct (business)Type theoryError messageGroup actionChemical equationEnterprise architectureFunctional (mathematics)Proxy serverSquare numberMathematicsPolymorphism (materials science)AbstractionSymbol tableMereologyData analysisPresentation of a groupAlgorithmInformationParallel portService (economics)Einstein field equationsPointer (computer programming)Functional programmingCodeNumberTerm (mathematics)2 (number)QuicksortType theoryLine (geometry)Core dumpInternet service providerCASE <Informatik>WordAlgorithmFormal languageCovering spaceBounded variationMathematical analysisPairwise comparisonVisualization (computer graphics)DebuggerCellular automatonBitSoftware bugFocus (optics)Computer programmingProgramming languageSoftware design patternPerspective (visual)Run time (program lifecycle phase)Electronic mailing listCompilation albumWeightData structureProduct (business)Single-precision floating-point formatObject (grammar)RandomizationObject-oriented programmingPoint (geometry)Multiplication signDefault (computer science)MereologyInformationPattern languageService (economics)Physical systemDeclarative programmingFactory (trading post)RoutingAbstractionJava appletStrategy gameProxy serverFunctional (mathematics)ResultantRight angleCausalityLink (knot theory)Endliche ModelltheorieProtein foldingMoment (mathematics)DivisorArc (geometry)WritingFamilyDistanceComputer animation
35:31
PrototypeCodeBargaining problemAlgorithmComplex (psychology)Maß <Mathematik>Error messageRankingFormal verificationEndliche ModelltheorieThermodynamic equilibriumDerivation (linguistics)Parallel portInformationMathematical analysisCalculationService (economics)Server (computing)SQL ServerOracleGraphics processing unitScalabilityWorld Wide Web ConsortiumSoftware frameworkData modelBuildingComponent-based software engineeringLatent heatSoftware testingMereologyVisual systemOpen sourceFormal languageComputing platformSoftware testingGoodness of fitComputer programmingPerspective (visual)Physical systemOpen sourceDifferent (Kate Ryan album)Connectivity (graph theory)Formal languagePoint (geometry)Object (grammar)BuildingMultiplication signVisualization (computer graphics)ImplementationProcess (computing)Latent heatBitQuicksortFunctional (mathematics)MereologyComputer programmingWeightCode refactoringSoftwareResultantCross-platformLine (geometry)Revision controlSocial classData managementGroup actionProgramming languageCodeComputing platformSoftware frameworkCodeUser interfacePresentation of a group1 (number)StatisticsEquivalence relationBounded variationTable (information)Programmer (hardware)Order (biology)Service (economics)RewritingInstance (computer science)Form (programming)Source codeDebuggerDatabaseFront and back endsProjective planeWave packetKey (cryptography)PrototypeServer (computing)PhysicalismWeb 2.0Computer animation
41:03
Internationale Physik-OlympiadeCodeComputing platformDensity of statesMaxima and minimaLattice (order)Point cloudGame theoryMagnetic stripe cardExecution unitSoftwareFormal languageSource codeMobile appComputer programmingProgrammable read-only memoryCompilation albumRaster graphicsMathematicsAndroid (robot)Computer programmingMachine learningGraphics processing unitComputer iconZeitdilatationInformationLocal GroupMenu (computing)Twin primeVisual systemMaizeGroup actionOpen sourceIntrusion detection systemStatement (computer science)Different (Kate Ryan album)BitSoftwareWindowQuicksortComputer programmingComputing platformRevision controlSelf-organizationGroup actionPoint cloudAndroid (robot)WebsiteMereologyAreaVisualization (computer graphics)Set (mathematics)Automatic differentiationVideo gameObservational studyMaxima and minimaSound effectPerspective (visual)Uniform resource nameProcess (computing)Instance (computer science)Computer animation
43:49
Computer-aided designUniform resource locatorAverageCodeInterface (computing)Library (computing)Functional (mathematics)AbstractionEnterprise architectureSource codeOpen sourceInternet service providerData typeFormal languagePoint cloudIntegrated development environmentMultiplicationPortable communications deviceScalabilityComputer programmingMathematicsDisintegrationQuery languageCore dumpComputing platformFunctional (mathematics)Core dumpPoint (geometry)Formal languageInternet service providerSocial classWeb 2.0IntelCharacteristic polynomialDefault (computer science)Set (mathematics)Real numberComputer programmingDecision theoryConnectivity (graph theory)Integrated development environmentJava appletDifferent (Kate Ryan album)Mixed realityKey (cryptography)Computer fileAreaSimilarity (geometry)Scripting languageRow (database)Revision controlSystem callData analysisSummierbarkeitEndliche ModelltheorieWeightObject (grammar)Physical systemInstance (computer science)Mechanism designFactory (trading post)Software developerLevel (video gaming)Type theorySlide ruleComputer-aided designMathematical analysisCircleImplementationCASE <Informatik>View (database)Cartesian coordinate systemProcess (computing)BitInterrupt <Informatik>MereologyContext awarenessString (computer science)Computer configurationCodePoint cloudMathematicsNormal (geometry)SoftwareQuicksortObservational studyMultiplication signProgramming languageLibrary (computing)Service (economics)Bit rateNumberObject-oriented programmingModal logicOpen setParallel computingNumeral (linguistics)ScalabilityOpen sourceEmailDependent and independent variablesCoroutineParameter (computer programming)Computer animation
52:09
CodeFormal languageCASE <Informatik>Similarity (geometry)BitIntegrated development environmentSoftware developerComplex (psychology)Computer programmingSystem callRight angleDecision theoryWindowUser interfaceEndliche ModelltheorieLevel (video gaming)Web 2.0WeightPairwise comparisonClient (computing)Computing platformChemical equationPoint cloudInstance (computer science)Programming languageInterface (computing)Social classLattice (order)Visualization (computer graphics)Multiplication signProcess (computing)Factory (trading post)CodeMixed realityFilm editingGraph coloringLine (geometry)Service (economics)Network topologyPortable communications deviceConnectivity (graph theory)1 (number)SoftwareExtreme programmingCross-correlationQuicksortMereologySet (mathematics)LeakCore dumpC sharpF sharpFunctional programmingTerm (mathematics)View (database)Absolute valueCode refactoringSoftware industryPartial derivativeUniformer RaumComputer animation
01:00:29
Computer animationXMLUML
Transcript: English(auto-generated)
00:04
Okay, everyone. Am I on? Hi, everyone. Thanks for coming along. This is my second talk here today. I started kicked off on the first technical session with technical talk. It's just lovely to be in Oslo.
00:21
Thanks for so many people coming along to this one. My name is Don Sime. I'm an F-Sharp community contributor. I also have a role as a principal researcher at Microsoft Research. And today's talk, this talk is less technical than my first talk was.
00:45
And it's really born out of a number of things. I've been working as part of the team, bringing you .NET language improvements, F-Sharp as a language, a lot of improvements in C-Sharp and .NET over the years as well.
01:02
And I think as I've been working with people adopting improved programming language techniques, I think I've become a bit frustrated with how we talk about why those techniques actually matter in practice.
01:21
We have a lot of language wars. We have a lot of arguments about why things are good or bad or what's the right way to do things technically. And we sometimes lose the big picture about why these things make a difference in industry. Now, we being perhaps the language designers, we've been the people providing technologies in core teams,
01:44
either at Microsoft or in the open source world, most of you work in industry and you know full well what a difference better language, better based technologies can make in practice and what harm they can inflict in practice as well when used incorrectly.
02:01
So in many ways this should be reinforcing what a lot of you know intuitively with programming language techniques. But if you want technical talks from me, like I normally give, then there's a whole lot of great F-Sharp videos, most of them from other people,
02:21
not from me, at fsharp.org slash videos, over 100 videos about F-Sharp to watch there. If you want an overview of F-Sharp 3.0 from Dustin Campbell at Microsoft TechEd 2013, a wonderful talk he just gave there just last week. And there's also the recording from session one today.
02:41
Today I want to talk about the problem domains where F-Sharp seems to work particularly well, where it seems to give particularly large advantages to companies adopting it in areas of data engineering, analytical programming, calculation engines and financial engineering,
03:02
and also general coding, but particularly the first four kinds of areas. And this is sort of focusing on how we can talk about a technology like F-Sharp. It also applies to other what I'd call functional first programming languages,
03:24
languages like OCaml, to some extent Scala, to some extent aspects of C-Sharp. And it's based on really a lot of informal observations of more than 30 successful F-Sharp adoptions in industry.
03:42
And trying to bring out why does F-Sharp succeed in some particular areas and what are the common things we can bring out there. And concretely the talk comes from conversations I've had with a guy called Matt Harrington who works on the Microsoft DP team, who introduced me to a wonderful little book.
04:04
How many people have read this book, Spin Selling? You have? Ah, great. My recommendation or separately? It's an excellent book by Neil Rackham from the 1990s. It could probably be updated for the internet era.
04:22
But it comes from experiences at selling technical products, complex technical products, as opposed to sort of how to close a sale if you're selling a vacuum cleaner or something like that, how to get that magic closing moment in a sale. It's not that kind of marketing book. It's a marketing book about selling computer systems for IBM, for example.
04:43
And how when you're talking about a complex product with a customer, how for instance there may be many decision makers involved in adopting a new major computer system. There are many decision makers involved in adopting a new programming technology
05:02
in the sort of organizations we work in. And so we need to think differently about how we talk about these kind of technical products as perhaps than we normally do. So the marketing methodology is called SPIN, which is quite fun. It's based around this situation, problem, implication, and need methodology.
05:24
And I would recommend you take a read of that. So let's talk about this through from the F-sharp perspective, from the functional first programming perspective. And we'll look at just generally at first and then look at some concrete case studies
05:41
and then look at how that maps through to the technical features of these kinds of languages. So the recurring business situation where we see, which we're looking at here, is I lead a team developing online data processing components, financial modeling components, insurance calculation engines.
06:02
I lead a team developing a trading platform, an algorithmic trading system, an online recommendation engine, a bioinformatics algorithm, sort of a disparate range of applications of programming. And let's try and simplify this and summarize that down
06:20
to the situations where people are developing analytical components, data-rich components. You can call them either of those. There's kind of what I would characterize as two kinds of people, the analytical programmer and the data engineer. And often problem domains bring in one or both of those components.
06:43
So that's the general situation where we are. So I always, sometimes when I talk about programming, I like to do this split. We're very familiar with this kind of split in our architectures. We have some coding in the middle where we have analytical programmers of some kind.
07:02
We have data layers, data information services. We have a lot of data engineering people over here. And then we have these people over here doing the front layer, the design, presentation, publication and UI. So in this talk we're focusing on this situation over on the left
07:24
more than over on the right. So what are the recurring business problems that people actually have? When you talk through the actual business needs of these people, what are the problems that they are facing?
07:41
The recurring ones we want to have top of our mind are time to market, time to deployment, time to market for the components. How fast they run is a key problem that people will talk about. Whether they're correct or not. And whether they're actually able in some sense to do the software at all.
08:05
Whether they're able to tackle the complexity of the problem domain with the programming tools that they have available. These are related. Obviously time to market, achieving certain efficiency, correctness and complexity goals is the big one.
08:21
It's all about whether you get the software to market in time to deploy at the right level of quality and efficiency and actually tackling these complex problems for analytical components. So that's the fundamental situation and business problem we're faced with. A key part of drawing out why functional first programming
08:45
will make a difference in this kind of situation is to focus on why those problems here are actually really severe problems that actually map through to real dollars for businesses. So what happens when you don't get a financial model to market on time?
09:05
Let's take one of these business situations, an insurance company who has to adjust for example to regulatory changes in the insurance industry and let's say they have a current turnaround time of six months
09:21
from their actuarial department making a change to their model through to the R and Mathematica models that the actuarial department use through to their translation into the C++ code that's actually put onto the deployed system. And with a six month turnaround time then being late to market in that kind of analytical component development
09:44
would just mean you'll miss entire business opportunities. You simply won't be able to enter the market. And that's a recurring theme in all of those industries. If you can't get a bioinformatics algorithm implemented
10:02
and out the door in time for your core team in order for your bioengineers to assess a particular new product then your entire startup or business may fail.
10:20
So is correctness a problem? And again this is very important for thinking in the back of our head why is it that functional first programming applies in particular domains more than others? And in these domains that we were just talking about correctness is absolutely a really big problem.
10:41
I mean you can get away with an algorithmic trading system that has a few bugs or a few approximations in it if you're lucky but then you might just make that one mistake that actually brings down your entire hedge fund or your entire trading group because it goes wild with incorrect trades.
11:00
But on the whole in those kind of components buggy models will lead to incorrect values, risk trades which will correlate through to full on exact dollar loss in your systems. If you have buggy services then you might incur a reputation loss and if you have buggy products then you'll get lost customers.
11:26
Is efficiency a problem? Absolutely. In finance and trading settings they frequently have a 13 hour window overnight where they have to value the bank and if they can't get the numbers on the desk by the next morning within that 13 hour window
11:42
then that is a hard limit, they have to have it there or else the bank can't actually run its operation and they're operating with out of date valuations and risks. Efficiency in services and products leads to again the obvious examples of not being able to scale out your services or slower products.
12:02
Perhaps the most interesting theme that runs through case studies where functional first programming is effective is the question of complexity. I think it's a question that we don't talk about enough in software. What's the software that we weren't actually able to implement?
12:22
If you're in a trading situation and you simply can't implement the software to model the financial products that are being traded then you effectively can't participate in certain markets. You're just unable to be a competent player in certain domains.
12:46
The same goes with all of the previous domains of work where we talked about the various situations. If you can't do your bioinformatics algorithms then in time or you simply can't model or implement them at all
13:04
then you just get failed project after failed project. So is complexity a problem? In these situations complexity is absolutely a fundamental problem as is correctness, efficiency and timeliness in delivery.
13:21
So that's the recurring business problems and they are severe problems that lie at the heart of software delivery in these kind of domains.
13:40
I don't think so. There's all sorts of things where improved programming techniques don't help. Part of this is trying to be clear about what better programming helps with and what it doesn't help with. And I come to an important part of that in just a moment.
14:03
I'll talk about it now. So complexity. Tackling complexity is crucial in the kind of domains I've talked about so far and that happens to be the domains where functional first programming is particularly effective. But in user interface work the situation is extremely different.
14:22
It's interesting in two ways. One is which asynchronous programming is hard to get right in user interface programming and you see these functional asynchronous programming techniques that we now see in C sharp and F sharp and going right through the industry are critical for tackling that part of the complexity of user interfaces.
14:41
But on the whole user interfaces are about making things. You have to make a simple thing, not a complex thing. There's just no point in being able to implement really complex user interfaces. Nobody wants it. It's wrong. And that's why functional programming isn't culturally in some sense a good...
15:01
It's a perfectly good implementation tool. You can do wonderful asynchronous programming. But on the whole it's a design problem, which is sort of what you say, wrong product. You have to make simple things. Yeah, well there's another aspect here which you could fold into this kind of discussion
15:28
and which is about time to failure and investigation of problems. You want a faster time to fail when exploring the design space.
15:41
And I think, again, functional first programming has a key role in getting... Finding out that you're doing the wrong thing sooner. But that's a slightly harder... I wouldn't say that I have data to back that up. People don't say... Occasionally you get people saying, yeah, we discovered failures faster. But on the whole people don't talk about that.
16:01
But I think you could draw that out much more as a thing. So the need in these kind of domains is analytical programmers delivering correct, efficient components in the enterprise on time. This core is what F-Sharp is about as a programming language. But I'm not just talking about F-Sharp here,
16:22
although it's obviously focused around my experience with F-Sharp, but functional first programming is really about addressing that set of needs. It's one set of problems that functional first programming helps solve. And the question is why? And really when it comes down to it, at the core of every functional first language
16:41
is just a fabulous set of problem solving tools. Simple correct code for complex problems. You can just churn out correct analyses and correct manipulations of data very, very rapidly in these... The Haskell, Scala, F-Sharp, OCaml, Erlang,
17:06
to some extent are kind of programming environments. They're just really wonderful tools for doing correct manipulations and solving software problems. A key aspect on this time to market side of things is interoperability.
17:26
And I hadn't appreciated just how important this was as a reason in particular for these interoperable functional languages, F-Sharp and Scala, for being so successful.
17:41
F-Sharp is an odd language because you can adopt it for just one part of a larger solution. You can have really 20 of your projects being C-Sharp projects and just one or two being F-Sharp projects. We see that, and you'll see that in some of the case studies, that many people start their F-Sharp adoption that way. Some people like to ask me,
18:02
how can we get our enterprise to adopt F-Sharp? And I say it's easy. You just go right-click, add project, F-Sharp. Actually, that's not that hard. And then ask forgiveness later. But because you can develop these components
18:24
in a way that just can integrate directly into these larger C-Sharp solutions, your functional code is just part of the larger solution. And in particular, what that means is in these kind of shops where you have some kind of analytical software development going on,
18:42
perhaps in R, perhaps in Mathematica, perhaps in Python, perhaps in some other system, then often these shops have a translation stage where the analysts work in these systems and then that code has to be put over to the IT shop and re-implemented in C-Sharp and C++. And honestly, that process can be six months long.
19:02
Not only that, but in the case of one shop I know of which translates Mathematica to C++, they do it in a way that uses this macroized kind of C++ in order to make sure the semantics stays the same. And then C++ ends up doing deep copy and cloning of every object almost at every step of the way and actually ends up not particularly efficient as a result.
19:24
And so you're not even getting the real benefits of the deployment in C++ in this environment. But honestly, you can just eliminate six months from your software development process
19:41
in some of these key analytical departments of a business by moving to an environment like F-Sharp. And it's very hard to eliminate six months out of a software development delivery pipeline any other way. Savings of that magnitude is just extremely hard to engineer.
20:04
A key thing from my perspective, I'm a big fan of these strongly typed functional programming languages. The F-Sharps and to some extent sort of the C-Sharp functional programming subset as well because these are strongly typed and we get great unboxed representations of integers and numbers.
20:23
We can get .net generics all the way down and that lets us maintain efficiency in this analytical code in an absolutely key way and you get performance equivalent to C-Sharp and Java and sometimes C++, so we love that. And strongly typed. And then this key thing about
20:41
they help analytical programmers tackle more complex problems. So that's the need being met by this class of programming language. The functional first programming helps through simple correct robust code interoperability eliminates entire phases from the software development process strong typing gives efficiency or can help enable efficiency
21:01
and above all empowering analytical developers to solve more complex problems. So let's take a look at some of the case studies where we've seen this actually work in practice. And what I've done here is taken some of the testimonials that are available on the F-Sharp software foundation pages.
21:23
So if you come over here, this is fsharp.org here and there's a wonderful set of testimonials provided by people. There's this whole range of them down here which you're welcome to take a look at. And there are permalinks here
21:41
if you want to send them around to people in your communities. So this first one So I've taken those testimonials, some of them and just brought out where they're pulling out these common themes. So this is a power company in the United Kingdom and they use F-Sharp for a calculation engine
22:03
to help decide when the power stations come up and down. So this application is taking a set of input feeds from the energy market around Europe and there's a lot of data engineering and manipulation around the edges. It used to be that Finland, for example, every country has to publish the amount of energy
22:21
going in and out of the national boundaries and it used to be, for instance, that Finland only published those as a bitmap, a GIF. And they had to do optical character recognition on the GIF in order to read those off and that's changed now. Supposedly they published an XML feed or something now, but that's fine.
22:40
But the market signals aren't coming in that rapidly but you have to still write very accurate analytical code to make a decision to react to those market signals in order to change the decision about whether you're going to spin up a power station or not beyond the expectation that there's going to be a need for it
23:01
in a particular country. And so F-Sharp is key to that implementation. So the people who did this implementation brought out a deeper analysis of what was it about F-Sharp
23:24
that technically helped them into operation units of measure in helping to make correct code, exploratory programming with F-Sharp Interactive, drawing out the link between functional programming and unit testing,
23:41
no complex time-dependent interactions to mess things up, parallelism, code reduction, and a lack of bugs. But when you think back, how does that map onto those four big themes? That's really about interoperation is time to market and deployment, units of measure is correctness,
24:00
exploratory programming is just time to market or time to deployment or time to fail, in a sense. Parallelism is about efficiency, etc., and lack of bugs is, of course, about correctness. So those four big themes just fit continually with these. You look at case studies in finance. These are two older case studies, one from Grades Insurance
24:22
and one from a major European anonymous finance firm who've got a major core component group developing all their financial models in F-Sharp. And again, time to market and correctness and efficiency are the things that come out. F-Sharp in insurance, a large actuarial company,
24:44
they're using F-Sharp for core actuarial components, quickly create a system which will perform the calculations highly efficient in parallel with a perfect match to the spreadsheet results. And again, it's just those themes, time to market, efficiency, correctness. The trading platform, this is done by a company called Tradeport,
25:09
making use of asynchronous programming heavily. Another way of saying that it tackles complex problems of experience, F-Sharp developers regularly solve problems in days
25:21
that would take weeks using more traditional languages, solving complex problems in an elegant and highly maintainable manner. So, maintainability, complexity, time to market. It's not just about F-Sharp. Other people adopting these functional first languages have reported extremely good results as well.
25:40
OCaml, this is some slides based on a 2006 talk, quite an old talk now, from a company called Jane Street using OCaml, a language strongly related to F-Sharp. And they brought out this thing, robust performance and readability. Now, it's interesting looking at this thing, the way they write this up.
26:02
They say that performance is better and better modularity. New systems implemented strategies more complex than previously possible. I think that's an interesting point where I kind of wish they had gone that one extra step forward to explain why being able to implement more complex strategies actually made them money.
26:20
Because it's not necessarily the case. You don't want people just sitting around making, hey, I've got to implement a more complex user interface than I ever could before, isn't that great? You want those people to just leave your company as fast as possible. But in this kind of setting, in a finance setting, that's just completely different. Implementing complex things is fundamental to the modern financial industry.
26:45
For better or for worse, but that's how financial software is these days. F-Sharp in biotech, similar kind of area. F-Sharp rocks, building algorithms for DNA processing. It's like a drug, etc.
27:01
It's a great comparison about Python. Python is a great language, achieves many of the goals set out here. But the actual F-Sharp code is 20 to 100 times faster to run and faster to develop. So in units of measure we see efficiency, correctness, faster to develop, time to deployment.
27:21
F-Sharp in advertisement and ranking and rating at Microsoft. Again, rapid development of prototypes, of code. Again, it's an interesting thing that we use this engine to simulate the auctions done on... So when we show advertising on the right-hand side of Bing's results,
27:42
for example, an auction is run behind the scenes, a second-price auction. And a key thing is to make sure you can't game the system by putting lots of extra fake agents into the system, for example, or by collecting information that other people may not have access to.
28:02
Could certain players effectively game the system so they get better prices than everybody else? Yeah, it's quite complex to do those computations and simulations. And again, a key place where F-Sharp actually gives good,
28:23
excellent results in core components. A more recent case study is F-Sharp at Kaggle. Kaggle is a bit of an iconic data science company. They run competitions for data scientists. It's crowdsourcing of data science.
28:41
You can put your data sets up there as a company and put a sample of a data set up and invite people to try and do a particular analysis or prediction algorithm on the data set, and then you get to put a bounty up, saying the person who gets the best algorithm will get a certain amount of money, and then those algorithms can be run over larger data sets.
29:02
It's really a very, very interesting business model. Internally at Kaggle, they use F-Sharp for their core data analysis algorithms, and the same sort of things come out about correctness of code and then moving more and more of their code to F-Sharp. OK, so from what I see,
29:21
the data agrees that the places where F-Sharp is particularly successful is where simple, correct robust code, interoperability, strong typing, and solving more complex problems as the common themes. Right, just to give you an alternative view. This is satire, so it's actually not an alternative view.
29:42
It just looks like one. Ten reasons not to use a statically typed functional programming language. This is... I don't want to follow the latest fad, et cetera. I get paid by the line. I showed some of this this morning for those who were already there, so if you prefer to program like this because you're paid by the line,
30:00
then that's just fine, right? But you might prefer to do this kind of thing. But if you get paid by the line, then you're not going to like statically typed functional programming. I love me some curly braces. OK, then if you're addicted to the curly braces, then it's not going to be your sort of thing. I like to see explicit types. That's fine.
30:20
If you prefer this kind of thing in your C-Sharps or Javas, then that's fine. If you prefer declarative approaches where the types all get inferred like in F-Sharp, then you're rather... I like to fix bugs. OK, yeah, that's it. Nothing quite like the thrill of the hunt finding and killing a nasty bug.
30:41
And if the bug is in the production system, even better because I'll be a hero as well. OK, that's what you want. And I know, I've been there. I've gone down implementing in the .NET runtime and finding those bugs in the C++ code. OK, I live in the debugger. I don't want to think about every little detail. There is something about these strongly-typed functional programming languages
31:02
that actually make you cover cases, make you cover edge cases in your code. Pattern matching as a construct in particular in these languages just means that as you take a financial model in and you write an algorithm over it, you have to cover all the cases of the code or the code will give you a warning or it won't compile.
31:23
And that's at the core of why strongly-typed functional code ends up more correct. I like to check for nulls. I'm very conscious about checking for nulls on every method. It gives me great satisfaction to know that my code is completely bulletproof as a result.
31:42
OK, haha, just kidding. Of course I don't actually do that everywhere. OK, design patterns. These strongly-typed functional languages tend to be... They do use design patterns, but they de-emphasize them in comparison to the object-oriented languages.
32:02
And that is sometimes hard for people to get used to, that we don't talk in terms of strategy, abstract, factory, decorator, proxy. That sort of language just tends to get thrown out. Big picture design patterns do stay around, like the MVVM kind of models, design patterns and the like.
32:23
And then people say it's too mathematical, but that's actually a cultural problem in the functional programming community, functional-first programming community. So I would actually agree with that. We have to change the culture of functional-first programming
32:40
because it's not actually hard at all. OK, we should have a little private chat about nulls, I think. The evil that is nulls in the programming languages that are most common in the industry today is absolutely awful.
33:03
How you can have data structures where at every point of the way the data might not be there. How you can reliably write code where you have to compensate at every single damn object, every single list cell in a linked list, every single place in your code,
33:22
your data might not be there. I mean, imagine taking this talk and then just like randomly replaying thousands of variations where words get deleted out of nowhere. And then you still have to kind of interpret and cope with all these different possibilities. It's so pernicious and so ridiculous that I would honestly say that the number one reason
33:44
for moving to a language like F sharp or to languages where nulls are not the default is because of that. The gains you get from not having to think about null as a routine part of your programming is absolutely enormous.
34:00
And I just do not see a way forward for the existing languages in the industry, in C sharps or Java or other languages. Maybe I'm wrong and someone will find a way forward for those languages where we can get to a non-nullness being the default. But it's really looking bad from that I'd say.
34:25
So we honestly just moving to a language where null is not the default just enables people to do such more productive things with their time than worrying about the absence of random objects along the way.
34:43
So that's the common themes for why functional first programming is effective in practice, in industry and where it's effective. Just mapping those through to where we have rolled out, where we've been aiming with F sharp,
35:01
especially from the Microsoft perspective of F sharp. I'll talk about that a bit more. This should be seen as a sort of visual F sharp's focus. Visual F sharp 1.0 and 2.0 is focusing on this middle part, code analysis and algorithms. Visual F sharp 3.0 through the type provider feature
35:20
which I talked about this morning was focusing on data, information and services.
35:43
On the presentation UI and design side, there are actually some great F sharp based solutions. This web sharper compiling F sharp code down to HTML5 is a great way of doing UI. But on the whole, at Microsoft anyway, we focus less on the user interface side of things
36:01
for the reasons I've explained about so far. Some other ad hoc lessons from industry. So much of the work that, as end users of F sharp that you really need to do is to work out how to combine it with existing components.
36:21
And there's a lot of variations. You might, for instance, have to combine F sharp on the server side with an Oracle database on the back end and you might be using a C sharp front end Silverlight. That's a trading company. The trading platform has used Silverlight as its trading front end. You might have to take F sharp and combine them with C++ components.
36:40
You might have to take F sharp and a GPU framework, for example. You might have to take F sharp and have it working with Hadoop and server stack, for example. But again, combining these technologies is a key part to being successful and not necessarily expecting there to be an F sharp sort of specific version of each of these technologies
37:02
but learning how to make F sharp work in conjunction with these other technologies is a huge part of what it takes to adopt it successfully. It takes a surprising amount of time to build capabilities in functional first techniques. I mean, like some anecdotes for people adopting F sharp,
37:22
some people say, we're a team of two F sharp programmers in a larger .NET team. One guy's job is to implement everything in F sharp. The other guy's job is just to delete the C sharp code that the other people write.
37:41
So I've honestly heard that. Another one is offshore teams versus onshore teams. That's a really interesting thing when you look at it from the first world perspective. First world is having a major kind of competitive problem with our outsourced industries in the developing world
38:06
providing good software delivery. And as industries, as physical industries, manufacturing industries know, the key way to stay competitive is better tooling. That's obviously the German, for example,
38:22
or industrial base of real manufactured goods know that the key way to stay competitive in the modern world is through better tooling. And we actually see first world programming teams adopting F sharp in order to be able to stay competitive against much larger teams of programmers in the developing world.
38:44
And some of the statistics that have come through from that are quite amazing. You get functionally equivalent systems or ones where the F sharp system has more functionality and the F sharp system is 7,000 lines of code and the C sharp system coming from the outsourced group
39:01
was 200,000 lines of C sharp code. So a factor of 25 difference in the end result. There's a couple of factors at play there. One is the programming language and one is the different kinds of programming teams and different kinds of cultures in the implementation. But it just shows you that you can take very different approaches
39:20
to its software implementation and that can map through from the language and tooling you're using. The building capabilities in functional first techniques definitely takes time. Training is totally key. People typically adopt by trialing on specific components, prototyping and testing and exploration and just using that one F sharp project and then extending out from that point.
39:43
I've seen people fail with F sharp because they've tried to rewrite entire systems in it even though they're stable and working and that's just crazy. And also fail because they don't reuse C++ high performance components and they try to rewrite everything in managed code.
40:02
You would see some failures in the C sharp world for the same reasons. I'm certainly not saying these lessons are in any way unique to F sharp. This is just like bread and butter for many kinds of software adoption and adopting new tools. But for some reason people can just forget that they need to do these things.
40:23
A little bit about what's going on with F sharp more broadly. Just check the time. We have plenty of time so I'll probably wrap up a little bit early just to give you a taste. I mentioned this this morning. It's really important to make this distinction between the visual F sharp tools
40:42
which are part of Visual Studio and, again, compared to F sharp as a language. F sharp as a language is open source and cross platform. And in many ways you don't even need to approach F sharp as a language through any Microsoft kind of perspective at all.
41:01
And that comes through in this fsharp.org here the F sharp software foundation. If you would like to use F sharp on Mac or Linux or Android or iPhone or HTML5 or 3BSD, this is the place to find out about that.
41:22
The mission statement of the F sharp software foundation is very interesting. They're quite happy for Microsoft to be the main contributors to the language and do the tooling on Windows because Microsoft do that extremely well on Windows. And they see their job as about promoting and protecting F sharp generally
41:43
and to take F sharp onto all these different platforms and offer all sorts of different tooling. You can get IntelliSense F sharp in Emacs, for example. You get autocomplete while using Emacs using the tooling that's provided through the F sharp software foundation. If you want to run on Android and iPhone and iPad,
42:00
you can use the Xamarin tooling. And if you want to find out how to use F sharp with Amazon, for example, you can find that out with the cloud programming under here and so on. And if you want to be a part of the F sharp software foundation, you can just join up either as a founding member. They're just starting some working groups in different areas. And if you want to contribute to this website,
42:21
you can just join in to send a pull request to the website on GitHub and they can integrate it very quickly. So it's a great place to participate in the community and the organization. Now that's F sharp org. So I think that's changing perspectives. F sharp certainly grew up as being sort of four windows and so now F sharp runs on many platforms.
42:43
And I think a new kind of thinking where it used to be that I think Microsoft can sometimes play the role of sort of being the popes in a way or being like the popes and the cardinals and people wait for the puff of smoke to come and from Microsoft and say, well, there's a new version of Visual Studio coming out.
43:00
I wonder what's in it. And we're kind of changing that to be, it's much more about Microsoft contributing to F sharp and lots of other people contribute as well. So we see Xamarin, for instance, giving support for F sharp on iPhone and Android
43:21
and lots of other community and startup groups contributing as well. So we see now that F sharp doesn't just have Visual Studio. It's IDE, but you can use Xamarin Studio. You can use ModoDevelop and you can use Emacs and all sorts of other tooling as well.
43:41
So this is a bit of a tour of what's going on in F sharp that's not to do with Visual Studio. So there's a great sort of set of tooling, which is taking the F sharp implementation and hosting it. It's actually taking the F sharp type provider mechanism, which allows you to interoperate with all sorts of things
44:02
and exploiting that to place F sharp alongside interesting application context. So F sharp hosted alongside Excel and with very nice interop between the two.
44:20
There's F sharp hosted as a scripting language for a 3D CAD system, which is a lot like AutoCAD, called Rhino. There's using it for data analytics or for web or for Hadoop and data analysis applications. So a very interesting initiative there. It's called Tsunami.
44:41
There's this tool called WebSharper, which allows you to do full HTML5. It compiles F sharp down to JavaScript. Full HTML5 development using F sharp. It uses a type provider model to access through to the strongly typed views of JavaScript components.
45:02
And this slide was provided by Intellifactory and just summarizes some of their experiences with that tool. There's also another community component, open source component, to compile F sharp to JavaScript. And again uses a type provider for TypeScript files,
45:22
TypeScript header files for interop. The people who do WebSharper have got an online development environment called CloudSharper, which is an F sharp development environment in the cloud. Again, this slide was provided by Intellifactory. And some other developments of Microsoft is F sharp 3.0,
45:41
which is the feature that I talked about this morning. We've been working on helping to show how F sharp can be used with Azure for scalable service programming. We've done some currently experimental work with F sharp and Hadoop for big data programming. And there's some interesting components of Microsoft called Cloud Numerics for scalable math programming,
46:02
which you can get in there in lab status at Microsoft. And I've talked about some of these things. There's some other frameworks, one called Embrace. And this is work done by the community, some of which I've talked about already. Okay, I'll skip this part here.
46:22
Okay, and I'll wrap up by saying functional first languages deliver real value in particular areas. We see that again and again in the case studies. And the key things are reduced time to market, rapid, correct development, efficient execution, and solving complex problems accurately with maintainable code.
46:45
And from the F sharp perspective, you can certainly use it to succeed in functional first programming in industry today. It's open source, cross-platform, strongly typed and supported. And there's lots of interesting work going on
47:01
in applying it in web and data and cloud arenas. And learn more at fsharp.org. And I would love to take questions. And I've finished a little bit early. And so once we're over, we can go and have a coffee. Okay, yeah.
47:24
Oh, so in F sharp, when you define a type, you can't use null with that type by default, okay? You can put some annotations on that allow you to use null. And if the type comes from .net libraries, you can use null.
47:41
That means when you, for instance, if you have an object coming in as a parameter to an F sharp function and it's got an F sharp type, then you know it's not null. You don't have to check for null. You know a value is not null. And that's normal in languages like OCaml and F sharp. You just don't have null at all in some of those languages.
48:03
And so some things, there's a whole set of decisions. You need design decisions very carefully made in F sharp all the way through to support the fact that things are, you don't need null, okay? There's a couple of places where you might need null when initializing arrays, for example.
48:23
They might initially be null. And so there's some back doors for creating an array with undefined values and then populating them as necessary. But in routine F sharp programming, values just type simply don't have null as a legitimate value or a normal value. So, yeah.
48:44
Oh, so, yeah. So if you need an absence of data, then you use what's called an option type in F sharp where it's, you know, if you have a string, but it may not be there, so use a string option, okay? And that means when you use that string, you actually have to check first. If it's none, then do something.
49:01
And if it's there, some, if there's something there, then do something else. But you actually have to put those explicit cases into your code. And that means you actually have to think a little bit more about what happens if the data's not there, if the data's not ready, if the response hasn't come back, if the component isn't initialized yet, or something like that. So you have to cope with those cases, and that's what makes your code more robust,
49:22
is being able to cope with those cases explicitly. I mean, I haven't got a slide particularly comparing those two, so broadly speaking, F sharp is,
49:43
they're different at the language level for how they do objects, for instance. F sharp has a .net object system in it. OCaml has a very interesting object system of its own. It's certainly different in interoperability characteristics. I've got a very similar core language in its core problem-solving capabilities.
50:02
F sharp has things like asynchronous programming. OCaml has its own version of asynchronous programming. But I think the key difference for this audience is F sharp runs on top of the .net stack, and it just gets all the interoperability and VM characteristics that you get from that.
50:21
But OCaml is a great language that's used for, I wouldn't say, yeah, but for anyone interested in .net programming, F sharp would be the place to start. Yeah, John?
50:50
I've learnt a huge amount about software and programming languages through doing F sharp, and yes, there would be things I would definitely do differently.
51:02
Through type providers, I mean, type providers is a very interesting mechanism because you've seen the examples where we interoperate through to other programming languages with type providers. And I would actually probably design F sharp to be a little further away from .net, and it just happens that one instantiation of it would be to interoperate with .net, okay?
51:22
And so we would actually probably access the .net libraries through the type provider mechanism, for example. So that's one area. I think there's a couple of places
51:43
where I think we've got... F sharp both has records and class types, okay? And I think we would bring those still closer together, and I would actually think we'll try and get that done in a future release of F sharp at some point, just keep bringing those concepts,
52:02
simplifying and reducing the number of concepts in the language. Some of the complexity in the language has sort of flowed in from the outside. It's very, very tricky to get the balance right.
52:21
So take, for instance, F sharp doesn't support partial classes. It doesn't really fit well with the model in F sharp, but it's an example where if we had done it, we'd have a more complex language, which would be less satisfying, but we'd be able to interoperate just a little bit more with the .net world. And I'm kind of glad we haven't done it,
52:41
but we almost got forced to do it. So there's a lot of those edgy kind of decisions we've had to make. We probably got the call right on 95%, 98% of those. There's some cases where this corner... If you look through the F sharp, F sharp is a very simple language in its core use, okay?
53:03
But there's edge cases about delegates or structs or .net things which are kind of leaking around the edges, which you don't notice for most of your programming, but I think we might have let a couple too many of those things come into the F sharp language properly,
53:21
but that's okay. It's not a big problem. John.
53:47
Yeah.
54:05
Yeah. Yeah, I... Absolutely. Certainly not all financial software has to be correct.
54:21
I do think the academic community, which both you and I have come from, do overrate correctness on the whole. I mean, there are many, many kinds of software
54:41
which are not covered by the situations I've talked about today, which tend to correspond to the ones where correctness does matter in terms of getting correct code delivered, getting in the time to market sense of correctness, meeting your requirements sense.
55:01
And I do think those kind of correspond a little bit to the parts where functional programming isn't quite so effective in achieving goals. I personally think that there's a strong correlation between where correctness is important and where strongly-typed functional first programming
55:22
is effective in practice. But yes, I agree with you. There are whole parts of the software industry where correctness is not as important as academics might think, but probably more important than practitioners might think. So, yeah.
55:52
Yeah, I think we're still... So the question was, relative to C Sharp, F Sharp doesn't have great refactoring support
56:02
and advanced tooling support in Visual Studio. People coming from C Sharp notice that. F Sharp is, in a sense, up against an extremely hard competitor on the straight coding front with C Sharp because its tooling is just absolutely fantastic, especially when you put in something like ReSharper into the mix as well.
56:23
Whereas if you compare F Sharp, say, to OCaml or some of these other languages, its tooling is absolutely... I mean, I think it's fantastic. So what are we going to do about that at Microsoft? I mean, I would love to open that up much more to the community
56:40
to allow many more contributors to F Sharp tooling. I don't know. Concretely, it's hard to make that happen because Visual Studio has to be done to a very high level of quality and we can't just allow arbitrary new stuff into the mix. So, yeah, I would love to open that up much more
57:00
to allow many more contributors to do interesting things with F Sharp refactoring and tooling. It's going to take us time to get there and to work out how to do that and what gets done in the core Visual Studio, Visual F Sharp team and what gets done on the outside. We've got a good balance with the community on just about everything else,
57:21
but that one we still need to work on. The one good thing that comes from having a relatively minimal, in comparison to C Sharp, level of tooling is that as you move to the other development environments like Xamarin Studio or Monodevelop or onto the web cloud sharper kind of thing,
57:42
they're all sort of similar development experience. So even though things are a little bit more minimal, at least they're uniform across all these different environments. And there can be something a little bit addictive about having a development environment that does absolutely everything for you, but then when you're in F Sharp, you feel like you can move into different settings
58:01
without really feeling like you're missing all those crutches, as it were. I just ignore it.
58:22
I just ignore that side of things. I find sometimes it's a matter of language. I mean, we have this feature called asynchronous workflows in F Sharp and that's a great name for it and there are mathematical names for that kind of feature.
58:43
This stuff is not mathematical. It's just code. It's just simple, straight code that anyone can understand. I mean, you show F Sharp code to a 10-year-old or a 15-year-old. It's just entirely natural to them. And it's not until we get our minds totally infected by some other programming language
59:01
that people start to find it hard. Yeah, but that's really de-emphasized in F Sharp. The F Sharp community is very practically minded.
59:20
So, yeah. I mean, we just remain very practical, very focused. One, I think, last question. How are we doing for time? Yeah, I mean, there's Microsoft's view on F Sharp,
01:00:04
which is about mainly for data and coding, code-oriented activities, which are mostly server-side or portable activities. So you can use portable components and use them on Windows 8 phone, for example, but not user interface.
01:00:22
The Microsoft's view on F Sharp is not focused on user interface work, which is why you don't see it on all these client-side platforms like Windows 8 phone.