Transcript
Welsh: Andrea has already introduced me but that's the social media, the website if you want to tweet me or read my kind of deranged thoughts. Thanks for coming along to my talk. Let's get going.
Outline
What is this talk about? The main point I want to make is that you should consider using more programming languages or maybe I should say you should consider changing programming languages, perhaps more frequently than you currently do.
One of the things I believe is that programming languages are over the long term the biggest drive of productivity that we have. I think is bigger than process, bigger than architecture, bigger than libraries but it takes a long time to see those returns, I'll make any case for languages on that front. If we are going to adopt new languages, we got to understand the forces of against adoption, what stops us from adopting languages as quickly as we might like and understanding how and when we should be adopting languages. Those are the main points in front of making this talk.<.p>
The Lawyer Hypothesis
Let's go back to a depressing long time ago back to when I was at university for the first time. Back in Australia, at the University of Western Australia, I studied engineering. For some reason, I'm not really clear on we had this on running feud with the lawyers, we had T-shirts that had this quote by William Shakespeare, "The first thing we do let's kill all the lawyers." Every year, we would have this big battle against the lawyers which involved sort of water fights, some tug of wars and just general mayhem. Every year, we would absolutely destroy the lawyers which was helped by the fact that we had many more students than they did and, probably, the gender bias in engineering gave us a bit of a physical edge.
I grew up thinking that lawyers were scoundrels, that was my first introduction to them. As I met a few lawyers outside of university, I understood that, actually, lawyers are not just lizards walking around wearing human skins. Well, a bit of a strong statement, they're mostly not lizards wearing human skin. Another thing about lawyers I also learned was that they do get paid a lot and programmers get paid a lot but there’s something interesting about lawyers which is that at the top when you have the people getting these salaries, which is CEO level salaries, these lawyers, actually, do law whereas the people at the top of software companies don't do software, they don't write code. That's interesting to me because I believe that the value of software is much higher than the value of law. I don't think that's really controversial because the richest people in the world are all coming out of software companies. These companies have huge capitalization, computing companies like Apple, huge market capitalization is clear, the value that software can deliver is much higher than the value that law can deliver.
It seems that the productivity of an individual lawyer, the ability to create value, is much higher than that of the individual developer. Then the question becomes, why is that the case? Is it just the fact that the lizard-like metabolism allows them to work 24/7 or is it something else going on? Let's look at productivity. What determines productivity in this industry? Something which I hope is not controversial is that humans don't scale, this is the law of software. Humans make mistakes, humans get things wrong but the thing that does scale is automation and that is why software is so valuable. We can take lots of people and do them on one computer and do them efficiently. If we're looking to scale, we need to look at automation.
Productivity means we can't be writing code, the only way we're going to get productivity is by not writing code. The only way we're going to get productivity at scale, is by not writing code. Ultimately, we have to not write some code, so all of your process, your domain driven design on that. The whole point of that is to find the right code to write so you don't write the wrong code. Other places where we can get productivity are by using code that's already written, reusing libraries, reusing that web server, that web framework or react or whatever it is that works for you.
Another place that we can avoid writing code is by the language. What the language features give us are things we don't have to write ourselves, for example, in assembler, you have to worry about register allocation. That's something you never have to worry about, it's done for you, it's written for you by a compiler, so the languages allow us to not write code. This is fundamentally about abstraction, it's being able to say more concisely something that covers a large domain.
When we look at the facilities that we get for abstraction, ultimately, languages give as much more power than libraries because libraries are constrained by the host language. If you write a library in C, for example, do you always have to talk about memory management? Maybe it's not actually relevant to the domain but it's going to be in there, you can't get around that but if you have a language that gives you some kind of automatic memory management there, like, last approach I find linear types or garbage collection. That's a concern you don't have to discuss, something you can only achieve in a language, you can't achieve it in a library.
What Is A Language For?
I want to look at what can we do with languages. When we understand what language does, we'll understand where we can adopt them. When I think of languages, I think of them delivering two main things. One, is this idea of language as a tool that allows us to control the machine, it's the interface by which we access the machine, can we talk about types that the CPU understands? Can we talk about floating point, IEEE Floating Point. Can we talk about machine [inaudible 00:08:15] to be integers. Some languages allow us to talk about these things and some languages don't.
JavaScript, for example, is a language that doesn't have any distinction between integers and floating point. You have to hope that the compiler can figure out what type you're actually using and do some arithmetic with it. That's something that you can't control in JavaScript. Another example might be CMG instructions, the vectorizing code. On the JVM, you can't explicitly talk about vectorizing code at this point in time. The just in time compiler, JIT, will recognize some patterns and vectorize them but you can't explicitly tell it, "Hey, I'd like you to vectorize this." You just have to know the patterns it's looking for or you have to hope that it's going to recognize the code and vectorize it.
The machine is more than just a CPU, it's a whole sort of system that you run on and so one of the things that you can do is like accessing an operating system. Can you have access operating system? You do not have a structured way. The JVM gives you kind of abstract view of the operating system which can be annoying when you can't get access to the features you want, some of the non-blocking stuff is not as good as it could be, for example. Operating system is sometimes not really like the machine operating system sometimes, it's something like the web browser that is a platform that seems to run on JavaScript being as an example there and so on.
On another case where we see a sort of a platform and maybe don't think of them as platforms are when we have frameworks so a lot of systems, for example, a mobile, thing that you're accessing. The operating systems, there are some aspects but it's like the UI kit that you get, user interface tools that are provided by the Apple's UI Kit, I can't remember what it's called in android. These frameworks are things that you also use languages for.
Another way of looking at languages which is somehow orthogonal, is as a notation for expressing thought or a notation for expressing solutions. How concisely can you express whatever it is you're interested in and avoiding the irrelevant details like memory allocation was example used earlier. It's going to be allocation relevant, if it is, can you talk about it? If it's not, can you not to talk about it? In many cases it's not relevant, so you don't want to talk about it.
What are the first class values in your language? What are the things you can return from functions? What are the things you can pass to functions? What are the things you can compose programs out of? Languages without first-class functions are a great example, season example there. You can return a function, you can return a function point, it's not quite the same thing. You can't really pass functions around the same way, you don't have a notion of closures we could say. You can't compose functions together in the same way that you can in function programming languages.
Another example of generic types can you express that some code is abstracted over any type often use in containers but not always used in containers in function programming world. We have lots of things where we abstract the types, the express of error handling or concurrency, all by using generic type is something that you can do in majority of 30 taught languages we can't do in Go, for example, in all the generic types, you're going to get the things that they build in. The limitations to what you can talk about, in Go, you have this repetitive error handling pattern that comes up again and again. You can't abstract over it because you don't have any notion of generic types.
Another example is automatic resource management. Do you have to manually open and close files or files be closed for you and if they're closed for you, at what point are they closed? This is really looking into the future a little bit, we're used to memory being managed for us but the memory just one type of resource and then there are lots of other resources that we might learn, manage files, sockets, whatever. Most languages don't provide any facility for managing these. I think Rust is where we're first seeing these ideas coming into the mainstream. Those are the different views of languages, controlling machine verses expressing thought, in terms of the platform and your language ransom, what can you use and then what concerns can you discuss in your program or what concerns that you're forced to discuss by the language?
I just want to emphasize that when I talk about the machine, I'm not necessarily talking about something running on a physical CPU, it can be abstract away like the browser and also we can narrow down this idea of what is the machine that we have access to? It would be quite narrow and we call these things like a DSL, Domain Specific Language. You might have, a common example, DSL is a style sheet, Cascading Style Sheets, CSS. The machine that you access here is the lead engine in the browser and you can control that in certain ways and you can't talk about anything outside of that. You can talk about layout, animations, and no more.
Domain-specific languages or as I call them sometimes little languages, a very important class of languages we need to consider. We normally think of these big languages, we discussed earlier in Go, Scala, Java, whatever about other languages as well. One of the things which I think is interesting is that, generally, notion of the machine which determines if the language is going to be used. For example, JavaScript. Who would use JavaScript if it wasn't for running in the browser? Well, some of you might but I don't think many people would because I don't think it is a very good language. Maybe I'll just say there are better alternatives.
Of course, if you're running stuff on the browser, you don't have too many options. At this point in time, web assembly is more ubiquitous, you have to at least compile into JavaScript some way. This kind of machine is driving adoption but it's really the notation aspects which are giving upper bound in productivity. There's a real tension here because we want languages that are productive but it's the access to the machine that is driving short term value, so a bit of tension there.
Where Are Languages?
I want to talk more about languages, and where we find languages, I've talked about this a little bit already but let's go a little bit in more detail. We've talked about the big languages, Python, Objective-C, Swift and all that. Lots of those but little languages I think are more interesting and there are more than we expect, here are some examples. CSS, I mentioned earlier, CUDA for controlling GPUs, terrible thing but it is this, configuration, we often don't think of that as being a language but it's already getting that way. Excel, Spreadsheet, probably the world's most popular programming language. Marketing automation, very much outside what many people are familiar with here, this is often controlling like sending emails and things like that or sending tweets when this person takes this action, send them an email, "Hey, I noticed you abandoned your cart, would you like to come back and buy something?" They'll ask millions of those.
There are many more little languages in use than there are big languages and they're much more ubiquitous and we don't really think of them when we think of program languages and we should. When we look at the frameworks that we use, and when using Spring - I feel sorry for you, my condolences - Kubernetes, all these kind of things, the things that are kind of frameworks but they're really libraries and we program them by the configuration files, kind of JavaScript, XML or YAML, or whatever. We call these things configuration and think of them as being like an afterthought but a lot of them are, actually, languages, they just don't realize they're languages. We're seeing that in these crazy little DevOps languages. I've used a bunch of them, Ansible was one of them, that was a lovely thing where I had like a programming language embedded in YAML. I had to work around the YAML syntax to actually get your programming language interpreted correctly.
I understand the Kubernetes are similar things going on, I've never used it myself. I understand I should be thankful but all these kind of things have language like facilities. They need bees of obstruction and reputation, but they don't ignore the fact they're languages and suffer for it. Another example, CSS, pretty much people don't do front-end stuff here but Cascading Style Sheets have just added this notion of variables, they're really not variables, they don't change the bindings if you like. They're probably 10 years, I would say about 20 years too late but this ship has sail because they didn't realize they were building a language, they thought it was a static thing and, really, it's always needed means of obstruction and people have been adding these means of obstructions through other means. Bunch of these little things, CSS was one of them, SaaS was another one generating CSS and now people just write on JavaScript because you need to treat it like a language. They didn't realize that the time they were creating it so they didn't build any facilities or obstruction into the language and now people have to retrofit it in there.
We're seeing the same thing in the DevOps world and these crazy languages that generate, YAML or whatever because the original developers didn't realize they were building a language here, they didn't build any forms of obstruction and now you've got to a mess of YAML and little crazy languages built on top of that. What we see here are languages, languages everywhere, we think of as programming languages but, actually, we're in a world full of languages or things that could be languages if we look at them the right way. A framework, for example, a configuration is a language or something that most people run into but there are many products as well which are, actually, languages, excel is a great example.
When Are Languages Adopted?
The question becomes, if you buy my hypothesis that language is the root of productivity, when a language is adopted, what are the forces that allow a language to get adoption? If you understand this, then we can understand how we can adopt languages ourselves.
The big languages, generally, access to compelling new platform or machine. JavaScript, like I said, I don't think anyone would use JavaScript if it wasn't for the browser. Objective-C, what would you use Objective-C for if it wasn't for iOS? Few developers here. These are languages which I think have a number of flaws in them and I'm not sure that people could use them if it wasn't for the fact that you have to use it because you don’t have to use Objective-C anymore, you can use Swift now on iOS.
Then keep this idea that the platform is not just like offering any system or the device so on. It may be the framework, like Ruby, at the time got popularity because it was seen as a way to access Rails and at the time Rails came out, it was seen as one of the few sane ways of creating websites or web services. They were web services and they were websites, maybe everybody's around at the genesis of Rails but at the time it was the early days of the internet. You had CGI and postscripts or you could write enormous piles of Java nonsense in XML and Rails are seen as one of the few sane ways of actually producing a website. It was compelling to people, I want to produce a website in a reasonable amount of time, I better use Ruby. The notion of a platform is not just restricted to what we typically think of as a device and people, the computation.
Another reason why languages get adopted is because they allow us to respect some legacy codes that we have to continue to maintain our investment in legacy but they give us a better notation here. I think legacy is under appreciated for in our industry. Why are we still using Unix? Can we not do better than Unix? We sure can but we've got legacy is there. We've got a huge amount of legacy tied up in Unix. Why did Windows win rather than OS/2, for example, if anyone was around for that? Because OS/2 wasn't going to run any of the existing software and Windows was and so on throughout computing legacy. Respecting legacy or maintaining legacy has been one of the driving forces of our industry, we don't give enough credit. If you can offer something which is going to allow people to continue using their investment in legacy and at the time has a dramatically better notation than you might see in the adoption.
Here, we have Scala versus Java. When Scala came out, we were still back in Java six days and that was seen as a vastly superior way of accessing the JVM. If Scala came out now, I'm not sure we will see the same adoption because Java has unbelievably to some of us who live through the job six years actually started innovating and changing, which is great. I'm not sure the advantages of Scala would seem so impressive in this new context. On android, it's still Java six days so they're using some adoption column, I think it's quite popular in the android field, I don't really work there myself.
Swift or Objective-C, very conscious decision there to allow you to work with iOS. Rust is introduced, basically, to do everything you were doing in C, to access that operating system, all those system codes but in a much better way. Perhaps, the final one is TypeScript, coming in here versus JavaScript. TypeScript is just adding a type system on top of JavaScript, you don't have to change any code. There's small changes through code but you can get a type system, since beginning adoption really just this year, it seems to be taking off.
There is another force here but I think it's a much weaker force and that is additional cultural fit, certain communities have different values that different languages. If you want to run something on the BEAM, the Erlang virtual machine, you can use Erlang itself which is fairly unpopular. There's this language called Elixir which runs on BEAM, I wouldn't say it's a hugely popular language but it comes from the Ruby community. It has, I believe, a Ruby-like syntax and it seems to be popular with people coming from Ruby who are looking for a language that has a more interesting platform. Ruby doesn't have very much support for concurrency and Erlang virtual machine, obviously, does so using some adoptions in there.
I'm going to say it's by Go versus every other compiled language. Go is an interesting one to me, I don't really understand why people use it, maybe be some of the Go programmers can tell me. My hypothesis is that if something that's culturally acceptable to a bunch of different people, if you're coming from a systemic world, then Go is enough like C. You don't have to learn new things, but you don't have to do all the C stuff and I think if you're coming from Python or Ruby, then you can write your code the same way you would write it in those languages because you've got structural type system and you get some advantages. I think there's a cultural aspect as well as a sort of better notation in terms of aspects, I'm not sure because I'm not much in the Go community myself.
Racket
Let's start the story, then how it has played out my own career. Record is a dialect of Schemes, Scheme is sort of a Lisp dialects. It's a wonderful language and I started writing it when I was at university. I might have continued writing it into a consultancy with a friend from university with credit control. I'm sure you've read some record programs, you got people to pay money for them which seems extraordinary now. Ultimately, though, we couldn't expand the company as far as we wanted to because we couldn't find clients who were prepared to put up that craziness.
The reason I see for Record not getting adoption is lovely. You didn't offer, you're compelling new machine or just lying to the same things, you do any other language. It didn't really have any respectful for the legacy either, you had to write everything yourself and this is one of things that got us, was we just couldn't write our own web frameworks, our own database drivers, and our own everything. It was just too much work to do, particularly, as a consultancy where you may be working different systems all the time. A lot of aspects went into this but I think one is irrelevant.
After doing Record for a while, we then switched to Scala and we've been happily much more successful with Scala. We started with Scala when it was really in infancy and it's been taking off and now there's quite a big community and quite a vibrant one. What I see is driving adoption of Scala was two things, one, there was Spark which at the time you've said you had Hadoop, which is awful and you had Spark and Spark was 100 times faster and you could get pages and pages of Hadoop code, hundreds of lines could be turned into three or four lines of Spark. That was compelling to people to get that Spark is one of the main drivers of Scala.
The other angle was the respect for legacy, the fact that you could take your existing Java Code, your existing JVM Software and you could just run it with Scala being a better Java. That's how I mean many people many people bootstrapped into Scala, they started writing Java without semicolons and then over time, they learned about the new features that Scala brings. The final thing I got to say, it was culturally acceptable for me to use Scala because I came from a functioning programming background and Scala's functional programming language, so I could use Scala without feeling like it was too distasteful so there's some aspects there.
Little Languages
What about other little languages because this is really where I think there are many more languages going on. What are the forces here? I think it's generally the same forces but much easier to adopt because it has much lower risk. Some of them, you have to adopt to access a platform, CUDA and CSS, some of them you can choose what to use. You generally think of that much less investment in them where people pick up, say, one of the CSS generators, none often think that this is like something you're going to be stuck with forever. You feel like you can probably easily get away, change it if you need to because the amount of code you have in CSS is maybe not that large. You don't, generally, have tens of thousands of lines. It's not such an investment so even more ready to adopt.
We've been talking about languages from the point of view of the programming using a language but I want to also mention that languages themselves can be a competitive advantage for business. One example is this idea of marketing automation. Marketers want to do things, they want send email, they want to send tweets or Instagram posts, and if you can give them automation, they'll benefit the same way that we benefit from automation. They benefit as well and they actually do programming although they don't realize it where they set up these little flows when triggers happen, they like sending emails. You can build companies around this and you can access a new market.
Airtable is a startup, it's probably exiting startup phase now. It's a programmable spreadsheet, it's kind of a combination between spreadsheet and database. It's a very flexible tool, I think it's something that we might be seeing more in software every time more program ability, getting closer to pass what people in the audience do.
Let's talk about Cloudflare. I guess most people know Cloudflare and then I think they're building a lot of products based on this idea giving you programming ability. They just announced something today talking about the web filter, the language for web filters and they've had something earlier there, computing at the edge with web assembly. Providing program ability is a thing that can be a real advantage to a company. There are many more of these little languages out there than the big languages. Frameworks are libraries that we really program.
How Are Languages Adopted?
What are the contexts where you can adopt languages? If you're looking like a big language, that's what we normally think of languages, my basic thought is consultancy forget about it. You might get lucky and you choose a language which is gaining adoption but I don't think as a consultancy, you can drive language adoptions. This has been my experience, you have to work so the markets prepare to accept. Most people are not willing for you to put additional risk into their company by using a language that they are not comfortable with. That was our experience with Racket, I got to the point where people would say, "No, you can't use that crazy language." That's quite understandable.
In a consultancy context, you have to work with the market. Maybe you get into that market as the language of the market is growing around it but it's not something you can count on. However, if you are a product company, then you can do whatever the heck you want. That's fine, my advice here is if you're going to choose a language, you need to go all in on it. There's a high cost of failure, but you do have some advantages. One, is you're normally around languages there is a bunch of really enthusiastic, early adopters and they will love to work in your language and you can hire them very easily. They will move for the opportunity or maybe accept lower pay, I've seen that in Haskell. At the moment, I remember one of the cases in Scala is now swung the other way completely where you can't hire Scala developers anywhere but if you get in that new language, then you'll find people who are really excited to use it and they'll come to your company and they will help you recruiting.
That pool is going to dry up eventually, I suggest very strongly and I think all companies should consider this really, is creating a remote first culture, I have companies who have been remote first. There are so many developers out there in lots of places that you can access, that are not London or New York or San Francisco and they will happily work through a company if you can accommodate them, particularly, if you're using a language they like. There are down sides here, I think you need to go in on a language but you got to be prepared for some burden you're going to be taking on.
You might end up maintaining or building a bunch of libraries than the database drivers or the AWS library or Google Cloud or other cloud providers who do exist. Those libraries might not exist, you might end up having to write them and maintaining them and that's the pain but it does give your status within the community which is another thing you really need to look at during getting new language. Maintain your community presence so that you can find these people who want to work with these new languages, come to, so you got to be visible there.
The other problem is you're creating legacy. One thing I've noticed when people start using new languages, they often don't know particular community is small, the idioms are not established yet, they don't know the best way to use the language, they make lots of mistakes. We made lots of mistakes in Scala and there are many frameworks in the early days that people don't really use anymore and we consider them to be bad designs, we first had to learn that the hard way. Be prepared that you will be making mistakes and you will just fix them up. That's possibly the case in anything but depending on where you adopt, there may be more mistakes to be made.
The advice here is start small, start maybe with your best teams, got to demonstrate success early. People get nervous, you're taking on a risk here, you've got to demonstrate that you can mitigate that risk. Choose something that's relatively isolated part of system to demonstrate that you can implement it or re-implement it in this new language. Once you've got that, then you can spread out amongst the rest of the company, normally, team at a time, telling people what the best practices are getting that new culture that is new ways of doing things, getting that spread across the organization.
As a consultant, who've done a lot of these, consider getting external mentors in. We do a lot of work with people that are adopting Scala, they tell us it really helps them. We're perhaps view that they don't have and we also have time that they don't have to help people switch this new way of doing things. There are external experts, maybe consider getting them in, I think a lot of companies underinvest in training, they make a mistake. Little language on the other hand, the risk is lower, so I just say, "Just go for it. Have fun, it's great." Low cost of failure.
The language that you're adopting here, firstly, is it simple enough? A lot of languages have an appearance of simplicity but if you see Rich Hickey talks, simple is not easy, they end up being real messes. You have like these DevOps DSL that I talked about earlier, they appear on the surface to be simple but when we actually get into them and you're trying to use them in a moderately sizing, they are very difficult to reason about. That's what real simplicity is, can you reason about this, what is going to happen when this beta code is used? Have people got a good design here or how they just sort of bunched together whatever came into the head the first time.
There's another point here that is this going to be used enough to actually make it worthwhile to overcome that? There's a one-time cost you pay for learning and you then get the benefit every time of that learning. Are you actually going to use this or not? It is just some peripheral part of your system that people look at once every six months, for example, in which case maybe it's not worth doing because you won't get that benefit from adoption of language.
The final thing is, when you introduce a new barrier in the system, you go from a configuration thought of framework or whatever it is. You're introducing difficulties of reasoning because it's very difficult to reason across boundaries, something you will see in micro-services, for example, where your protocol ends up being something you just agree on and it's very hard to understand what's going on the complete system. It's the same thing with DSL, if it's DSL, particularly if it's an external DSL, the one embedded in a host language is difficult to reason about that, it goes across the boundary. Be careful about where you're introducing these new boundaries and ask yourself, do you want to reason about this?
I have a colleague of mine who is working in the U.S., probably, she can tell you the customer but he has spent. This week and most of last week, has been just dealing with configuration files trying to understand, what is the actual configuration that this system is running on because it doesn't seem like it's doing what it should be doing. That's an example of this problem, we're trying to reason across the boundary, the configuration file, how they actually get assembled and what is the current running with. That's much of what I got to say.
Conclusions, I think languages are really powerful tools, I don't think we give them enough credit. What we can do with languages, they can allow us to be much more productive, they can open up new market segments based externally in terms of what we're doing, providing for customers or internally, they give us novel ways of doing things that can be radically more efficient than what we're used to. Adoption is risky, the conditions have to be right. I've gone through some of the conditions, I've seen in my experience some suggestions but you consider adding an idea of languages into your toolbox along with everything else as discussed in this conference.
We've talked about continuous integration, deployment, DevOps, domain driven design, people very rarely to talk about languages. I think that's something you should consider adding to your toolbox. I think it's really powerful if you can leverage it correctly.
Questions and Answers
Participant 1: How important do think opinionated this is in languages? For example, one thing that Go may be was that it had good format. There's just one way of doing this. TypeScript opinionated JavaScript.
Welsh: I think there are a bunch of things where your opinion is unimportant and that is like formatting of code. Who cares? Maybe some people do care but I don't think any sane person cares about the formatting of code. I've got some OCD colleagues who like to rearrange code all the time. If you're going to take away a bunch of decisions you don't need to make, I think that's great. That's one aspect of opinionated, of just decisions that you really don't have to care about to get rid of them, give them to a tool.
I think the other point is opinion is guiding you down a certain form of language design. We see that probably in Scala where perhaps it's not opinionated enough and people end up doing all sorts of crazy things that aren't working so well for them. I think having clear consistent paradigm is important but then I got to say in defense of Scala, I don't think it will have the adoption it had if it wasn't so easy to go from Java into Scala. I don't think it would be that gentle slope and then you can get down the sort of functional roots that I think most people end up.
Opinions, I believe, are important but if you're particularly opinionated, that can be a hindrance to adoption. We probably see like Scala getting adopted instead of Haskell, Haskell is a much cleaner, pure functional programming language, many of the words in Scala don't exist there because it doesn't respect legacy because aspects, it doesn't have the kind of same adoption, so you got to be careful there.
Participant 2: What do you think of the future of Scala, especially, in the face of all of these innovation in Java, these functional features, etc., being added?
Welsh: First question, are you a Scala programmer?
Participant 2: Yes.
Welsh: I'm heavily in Scala. I think Scala 3-Dotty is going to be great, is going to get rid of a load of inconsistencies, what's in the language, and give us a much cleaner way of writing the kind of code I want to write, I think that's great. I also don't believe that what Java is doing is a serious threat we can say to Scala because I don't think it gives us the features that I want to use. However, I think you have to go quite away down the functional programming in which to understand a lot of the concepts, a lot of the benefits you get from it. When beginning functional program, let's talk about functional programming, they tend to talk about first class functions and high order functions and immutable data structures, they're very surface level things.
I don't think that's wrong, I think that's just the way that people learn, there's no problem with it. My experience has been as I go further, I'm caring more about reasoning about code and things like higher kind of types that allow me to reason about code, which is much harder to explain because you need to adopt a very different mindset, you need to do a lot of learning to reach the point where these concepts are meaningful. In summary, I think Scala 3 is great, I think it's going to allow Scala developers to do much better things. I don't know that it's going to be particularly compelling to Java programmers because I'm not sure that they're necessarily on the mindset or paradigm, what do we want to see where there's compelling features to them, but we will see.
Moderator: You talked about configuration and small languages and I'm wondering, this is what happens to me? I see configuration files and I see this looks like a language to me. Why should I stop going and implementing an interpreter language on top of this configuration files or then, I don't want my co-workers to hate me.
Welsh: No one would hate you, Andrea [Moderator], it's impossible. I think we should be treating configuration as language and I think we can do some really interesting things there. One thing they're going to ask the world to have this language code DOL, which is not Turing complete. It's a configuration language that we can't write in an infinite loop, I think that's fantastic. I have a customer I'm talking to at the moment, actually talking to the lawyers which is terrible because I think their lawyers are reptiles. They insisted like a configuration language, the system is configuring it for the enterprise.
If you can have a configuration language that doesn't allow some sales engineer to have set everything into an infinite loop, that's fantastic. There's a real benefit to be got there from having taken the idea of configuration as a language. Of course, the usual benefits of abstraction, these configurations can be enormous, you want to re-use them across different clients, particularly, when you've got like parent organizations that have accomplished that. Lots of benefits of abstraction and configurations, I think we really should be treating configuration as a language and apply the same discipline we do to big languages and perhaps we should be looking at terms of things like this non-Turing complete guarantee to terminate some languages.
Participant 3: What are your thoughts on evaluating and re-evaluating choices that you've made as a team for certain languages? Like for example, I work in analytical team where for the last three years, to my experience we've had every year the same discussion, are we using R, or Python or both. It's coming back every time. Do you have any thoughts on the matter?
Welsh: If you use a big initial distinction, then I think changing the big language has a higher cost, a higher risk to it. That's probably the case you're in of using R and Python, use both. You have to see what are the benefits you're going to get from changing. Normally, it has to be, most people are fairly dramatic in improvement or can you lower the cost of switching to the extent where it's not such a big deal to change between the two. I think there are some interoperability between Python and R, maybe that's sufficient.
I would just say, look at the cost in case you get our training and unfamiliarity with code, perhaps. What are the benefits that you're going to get in return? Access to different tools, perhaps, I think, ours has got a better sort of statistics, toolbox and Python probably a better machine learning toolbox. Then if you can push down the cost of maybe people who can develop training internally, learn R or Python or whatever it is that you need to do, just the way you organize your team, so that's not just like a Python silo or an R silo, then maybe you can push down the cost of benefit from both of them, I think that's possible but definitely, are risk associated. We need to be cognizant of that.
See more presentations with transcripts
