 All right, so the idea is that there is one chair empty over there and One chair remains empty at any given point in time This is to encourage people from the audience to come up and take that chair whenever they feel they have something to contribute So it's not a one-way thing Of course, we've seeded the panel with the speakers From today or over the conference on the conference speakers and the idea is that when You know, you folks are going to ask questions that you think were not answered today And then once that is done then, you know, we'll when you ask a question It depends you can you can Tony if you don't mind just we'll rotate the speakers. Yeah We will get you up shortly. So When you ask a question, you could specifically ask a question to one of the speakers up there Or you could ask a generic question and you could say I would like every speaker's opinion or I would like You know anybody's opinion like up to you when you ask a question. All right So simple rules you ask a question the panelists will answer if it's directed to a specific person They will answer it if not anybody will pick up and answer if you are in the audience and you feel you have Something to contribute to this then you come up take the empties chair and you, you know Get a chance to contribute when someone comes up and takes the chair one of you will have to leave the panel So that ensures that there is an open chair at any given point in time Yeah, simple So who wants to inaugurate Do we want to introduce the speakers quickly? All right, my name is Saurabh. I Write a lot of Haskell at vacation labs my company. We have about Close to a hundred thousand lines of Haskell code in production So yeah, you can ask me anything about Haskell and how it compares to Ruby because the other hundred thousand or two hundred thousand lines Are in Ruby on Rails? My name is Andrea and I work with elixir. I'm a member of the elixir core team and Yeah, mostly work with elixir. So if you have elixir or a long questions Can try to answer My name is Bruce. I work with a tiny startup called groxio. I am a language expert. I also work with elixir My name is Edward Comet. I do a lot of work in the Haskell ecosystem I think I personally maintain something like two and a half million lines of Haskell Which is somewhat absurd at this point I'm trying to figure out ways that I can replace that with something like 400,000 lines worth of coda. We'll see if that happens at some point My name is Aaron Sue, I'm one of the APLers here and I guess I'm responsible for the code funds compiler So I've got a host a GPU hosted data parallel compiler for an untyped Functionally oriented language that is written in 17 lines of APL. It's 948 nodes 74 unique names and 1000 no 1000 tokens something like that I'm Morten Kromberg. I'm the CTO of dialogue We would say the leading vendor of APL systems in the world So my job is to think about the direction that APL should be taking in the future. I'm Alexander Ganyan I'm a Haskell developer and my mission to make Haskell more adopted by mainstream and industry Hi, I'm Anupam Jain. I work for S&P Global The very small FP team within S&P Global. I mostly do web development with Haskell and PeerScript Ed Comet used to work for that team and now we he left just before I joined Yeah, so but but we have great help there Is So 15 years ago my experience was mostly not that functional programming is banned but that it's we don't know what it is And even now I would say it's something somewhat similar When I I still get comments that when I say Haskell people say oh Pascal So I think the step here is educating people and Conferences like these really help with that, but I don't think I've Had a lot of resistance with people willing to listen, you know It's just that resistance to adopting it in their work, which is understandable So yeah, so continuing on the path that we are going on I think we'll we'll get there the day of FP will come Okay, considering Partial programming is about Haskell nowadays mostly Yeah, I can answer the question how we can make our best functional programming language more popular in the mainstream I It seems we have several problems to solve for these the first problem is that okay? Haskell is quite different in sense of its semantics its concepts and It's code structure. Still it's not really different in the design space if some business Wants to build applications. It doesn't bother about filters applicatives that they'll magic type families it needs to create real value to to get its job done in this sense a really really comes from the Possibility to change your code according to changing to Fastly quickly changing requirements and this means we should not play with our language and we should not play with our Cool concepts, but we rather need to focus on the creating this value We probably need to understand that Haskell Well, it's very powerful language it it should be Treated as other languages In the design space like you need to structure your code you need to spread concerns and you need to test your applications this only can Attract some attention from the mainstream. I'll do one more So I think When Norash did the sort of opening comments about this it was sort of the the two feet principle of You know vote with your feet There's something to be said about the fact that you know the blockchain is active to sort of the Haskell full employment act and If you really are willing if you just aren't happy where you are and just need a job and are willing to work pretty much anywhere involving a blockchain You can probably do something that may or may not be meaningful to your to your personal ethics But One can get up and leave pretty easily With that sort of a scapegoat on hand So I think that if you're selling features if you're talking about features that you've already lost What we need to be selling for functional programming is success. So It's all about business value. It always has been and it's it's So I I I came off about a period of doing about 10 years of language adoption talks and every single one of them was a different angle on the same discussion Where does the business value come from? And and where are more to the other? Languages have limits. I think we need to sort of again It goes about awareness at two levels one is at the very top of the end Which is talk about and celebrate successes, right? I have a hypothesis early online people can correct me if this is wrong the acquisition of WhatsApp did a lot to sort of Create the buzz around Erlang, right? So we need to talk about where these were the programming language itself was critical or you know Was one of the reasons behind a business's success because that gets covered and talked about a lot more That is at the top end at the entry level specifically for Haskell We probably need to be Create educational material to make the journey to learning has to be easier because once you've learned about the success And you want to sort of get into FP? It can't it shouldn't be that uphealer task. We need to make that thing easier as well to get broader adoption All right. Sorry. I I'm This is a huge passion and big topic of mine. So forgive rant on Every single one of any every okay the short TLDR Stop playing a religious game start actually doing real science. So here's the problem is everybody here has talked about Basically the solution is to deliver more miracles and preach those miracles in a constantly Religious battle between who's got the best programming language? That's the state of programming language design right now We're great implementers. We're terrible designers because we have zero Practical experience with how to do good design and what that means because it's a human social science. It's not a Mathematical science in the way that we would like it. So we ignore it and we turn it into a religion and then we fight back And forth about what's best on religious arguments with faith-based reasoning with no actual Evidence to back up any of our claims except for the miracles that we perform Right or the magic shows we perform and that's not a sustainable model for actually explaining why something is a value Your business value is essentially look at this miracle. Maybe we can replicate this miracle if you go with one of us Apostles will help establish your church, right? That's that's what we're doing. It's this exact same model What we need to do is start recognizing that HCI design Hcid those guys who do all that work on Developing the cognitive science and applying it into things like Facebook and all of these apps have something that's really valuable to the programming language design community and we should start doing large-scale Usability research and design using those techniques and formulating patterns and ways of addressing that inside of the programming language design space because we do that we then have the Research to say ah this actually is useful and this is why it's useful in this space And this is how people engage with that code this programming language. This is how they use it This is how it affects how they think and now we can have a conversation between two language and say oh Should I use semicolons? Should I not should I use this types? Should I use not this types all of those now become useful? Decisions because we have data to back them up And we're not just arguing based on how we feel or how who influenced us the most By showing us the most compassion in our journey towards enlightenment. Thanks. I'm not following that up I mean I can say I can say one small piece about this which is the sort of almost Apology for this current state of affairs which is in many ways We ask a lot more of our tools in our environments than we used to like once you have this headroom to do things We we ask our compiler to stay resident So it's giving us since it's giving us information about the symbols that the compiler was using so that you can Actually have all the tooling inside of your VI or emacs or visual studio code So we ask a lot more of our tools And that's one component of the thing I mean we there's there's folks who like do have this sort of microscopic focus the Russ community comes to mind like like religiously avoiding having a runtime system I Will say Haskell was definitely not one of them More interesting things to say than I I think I I think I said most of my opinion about this yesterday So I don't feel I need to reiterate that much, but I think basically we have the wrong abstractions APL One thing that I would like to add to that is that a lot of The layers that we built upon software have to do with the fact that People who are working with that layer don't understand how it works So they build more and more abstractions on top of it then someone uses that abstraction and doesn't know anything about the layers below So it's more about understanding your system and the more we understand the system the less layers you're gonna build around it So we we need to work more towards that educating Resources to help people understand what they're building, right? Yeah functional programming started Being popular in the industry not that far not that so far back to the Decades maybe ten years maybe not more, right? I mean intensely so it seems not our fault that Software is so slow So I think that one of the things that's happening is that the level of abstraction is coming up on the hardware layer And I think it needs to I I had the opportunity to teach a team of Mintes in in Chattanooga, Tennessee From experience from Non-programmers to people that had a couple of years of coding experience a project and the project was to build a photo booth The photo booth was on you know Raspberry Pi and then a couple of pieces on layers on top of that And it was pretty gratifying because we were able to do that on a much higher level language And we had the tools and the infrastructure to kind of burn the You know burn the cards over over the internet We had we had full networking on the card. So I don't think that That we're comparing apples to oranges here I think that the level of abstractions are getting higher and I think they really need to What's this great language you're talking about? That's not elixir with nerves I'm just kidding. I'm just kidding. Yeah, so there's another aspect of this which is We there's a there's a cultural and an education component that I think we we could do well to maybe improve a little bit because Across the board computer scientists are terrible at educating which leads to poor competency Which leads to a culture that has to justify that poor competency which Contributes highly to a lack of high performance and of the ability to deal with those extra Value-add things that maybe don't appear important, but are the long-term decisions we need to be making So if we sort of fix some of those issues, we can Create the space to work with a more long-term vision. I think I might be wrong But the most slow software we have now is like browsers like ideas maybe and GUI applications and maybe a rust can Give more sense here for example in in browsers. Yeah Yeah, yeah, we can do that Okay again again, this is again coming from a user perspective and somebody who's interested in Just looking at the world from that perspective It fascinates me that we are able to like, you know, we're able to like run a system that sends 23 watts of power our way and we're able to sense a billionth of a billionth of a watt and that system has been running for like 40 years plus the Voyager probe one and two both of which have gone into setter now and I mean, you know, it's very hard to follow that act It's really hard to follow that act and You know even having these examples out there like real-life examples you can see today There's like this, you know What do you what do you call that like Disembodied kind of experience like, you know, there's a quote from the wire for fans of That TV series like world going one way people going the other you okay, so it kind of feels like that So that's what I wanted to say. So I think that one of the things that's happening is is inertia I have a couple of a couple of times through a college called Mississippi State University And that's that's not a very big technical college in the United States when I was coming through We were one of the first schools accredited in the south and the school was dedicated to teaching You know undergrad studies and and not investing so much in research and hardware And the school did very well More recently the school has been investing a lot in the Java infrastructure And and the Java professors and the Java curriculum and the certifications And there's not much room for the curriculum to go And so it's not there's not much room for the curriculum to grow. So I think that We have to overcome a lot of inertia and in academia Really and in corporations also for things to move So I've worked with JavaScript Java and PHP Earlier I can I can give some insight into what made it easier for me Because I did dabble with Haskell at that time as well It's when you have a problem to solve that's when you look for a solution, right? so When you have a simple problem you expect the solution to be simple a lot of these languages that We work with now we realize that they scale well. They have nice abstractions But are they really easy to get started with right and there's a lot of boilerplate and there's a lot of Concepts that you need to understand before you even get started, right? I think we need to work more on that and then Tooling is a really big factor that basically contributes to the same thing You cannot get started a person new to the language or framework cannot get started if you don't have good tooling if you don't have an ID You have a research project That's what I believe so Any so Haskell is still a research project in that sense But there as and it can be done because pure script has much better tooling It's it's like a pet peeve with me because over the past year or so I've started getting into pure script and The ID situation is very nice there so Pure script is much easier to get started with and the same with JavaScript the JavaScript with You have sources available right in the browser. You have fantastic debugging tools right in the browser You're using the application. You can see all the libraries that it uses, right? Those are the things that we need before things will Before people will adopt Haskell So because pure script compiles to JavaScript has some of those advantages because you can jump into pure script code and jump in JavaScript code Beyond that, but I think those are very important much more important than we give it credit so Not a surprise that I'm opinionated But I want to reiterate that education question because if you actually look at what happens with a lot of these things You can see a correlation between The time it takes for a university graduate student or a set of them to begin to enter into the workplace and then get senior enough to affect decisions in that organization and Programming languages and how that changes right and so you can begin to see the effect of object-oriented Programming in the 80s and the 90s finally leading into something and then you can see the same thing in functional programming Getting during the 90s getting into the 2000s right and I go back to that experience right so you've got the education thing So if you don't equip the students coming out of these things to think with a certain model the experience of engaging with that New language is going to be significantly worse Right, so they have to the border or the barrier to entry on functional programming if you have never seen it in your university Is really high, but if you've learned functional programming as an undergrad Suddenly, maybe you think it's useless or not But then suddenly it shows up again at some point and it's much easier to adapt to at that point So there's a big usability question and that usability goes right into tooling because the tooling matters as well And when you put the whole thing together, what's the experience that they have? And this is a place where I think somebody the other day mentioned the the correlation was it you that talked about correlation and Pursuing an end goal and things something happens to be correlated with that end goal And so we hyper-optimized for that correlated thing, but it ends up leading us in the wrong direction So this is a I think this is a really insightful thing because we do this a lot in our programming languages Communities and if we can shrink this down to a simpler problem keyboards So keyboard layouts right if we can I'm a geek about keyboard layouts And I'm a really big geek about keyboard layouts because I can type really fast on all the four major keyboard layouts in English Dvorak, Korty, Colmack, and Workman And I spent years studying the effects of each of those layouts and each of those layouts purports to be better than Korty and there's this classic example in that mistaut in business school saying oh well Dvorak should have won based on how much better It was but it lost because even though to it was an inferior solution. The problem is that's one of those bad Examples because actually Korty is not bad when you think about what really matters to somebody who needs to type at a high performance level It's actually one of the fastest keyboards. You can type really really fast on Korty compared to the other systems It's just that those other keyboards are hyper optimized for things that people think are correlated with performance and efficiency So Dvorak does the optimizations the key Colmack optimizes certain finger Triplets Workman optimizes for a columnar layout But when you actually get into to high performance I saw I say above 120 words per minute on each layout You start to see a pattern of which one flows at the high levels and it comes out Oh Korty is actually just fine And I think a similar thing happens in our programming languages We optimize for this experience that we think is correlated with the end result that we want and it's really not I Just want to make a very small point to your to your the very start of your Comments, which is that I think just about five or six years ago Working with the ACM we there was just so if you look at the standard like computer science curriculum ACM advises universities about what that should be and The functional programming wasn't even on the syllabus of what should go into a computer science education as of five years ago So we just recently got to the point where like it's even being included in the Recommendations from the ACM as to what should be taught So there's some hope Using your kind of timelines that if we move forward another ten years Then we'll be able to see better impact from it, but it's just now coming into the computer science curriculum I feel like again from coming from a student and user perspective what doesn't get taught doesn't get popular So to extend the keyboard metaphor like the fastest type is in the world use corded keyboards, okay? they use coding and They go up to like 300 words per minute Many times and but that's never taught like regular typing Korty keyboard. I mean I feel like Learning to touch type should be like a basic skill taught in computer science school but it almost like at least in India it almost never gets taught and That removes accessibility to a lot of things like you cannot be productive on the command line You cannot be productive in your plain text editor. It's really hard to get any of those things done Like that is a entry level scale which opens up doors to many other, you know, many other tools and utilities that Are not becoming popular for that reason So so it's like I think I'd like to Yeah, it seems we are mostly talking about technical aspect of this decasional reason Decasional process still I want to make a point that in 18th we had a situation when OP occurred and It was equal to the phrase Your code quality is how much OP you have in this in this sense The industry decided to teach Other people to OP because of this and not like separate people but the industry as as well and maybe we can have a similar situation with functional programming in Education facilities like universities or maybe schools and we'll hear that How much FP you have in current code? This is your quality of the code. So whenever you have a bigger FP code base Then maybe you have more quality and less OP like something like that I'll just take the level of abstraction down a bit the going back to the question was like what are languages like PHP and JavaScript doing good So I'll take the example of PHP So a lot of us in this room Are have probably picked up PHP on their own Right, so the good thing about PHP is the beginner onboarding story. It's just so dead simple coupled with the Deployment story. I mean once you've got something working and you want to put it out into the world PHP has got the dead the like nothing beats the deployment story of PHP get an FTP Transfer some files onto a shared hosting and bam your your whatever concept that you've worked on is out there in the world That's fine. That's that's yeah, but at least you've got your instant guy you've got started Right, so I mean that beginner onboarding Like to give just one small example. What is why is PHP so popular beginner onboarding? And the deployment story, right? So what for what it is primarily used for I? It was by design or by accident, but it's absolutely well optimized for that So I mean this is really a question more than a comment So APL is coming into this functional space sort of from diagonally from the side We have a lot in common with functional programming But one of the things that's really important to me in my daily life as an APL programmer is that APL is a multi paradigm So I can do imperative. I can do oh, I can do functional programming depending on the requirements of the particular application that I'm writing So often a lot of my computational code will be in a very functional style But then I'll be writing gooey in an OO style and so on and to me that feels very productive I'm just wondering what people think about the importance of being multi paradigm rather than purely functional Very briefly that I consider haskell to be a perfectly Cromulant imperative language Yeah, I get a lot I get a lot of imperative code if you look at I was talking about guanxi this logic programming framework thing That I have here right behind the scenes. That's all mutable references and like very imperative style flow Like bolted in like this sort of functional paradigm Yeah, I mean do you have a way to do that that makes you feel elegant or do you feel dirty when you do that? I feel no more dirty than if I were to have to go off and read it in kotlin or java or something Like I at least get to I at least get to keep the rest of my tooling in my ecosystem Right, but I mean some applications just you know do this do that do the other thing You shouldn't feel dirty Well, I think right now if you were if you were to come into industry today Um, java has picked up lambdas, right? We've gotten to the point where there's a little Smattering of functional programming that everybody feels the need to incur in their language design Just to feel hip and trendy enough or something or relevant enough to this current Like the current zeitgeist or something like that So you're going to see like getting a little bit of it during your education and then seeing it in industry as sort of a Gateway drug is already there. So I don't think I mean whether you like completely decide to wear their whole hair shirt and write Haskell all the time is a completely different thing but I think Like everybody I've run into at this point in time knows what a lambda is and has gotten the idea of like mapping over a structure or like iterating and doing for reaches and stuff like that in a fairly Object functional mixed style. So at least we've made those in place So also Having been just deeply associated or working with the university at in indiana for a while And I did a lot of education work there and this question of what should we should be teaching? Is is a is a big thing and I The reality is is that if you focus On and and IU has tried both both approaches the high theory approach and the Get them a job approach and the reality is is that the universities are not Agile enough to be able to get somebody placed in a job by predicting what they're going to need is skills That it doesn't work and the kids who come out resent the university for teaching them old skills that are useless So the the problem that we have with computer science right now is it's too big There are too many things to learn that you you cannot learn them reasonably in the amount of time given With the typical student that you're going to see So the problem is that you've got to pick and choose what you're going to teach and if you focus on teaching Java or these particular language skills or these particular things You will never actually be able to place the students well They will always have a bad record and your university is going to get a bad reputation The only real hope is to elevate the Students mindset about how they're engaging with the computer science field and teach them an engagement methodology with technology Rather than teaching them a specific grounded skill And that's all the time you have in an undergraduate curriculum in the u.s To do and so what you do is you teach them all the things necessary to As rapidly as possible adapt to whatever position they can and then Arrange for good relationships with the local industry so that you have a reputation We're giving the best students out and then get them hired through those things And you have to teach them programming languages to do that and they will have those skills In certain programming languages, but they will not think of themselves as an identity of i know java I know this you have to stop making people think that's their identity until they've spent time in industry and actually know What's going on because they need another like six years to actually figure out the landscape Yeah, a couple of things um the first i'd like to i'd like to make a comment on the um on you know the the c plus plus idea so this pattern of of Kind of sprinkling other paradigms with the next paradigm is not a new one I mean we had we had that with with c plus plus we had that with with eta for oop and Nobody really wrote C plus plus object oriented code with the first iteration of c plus plus right so it was more of a c plus plus minus minus right so um But this is already happening again So with with python and with ruby and and with kotlin all the languages we're seeing not just the lambdas But also the things like the folds And and so I think that that this is happening. Um, we're already seeing We're already seeing the the the wave of functional programming adoption And I think that this time the wave is not necessarily going to be driven By the universities. I think that like the last time Java wasn't Adopted because of a wave in the university java was adopted because it solved a deployment problem because when when it was time to Deploy these super sophisticated client server applications that were coming forward It was too much and so we deployed to the browser and the browser actually solved the deployment That's what's happening now. It's the multicore. It's the concurrency. So as we go from 16 and 32 cores forward It's it's too much to balance in a single programmers head and that's that's what's going to drive things and And universities will catch up or they won't right and there will be an alternative I I I agree that universities are losing their immediate impact. I think they still have a Powerful long-term impact, but there's a big movement for independent education in the tech field And I think that's a really healthy thing right now Much to the chagrin of the universities, but They need a good kick so With respect to universities I agree with Aaron's point that you need to focus on concepts rather than giving the students an identity that you're a java programmer or c programmer Just today, uh, I saw a cartoon in Online somewhere that a student is sitting in a state machine Class and he's like, what is this? I just want to write games right So I think what's missing is being able to give them a connection to a real world application that they will actually be using Uh, so with haskell, uh, you ask someone, okay I don't know what functional programming is. I don't know what haskell is. What is it good for? And you say it's a general purpose programming language, right? That doesn't help right? You need to pick Blockchain yeah So you you need to have something grounding, uh, you know the Person that okay, this is what you can use it for and that's when the interest will really come It's not worth getting out of bed. Otherwise I'm staying in bed with it if I don't have a type system. There's no point My attic that's run the wrong way. I'm sorry so so I was I was um privy to Um to a conversation that I really wasn't supposed to be I was kind of fly on the wall When a man named david turner, um, who was the creator of a language called moranda um walked up and Talked to joe armstrong at a party in london And it was the most fascinating conversation that I think that I've ever heard um So it it turns out that david didn't know joe very well and he said Pardon, but I wanted to talk to you to kind of tip my cap to you for the reliability that erlang has been able to achieve I never thought that that would happen from an untyped language, right? And um, so the philosophical discussion that those two men had on two ways to accomplish the same goal And the ways that they thought about those problems was really, um illuminating to me. Um, so I I think I'm going to take the other side of this For me the reason why I work with type systems you you have this very polemic argument of our type systems worth it um, I could not do what I do Without type systems now there are folks who can live in in languages like erlang and and I've written my share um, or in closure Um, and closure works really well as long as all of your problems look like lists and maps Um But like I write a lot of code that Um, I'm not going to get right the first time and I'm going to refactor and tear apart my apis and I have a lot of users And if I'm doing this in a language like python What happens is the only way that I can ever migrate my users is to write an entire new library I get the library wrong the first time But if I ever remove a keyword argument from something in numpy Everybody breaks in production Right if I break an api in haskell I at worst break somebody at compile time I can make fairly large refactorings of Rather important to the haskell ecosystem code bases and the entire community basically adapts within two weeks And I do not have that experience like if we look at the javascript ecosystem One of the problems of the javascript ecosystem is if they have to come up with a new ui framework every six months It's because it's the only way to learn the life lessons from the past ones Okay, and so I can write a library and I can still be maintaining it seven years from now And I can only really do that because I have the type systems breaking people at compile time so I'm going to actually Come down a little bit in the middle on this one Uh in that so I I've done a lot of scheme programming And I actually think I became more typed in apl So I actually my joke is that apl is a great type system that doesn't have to that automatically gives you your terms And the reason I say this is that Um the effect that you get from working with the types the value that you get of working with the types I I feel that I achieve something akin to that not identical but akin In apl and I actually when I wrote my compiler I tried to go full formal on it I tried to actually have a real type system that did something useful on it And so the problem with this is partly I was working in the array domain But the which is a research area in terms of types But the other part of this problem was that when I started writing the types I had the choice of writing useless types that were so obvious they didn't matter Or the types that actually did say something that did matter were literally five to ten times longer than the line of apl I was trying to type and so at that point Yeah, yeah, it's apl. So so I actually I actually think the types have been demonstrated There's like some limited usability research that have demonstrated that types are very useful But the reason they're useful is inside a specific context It helps to address a specific usability problem in a given language So if you change that context to where that usability Disappears in some other way now that type system doesn't become very usable So what you can imagine is that the Haskells continue to do even better And they get more and more stuff expressive in their type system They maybe go full dependent and suddenly the dependent type system becomes expressive enough to Automatically write all your terms for you. Well, you've got a really powerful untyped programming language at that point And then you just don't now you need to build tooling debugging and everything and then at some point somebody's going to say Oh, you know, we should probably type this And then it'll repeat because you're addressing a particular problem using a particular mitigation technique And it's a useful mitigation technique. It works But we should not do that local optimization and sort of worship at the altar of types We should think about what the end experience the usability questions are and find ways of achieving that as efficiently as possible And holistically rather than just trying to invent the best type system Um, I will make a strange point. Remember the times where most of us didn't even exist 70s, for example There was Yeah Yeah There was situation when we had different assemblers for different architectures and Uh Someone invented a c language. We know who did it and In those language you could You could define some integer variables and you could not even borrow how these integer variables will be Placed into the registers. This was a clearly a step ahead The untyped way of how does Assembler do it nowadays. We have a Similar situation, but our registers not about real hardware registers our registers about Processor scores and even human minds to handle complexity we Currently facing Nowadays, uh, we need to define it our programs in such a way that the most of the stuff should be somehow visible to us to not to Get into details of this Because it's a lot of problems It's a lot of code and without clear understanding of what's happening there. We have to go into the Some tool to check this particular part how it behaves how it should be Implemented in a certain way Types help us to not Leave our abstraction level in which we can solve these complex type problems So yeah Yeah, just a bit more seriously about why I use types. Um There exists programming problems that I solve quite regularly where I have not internalized the answer fully. I don't know what it is. I'm going to do But if I can work out the type of what it is I'm going to do and then say to myself If I can get a program with this type, I will have the solution Um, I use types to get me there um Then I also have to consider that I work with other people It's not just myself who have different things internalized like consider for example I know the map function on lists. It's internalized in my head and I don't really need the types But there might be someone else who doesn't have that and therefore we should use types for that as well That's the real reason I use types Just a comment on that. There are also lots of cases where You know a term does what you want, but you have no idea what the type means and you know Those cases also exist in hasco quite regularly So I would say it goes both ways And I've given rants about type classes, right? So The focus there is that they write a significant cross-section of my code. That was the other piece that I So I in fact have an active example of a language which is seriously considering rolling back its type system And the answer is the llvm language, right? So for those of the llvm language So for those of you who don't know like essentially llvm is sort of like a general abstraction over assembly language Um, so that you know different compilers can generate llvm and then llvm can target different processes And and for those of you who use llvm like, I mean, okay, even if you don't So so essentially llvm actually tracks the type of many different pointers and of many different values So within llvm it understands the notion of an integer of 32 bits a floating point number a character array of 32 Like elements and things like that But then like, you know, if you ever read like c code or assembly code that's written by people They don't give a shit, right? Like essentially they so like people who write c you very often typecast between Like yeah, so I mean So within production c code people often like typecast things of the same size, right? Like, you know, the There are lots of tricks that involve like taking a pointer of one type type casting it to another type and doing something to it Or like for example, taking a floating point number sticking it into a union pulling pulling its integer representation out and doing something with it So essentially encoding all of this within llvm's type system Just added a whole bunch of noise into llvm It made analyzing the language harder for no clear benefit anyway because because the thing is like when llvm eventually generates code It doesn't really care about the type. It just cares about the memory widths So within llvm, there's been a serious discussion of essentially scaling back the type system to only, you know, it did Yeah, to essentially only track the sizes of objects in memory and not their semantic types at all So I guess like the moral of the story is a bad type system is worse than no type system at all because like Right. Yeah, because like