Tooling Talks Episode 3 - Justin Kaeser

[Music] so today i'm very excited to introduce my guest justin justin i will not give a huge introduction but i will actually just let you introduce yourself so go ahead and thank you so much for for joining me and uh yeah go ahead and introduce yourself hi uh yeah i'm justin justin caser i work at jetbrains on the scala plugin for intellij um i don't know what to put in these introductions whatever you want to put in him no how about you just give a little back story of actually i'll give you a few different questions that you can answer right away so maybe a little bit of backstory about how you got into programming uh what got you first interested in tooling central primarily be talking about tooling and then maybe how you got started with jetbrains right okay extra in tooling so basically whenever i started working on a project that accompany uh it turned out the way things were running wasn't quite as smooth as i'd like so i i'd get kind of fed up with that and uh start trying to fix it so like a previous company i was working um yeah i was starting to work with scala it was 2012 or so so the scala tooling ecosystem wasn't very developed yet um and like everything was just kind of causing blockages uh like from the ide we were at first using eclipse and the build tools like there was spt 2.9 or so if anybody remembers that um the ci servers like at first we didn't have one then we tried jenkins i i wasn't really happy with that so while the company as a whole was more working on semantic analysis of news bits and trying to generate some knowledge graph out of that and support traders uh the actual building the actual parts uh yeah there was a major challenge in keeping things running uh redeploying and so on and so i i basically just picked up the slack and started implementing like code style checkers uh ci tooling look for a proper ci server uh and like we were just a relatively small startup like maybe 30 people but we had an interesting code base like today big companies like mono repos but back then uh we basically we had yeah dozens of small projects that you could describe as some proto micro services but they had to work together with different in in the correct versions and be deployed together with correct versions so that was yeah that was challenging from the tooling side and i just i just started to work with that okay trying to get things working a bit smoother okay so i'll take a step back then before that how did you get interested in programming did you always like programming did you go to school for programming what was like sort of like your first step into that world well for one my father is a programmer so i was exposed to it kind of at an early age but i didn't really get into it before university okay uh like i was a i was a bit aimless in my young years and one day a friend called and she said hey justin uh let's study computer science and i was like okay um and the rest was and it turned out i kind of liked it and wasn't horribly bad at it so okay okay also i'll take one like second and i forgot to mention this when i did an introduction but if people do have questions at all during the the interview don't hesitate to just drop them in the chat and i have like a little bot thing that we'll be watching for them and we'll capture them so if you do have questions don't hesitate and then we'll potentially get to them if we have time um but to jump back to what you were saying um so yeah so you were doing programming that's how you got started you started at your first company which then got you interested in tooling a little bit so then where does jetbrains fit into the picture like how did you start at jetbrains and your work with intellij so that's actually connected to that first company okay so yeah i was looking for good tooling uh namely a ci tool uh jenkins was really not cutting it for us because we had like this massive collection of repositories that we had to work with and jenkins didn't allow at the time at least any automatic way of configuring these projects in a consistent way you had to copy paste and every time you changed something you had to copy paste again and and uh things would be immediately out of sync so i looked for a better build tool i found uh teamcity okay and jetbrains yeah which also happened to have uh some basic scholar support uh basic sbt support um and i had a question about the sbt support so i just commented on the blog post that introduced it and the developer who wrote the blog posts got in touch with me okay and we exchanged some emails and uh she noticed uh oh we're working on the same street literally oh wow okay yeah our office is on the same street so so we just decided to get together and have some chats nice which we did once in a while okay now fast forward like two years or so uh like the startup has kind of gone dead i had switched to another company but i wasn't really happy there so i just got in touch with her and asked her if there's some opportunities at jetbrains and as it happens there were like someone who was working on the spt support had just recently left so i just filled that space okay and you've been working on it pretty much ever since right pretty much yeah okay like it's it's a very yeah okay so normally i ask people this question right away in the beginning and i joked about it with you earlier a little bit but yeah what is like your personal preference in tooling like normally i always ask what editor do you use and why so just for for sake of continuation i'll ask you the same question justin what editor do you use and why clearly vs code so that i know what the the uh the opposition is up to opposition you can't you can't pit us against each other like that what's the english word rivalry i don't know if no i'm kidding the alternative it's just an alternative that's what i like to say yeah yeah what alternatives there are but usually i only use that for like quick editing tasks um when i want to just open some other folders somewhere yeah but uh yeah day to day obviously i do dog fooding we're big at that we're digging into dog fooding at jetbrains okay and what is it about intellij that uh really drew you to it as an as both an editor and an ide i guess well at the previous company at the startup at first i was using eclipse and we were having pretty serious problems with that in scala because uh like completions would sometimes take 20 seconds and it'll crash or not show highlights i don't even remember what the problems were but it was not fun to use i tried intellij once uh like highlighting wasn't working so well so left it for a while but then i returned to it half a year later or so and things have gotten much better was usable with spt yeah you're still there yeah i'm still here i just noticed i was lagging a bit so i cut my video to you yeah sorry so so i i just had started using intellij is the default editor but obviously there were still uh problems with it okay um well but by the time i got to jetbrains which was like 2016 july 2016. things were already a lot better but yeah as you may remember the spt support was working but still also had its issues so uh yeah as always with tooling i'm not entirely happy with it so i uh start working on things that i'm not so happy with and try to improve a little bit was there anything from like your early eclipse using days that you missed now that you're on intellij like was there anything that that you felt like eclipse did a really good job at uh did i now miss no not anymore okay was there one thing that like they set the bar for that and i when i initially switched i missed some things like uh yeah like initially the highlighting still wasn't sufficiently good uh it would not show errors all over your project so so you'd only see like the local errors or something but i think uh that's mostly all taking care of some time ago already okay so i want to ask you a whole bunch of questions about about intellij but i i feel like before i can really do that i also need to talk about some of the other projects you're involved in one of them being the build server protocol which we also use on metals and there's also other tooling that uses it so for those that are maybe unaware can you give like a little introduction to what the build server protocol is okay so um basically the build server protocol just gives you a standard protocol to connect uh build tools such as svt or mill or maven or whatever with a ide or front end or a language server such as metals and the motivation for me to get into this was that yeah i had already worked on sbt some two years or so yeah uh and there were some efforts to support other build tools uh initially like we had an intern working on cbt if anybody remembers that chris's build tool exactly yeah the conflict spill tool compared to the simple build tool yeah carry on right uh but yeah so we got some basic integration working but like immediately issues started popping up and i figured okay uh if i have spt if i'm already i'm still working on spt every once in a while there's something that needs fixed uh the most i could do would be support one other build tool uh and it probably wouldn't be some fledgling build tools such as dvt because like yeah we have teams supporting like gradle or maven specifically in intellij so the scala support for that basically just piggybacks off of that but uh as you may remember in scala we're never quite happy with our build tools so somebody comes up with a new one every year or so maybe that has cooled down a bit but that's it that's a good question that's innovation there yeah that's a i actually have a question about that too about about bill toying another question i typically ask people is like what is your favorite scholar build tool and like why is that like i i'm i know that you work primarily on the sbt integration for intellij but like is spt like your your preferred scholar build tool and if so like is it the one you recommend to people and if so why um yeah it's my preferred tool for one because i'm just used to it yeah i've worked with it a lot i'm most familiar with it yeah so i and and like it's improved quite a bit in usability yeah so i don't really have a reason to go to another build tool but as i understand people are pretty happy with mill um and there are some applications where basil or pants are better fit yeah but like for my personal situation that's sbt is just fine you mentioned that for a while it seemed like there was so many build tools coming out for scala or new build tools but that's maybe slowed down a little bit like it is something super interesting to me because there does seem to be a somewhat dissatisfaction with build tools in scala and that's not a jab whatsoever any of the current build tools or like the work that has gone into them just for whatever reason people are unhappy with it so then the question is sort of like is there space for another build tool ever in scala do you think and yeah sure yeah and it's tricky too because you it's funny whenever you see talks of another build tool you see people complain like oh not another build tool like are you serious uh but at the same time there's sort of like this dissatisfaction with build tools which which is interesting to me like yeah yeah yeah i think uh build tooling is very interesting so it's a not entirely solved problem uh that's why probably people are always dissatisfied yeah uh like maybe there's also this expectation that i really just want to compile my code and work on my code and not code how to build the code right yeah um so one thing many people try is making a build tool that is configuration only and in my opinion that's kind of doomed because you will always need some kind of specialty configuration like coded configuration on in any more complex project [Music] uh so you end up either writing build tool plugins or you that you then configure or you configure your builds directly by programming special procedures or you end up writing [Music] uh like some hecky record wrapper scripts around your build to invoke your build with different parameters so then you have basically two build tools you have like bash plus whatever configuration the tool command or so you have or that's what i was going to ask if you can like what do you consider a configuration only bill to like maven i'm assuming because you said maven now but was there another one for scala that you can think of and i don't know if you're familiar with seed or not like that was yeah sort of had that approach yeah like just a tomophile i think fury tried that kind of but also was programmable um yeah but like i don't think any particular tool has become prevalent in scala that is not programmable okay so yeah so bsp in some ways is aimed to to solve in some ways that matrix problem right where you don't have to re-implement in different editors and uh different build tools that they can share the work right and uh if i if i remember the website correctly the first ones to do that were bloop on the bsp side right and then on the editor side uh what was it what was the first editor that did it actually intelligent intelligent okay so yeah um now that there's more like is this sort of what you were hoping for and what you were expecting to see like more and more adoption because i i believe there's also some other languages that are potentially looking into using it as well if i understood some of the things left like what's the future of bsp yeah so right now basically every scala build tool that is in use sort of supports bsp and uh you're able to fairly quickly implement some basic esp support if you're like developing a new build tool and then get some basic ide support out of the box yeah uh yeah what i'm looking into right now yeah is expanding uh the language support and the build tool support so i've had like so i haven't myself worked directly on them but i've worked with a bunch of interns who did most of the heavy lifting there like the no bsp support was initially contributed by one of my interns alexandre dima and over the last year the bazel esp support has been worked on by several interns we get the names together there was andre hosha if i got those names right most of them polish we worked on that too uh as part of their bachelor's thesis so they they got the bazel support working to a high degree with support for not just gala but also some degree java and kotlin yeah and i think that's a great advance for bazel support in intellij as such because that's always been plagued by the official bazel plug-in kind of being a version or two behind the intellij version yeah and also as i gather it doesn't really support the mapping uh bazel project properly to the intellij uh project structure yeah and so that's mostly solved i think and i think we support some of the major features now that are necessary for larger projects yeah okay yeah so like some of the things that popped in my head that i'd love to pick your brain a little bit on is is maybe some of the differences between uh how different editors are using bsp because for example like mill is interesting to me because they they have their own bsp implementation as well that intellij can use right and i believe it works quite quite well but i know on the metal side we actually don't officially like support the the mill bsp implementation because there are like some things that don't quite work for it on the on the metal side and i'm and the reason that's a little bit interesting to me is because i feel like intellij also sometimes will do things a little bit differently than metals does like and i'd love to like chat a little bit about some of those differences and one of them that comes up right away that i think a lot of people will ask about is the presentation compiler because like metals for example we use the scala presentation compiler intellij if i if i understand it correctly it uses its own like internal representation of the presentation compiler correct not quite correct okay correct me educate me so this is not really the area i work in the okay the overview like so intellij internally doesn't compile at all what we have we have a representation of the program structure okay ast if you will but more rich than a just a compiled ast it's called psi program structure interface and that represents not only uh the raw ast but like editor positions and uh there's types in there and so we do have our own type checker that runs on top of that okay right uh and so yeah if you're asking about why we get like false positive error messages there are some uh mismatches in the rip in our own presentation what the scala compiler does yeah uh for probably various reasons yeah maybe sometimes we don't completely follow the same like as the skull compiler uh sometimes because it's maybe a bit underspecified or maybe sometimes yeah probably sometimes often it's just a bug yeah i i think i saw a tweet from from you uh sometime in the last like week even where you mentioned that the next version of intellij you'll actually have the option to use the official presentation compiler did i see that right not the presentation compiler but uh yeah so the next release is coming up next week about okay that's 20 21 2 okay uh and yeah one of the features we added is being able to use the regular compiler for highlighting your code so this is similar to what uh metals does with esp yeah actually we have two ways of doing it so we have our own compile server historically which we use to compile code uh and that one's if if you enable this switch on a regular project that is not bsp then it will use the built-in presentation not presentation quite a regular compiler sorry and i've stuck that in your head that i said presentation compiler to yeah to to get the uh compiler messages errors and warnings and then just highlight them there in the code okay so yeah if you have problems in your project with false positive highlighting then you probably want to enable this option uh the other way is doing it with over bsp so in that case we just outsource the compiling to the bsp server but the result is the same so the result from the bsp server gets put into the editor used for editor highlighting is there a future with intellij where bsp will be uh the default because right now you get like the choice right so like um how come there is that choice and why for example isn't bsp just the default uh for historical reasons oh wow thunderstorms yeah we've been having thunderstorms like almost every day here for the past weeks month i don't know 2021 is pretty apocalyptic yes all around right um so yeah so currently we have the regular spt support yeah and support for other build tools specific build tools on the one hand and we have the support over for importing them over bsp if they support bsp yeah so one reason is of course backward compatibility uh not every version of spt supports bsp that's fairly recent and also doesn't support it to the same degree and if we did it over via bloop like metals does which which we do support but you do lose some spt metadata in the process and uh sometimes the interaction isn't quite as smooth yeah you lose access to the entire task graph if you do it that way right yeah and the to the built-in spt shell and so so there's some people for whom this is a fine trade-off but like it's not ready to support his default at this point okay um but i do want to work on like polishing the bsp support so that it can be used as a default for many build tools especially for spt yeah um and yeah it does require some more work on some odds and ends and we'll still probably need to support the other options for backward compatibility because like many people rely on that we we're not quite as greenfield as metals was at least yeah if it's not anymore uh we haven't hit 1.0 yet so i guess we're still still beta maybe right uh so yeah yeah we do have a lot more uh compatibility maintenance load sure i think yeah plus you have like or i was gonna say plus you have a plug-in architecture to think about too right so like there's more compatibility issues you have to care about where with metals we don't have any of that so we can kind of just change whatever we want to whenever we want more or less right um but yeah so mid-term i would like to get to the point where bsp can be the default protocol for communicating with build tools and like the import would be more or less transparent to the user let's say if you have sbt version one point something then it will use bsp by default and yeah otherwise use the old way and and maybe somewhere hidden away you have an option to use one or the other there's always somebody who needs that that brings up a good question or like a good point too that i often think about about oh wow that's really storming by you about like how much of this stuff should actually just be abstracted away and be seen almost as an implementation detail because i know for us at least on the metal side we get so many questions about for example like well what what is bsp like do i like we have the like be like a bsp switch command for example to switch from bloop to sbt if you want and sometimes that's confusing and it's confusing which one you're currently using or what's the benefits of using one over the other one and yeah like sometimes i personally wish that like i i don't even want you to know about it i just want it to work and i want you to like yeah do you do you feel that a little bit sometimes that those things are sort of subtracted away like uh yeah of course people get confused all the time about what does what like uh presentation compiler like people keep asking us why don't you just use the presentation compiler uh yeah we have this whole architecture in the back end that we rely on for all our other features pretty much that you can't just switch out by switching the compiler yeah of course uh yeah and of course i get that with sbt and with sp and so on there will always be some edge cases or some someone poking around and then or somebody who just runs into some problem that is specific to their configuration and so on yeah yeah for sure if do you feel like there are some really untapped areas of bsp yet that you just haven't had time to work on or that that yeah maybe just have yeah you haven't had time yet like what are the untapped areas of bsp uh so obviously i want to work on a tighter sbt integration so that that's really mostly transparent and fluent to the user and i want to integrate it more tightly with intellij i have a dedicated esp plugin for instance okay so that intellij even when you're not using the scala plugin is able to import bsp projects more seamlessly automatically okay so so that it expands this go but so those are like primarily on the integration side what about the protocol side is there any like part of the protocol that you feel like you'd want to further develop or is like the protocol at this point solid and sort of where'd it where it's going to be like there's no major thing i want to add at this point yeah uh but we always run into some something that would be nicer to have differently or to expand so like obviously language support but that's like a language by language thing uh if we want to support a specific language we might have to transmit some bits of metadata but those are protocol-wise or fairly minor additions they're they're they're largely a matter of integration like or build tools and uh clients to support them yeah yeah that's where the most of the work actually lies okay the um like i know you mentioned that you primarily work on the spt integration have you worked at all and and the other build tool integrations with intellij or is it really only been like the spt part that you focus on if focused pretty much on spt and no bsp okay so i i did some supporting work to have bsps supported in some build tools nice though as i mentioned though that has been largely done by interns i've worked with yeah it's the reason i ask is i find it interesting that like uh somebody who works in tooling like yourself you're you you use build tools for your own projects but a lot of the interaction you have with build tools is actually programmatically almost because you're building tooling around it in some ways so i was curious like if there were any examples you maybe had of some type of build tool or tooling that has like a really nice api or that you really enjoy working with or like yeah like what what's something when i mentioned that that comes to your mind if anything that you're like oh i love this uh nothing directly so the only bill tool i have some experience with in the guts really is sbt and well that that was kind of hard to get into and i wouldn't say i'm i have a deep understanding of it but uh that that's the only one i have some deeper understanding of really otherwise i i've only really scratched the surface okay one thing that like intellij i feel like is really well known for and to be honest it's even something on the metal side that when people ask about it we sort of just point them to intellij instead is that you guys have like such a good uh scala java interrupt where like if you have mixed projects everything just works uh how how is that done can you like walk through a little bit of of how that works like how you can like is there some type of uh like you mentioned an ast representation in the back end like is that like a jvm representation that can be shared between scala and java or like how does that work yeah so so so that's basically the magic behind it uh and and that's what enabled intellij a longer time ago to support many more languages effectively than eclipse did at the time this program structure interface so it is a shared interface for program structure and then on top of that you have like language specific implementations yeah but you have a lot of shared structure between scala and java so that enables it to pretty much seamlessly jump between scala and java definitions or use them okay and like just access them from your code and completions and whatever okay okay so i'm i'm curious too so like well i'll try to shift gears a little bit because i'm curious to like a lot of the stuff we're talking about is you know the current tooling in scala and one thing that really interests me is sort of like the future of tooligan scala as well and maybe you too but you you said something in an interview that really stuck out to me uh i like was looking back like literally just googled you and was watching a bunch of your stuff but one of the one of the interviews you did in 2019 at scala on the bay uh you mentioned mathematica and you speak about it and its notebook experience like really positively and then ask why in scala are we so far behind this because mathematica was you know so many years in the past like do you still feel that or do you feel like scala tooling in the last couple years has improved or like yeah i haven't used scala notebooks much recently because of because uh the the way they are that what they are supporting is yeah mostly maybe prototyping data science and such yeah uh i found but like i had a quick look at it and it looks pretty nice but from what i gather what you're really missing is the integration for with a full development environment getting the full level of code assistance you get from an ide and the exploration and documentation and so on so one thing that really impressed me about the mathematica notebook interface was how the documentation for the whole mathematica api you could call it uh is implemented in the notebook interface itself so you can look up any function and you get a nice overview of first of all what the function does in the abstract then you get some nice practical examples uh that you can run and manipulate right there in the notebook in the documentation so it's better than just type check documentation it's like actually runnable documentation and that's something i'd really like to see for any mainstream language but especially for scala obviously yeah do you feel like mdoc comes close to that because i know you mentioned like type tech documentation or typed markdown i guess yeah i mean type check documentation is good to keep your documentation up to date with the actual code that that's a big improvement over what we have in most language ecosystems yeah but it's still so far away from actual runnable manipulable documentation what do you mean by manipulatible documentation that's an interesting phrase for me uh so so yeah in the in the mathematica documentation you look up a function you get some description and uh some examples and you can actually manipulate those examples right there in the in the notebook so thomas like your scala docs like you can manipulate your scala docs almost is that would that be like the closest thing i guess yeah uh but you like you can you have the input and the output right there on the same screen okay you can mess around with the inputs and see how the output changes so you can really explore what a function does right in context and of course in mathematica uh it has a lot of visualization functions uh with a lot of options so so it gets it's really [Music] interactive really visual but you can it really makes it uh palpable what you can do with it yeah yeah okay and mathematica had this i don't know 20 years ago yeah that's crazy to think about yeah we're only really getting close to it now in mainstream programming languages so what what do you think is like an area of scala tooling that if it was just like magically better scala would be way better uh yeah i mean obviously notebooks could be further improved okay one vague idea other vague idea i've had would be the editing experience so like we're still kind of manually formatting files and dealing with white spaces and so on okay what i have in mind would be something that makes the manual formatting or the like the formatting plugins such such as what was it called uh the scala formatting plugin yes scala formatting like format yeah scala format or the formatting built in intellij whatever yeah that kind of obviates that because like i think that there's your program has a structure uh and your editor should be able to render this the structure the way you like it like like like the way that i like it and the way that you like it that you like it you have to have to agree on a common code style because really our editor should be able to format this the way we like it interesting okay that could be that could be doable right like even with tooling now like if you would have some type of if you have your own for example let's use scala format as an example if you would have your own scala formatting file and i have my own and we have a shared one that's checked in to get that would you have a format something as simple as that even on that level yeah i think it's doable and we could also make better use of like rich text uh so like for latte there's some tools that kind of do this uh like licks uh that gives you a wheezy whim what you see is what you mean interface so you don't get the word style wheezy wig that it shows you on the screen exactly what you'll get but you'll see the structure in nice formatting that's easy to read and work with uh so we we could have something like this for programming in principle interesting okay all right yeah there's i i found myself recently really thinking about like what's what's next for for scala like what's the next uh not evolution maybe that's like a like a cheeky term a little bit but yeah like uh what's the next evolution in in tooling for for scala and like what is that next next step the next thing all right yeah right and on on exactly this would be like just a base for what more you can do with it like structural editing so you know we actually have a tool that jet prints that allows this but it's kind of more for especially tooling uh called uh um um wait i'm forgetting names here mps yeah meta programming system uh so instead of just manipulating text you could be manipulating the ast directly okay and the editor could be giving you much smarter suggestions based on what actual through the ast at this point and disallow or let's say strongly discourage entering things that are not legal at this point in the ast and then you could be just checking in actual ast so part of this you actually uh originally paul chizano worked on the editor side of this when he started working on unison but i think they sent shifted more to getting the back end to work right yeah but so you're familiar with unison well i was going to bring up something about unison in a second so it's funny you you brought this up so i can i'll wait for you to finish but yeah there's there's actually a point that i wanted to bring up about unison 2. yeah so one of the innovations relatively innovations in unison is that you actually check in uh an ast into your code base and when you check it out it just transforms this into a code that you can edit in your favorite editor but in principle this favorite editor could work directly the ast as well yeah i was going to bring up that and i apologize if this is wrong because i really don't know much about unison but i remember reading about this and it really struck me as something that was very interesting was the idea of uh where you put your your code because i like i'm not a very like i'm the worst person when it comes to like how do we architect this large application to make sure we have the correct packages here or there and where you put stuff and to be honest like i just don't care that much i just like create a directory and i want to throw all my files in there and i want to go to them when i want to go to them and see them but i don't really want to care about like the overall structure of stuff and if i and if i understood what i read with unison that it's much more of you just write your code and it stores your code and you don't necessarily have to worry about where you're putting your files and all this jazz and that that concept i really like yeah in a way so the idea is that your code is content addressed so code when you check in an a piece of code a function or something you will check in the ast and that generates a unique hash and when you refer to this function you refer to this unique hash rather than referring to some name yeah and that of course allows other interesting applications like distributing this code over a network or something and also having a code base that isn't text based and managed by git but instead uh yeah is basically a big hash map of code yeah functions of individual functions of and you could use any version of any function at any given time of course then you need uh special ways of updating usages of functions but i think they they've worked that part out already so i'm not actively following unison but it's a project i ideologically strongly support i think in the future i'll need to talk to somebody from unison maybe so if anybody if if anybody has a recommendation on somebody that would be like really good to talk to you about yeah talk to roona or paul okay yeah i'll have to reach out to them because that would be a fun conversation uh so like again shifting gears a little bit because i also want to to talk a little bit about um like you're pretty active in open source like i've interacted with before online i always have really positive experiences and there was something that actually stood out to me that i like made sure i wanted to ask about because it was like very different than you normally see all the time and your your github profile says in favor of niceness and uh it was simple and i really liked that and i wanted you to maybe expand on why you felt that that was important enough to include in your profile uh actually says in favor of niceness community and civilization okay i butchered i took part of it so all of it sorry yeah which uh refers to an old uh slate star codex post okay which some people these days might even find controversial but i i really liked the main point of that post so it kind of argues for improved discourse norms where like you can disagree with ideological opponents on some things while still being civil uh working with them uh even friendly with them in other contexts rather than uh basically then turning them into a evil out group that you must be destroyed with words or other means and another point of the post is that it emphasizes like intellectually honest discourse so if you want to be part of a group and work together with people not every rhetorical weapon will be permissible like if you think the other group is uh killing people through their ideology uh it's still not a good idea to actually make up things about them like uh that they eat babies or something okay rather uh yeah okay yeah so i didn't know the phone that's the basic idea okay yeah well thanks for explaining i didn't i didn't know where the the quote came from kind of kind of related to that and i guess in the in the thread of i guess just being a welcoming environment in general like one question that i always like try to ask the people that i talk to is what do you think we can do to make tooling a more diverse and welcoming environment for those that are underrepresented in this space yeah that's tough uh so i i don't really know you know all right i think we should not uh yeah make things up about people and just because we disagree with them or dislike them for some reason okay but like if you're talking about like uh so so being welcoming is one thing but uh actually attracting more of a more diverse crowd yeah as we all know tooling is dominated by a male demographic not necessarily white but definitely male um i would definitely i think i'd still say it's a bunch of white males but yeah go ahead well we do know several non-white people who are contributing but yeah most of them are white sure um i think that well for one one reason for that might be that where tooling generally draws from uh the same pool of people that open source generally does which is exactly this demographic sure um i've noticed like within jetbrains for instance uh like our all female ratio is obviously as good as anywhere in the industry but not as much as in the public facing tooling so like i think in turn where about is skewed as the industry average okay so uh maybe and like some of our committers are women so cool so yeah the question is why do we see only certain entire public key publicly yeah contributing to tooling yeah that's a that's a good point as well like why why are they why is it the same types of individuals that are maybe more publicly visible kind of like related to that in general is you know when i first started getting involved in tooling i found it to be honest like a little bit difficult not because people weren't helpful like i actually found like some of the most helpful people in tooling but just because a lot of the concepts are like way less covered and there's you don't find like i mean you start with a library you get a bunch of intro articles and there's tons of stuff about it where you start getting involved in certain parts of tooling and you don't necessarily find those same things so like how can we just in general make contributing to tooling easier for anybody big question go i think you mentioned the main pain points already right like it's hard to find an in point in the first place i think one thing that's really hard is uh tooling interacts with a lot of end points in different organizations so i noticed in my work here on the scala plug-in i've often worked with people from many different organizations as much as i've worked with people within my say within my own team [Music] and a lot of the tooling addresses very specific problems that specific people or organizations are having uh so i think a lot of the uh reasoning for why things are the way they are are hidden away in like maybe some github discussions or some or even more privately at some discussion somebody had a at a conference with somebody else yeah uh people aren't maybe really motivated to document every little bit because there's only a small amount of people who will ever be working on a specific tool yeah of course like uh the scala plug-in is maybe one of the largest single tooling teams in the scala ecosystem we have like uh 10 people give or take okay carrying a little the scala compiler team i don't know how many people are there i think less than 10. yeah yeah i i i don't know of another tool i guess that has 10 consistent people that are all working on it at the same time yeah so so within the team we just usually often share knowledge on demand yeah uh except for some very basic documentation okay and like writing documentation is hard right it's yeah it takes a lot of work it's not always fun yeah it's arguably just as hard to write good documentation than it is to write like good code if not harder at times yeah yeah sure okay so i think i have pretty much like one more softball question for you but um if you could take the next six months of time off and just work on whatever you want what would you what would you work on how about six years so sure six years special questions six take the next six years and work on whatever you want to the first approximation i'm already working on what i think is most valuable but most of the time that's uh maintenance and polish of stuff keeping stuff working keeping things up to date but let's say i didn't have that uh didn't need to do that uh just start fresh somewhere i i really would like to address the notebook question okay and actually i i'm working with an intern right now who will start having a look into that here uh shameless plug we have a our own notebook tool that we're developing at jetbrains called datalore which is focused on data science notebooks and so far it supports mostly python and kotlin notebooks we're looking into supporting scala notebooks as well but that's still mostly just uh offering a good notebook experience in itself but what i i think they'd have a lot more potential in offering uh interface for documentation like as i mentioned in mathematica live interactive documentation would be really valuable yeah but they could be used for various other things like uh better debugger interface like in the debugger run code in cells and like reuse bits of code or for writing tests so having interactive individual tests instead of writing a test and then running them separately through some test runner interface which is often clunky yeah okay okay stuff like that oh so six years of work that's a lot of stuff okay probably yeah is there anything else that you have on your mind that you wanted to bring up that i didn't ask you about or that you were curious to either give a shout out about or just chat about um no not really okay well with that that's all actually the questions i have for you but i wanted to again just just thank you for your time for for tonight just answering a bunch of questions and making time to chat about this type of stuff i also i always really enjoy this also thank you so much thank you also for your work on on intellij i know it's still the most popular scala editor out there so yeah thank you so much for for all of your tireless work to just make you know the scala ecosystem have solid editor support so i'm sure thank you for setting up this uh talk thing because i've been missing going to conferences yeah and online conferences don't really do it for me uh because there's a lot of the interactivity missing that you get like regular conferences yeah for sure yeah i feel the same way and that's that's part of the reason why i wanted to to be able to do this to chat with people you virtually it's hard to get the you know i listen to you speak or something at a conference or see you at a conference and we go sit at a table and chat with to each other about developer tooling or something so the fact that i can't really get that this uh this fills that void a little bit so i really i really enjoy it yeah but yeah so thanks again for for making the time but one thing i i also wanted to do real quick is actually introduce the speaker that i'll have next month which i'm really excited about so without further ado i'd like to let everybody know that this next month in august i'll be sitting down with eugene yokota be really excited to just chat about sbt and developer tooling and build tools and all sorts of things so yeah please do tune in for that i'm really excited for it and again i just wanted to give everybody uh i just wanted to basically thank everybody for for tuning in and to to always showing up and listening to these again my my goal is to really be able to provide some just more insight into the tooling world we we talked a little bit about how difficult it is sometimes to get involved in tooling how there's maybe not as much intro material out there so hopefully this can be another ins like another resource or just more insight into it to to help people get involved or to help people yeah just make more sense of the of the ecosystem so with that i want to thank everybody again for for coming and showing up and thank justin one more time for for coming and hopefully i will see you all again in another month so thanks for tuning in everybody [Music] you

Channel: Chris Kipp

Views: 339

Keywords:

Id: 5ZebGDMpPgs

Length: 62min 55sec (3775 seconds)

Published: Wed Jul 28 2021

Reddit Comments

[u/ckipp01]

A big thanks to Justin for sitting down with me last weekend! For any of you that have been listening/watching, the future of Tooling Talks will change a bit as I migrate away from the live stream to a podcast. This next episode with Eugene Yokota will instead be podcasted. However, you can submit some questions that might be discussed here on GitHub.