[00:00.000 --> 00:13.240] it's green now okay now it's fine okay again sorry for those online it was [00:13.240 --> 00:19.120] muted the whole time yeah so let's follow through consistency like the design [00:19.120 --> 00:24.320] must be consistent or when worse is better the design must not be overly [00:24.320 --> 00:29.640] inconsistent right and and he also starts to look about priorities and we'll get [00:29.640 --> 00:33.240] to that like in the list world in the view of the right thing consistency is [00:33.240 --> 00:38.560] as important as correctness right whereas in the unique style worse is better [00:38.560 --> 00:44.000] well consistency can be sacrificed for simplicity in some cases but if you have [00:44.000 --> 00:47.160] to do that it's actually better to drop the feature all together if it's not [00:47.160 --> 00:51.600] that important right so that so it's better to drop the parts that are that [00:51.600 --> 00:55.280] deal with less common circumstances rather to introduce more complexity or [00:55.280 --> 01:00.320] inconsistency right so that's one way to keep it consistent is like not add more [01:00.320 --> 01:03.440] inconsistent stuff right if that was supposed to break down with the [01:03.440 --> 01:10.320] simplicity like and finally the the completeness both of them want the [01:10.320 --> 01:14.040] design to cover as many important situations as practical or reasonably [01:14.040 --> 01:19.800] expected cases should be covered right but in the right thing way of thinking [01:19.800 --> 01:24.200] completeness and consistency are what matter the most so that simplicity is [01:24.200 --> 01:30.920] not allowed to reduce completeness whereas in the unix world the unique [01:30.920 --> 01:34.040] way of thinking Lord in worse is better it can be sacrificed in favor of any [01:34.040 --> 01:38.880] other quality right consistency can be sacrificed to get completeness if not [01:38.880 --> 01:43.960] at the cost of simplicity right so these are these are different ways of [01:43.960 --> 01:48.200] working that are concerned with the same things and they are similar on the [01:48.200 --> 01:52.920] surface but as you go deep they are very different right and both of them work [01:53.200 --> 01:59.080] like they're both proven and they both built very successful software right so [01:59.080 --> 02:02.480] but what we can get out of this like what does it matter for us okay it's [02:02.480 --> 02:06.400] interesting that in the 90s someone wrote about this and identified this two [02:06.400 --> 02:11.120] ways of thinking but what matters for us in our everyday development is that [02:11.120 --> 02:16.560] there is no one right way to do like minimalistic software there are in the [02:16.560 --> 02:21.000] decision space in the design space there are forks in the road where you will be [02:21.000 --> 02:24.440] faced with decisions like okay I want to make this software clean and minimal [02:24.440 --> 02:29.040] and nice but okay do what do it this way or do it do it that way right there [02:29.040 --> 02:33.960] will be forks in the road and I'm gonna talk about all the ways that I got that [02:33.960 --> 02:39.600] wrong right so we will see what happens when things go wrong even if you have [02:39.600 --> 02:43.280] your best intentions of making clear and nice and simple minimalistic software [02:43.280 --> 02:49.200] right so bit of context I've been involved as like Andy said like many of [02:49.200 --> 02:52.680] us said we're all getting older like I've been involved with the Lua community [02:52.680 --> 02:57.400] for Lua programming language for like almost like 20 years now and yeah here's [02:57.400 --> 03:04.440] me at like the first Lua workshop back in 2005 like and giving a talk on a piece [03:04.440 --> 03:07.920] of software that I wrote so I was talking about how nice it was and like now 20 [03:07.920 --> 03:13.160] years later I talk about how terrible this after I write it right so yeah [03:13.160 --> 03:24.240] that's called maturing right so yeah so so yeah so this is Lua is like an [03:24.240 --> 03:28.280] example of like a very nice like minimalistic language like the whole [03:28.280 --> 03:32.720] source distribution is like 360k right and that includes like the bytecode [03:32.720 --> 03:39.600] compiler the VM the standard library like an amazing C API which is like stack [03:39.600 --> 03:44.360] based and like it's a triumph of like the power of simplicity and all that and [03:44.360 --> 03:52.440] the these three guys here who are is this and this they are like the creators [03:52.440 --> 03:56.480] of Lua and they have said like time and again how influenced they were by scheme [03:56.480 --> 04:01.640] right so but if you look at the surface it's like an all-goal style syntax it's [04:01.640 --> 04:05.680] like no parentheses and all of that right but like in essence you know because [04:05.680 --> 04:09.880] there are very much in that spirit of the right thing like it's it's it's very [04:09.880 --> 04:16.120] much in that mindset right but then when you get minimalistic systems like that [04:16.120 --> 04:19.960] and minimalistic languages right you end up with that batteries not included [04:19.960 --> 04:23.680] effect because that's how you get like such a simple and small thing right but [04:23.680 --> 04:27.480] when you have to interact with the real world the language that the minimalistic [04:27.480 --> 04:30.880] system is like the tip of the iceberg right because you have to deal with xml [04:30.920 --> 04:36.720] parsing and json and various protocols and all of those such things right so [04:36.720 --> 04:42.200] like you have to build on top of that little minimalistic base right so how [04:42.200 --> 04:47.720] do you deal with that we go modular right the idea is that instead of having [04:47.720 --> 04:53.520] that you know that big monster system with like every capability under the [04:53.520 --> 04:58.440] sun where that you see in some environment [05:00.880 --> 05:20.840] build like the smaller system that you can right so enter lure ox which is like [05:20.840 --> 05:24.360] a module manager a package manager for modules for the Lua programming language [05:24.360 --> 05:28.720] when I first got involved with that Lua had no package manager and and this was [05:28.760 --> 05:34.560] a project that we started around 2006 that so it's been like I was like around [05:34.560 --> 05:42.520] 15 years that I've been maintaining this project right and I know I know I [05:42.520 --> 05:46.600] understand if many people here don't like language specific package managers I [05:46.600 --> 05:50.840] know because in my other hat like I'm at this Linux distro maintainer and I know [05:50.840 --> 05:55.240] the pain that they can be but yeah like I have extra slides about that in the end [05:55.240 --> 06:00.400] if it becomes like a topic but let's agree that for many situations the [06:00.400 --> 06:07.800] necessary evil right to have them like so the story of making lure ox like it [06:07.800 --> 06:10.880] started with some sets of challenges because Lua was designed to be an [06:10.880 --> 06:16.200] embedded language so people run it like you have like an engine X server like as [06:16.200 --> 06:21.320] we do at Kong and where we have like a Lua Lua VMs embedded into it or you have [06:21.360 --> 06:25.320] like games and tons of games that were Lua first got really popular where you [06:25.320 --> 06:29.240] have like Lua scripting embedded in it so the idea is that you take that small [06:29.240 --> 06:32.680] language you put inside your large application you hook one to the other [06:32.680 --> 06:37.480] via the C API and then your scripts gets the functionality of the host [06:37.480 --> 06:40.840] application right and you can write scripts that control your game or which [06:40.840 --> 06:46.240] handle your requests and and all of that stuff but what ended up happening is [06:46.280 --> 06:51.600] that at the time we started lure ox and again I think I'm using Andy's like [06:51.600 --> 06:57.680] royal we in this case there was no one Lua community there was several scattered [06:57.680 --> 07:01.160] Lua communities right because most of the applications were like this were [07:01.160 --> 07:04.720] embedded applications and even though there were some modules here and there [07:04.720 --> 07:07.480] that you could use there was no convenient way to use them all together [07:07.480 --> 07:12.440] and build like pure Lua applications right so one of the goals was not just [07:12.440 --> 07:16.440] create the package manager but also kind of create that community of usage of [07:16.440 --> 07:22.520] modules right so I so we kind of have a had a point to prove right with with the [07:22.520 --> 07:29.560] with the system so yeah so to kind of try to prove that point right from the [07:29.560 --> 07:33.200] beginning I decided okay let's make lure ox the package manager into a pure Lua [07:33.200 --> 07:36.960] application of the kind that I want to show that it's possible once you have an [07:36.960 --> 07:41.120] ecosystem of modules right so we can do like the proverbial dog footing right [07:41.120 --> 07:50.680] so yeah so so we set out from from beginning with that idea right and that [07:50.680 --> 07:54.760] proof challenging because how do you make a system based on you know packages [07:54.760 --> 07:58.640] and modules when you don't have a package manager yet right you you get it [07:58.640 --> 08:04.720] you get into that like who watches the watchman situation like who packages the [08:04.760 --> 08:11.160] packages for the package manager and yeah so then of course we get to the the [08:11.160 --> 08:18.320] solution is bootstrapping right so I guess as open source developer right for [08:18.320 --> 08:22.520] the love of the like the will of the open source developers to show the [08:22.520 --> 08:27.720] products worth by dog footing like and like compilers and programming language [08:27.720 --> 08:31.840] people like like to show the worth of their systems by bootstrapping it by [08:31.880 --> 08:38.080] building it in itself right so so that's what we did like so we had a file [08:38.080 --> 08:42.640] system operation because that's generally what package manager do is a bunch of [08:42.640 --> 08:45.800] file system operations like moving files around calling calling other [08:45.800 --> 08:49.280] compilers and things like that building stuff and you know putting things in [08:49.280 --> 08:54.120] the right places so we had a library of file system abstractions and we made [08:54.120 --> 08:58.080] like an initial bootstrap version of that library which would have zero [08:58.080 --> 09:03.240] dependencies it would like because like core luon like has shell out command like [09:03.240 --> 09:09.360] a system can do like a CLI call right so we could so we made a library in terms [09:09.360 --> 09:13.320] of those operations that that was like the bootstrap version right so that we [09:13.320 --> 09:18.120] can that we could then build the rest on top right as I said who watches the [09:18.120 --> 09:22.520] watchman so we ended up with these two versions like the bootstrapping version [09:22.520 --> 09:26.560] and and the dog footing version and so this one could run with zero dependencies [09:26.560 --> 09:30.480] but then once you had the ability to install additional modules this one ran [09:30.480 --> 09:34.520] all of the file system operations in process so it ran a much faster right [09:34.520 --> 09:39.480] so because of deployment into systems and new operating systems that did not [09:39.480 --> 09:44.200] have any support yet we ended up having to maintain both of them in the code [09:44.200 --> 09:49.880] base right so there you start notice that things are getting smelly right like [09:49.880 --> 09:53.240] it's no longer that minimalistic anymore when you have like these two [09:53.280 --> 09:59.200] different implementations of right off your core libraries around plus the real [09:59.200 --> 10:02.600] world keeps getting in the way and once you have those little like Unix CLI [10:02.600 --> 10:07.560] abstractions often you start to have like to put little additions because some [10:07.560 --> 10:13.040] of the OS's are different right and then as time goes by you have to make an [10:13.040 --> 10:17.920] entire different implementation in order to support windows as well right so [10:17.960 --> 10:24.360] yeah so things are things are not getting like looking any nicer right yeah [10:24.360 --> 10:29.800] plus over time people start asking like this is a package manager you told us [10:29.800 --> 10:34.320] that low rocks was a pure low application why can't I like upgrade it in itself you [10:34.320 --> 10:38.640] know just run low rocks install low rocks and I looked at it and then I thought [10:38.640 --> 10:42.960] about like the two different bootstrapping situations and all of the [10:42.960 --> 10:47.520] complications that that would happen and after a while like I caved in I said okay [10:47.520 --> 10:53.240] let's try to do this we've done this for a while it worked if you had the exact [10:53.240 --> 10:56.720] same set of circumstances in your system you know for in order to that to work [10:56.720 --> 11:00.080] because lower rocks can be installed like in a home in a home folder without [11:00.080 --> 11:06.520] permissions as a system-wide package with permissions installed by the package [11:06.520 --> 11:10.440] manager installed by yourself from sources or if it's on windows then [11:10.440 --> 11:16.320] windows you cannot modify files that are currently open unlike in Unix so over [11:16.320 --> 11:19.560] time we ended up dropping this one because now this is no longer supported [11:19.560 --> 11:24.520] like so you actually have to install lower rocks by some other means right but [11:24.520 --> 11:35.880] yeah so but we really tried so another point where like the idea of minimalism [11:35.880 --> 11:42.680] kind of backfired was the definition of the scope of the project itself so [11:43.000 --> 11:48.520] especially because I was coming from experience of being a maintainer for a [11:48.520 --> 11:53.680] Linux distro and writing the package manager for that Linux distro as well [11:53.680 --> 11:59.440] so I had a bunch of experience in in package management and the development [11:59.440 --> 12:03.640] of that area I decided from from the beginning and said like this is gonna [12:03.640 --> 12:07.960] be a package manager for Lua modules specifically and Lua modules can be [12:07.960 --> 12:12.400] written either in Lua like .lua files which contain like source code or they [12:12.440 --> 12:18.840] can be actually see dynamic libraries like .so files or .dll files right which [12:18.840 --> 12:23.320] are like C programs that use the Lua C API and built into a library that can be [12:23.320 --> 12:27.680] loaded by Lua at runtime right and I limited the scope and said that's this [12:27.680 --> 12:32.000] is it right because I don't want people to start making like crazy hacks with it [12:32.000 --> 12:36.120] because I knew that once people would start doing crazy hacks with it they [12:36.120 --> 12:41.360] would start stepping on the toes of the operating system package manager like [12:41.480 --> 12:47.040] even more than language package managers already do right because I've had [12:47.040 --> 12:50.840] people ask me things like oh I have some Lua stuff that integrates with a JVM I [12:50.840 --> 12:55.640] would love to distribute my Java files and classes with Lua rocks right I've [12:55.640 --> 12:59.040] heard all sorts of things like that so at first I thought the decision was [12:59.040 --> 13:02.600] right but then there were things like okay I'm doing web applications and I [13:02.600 --> 13:07.400] need assets like CSS and things like that that actually have a legitimate case [13:07.480 --> 13:12.920] of being distributed with that right or I'm making a game and my graphics like [13:12.920 --> 13:16.600] they need to come along with that and all of that and at first I say well if [13:16.600 --> 13:19.200] you're making like a whole application like you can use Lua rocks for your [13:19.200 --> 13:22.440] modules and then you have to package it some other way that would make sense if [13:22.440 --> 13:27.800] you're thinking with the hat of OS package manager but in the end people [13:27.800 --> 13:31.920] would just end up like doing like crazy hacks like you know renaming their [13:31.920 --> 13:35.560] files like .lua to please Lua rocks so that they wouldn't install it and then [13:35.920 --> 13:41.160] load it by other means and all the things like that and and and I myself was [13:41.160 --> 13:44.880] guilty of that at some point in which like I made a Lua module that could [13:44.880 --> 13:48.640] read the Lua rocks metadata and find out where Lua rocks it's install it's like [13:48.640 --> 13:52.040] documentation files and you could put like other files in there and things [13:52.040 --> 13:56.480] like that so it's kind of like you know like I should have put like a Jeff Goldblum [13:56.480 --> 14:03.680] slide saying life finds a way you know so for this one maybe you can add it in [14:03.720 --> 14:11.560] post and add that so yeah so the next story I think this is the third this is [14:11.560 --> 14:18.600] the third story of the so Lua keeps its simplicity by having this model of [14:18.600 --> 14:23.400] mechanism not policies like people ask for features and the Lua authors do not [14:23.400 --> 14:26.320] give them the features they give them like the mechanisms in which you can [14:26.320 --> 14:30.000] actually write the feature right so instead of having a debug error Lua has [14:30.040 --> 14:35.040] like a debug API which can provide you like you can call functions and get [14:35.040 --> 14:38.280] information of the about the debug state and people has used that to write [14:38.280 --> 14:43.680] debuggers and IDs and all sorts of things right so it's a it's it sounds [14:43.680 --> 14:48.480] sounded to me like a smart way of keeping things minimal and and bounded [14:48.480 --> 14:53.880] right while being very principle about how they do it you know the right way so [14:54.880 --> 15:00.760] so in Lua rocks kind of tried kind of trying to find the to follow the same [15:00.760 --> 15:08.280] path and going well when in doubt make making a sensible right for various [15:08.280 --> 15:13.200] things for example like how to download code from the internet in order to make [15:13.200 --> 15:18.400] your packages right back like nowadays the whole version control wars are done [15:18.560 --> 15:23.600] and get has won right but at the beginning like around 2006 you would have [15:23.600 --> 15:28.760] like subversion and mercurial and fossil and darks and all of the other ones [15:28.760 --> 15:33.840] that no one else remembers anymore and so yeah so so it came up with the whole [15:33.840 --> 15:37.400] thing where okay so depending on who what you used in the protocol if you put [15:37.400 --> 15:42.600] like get you know colon slash slash or if you put like foobar it would try to [15:42.600 --> 15:47.360] load the foobar module and see if you know if we had like hooks in order to [15:47.400 --> 15:52.880] download stuff and and things like that the side effect is now now we have the [15:52.880 --> 15:56.120] code base like modules there for a version control systems that I'm sure [15:56.120 --> 15:59.600] no one has used like for over 10 years and they're still there in the code base [15:59.600 --> 16:07.120] right as extensions and things like that extensible build types another aspect [16:07.120 --> 16:12.920] of that you know you know heard of cats that was the Lua community and then the [16:13.080 --> 16:16.400] various subcommunities around it was that everyone was building before [16:16.400 --> 16:20.200] Lua rocks existed everyone was building their module like their own way right [16:20.200 --> 16:23.920] some people use C make some people use make some people just put the code out [16:23.920 --> 16:30.120] there and say like compile it yourself you figure it out right and and I didn't [16:30.120 --> 16:33.840] want like some people use like configure with auto tools and all of that right so [16:33.840 --> 16:38.120] I didn't want to annoy anyone because the goal really was to get a community [16:38.120 --> 16:41.560] formed around it and not like segregate anyone so we did the same thing with the [16:41.560 --> 16:48.720] build types right but this time I kind of followed my unixie itch and I went [16:48.720 --> 16:53.160] like full worse is better on it and in addition of all that is those extensible [16:53.160 --> 16:57.000] build types I create one that I just called like built in like a total lack [16:57.000 --> 17:01.600] of creativity which was like kind of like make you know like just get a list of [17:01.600 --> 17:06.120] things to do and things to compile but like without any sort of like dependency [17:06.120 --> 17:09.760] resolution not anything like I was like super dummy was just go through the list [17:09.800 --> 17:15.280] one by one call the compiler get things done and recently like a few years ago [17:15.280 --> 17:19.240] like I I ran the numbers on the whole rocks repository like thousands and [17:19.240 --> 17:22.320] thousands of packages and like 80% of them were all using the built-in mode [17:22.320 --> 17:25.920] because like the most common cases they are is that your lure modules just a [17:25.920 --> 17:32.400] couple of Lua files and not even or it's a single C file like so that one like it [17:33.240 --> 17:39.760] it really was that one was a success right so in that sense and the last [17:39.760 --> 17:42.880] example is like configuration this is also not supposed to be read like it's [17:42.880 --> 17:46.960] just supposed to be like how big are is the response when you run like low rocks [17:46.960 --> 17:51.520] config because at first because everyone was using their own like little ways of [17:51.520 --> 17:56.920] running Lua I made like every single path and sub path and folder name like oh [17:56.920 --> 17:59.720] do you want your includes to be in a folder called include or do you want [17:59.720 --> 18:02.680] your bin to be in a folk art bin so nothing ever is hard-coded in there [18:02.680 --> 18:08.440] right so end result I've barely seen people like customizing all those deep [18:08.440 --> 18:12.800] configurations plus people tell me that the configuration is super complicated [18:12.800 --> 18:17.840] and sometimes people who would maybe like solve their problem by changing those [18:17.840 --> 18:21.800] things they just can't just can't find which is you know the proper entry to [18:21.800 --> 18:25.760] fix because you know because there are so many options and they're so very [18:25.800 --> 18:31.560] similar like runtime external depth subdirectories and like runtime external [18:31.560 --> 18:35.400] depth patterns because maybe in our different operating system where it [18:35.400 --> 18:40.880] doesn't end with SO and things like that so all of that is but but it was I kind [18:40.880 --> 18:50.640] of overshot in making it you know too configurable right so now by now you [18:50.640 --> 18:53.760] must be convinced that low rocks is like the worst piece of software in the [18:53.760 --> 18:58.440] history of mankind and or at least the worst package manager out of them but [18:58.440 --> 19:02.760] if you think about it like on paper low rocks is like the minimalist's dream [19:02.760 --> 19:07.280] package manager right it has zero dependencies it dogfoods its own [19:07.280 --> 19:11.400] optional dependencies it has a well-defined scope in terms of you [19:11.400 --> 19:16.560] know the files that it manages it's built like its internal APIs are built on [19:16.560 --> 19:23.160] a minimal base yet it's extensible right so what went wrong right I guess in the [19:23.160 --> 19:27.720] end but what happened is that it also ended up becoming like the kind of thing [19:27.720 --> 19:31.560] that minimalists despise the most right because it ended up and ended up being a [19:31.560 --> 19:36.120] large system that tries to be all things for all people right so well let's make [19:36.120 --> 19:39.280] the extensible then people start extending it in so it started growing in [19:39.280 --> 19:47.320] all sorts of directions right so what happened why why did why why we got to [19:47.320 --> 19:54.200] that point like two things one was that like the realization that reducing [19:54.200 --> 19:58.960] complexity is different from shifting complexity around right you say well I [19:58.960 --> 20:04.600] made a minimal base and now and now this is extensible but then all of the [20:04.600 --> 20:09.280] extensions was were bundled right so I so I still have code around for [20:09.280 --> 20:14.200] maintaining all all of those like old deprecated version control systems and [20:14.200 --> 20:17.040] things like that because they were all part of off the core application still [20:17.040 --> 20:22.280] right so many of the extensible bits they they kind of like if you were to use [20:22.280 --> 20:26.680] like a third-party extension sort of felt like a second-class citizen like you [20:26.680 --> 20:30.280] would have to add like an additional build dependency for that so and and and [20:30.280 --> 20:38.720] things like that and second the world is dynamic like things change and when we [20:38.720 --> 20:41.960] talk about design people often think about design as a blueprint but a [20:42.040 --> 20:44.720] blueprint you know it's something that you'd like before you start building the [20:44.720 --> 20:50.480] house right so so people tend to see design a lot like a initial step right [20:50.480 --> 20:54.920] you have to design then you have to build but the world keeps changing the [20:54.920 --> 20:59.000] requirements keep changing like stuff keeps changing and you keep accommodating [20:59.000 --> 21:03.640] for those changes so you have to think about how you're going to keep your [21:03.640 --> 21:08.520] minimalism over time right because it's easy to start small and then and then [21:08.600 --> 21:14.400] it spirals out of control so that got me thinking a lot like the sort of like [21:14.400 --> 21:18.240] the final section here of the thought about it is that that got me thinking [21:18.240 --> 21:21.560] about like minimalistic software maintenance because it's nice to you [21:21.560 --> 21:25.560] know you think about like oh this nice and small like piece of software like as [21:25.560 --> 21:29.840] a something like still in time or at the beginning but you have to think how do [21:29.840 --> 21:33.000] you make it how do you make that work over time you know and keep those [21:33.000 --> 21:39.080] principles and the way to do that is by setting boundaries and and that's one [21:39.080 --> 21:44.920] thing that that worse is better system that like that puts simplicity at the [21:44.920 --> 21:51.960] front so it does that well it's like a lot you know cuz that really like it [21:51.960 --> 21:56.040] stops from like say oh we're gonna drop a feature if it reduces simplicity or [21:56.040 --> 21:58.840] we're gonna make it a little inconsistent as long we keep everything [21:58.840 --> 22:03.480] simple because simple is more easily maintainable right because things can be [22:03.480 --> 22:10.120] like complete and consistent and end up being super complicated right so for [22:10.120 --> 22:14.720] example like one example within the realm of like the right thing philosophy I [22:14.720 --> 22:19.800] think was that the little language itself it favors simplicity over [22:19.800 --> 22:26.280] compatibility right because they they do put consistency and completeness like [22:26.320 --> 22:33.960] and in first place right but also like the right way style of managing that [22:33.960 --> 22:39.720] growing complexity is by changing your definition of complete right or limiting [22:39.720 --> 22:43.280] your definition of complete right then you like if you want to go for [22:43.280 --> 22:47.800] completeness and you want to still be minimal like you have to put a bound on [22:47.800 --> 22:53.360] your definition of complete right so so the way they did it was that okay we have [22:53.400 --> 22:57.760] to make changes all right what are we gonna take out what are we gonna you [22:57.760 --> 23:02.760] know in order in order to keep that going so so basically in Lua every like [23:02.760 --> 23:06.360] major version which is like every 5x version five one five two five three [23:06.360 --> 23:09.560] they are essentially different versions of the language in terms of like even [23:09.560 --> 23:12.280] like source code gets incompatible because they make changes that break [23:12.280 --> 23:17.960] things right like as long as they keep the design consistent and complete within [23:17.960 --> 23:25.360] their definition of completeness right so yeah and and when we think about is [23:25.360 --> 23:31.840] like the easiest way to go is to go like the Unix approach which is if you if if [23:31.840 --> 23:36.240] you just follow the way of keeping simplicity then you do get that long-term [23:36.240 --> 23:41.080] maintainability and even in the original essay Richard Gabriel said like he [23:41.080 --> 23:44.480] said here like I have intentionally caricature the worst is better philosophy [23:44.480 --> 23:47.720] to convince you that it's obviously a bad philosophy and that that New Jersey like [23:47.920 --> 23:51.720] the Bell Labs Unix approach is a bad approach however I believe that [23:51.720 --> 23:56.320] worse is better even in its strong and form we watch that caricature of you [23:56.320 --> 24:00.400] know like everything simplicity is more important than correctness and things [24:00.400 --> 24:05.200] like that has better survival characteristics right then the right [24:05.200 --> 24:08.200] thing and it's interesting because survival characteristics gives you the [24:08.200 --> 24:12.680] sense of like something happening over time right you keep surviving right so [24:12.680 --> 24:16.640] so here isn't directly talking about maintenance like about long-term [24:16.640 --> 24:20.600] success of the project right not that's something that was like oh I dreamed [24:20.600 --> 24:24.920] it up one day and I came up you know with with Lisp and wrote a paper and [24:24.920 --> 24:30.040] that's it like okay what happens with Lisp over time right and so it's so he [24:30.040 --> 24:34.160] said that in line one right he said oh it's a you know the New Jersey approach [24:34.160 --> 24:36.960] when used for software is a better approach than the MIT approach like said [24:36.960 --> 24:40.760] that later he wrote another paper that called that's what's called worse is [24:40.760 --> 24:44.600] better is worse right because he was still trying to advocate for a list [24:44.640 --> 24:49.280] approach but things can't get out of hand like and then you remember if you [24:49.280 --> 24:52.960] remember that Richard Gaber was involved with common Lisp right which is not [24:52.960 --> 24:59.360] exactly minimalistic right so that's why that that's what can end up happening [24:59.360 --> 25:04.440] right so why are the lessons learned like what about lure rocks you know what [25:04.440 --> 25:08.280] can we do about it like after all this time right there are things that I'm [25:08.280 --> 25:13.160] thinking about doing like this is like this whole talk is like the foreshadowing [25:13.200 --> 25:20.080] of the changes that I plan to make into the work all right so yeah that's like [25:20.080 --> 25:24.640] the last talk so we have a little bit of a relax all right so yeah that's the last [25:24.640 --> 25:29.680] last couple of slides here so just to say like we can still provide zero [25:29.680 --> 25:35.000] dependencies for users if we vendor in our bootstrap dependencies so we don't [25:35.000 --> 25:38.680] have to deal with bootstrapping anymore because like now we know 15 years later [25:38.800 --> 25:43.400] that the base set of dependencies really doesn't change over time right like we [25:43.400 --> 25:47.880] need a socket library we did an SSL library we need you know just a little [25:47.880 --> 25:52.120] couple of things right we can still make it zero dependencies for users and we [25:52.120 --> 25:55.880] can manage like a small set of libraries that we keep need to maintain [25:55.880 --> 26:02.280] ourselves right so that whole you know set of boots can be done away with like [26:02.280 --> 26:06.360] we could like simplify the scope and you know so that people don't have to do [26:06.360 --> 26:10.920] hacks in order to use assets and things like that because we do present it like [26:10.920 --> 26:14.160] and then it goes back to the whole right thing and worse is better right because [26:14.160 --> 26:17.840] the concerns with implementation versus interface because I was very concerned [26:17.840 --> 26:21.440] of presenting a cleaning interface you only deal with lua modules but the [26:21.440 --> 26:25.240] internal implementation was that lure rocks and it's internal it's a general [26:25.240 --> 26:28.680] purpose package manager has to deal with files moving around in a completely [26:28.680 --> 26:32.880] general manner right so we could just expose that to users and trust their [26:32.920 --> 26:37.320] ability to you know not mess up with the files like if they say like I'm gonna [26:37.320 --> 26:40.760] put them in this folder then alright we just we'll just put it there for them [26:40.760 --> 26:45.720] right and the other thing is that yeah the idea of the extensible minimal base [26:45.720 --> 26:50.160] is a good one but it should be a minimal base that it's extensible not like [26:50.160 --> 26:54.000] already extended right and the way to do this is that the extensions need to [26:54.000 --> 26:58.360] feel like first-class citizens like just like you know the rest of the code and [26:58.360 --> 27:02.040] not have things like okay these if you use this bill type you don't have to pull [27:02.120 --> 27:06.000] in anything else but for this time this one you do right so if you if you put [27:06.000 --> 27:10.520] everything in an even playing field then you can keep your base small right so [27:10.520 --> 27:14.360] in the end yeah it's still about simplicity correctness completeness and [27:14.360 --> 27:18.600] consistency but I would say and as we get older and start learning those [27:18.600 --> 27:23.040] lessons about how time matters is that you need to think about simplicity over [27:23.040 --> 27:28.000] time correctness over time completeness over time consistency over time now I'm [27:28.000 --> 27:30.360] over time so thank you [27:43.880 --> 27:46.320] do you have any questions or should we go for the drink last we have questions [27:46.360 --> 27:46.720] okay [27:56.160 --> 27:56.960] what do you mean by that [27:58.720 --> 28:00.720] a moment very overwhelmed by amaziness [28:02.240 --> 28:06.880] yes yes yes yes so yeah thank you for allowing me to talk about the good parts [28:08.640 --> 28:15.040] yeah there was a to me a turning point moment was I think well I think like [28:15.040 --> 28:20.800] law rocks are 2006 I was hired to do a law consulting project around 2013 so that [28:20.800 --> 28:26.400] was like quite a few years afterwards in which I had the experience of using [28:26.400 --> 28:31.520] lower rocks as a user with a deadline who actually had to put up something [28:31.520 --> 28:35.800] together that solved a real world problem for the customer and I needed like [28:35.800 --> 28:40.680] protocol buffers and lots of things from the real world and I was actually like [28:40.680 --> 28:44.480] able to I was so used to having to come up with everything on my own in lua and [28:44.480 --> 28:48.480] then like okay lower locks install lua protobuf well it actually works like [28:48.480 --> 28:53.040] okay now in an XML and I pull like five six seven eight different packages and [28:53.120 --> 28:56.840] actually got my problem solved in a way that was much faster and I felt like [28:56.840 --> 29:02.880] yeah okay the yeah this is the actual park you know like like the it is a [29:02.880 --> 29:07.480] reality like it you only believe it when you use it right and sometimes the [29:07.480 --> 29:10.160] people who make the software and other people using it right so you don't [29:10.160 --> 29:14.280] actually get to experience that but but yes like I think the part about the [29:14.280 --> 29:18.280] building an ecosystem that was a success in the end right we actually have an [29:18.280 --> 29:33.200] ecosystem now any other questions over there yes so that's that's the slide I [29:33.200 --> 29:47.200] prepared for this topic yeah so yeah so like language based package managers [29:47.440 --> 29:52.360] and open system package managers right because whenever people are you know [29:52.360 --> 29:56.280] reticence to the idea of language package managers they go like oh why don't [29:56.280 --> 30:02.920] we instead just instead packages all as insert my favorite package style like [30:02.920 --> 30:06.360] why don't we just do deb files for everything or why don't we just do [30:06.360 --> 30:11.480] geeks for everything why don't we just do rpm for everything why won't we just [30:11.520 --> 30:17.400] do you know macOS whatever they use now things right so it turns out that it's [30:17.400 --> 30:24.680] so one okay this alone would sort of answer right but then again there's [30:24.680 --> 30:29.240] another argument of scale because if you think about like how many packages do [30:29.240 --> 30:33.880] just debian which is one of the largest distributions have like I think like [30:33.880 --> 30:38.160] last I checked a couple of years ago it was like something like 60,000 packages [30:38.200 --> 30:43.800] right must be higher now right the JavaScript okay JavaScript is the worst [30:43.800 --> 30:46.600] example okay so let's take something like this JavaScript is over a million [30:46.600 --> 30:52.280] packages right so that's let's call that too much right but take something in the [30:52.280 --> 30:56.360] middle like Ruby Jam's like will easily have over a hundred thousand right or [30:56.360 --> 31:01.960] maybe like two hundred thousand by now right so like the set of modules of a [31:01.960 --> 31:05.560] language ecosystem would easily overwhelm like the pack like the old package [31:05.600 --> 31:09.320] management overhead of the community of that distribution like so if you do the [31:09.320 --> 31:13.800] math the matrix of like every operating system and Linux distro versus every [31:13.800 --> 31:18.480] language out there right doesn't add up like this so you kind of have to have [31:18.480 --> 31:24.240] language module managers on one side and system managers on the other and okay [31:24.240 --> 31:28.240] this was the funniest slide okay this is actually the actual slide so actually [31:28.240 --> 31:33.160] we're a paper on this problem right which was rejected many many times [31:33.520 --> 31:39.240] because you have operating system conferences and you have programming [31:39.240 --> 31:44.680] language conferences and package manager is always everyone else's problem right [31:44.680 --> 31:49.360] and I was there like living at that crossroads like these that the other two [31:49.360 --> 31:52.960] guys like Lucas from IBM Research and Michael from Victoria University in [31:52.960 --> 31:58.360] New Zealand they were both developers of global Linux was also the Linux distro [31:58.720 --> 32:04.880] that we were developing together right so so we're all coming from and Michael is [32:04.880 --> 32:09.480] a researcher in programming language department as well right so so we so we [32:09.480 --> 32:13.480] had like and like Lucas works with operating systems so and I'm sort of in [32:13.480 --> 32:19.840] between so yeah so so it took a while right so that was this this was in a rare [32:19.840 --> 32:23.880] like PLOS programming language operating system workshop that happened within [32:23.920 --> 32:29.200] SOSP which is an operating system conference and at last that that got [32:29.200 --> 32:32.600] like accepted because we came up with a taxonomy of like identifying the [32:32.600 --> 32:36.040] different types of package managers and what do they get right and wrong because [32:36.040 --> 32:41.000] yeah they do step on each other's toes a lot and yeah this this paper has some [32:41.000 --> 32:45.560] recommendation on how not to because low rocks was very careful not to step on [32:45.560 --> 32:48.960] top of the toes and now we're gonna be kicked out of the room let's go out and [32:48.960 --> 32:53.560] have some beers thank you