 So this is does APL need a type system and really You know snowmen did my job for me. I don't you know, I can't we can leave now We're done. We're good But no actually so a little bit about me first. I'm Aaron Sue. I am a PhD candidate at Indiana University funded through dialogue AP dialogue limited and I in a previous life I spent about eight to nine maybe ten years as a scheme programmer and I was on the R7 RS language small working groups designing the language and working on standardizing it that was I'm a compiler writer by trade I taught the Compilers course at IU for a little bit because I got tricked by Kent did big so when we talk about the lineages Kent did big has this sort of my research lineage if you will and and You know, I also want to thank our previous illustrious speaker for bringing back all the most important things I wish everybody knew about axiomatic semantics linear algebra, you know proof derivation like this is this is I actually also implemented a small axiomatic semantics for task parallelism on top of APL so this was one of my I'm this kind of formal verification is my favorite sort and After scheme I started doing APL and I still if I can't use APL I use scheme for any problem that APL doesn't work for and I haven't written a line of scheme in seven years or so But you know the the the two languages couldn't be more different in some sense So we'll get into that but this talk this talk is specifically about my experiences with APL and This talk is also going to be a high-level talk So APL It's a high-level language. This talk is high level We're not going to teach you how to do APL if you want to learn how to do APL go to the workshop Later at this afternoon and then go to work the workshop tomorrow We're going to get hands-on deep dirty with the APL code and you'll actually learn to play with some stuff here We're not talking about that. We're talking about bigger ideas bigger fish that kind of thing So APL at a high level What are we dealing with there? Well Sorry Get something going so APL at a high level one word to describe it This is this is really about how it seems to most people Similar to the experience a lot of people have when they first see lazy Evaluation in Haskell it's like what's going on you know and so magic is an interesting concept in itself and APL to some people is a light to lighten the Gentiles if you will and to other people It's more of thou shout not commune with the spirits of the dead so But regardless of which side you fall on Everybody will agree that compared to the rest of the computing industry APL is pretty weird Maybe less weird than it used to be but it is still pretty weird and APL is the granddaddy of Functional programming we were we were hacking on live terminal sessions and doing functional programming before it was cool And before we had CRT screens on it, you know, selectric typewriters. So You know, we have a strong history of APL in functional programming But it's entirely different than mainstream and nowadays we have mainstream functional programming and mainstream functional programming is something very different than what we think of the Functional programming and APL to a degree. There's a lot of overlap But nowadays functional programming is almost synonymous with strongly type static programming languages It's not strictly true the scheme guys will Theonately oppose that and say that we're functional programmers too and then you set bank But you know, it's it is what it is But the this has led to this question that I get all the time when people see APL and they go oh cool Can we put a type system on that or do we want a type system or why don't you have a type system? Or I would use APL if only it could provide me with type system stuff. And so again another spoiler Lord I'm gonna tip my hand here. Yes. Yes does APL need a type system. Oh, yeah. Yeah, it would be great It'd be wonderful. I would love it, but You'll be sorry The day that APL gets a usable type system. You will be sorry There will be weeping and gnashing of teeth and somebody will be crucified And why is this because I don't think when people are asking that question of what does APL need a type system They're actually talking about improving APL as a language. I think what they're actually looking for is validation It's a bit of the sunk cost fallacy is they're trying to say well I'm used to thinking about things of the type system types. Good. Why don't we have one and there's a bit of this question I think people there's a social issue going on here as well not just a technical one and Keep in mind that my background in my PhD I also did my minor in my undergrad minor was an accidental mathematics minor So I didn't intend to get it I just accidentally picked all math courses as my electives and they said you should do a minor and I did HCI as my minor in My PhD program. So this should give you some context here as I'm very focused on user experience And design in the learning sciences education that sort of thing so I do think that to get back here the issue a little bit is is how how much we You know want to attach ourselves to things that we think are more common or that we're used to But if APL gets a type system, it's only gonna get weirder It's not gonna look more familiar a good APL type system is just going to be weirder and make the language stranger Than you ever thought it's not going to bring you closer to the language and so Why would we even want to type system we got to ask this question because I think people forget right and so why does anybody You know think about this for a second. You don't have to scream it out right now But let's think about what the answer should be and think about this really. What is your reaction if you said? Why do you need a type system? This is the right answer This is not really a joke This is the right answer in most communities and the truth is that type systems have proven themselves over and over and over again in the community and to the point where there is even some small degree of usability HCI research That's provide preliminary evidence to suggest that type systems provide a real advantage in the languages in which we're seeing them used right, so I'm not anti type system at all This is really the right answer. So flip the question around. Why might we not want a type system? And this goes back to APL being weird Because all of the research all of our experience with type systems are in languages that feel very very very different from APL So it's possible that there's something about APL that makes it unsuitable for a type system And so in order to dig into that a little bit more we need to ask ourselves Why do we want a type system again? What is it about the type system that we're going for and Unfortunately the reality in a lot of the world, especially the research community doing some of the best and most interesting stuff in types is Well, we do types because of types Right and this is not a bad reason. This is a perfectly legitimate reason to do research on a thing because it's fundamentally interesting That's perfectly fine But if we're trying to think about type systems as a thing that we need in a language a thing that's supposed to help us for Some reason we need to get away from just studying types for their own sake This still needs to be done this kind of stuff still needs to be pursued But if we're talking about the pragmatic questions, what's what's the one word answer for why would we might want? What does a type system give us in our language and usually it's some variety of this? Productivity we want productivity somehow and type systems help to improve productivity on some level But to understand this concept of productivity, we have to go deeper into saying what do we mean by a type system? So Let's think about that because type systems themselves the word type the word type system It's actually a pretty broadly interpretable Concept so we need to narrow this down to what do we actually mean when we say does AP I'll need a type system and so type systems generally fall into the class of static analysis things right and Let's think about some things that are static analysis that are not a type system One of the immediate ones that should come to mind are linters Nobody really wants to say that a linter is an adequate type system or that's even really a type system at all But it is a form of static analysis So when we say specifically static type system, what do we mean? What is the actual thing that we're referencing? So in order that so that we can be precise about what we're thinking and I have a few things that I think are important critical Necessary features one is that a static type system is explicit in some form. It has to have a degree of explicit Feature or explicit existence in some fashion. It can't just be an entirely implicit concept in your language Right, it has to form an explicit form On the language itself and it has to constrain the semantics of the language So a static type systems bread and butter is its ability to constrain the semantics of the language And restrict it and if you're in HCI, you know constraints are good You want to constrain yourself because that allows you to explore that space more efficiently If you have no constraints on your design space, you're in serious trouble And furthermore, I'm going to claim that static type systems must involve some degree of syntactic burden Not just semantic constraint Because you can do a lot of semantic constraints and scheme or these other languages But unless you layer on top some sort of syntax to talk about types in your program now It doesn't mean you have to litter every single statement with a type But it does mean that there has to be some things somewhere Syntactically talking about your types if it doesn't have that I'm claiming it's not really what we mean when we say a static type system, right? so What does this give us? What's the value proposition of a static type system and I'm going to sell types as hard as I can right now Right, I'm going to try to convince you to need a type system and I'm going to do that with a trifecta trinity I think types assist us in the past in the present and in the future This is my my sales pitch for types and the way they help us in the past is that type systems provide intent a Form of formal documentation They help us to communicate what the intent of our software was and should be so that when we read our software Hopefully we get a better idea of what we're trying to accomplish and what the point of all this code is Right. This is about documentation. It's about you know And the communicating that intent and it communicates the intent Ideally in a way that is not necessarily communicated as efficiently or it covers for a potential deficiency in the programming language in the present It's about robustness and performance with a broad definition of performance. This could be correctness This could be performance of execution time. This could be the efficiency with which you can refactor your code any of this This falls under this concept of being presently useful so that when you're working directly on the code right now And you need to change something manipulate something that type system forms that structure a framework that helps you to ensure that That code is going to be correct or it helps to make sure that that code that you're changing or manipulating You can understand it a bit better or that you have systems and tooling support that can help you to do that And so this for instance is to help compilers or something like that anything in the future It's code prediction because it is a constraint on your design space So this is where we see things like type directed programming or compiler directed program and when we do this this allows us to Control the process of code creation in a way that helps to guide us towards a solution that we believe will be more likely to be reasonably correct Now a type system can't make the claim to answer your question for you It's not going to give you the solution But what it hopefully does is constrain the potential solution space in a way that helps you to arrive at a satisfactory solution quicker or more robust or something like this Sold right I mean who wouldn't want that I say that's good. Let's do it. This is this is great Like all right type systems. Let's do this thing. So now let's swap over and let's look at APL What's APL's value proposition? Well, it's intent robustness performance and time to solution we've seen this before right I Think a couple of slides ago if anybody's still remembering that This is almost the same thing that I talked about with the type system. So what's going on here and What's going on is we're approaching these problems because intent robustness performance time to solution These are all things we care about But APL is addressing this through it explicitly different design motif And that design motif was coined tool of thought by Ken Iverson the creator of APL And so the idea is we're not really thinking of APL as a programming language per se right the name means a programming language, but the the concept is that it should be a notation that provides us with a way of thinking and That really means that we're very very Solution-oriented in the way we think about problems the way we think about things and so that means in order to really juxtapose or merge type systems APL have to understand not only the Technical context in which we exist the semantics of our language, but we have to also understand the social context In which these languages are used why they benefit the social groups that they work on we need to take a socio-cultural Evaluation of this and that means we need to go into the linguistic context of how we use this language in our community and That really is an HCI problem This is less a technical problem, but we'll get to the technical stuff But more an issue of we need to deal with the experience that we're going for and this is the fatal flaw in this question Because people always assume a lot about what is or is not a thing and they forget the HCI They start thinking about the semantics. Oh, we can do this. We can do this. I can do this in this language I can do that in language So some of you guys are FPers in here and we all know that FP is great And it's also true that you can do fpnc, right? Perfectly possible, right? You can do it. It's I'm a well claim. Yeah, so now that we know that we can do fpnc Why are we using Haskell? Why do we even care about any of these programming languages and most functional programmers should go? Can you do it? But oftentimes they don't know why They can't do fpnc because the arguments for doing fpnc are pretty strong And there's something about that that you don't want and we can take it even further because you can kind of do functional programming in assembly too But what is functional programming? What's the really big thing and we got to put this around too because people say oh Well, I can just do APL with x language and the world is littered With APL in language x failures It's a common common thing for somebody to see APL they go in they try to implement it they fail But oftentimes they won't know why they fail either they and they'll project that failure somewhere Where it maybe doesn't belong and part of my claim is that APL failures occur because it's an attempt to translate something using semantics into another language when what is making APL useful is not just semantics and This is true for functional programming too. We're not just about semantics. This is an HCI problem functional programming languages Solve an HCI problem Not just a semantics problem and we need to make sure that's a focus when we think about these concepts So let's go into these proposed values So let's go into these proposed values intent right an intent is really about readability and who's heard me talk about readability before Yes, last year I talked about it. I ranted on it a little bit I'll give you the brief over here readability is not how comfortable you feel with seeing the source code, right? This is goes back to snowmen's on ramping thing. This is not just about how easy you could on ramp yourself this is about expert level confidence in your code and I measure this by the one a bet concept which is How much are you willing to bet monetarily your risk that a change you're about to make to the code will work? the first time without Referencing any mechanical aid whatsoever because we're thinking about readability here and readability is about how well you can understand What your source code is doing visually and looking at it reading it not necessarily the use of external tools to do it and The type system community tends to leverage abstraction in order to accomplish a enhanced readability on some level No, because if you do the HCI research you find that humans are fundamentally good at ignoring those sort of details And so parentheses are a non issue the parentheses do not usually negatively affect that bet That's not the reason people might be scared to change a piece of list code a little bit a little bit But it depends but it depends so we can go into that in more detail towards the end That's an interesting question if we look at the APL's approach to dealing with readability We solve this problem in a diametrically opposed way, which is directness and The reason we approach it this way is something that somebody pointed out And I think it's universally true naming is hard right and more than just that there's a reason we don't work judicious with our names in natural Language right imagine if every single time you referred to anything you had to give it a proper name That's what we're telling our programmers to do very often This is something that's not easy for humans to do because it vastly increases the dictionary size of our language And that makes it and it can be difficult now types are a type of structural name there are type of summary or Condensation or concision of a broader idea in a form of a structure that Communicates some amount of information that we want that helps to identify that piece of thing that we're working with Maybe it defines a set of things that we're working with like table Is a word that sort of defines a set of possible things, but types are structural names now What happens when we introduce names is we increase the distance Metrics in our code that's both semantic distance in terms of abstractive indirection and that's syntactic distance by the actual introduction of syntactic elements inside of our software and Edward Amsdon Haskell or FR peer user of Idris at one time and Colleague that spent some time at IU with me now. He's professionally how Haskell or he had this to say about it Abstraction means that the code that does what you want isn't where you think it is We can think about this for a second. All right, so now let's take it some names and some APL code Don't worry about understanding the APL code Just ponder the intuition here because each of these lines of APL code is a complete implementation of the idea specified in this name Not a partial implementation a full complete expression of the entire solution down to the metal where we can fully Understand what's going to happen. There are no open questions So we got some of the multiples of 3 and n or at 3 and 5 so here's one question Do we want to count multiples that are both multiples of 3 and 5 twice or just once? That's not answered in that name. It's answered in the APL code Prime numbers from 0 to n. This is three different versions How about connected components on a graph? game of life two different implementations But you know everybody says oh well, so APL is good for computation good for linear algebra good for math But you can't really do your cool recursive tree stuff, right? Well, I mean read my dissertation, but how about we delete nodes inside of a tree by name or? How about we create a binding table for lexical lookup in environments? For our ASTs How about we remove binding chains from inside of that environment nope? This is all real production code. That's in the compiler or otherwise Or maybe we want to check whether a variable matches. It's found binding How about we look up variables inside of our lexical scopes? How about we go through and find our variable and binding references and it collapse reference chains that are too long So if we have a variable referring to a variable referring to a variable referring to a function Let's just make sure all those variables referred the function. There we go All right quiz type the above The easy one is how do you type the characters? That's a keyboard. I am me. It's It comes by default on your Linux machine set xkb map dash Lang of US and APL dash variance comma dialogue dash option GRP colon L switch there you go you can now Type APL symbols with your left alt key as an alt gr key But what if we wanted to actually statically type these using a type system? What did that look like? Think in your heads What would the type signature for something like that be? I? Mean obviously we could go the scheme route and just say array to array That's a type It's an accurate type. Is it useful in any way? No So we need something richer, but what is going to state a useful information about these invariants? The names capture a little bit of what we want the type to say Right a good type system should communicate some of that information Hopefully structurally informally rather than just with names right? Lest we fall down the pitfalls of C++ What are they called? Intentions structure that extra meta layer of names on top of this So the question is Would any type signature that we come up with in a currently understood type system actually be a fundamental improvement? To that line of code Does it really give us a benefit or is it just making our code more complex and just mucking about with readability? so Another way to think about this maybe APL is just a type system We've just eliminated the term level problem, and we're just programming directly in our type system. This sounds insane but There's some evidence to back this up because APL is regularly compute over the things that most people would consider type-level Entities in their other programming languages. Here's a few These are all computable things in our we do arbitrary computation on these objects Normally in a statically type functional programming language. These things are reserved for type-level things type-level objects that very often are highly restricted and how you can use them So this should remind us of something in Lisp we have the you know quippy term code is data Well, maybe an APL we need to introduce the term types or data And of course that leads us back to think about dependent types, and that's very cool research But there's also another thing. This has been understood since the 80s So Lenore Mullin's dissertation of mathematics of arrays provides an axiomatic semantics of arrays using APL as the proof language and the proof system to do reasoning about programs and about problem solutions using a Ray basically rationalized APL and We do this kind of stuff to our types. So TYP is a type of type It's a tag inside of our enumerations and it might also be part of an ADT if you were doing this in another type language and We've just negated a type and we've also added to a type and those have meanings in type systems to some degree But they mean something very different here We're doing some very interesting computation on these because we're changing the actual underlying representative value not just altering and creating a new structural type and So if we look at the types that we might want say in a dependently typed APL language that describes in a meaningfully Interesting way the constraints we care about for these single lines of APL code the types end up being larger So I've got a new type system for Haskell That type system produces types you when you put your type signature on your program It's going to be between three to seven times larger and bigger than the program code that you're typing Is that a good type system for Haskell? Do you want that? So in APL I actually did this I took an axiomatic semantics approach to typing APL using a variety of whore logic and Did essentially a dependently typed APL and wrote the types out and saw what I would have to write Most of the time those types were insanely long Probably between three to five and seven times longer and more complex structurally than the APL line that we were typing and It was not usable So this is also a known problem in the types research community APL typing is research level hard Look at all in shivers work with some other people I'm blanking on the names now, but there there has been some research out They're trying to type APL and achieve good rank polymorphism But the problem is those type systems are a not usable and be not even close to it capable of fully expressing the semantics inside of a current trivial APL system So we're a long ways away from figuring out even what we need to do with those types Much less make them a usable language like Haskell right So let's go to our next question robustness and performance. Well with types essentially We're getting a theorems for free or infinite tests, right? we're sort of Eliminating a whole class of things that the compiler is going to do for us and that's both for correctness and for performance and By refactoring or by providing these things we get nice nice good factor So what we're doing is we're using the type system to provide mechanical Assistance to us to not let us worry about a certain problem, right? And this is a useful thing so Storytime once upon a time Free was feeling down Nobody liked him No one liked to call him But GC came to find him and GC promised to take care of him GC took him to a tower filled with joyful boys and girls and everyone was building happy memories and GC promised free that he could play and share memories too But free didn't notice through all the boys and girls queuing for events That the name of the tower was node.js And for those of you who didn't get that A node.js programmer. I saw where I can I'm sure I can find his quote He said something like it's not a real node.js program without an unmit gated rampant memory leak Just taking your software down that can't be found So tune in next time for the perils of lazy pars paralyzing parallelization So what are we talking about here? And this is a danger in mechanical guarantees if You go too big picture You might be a might lose the ability to reason about the small details and destroy your performance But if you stay too far in the low details You might have usability issues with thinking about problems because you have too many abstractions that you have to build up so what you want is a language that allows you to reason about the little details without worrying about them and see the big picture without getting lost and Making bad architectural decisions So APL is really high level on some sense And it's really high level because oftentimes you need almost no abstraction to solve the problem You're trying to solve it just gets a direct expression in APL. It's almost ultra instinct high level though because Not only do these APL programs Show you know good high level behavior. They're also remarkably mechanically sympathetic and That means that their cost model is directly related to the modern architectures of our machines when you write good APL code They are almost like writing C code for the 70s level CPU architectures Good APL code is data parallel and maps very very well to our SIMD and vector architectures and our memory architectures that are currently extant on Modern CPUs and GPUs. That's why you know my my big research was a data parallel compiler That's designed to self-host on the GPU and it does that without any branching or recursion or if statements or looping or pattern Matching or any of that and that's because APL allows me to express those solutions in a way That's data parallel by construction and maps to those architectures efficiently But I'm not the only one who says stuff like this Martin Thompson. He came and gave a talk last year, right? And he says functional data structures are like sausages the more you see them being made the less well you will see Anybody who's enclosure should know this Functional data types will save the world as we can only get them to work and you know This is another quote. I don't care what data structure use nothing beats an array and People who have to get real stuff done real fast and Have to iterate quickly. This is the kind of thing they say and when it comes to arrays Or matrices or anything like that. Nothing beats APL so One of the reasons is shorter code is easier to debug Arthur Whitney says this But some people consider Arthur Whitney a total kook absolutely crazy genius level in sanity So maybe he doesn't count. Well Our our own Michael snowman said this in the keynote yesterday We've got a lot of very maintainable code there that we just showed not only does it not even need a whole slide I could fit all of that on one slide and it's Maintainable right easy to go and this gets at something really important from an HCI perspective in the human mind The more you can see the more you can know and This is actually almost a proportional relationship or something like that But it's important to understand the limits and so we're not talking about just shrinking our code size a little bit We need to talk about shrinking our code sizes by orders of magnitude because unless you do that you're not going to reap the benefits If you can't shrink your code drastically You're not going to see as nearly as much of a benefit saving 20 lines here 20 lines there out of a hundred or you know 200,000 line program That's not really going to do it But if that hundred thousand line program suddenly became a 1,000 line program now we're talking right and One of the ways that APL does this is that it's very general and that means that the code that we wrote up behind There was rank polymorphic. That was part of the difficulty of typing it, but we're general in a very specific way Right and this generality when we apply it correctly allows us to get faster iteration Really fast iteration on a problem and this allows us to solve problems in what I would call a hyper agile way Because we can iterate on multiple solution spaces very very very fast and one of the things that we can do because of this is oftentimes APLers will have code memorized and Do not underestimate the value of being able to memorize large pieces of non-trivial computations because when the human mind gets to work if that knowledge is externalized it does not become as deep It's not as useful to you But if you can internalize that knowledge into your brain where it can sit around You've got that deep knowledge and now this can affect everything that you're doing and everything that you're thinking And now we can begin to see why we think of APL as a tool of thought and additionally to maximize this We want to optimize for whole program rewrite be willing to delete all of your code or at least design your architecture So that you're not very afraid of losing the whole thing And if you can do this or if you push towards this It's one of the ways the APLers work to remove technical debt Because every time you see something the technical debt is more painful than rewriting the thing So we shift the value proposition And you can see why this maybe conflicts a little bit with what we're other stuff is doing So let's look at compiler analysis Well, if our code is written in the way that good APL is written and I've done some of this stuff that takes research papers to describe For solving problems in these type languages is literally trivial for any practical situation in APL And we didn't need the types to do it And so this can simplify optimization not only with our compilers doing things and thus make our compilers simpler and more Robust and that we can handle higher level problems But human level optimization becomes easier because reasoning about that code is easier and thus We now have something that allows us to make good high-level architectural design decisions and think about macro problems to eliminate You know inefficiencies But this requires being able to break our abstractions This is critical So let's go into code prediction That's type-directed programming or other stuff like that and this is basically a funnel method of doing our work We start with a broad set of possibilities and we funnel it down to what we want and the human mind is not particularly good at this So we use compiler support to do this right and systems tooling support to help us get this Benefit and so it's not really quite human optimize. So what do we look at as the alternative in APL? Here's some APL code. This is APL code that I actually was writing and this APL code is broken It's not typing. It's not even valid APL code and more over it Probably between three to five different potential implementations of this code So this was me trying to solve a problem. So rather than going type-directed. I went undirected Like a giant Tetris puzzle that I pick and choose what isn't going to work until the pieces all just fall together and So what I had here was a bunch of things that are Potentially interrelated and because I could have all of them on the screen all at once it allowed me to see and think about all the potential ramifications of each of the potential solutions But if this were a less a more of a both system I wouldn't be able to visually see how this all fits together and fit the pieces like Lego blocks and This is one of the concepts of suggestivity in APL that Iverson talked about in his paper notation is a tool of thought and That's a fountain approach instead of a funnel approach So where the type-directed Programming gives us a funnel the fountain gives us something called serendipitous transfer and serendipitous transfer allows us to discover serendipitously Applications for prior knowledge that were in domains that seem like they're unrelated. This is cross-domain optimization and this is Possible only because we have short code They share a common foundation and their abstractions are breakable meaning we have transparent implementations and This allows us to empower our existing knowledge and we do so in a way that's visual and maps to the pattern recognition capabilities of the human mind and We can do this because we have concretized domain overlap So what does that mean that means that our domains are not just abstractly related But that we have a concrete way in which they're fundamentally related night Just I had a moment like this the other day while I was working on some stuff I was working out a checkerboard, you know studying a checkerboard problem in this one, you know, this gives us this picture here It's just a little checkerboard, right? But it didn't it didn't feel satisfactory something fell off about it So I was like, okay, we can actually do it like this You get the same thing and the important thing to want think about here is I was studying Let's see if we go back here. I was studying. All right, I'm just gonna try to point here this piece of code here Right and that piece of code gives you this I thought oh This this something in the back of my head was going. Oh, this is This reminds me of something. What does this remind me of I'm on checkerboard mind you I'm thinking about checkerboards trying to solve nothing. Oh, I know what this is This is just like the walking distance between nodes and the paths of an AST Why well because I had studied this problem with on APL orchard and somebody had produced this solution Which has this really visually distinctive piece right here Flip great up great up flip. It's sort of stuck in my mind like that is a really interesting technique That's an idiomatic technique. It's kind of like whoa What was that and then I thought This this this that if we take that and and then if we combine it with this what do we have? Does anybody know I mean because it's obvious, right? We have a proof that the rationals are countable and so how did this happen? well it happened and Notice that this is all trivial. This is the fundamental concept of the proof of the rationals are countable That is the diagonalization proof if anybody wants to study that one right and The reason we did this is because we were able to reuse this code in a serendipitous way and Transfer it around and we jumped across domains because we could see the patterns across those domains those techniques worked across those domains And this is code reuse and where the type system approach achieves code reuse through abstraction Which forms a sort of hiding of information we try to achieve code reuse through transparency and That transparency provides us this ability to do this stuff. So FP what did the FP or say well types help you document your code absolutely true APL or say well just write clearer shorter code and The fp here goes well types help correctness and the APL or go well just write clearer shorter code more often and The fp here is go well types help performance and the APL or goes we'll just rewrite clearer shorter code more often with a mechanically sympathetic language And the fp here goes well types help you write new code more vigorously. This is type-directed programming and The APL or says we'll just rewrite clearer shorter code more often with a mechanically sympathetic language that optimizes Suggestivity to reuse idioms in more places Easy and so of course then the APL or goes but types types man And the APL or goes but APL and so in closing we'd love a new type system I totally want to see a type system for APL. Do you guys have one that's more economical than APL? Thank you, and I don't know if we have any time for questions. Oh, yeah, I Love questions, please go we've also got one over here. So Yeah One question how to explain all this to a college graduate or a fresher I'm sorry. Could you repeat that? How to explain all this to a college graduate or a fresher? How to explain APL to a fresher? Somebody's just passed out from the oh, how do you explain APL to somebody who's new? Yes I do you have prior programming experience? Just like CC plus basic computer science graduate. I'm sorry then that's a real hard problem No, no, so in truth if you don't have any prior programming experience APL is trivial to teach It's very very easy to teach a non programmer or a scientist PhD Physicist any of that easy to teach them APL the moment you come out of a graduate program or even a Associate's degree with the computer science on that plaque you like suddenly become unable to understand APL and This is a really hard problem And it's one that I've been working on because part of my research agenda is the learning sciences aspect of computing and so I'm very interested in how do we teach something like this to other people and This is why for instance last year I gave that talk on design patterns versus anti patterns And that's why the short workshop array oriented functional programming this afternoon is going to cover some of that So one of the things we're going to do is we're going to look at the core tool box that the assumptions that you would make with functional programming just are taken as fundamental Basic tools that you're just used to using and the problem is is that in APL oftentimes? Those are the exception not the rule for doing things and so you have to get used to not using those You have to have something to replace That so you need something to replace your if statement you need something to replace recursion You need something to replace pattern matching or the type constraints or ADTs or any of this You need techniques to say hey, I'm not going to use this I'm going to use something else because the eight the programmers universally struggle because they have this almost unconscious Practice of thinking about problems in a certain search space They have a search algorithm for arriving at a solution and the APL is are sitting way over here And they never find the solution because they're they're going crazy on it but yes, it's a It's a tractable problem. I have a blog post getting started with APL you can go to that It's got a whole bunch of links on what we're doing But I have a I have an approach that I think will work in the future and I'm trying to Get the textbook written specifically for people to overcome some of these humps Yes, and there's a path from FP to Yeah, so The F peers are in a better spot because you will recognize a lot of potential things F peers are in a worse spot because they might recognize a bunch of things, right? So yeah, yeah, so what you have to do is you have to Forget everything and just accept that it's going to be a really steep first apparent curve But once you let yourself do that let yourself Feel the pain a little bit once you hit that suddenly all that FP knowledge will come racing back And you'll be able to use it again But you have to sort of forget it all to start with a little bit and then it'll suddenly all fit back together once you've Learned it again. So the APL is very front heavy in terms of learning, but it's it's not very long Front heavy, right? So it'll go really high and then you'll quickly Get back into it, but you have to be willing to sort of endure that initial mental anguish Sorry. Yes. Yeah as somebody who does evangelism for for prologue Guy, you know all of your talk was like. Oh, yes. Yes. Yes. This is this is exactly the pain points. I'm having and That leads me to the question. Maybe we're both playing in a space that is larger some space of languages that are not That are not the Paradigms were used to I'm using paradigm and So Are we in? Yes, yes, but actually not having the same problem, but but actually this is across the board, right? Everybody has this problem just to one degree or another. It's about distance and Paradigms, but it's also everybody's trying to solve the same problems that we're having with programming We're just doing it in very different ways and the more different you do it the harder it can be for the mainstream community to adapt to that and see it and Prologue is one of those right and you know on the technical details APL and prologue are very very different but in terms of usability from previous programming experience, they suffer from some of the same difficulties because Prologue has such a different model mental model and way to engage with software compared to Your mainstream code and so this this issue is going to creep up in both of them. Yes Well, yeah, so I wonder if like I wonder if we're only playing on the corner of The computing space yet. Oh, and I happen to be people who've kind of like found little holes in some much larger space Well, the problem is nobody is willing to do HCI research on programming languages And we need to do that in order to better understand where those holes are because right now most people program and design languages through guesswork and Voodoo, we're like it makes the Chinese medicine look really really sophisticated And I would agree I I think most kind of we're barbarian alchemists And and most research into the practice of software engineering does tend to resemble like education research Yeah, yeah, so any other questions thoughts comments? Oh, we got one over there I was just about to add that, you know, we need to break for lunch, but it's amazing to see no one's leaving Well, I'm happy to stick around and answer more questions, but I don't if anybody does want to leave for lunch. Feel free So my doubt was like are there any tools out there or any research being done from a from a HCI point of view Which can kind of translate some APL code into maybe like English, for example, okay. Yeah, that's a common question I feel is like yeah in terms of design affordance. Yeah, say there's a light switch which is like an on and an off Yeah, so immediately we can like with respect to the physical interface I can feel that only there is some constraint available and that that's what happens in a normal programming language because we use English language Like for Luke or something like that. So maybe that's that's the initial, you know barrier for understanding like if I see some Japanese Symbols on the screen like my mind simply goes off Like is there any research being done in No, like even I can show some Kannada language for you like again your mind will not even try to understand that So if we can kind of build some tools which will say like so, how does this light switch work? So again, that's the design. Well, no, so this is a very common light switch in the US people understand how to use it Yeah But if you come from another place like for instance, I spent about 15 minutes figuring out what these things with the glowing light on it We're in a hotel So this is so the problem Yeah, so this is a common thing that people come up with is they say well Well, can't you bring it to something that is easier for me to see? Yeah, and the problem is It doesn't work because the you're assuming that your problem is the symbols and that's not the problem, right? Everybody wants to latch on to why am I having trouble and they look for what appears to be the easiest Explanation for why they're having the problem and the truth is in the studies I've practiced and when I teach this and I track the record and things like that the symbols are a red herring and they're not They're actually Significantly more efficient to communicate the idea is not only to experts, but to beginners The problem is that you begin to shut down and when you shut your mind down and you don't think about it anymore you miss learning the thing that's actually Causing you to break down and so what you have to do is you have to remember that and Don't be afraid of the symbols right because the symbols are not what's going to be difficult. I could write that stuff up using any Ideography or or Idiographs that I wanted up there and you still wouldn't have a clue what's going on In fact, if I translated that into three letter Haskell points free programming style You still would have no idea what's going on Right because and in fact you'd have a harder time figuring out what's going on because that Haskell line might span 150 you know thing or might be take two or three lines and then the patterns disappear You have no anchor points visually for you to begin to see the patterns and so The it's like mathematical notation, right? there's a reason we use symbols in math and we don't write everything out with English and There's a reason we teach people to learn those symbols rather than expecting everybody to just derive algebraic proofs by using scheme code, right and it's Not going to help you particularly much to learn one set of symbology and then try to switch that symbology It's equally difficult just start with the symbols and just go step by step and work through it And it'll be much easier for you It's it's a it's a fear that people have that isn't actually justified by the research Yeah, I second that like I've attended the workshop a few years ago the first Half an hour you're like sitting in the workshop and you're like you're never going to make any sense out of this Right by afternoon you actually you start typing and you're like oh did I do it or it just happened? Right like it actually hits you that you no longer thinking about the symbols They just happen like half a day, right and by end of the day You start thinking about the patterns and you start thinking oh This is a very different way that I'm just not used to solving and you have that aha moment You know like towards the end of the day I kind of second you that you know replacing it with something else trying to do the same in another language It's just not well and the sim the experience is extremely similar between these two lights This is demonstrably Objectively a simpler light switch, but I didn't know how to use it I was lost about it and I was searching for the solution in a totally different space I thought this was a reset measure for telling whether we blown a circuit inside of the system So it didn't even occur to me that this was a button But I know how to use these no problem, but this is demonstrably objectively more complex and harder to use and It's just that I've been trained on one versus the other And so I was searching for something along that line and when I encountered this my search space just won't Died I had nothing to work on Right It's the same thing with your programming languages All right We should wrap up if you guys are more interested this one more in the afternoon and then tomorrow if you want to attend There's a full-day workshop as well. So you can participate in that. Yes, they'll get progressively more detailed All right. Thanks. Thank you very much