Hey MPJ. First of all, I really like your videos, thanks for the great work :). I think this video however gives a different meaning to the term leaky abstraction than the common one, or at least how I understood it from Jeff Atwoods post. Afaik: a leaky abstraction leaks the thing it is abstracting, not how it is abstracting it. So I wouldn't call that http library leaky on your criteria; you do not need to understand http because of its error handling. In fact, I'd say it makes it less leaky; without it, you would need to understand how error codes work in http. To give an example of what would be leaky (to me): you have an OEM, and you can navigate through your objects like this: class.students. but because you also need the homework of each student you do 'student.homework' for each student. Now you run into the N+1 problem. But to understand this you need to understand how the SQL works. The ORM abstracts away SQL, but a little bit of it leaks through. Actually, I'd say hashes are leaky to (for at least one, but I think its most common use). If you use a hash for security (for instance a passport) you need it to be slow. This means not only do you need to know the algorithm of the hash, you need to know the Big Oh complexity of its best implementation. Anyways, I think the problem is subtle but useful. the http lib you mention isn't leaky, but you need it to be; you actually care for http return codes while contacting the server because for instance 404 is valid and needs to be handled, whereas a leaky abstraction leaks its underlying stuff, so you cannot suffice by only learning the abstraction, you need to understand what it is it is abstracting (again, ORM is a great example; you cannot really use it if you don't understand how a relational database works)
Hey MJP... I think the one thing missing here is the context on how we create abstractions in our code and steps we can/should take to avoid leakage, like: determinism, understanding what we are encapsulating (scope), decoupling, test writing with leak exposure in mind, etc. Your examples are good to define it, so nothing wrong there... I just hate the idea that programmers might frame this only in the context of choosing libraries. It is much more prevalent in the way we construct our code and think about it.
nice explanation. I'd suggest 'market' as an example of an everyday abstraction. in reality its an incredibly complex interaction of shifting behaviour patterns but the abstraction allows me to say something like "There's a lot of uncertainty in the market" and make sense.
intestines? Let's abstract out those details and just call it guts. No matter. Mondays would suck without MPJ to get me started. Thanks for another great video.
Love your videos!! Regarding not using libraries like "axios" - well I guess people who worked with web applications before whole this "npm" wave were used to jQuery dealing with browser implementation nuisances. And, though I haven't used "axios" myself yet, I kind of assume, that if I use it, I will never have to deal with browser specific issues. Also - you mention using "internal function" to make requests. I think having internal wrapper is actually a bad idea if there's team of more than one. If you are going to use a wrapper, use external, well tested and well documented one. But I 100% agree, that doing a wrapper on top of a library is probably the worst way. As you say the order of preference is: Raw Function > 3rd party wrapper > internal wrapper > internal wrapper on 3rd party library.
Hello! I've watched your videos for a while, and they're generally both interesting and educational. This one was especially good. Thank you for the effort you're putting in! I dislike one thing about this video: you're contributing to people thinking complexity is the same thing as complicatedness. If you'd like to keep it simple, I suggest sticking to one and ignoring the other. Your examples seemed to be about complicatedness. Hope you keep making these videos! Stay safe, Teodor
+Teodor Heggelund hey theodor, you talk about these words like they have firm definitions somewhere, which they don't. I have NO idea what complicatedness is and how it differs from complexity.
+funfunfunction in theory I subscribe to rich hickeys definition of complecting/complexity/simple/easy definitions that he talks about in "simple made easy" but I find it super hard to use that terminology in practice when talking.
That's a great talk. I'd love to hear what you think about ClojureScript some time. But I'm afraid it would end up like your (excellent) videos on Haskell, not easy enough to get many viewers.
I remember an abstraction in a C++ lib that meant you defined a template class, which inherited from another template class. Then you defined three member classes inside your class there - which the parent template class would then inherit from!
I have an idea for a video (series). I personally would find it really interesting to view the source code of something you have written (preferably a semi-serious web application). I have been looking at your Github but could not find anything with a larger code base (such as an app). So, I would like to see a series, of maybe 30-min episodes where you code something up, maybe comment on some of the things that you do and in some cases refer to previous videos. So that one could not only follow along during the coding process but also later view the code at for example Github. This would be really interesting to me =)
+Johan Gudmundsson yeah, many people have suggested this. It's really tricky though, even a simple application is hundreds of hours of work, and not exactly neat 30 minute episodes with pedagogical illustrations. The format is tricky. I know the need to see a cohesive picture of these things, but I'm not quite sure how to deliver it.
I feel a lot of new programmers (especially students) tend to jump on buzzwords like Axios because they hear it from middle or senior programmers and feel they need/should to use it. Sometimes they miss the reason of using something simpler or less featured like Fetch to do something simple. The hype gets in the way 😕 and they end up building a bloated app. In some ways the hype that surrounds frameworks and libraries is much like other cultural bandwagons outside of programming depending on the person.
That's a big, hard question, not readily answerable on UA-cam. I'd recommend taking a master's degree or better in computer science, then ten or more years of experience building software...
A few principles I keep close to heart, are SRP and DRY. SRP is the Single Responsibility Principle. I am happiest with a piece of code if it does _one_ thing, and does it well. In other words, it has a single responsibility. DRY is Don't Repeat Yourself. It combines well with SRP, since if you need the same piece of code in more than one place, you probably need to package it for reuse instead of writing it again.
My technique is: "Wait for at least 3 duplications before making abstraction" From my personal experience, I found that making abstraction immediately after you found duplication will mostly leads to leaky and wrong abstraction. The pattern is not fully aware yet but programmer (including me) will always have an urge to abstract the duplication. At this point I have to assume a lot about which concept can encapsulate duplication nicely, and mostly the assumption will be a lot better if I wait for third duplication. Dealing with 2 duplications is much easier than dealing with wrong abstraction.
Chakrit Likitkhajorn True. A few factors that come in to play though: 1 You might foresee that you will need the duplicated code before you have used it more than two times. If you write som kind of code related to 2d/3d objects, you will probably put your code for finding the distance between to points in a function right away. (Unless you have that formula in some library to begin with) 2: Will writing a general function be a complex pice of work? Or will it simply be copying a piece of code into a new function? (I would gladly copy 5 lines of code into a function, even if I only used it twice throughout my code. Well, unless I had to make some complicated structure to map my arguments and such.) Or maybe something in between? 3: How much code is each duplication? If you in som form or manner calculate what can be abstracted to A+B*C seven times in your script, is it any good abstracting this away with a function? The ApBtC function might just confuse stuff. As MPJ said: it can be a complicated topic.
Probably I haven't been listening carefully enough but I didn't get the idea. I got that things with simple interface is good.. Sort of like Unix gnu tools.. But I didn't get why if a library throws an error on http it's now a leaky abstraction? Just because it handles something differently? Doesn't sha1 trow an error in case of invalid params? I'm not arguing that leaky abstraction is somehow mythical but it's hard to me to get the point.
Because they assume that http error should be encapsulate with javascript error. And most cases, it should not. Javascript error such as "undefined is not a function" and http error should be handle very differently. But axios just automatically transform the network error into javascript error. Therefore in many cases, developer need to separate these 2 kinds of error once again in "catch" block. If sha1 throw an error, I will handle it along the line of "null is not a function". Because it means that basically something is seriously wrong along the programming logic. Maybe someone forget to assert something. It is "unintended" error. But many times http error is "intended error", which happen because of user, not the programming itself.
I'm not an Axios user any more, but my feeling is that Axios throwing and Fetch not throwing are simply the assumptions their authors have made about what a user expects to happen when server error responses happen, and not a case of leakiness: I faced the exact same API situation as you and I had the same reaction but in reverse when I moved from Axios to Fetch and I still find it really odd that Fetch doesn't reject on 500-errors. I actually felt it was a case of over-abstraction -- smoothing-over basic flow logic and requiring more lines of logic to sort out normal responses from problematic ones. But I see now how you could see it the other way. In any case, I don't consider Axios leaky because of this. That said, the fact that Axios returns a native Error object, rather than their own error-state object does strike me as hugely impure (in fact most FP programmers I know think throwing at all is fundamentally impure), so it does not surprise me that you prefer Fetch over Axios because of this.
Have been watching your videos for a week now. You have an absolutely lovely insights about "things" and general concepts. I'v heard you were working at Spotify. I'm the"CTO" & founder of a 5 years french startup (360medics) and i'd have questions about tech team organization and management that i'd love to ask you about (we just finished our 2nd fund raising and are currently growing/organizing). Any chance we could discuss a few difficulties we stumble upon / compare with your own experience in the companies you worked at ?
Would you consider redux a leaky abstraction? My thoughts are these. It claims to solve a lot of problems and because it is small it can easily be implemented and used and the abstraction seems legit, use flux as your pattern and only action can mutate state, easy enough, but as you said this is not always the case so you now need to start unraveling all the libs added to redux inorder to make it do what you want. Thus the abstraction sounded simple and seems to be adding benefit but as soon as the use case starts getting complictated it could potentially force a complete rebuilt or some other costly affair... thanks for great show.
thank you mpj for all your great videos, but i really want to know, how do you document your code?, do you use a specific tool?, or you just use comments in the code?, i really have problems with this topic, we used to work with the program case complete, but i want to know what everyone else is using.
I've been thinking about this a lot lately. I've fallen into this habit of chasing the general case too much. What I'm really chasing is simplicity, but in most cases it makes things incomprehensibly complex. Using generic code is simple, but writing it is not!
Mike Talbot - Thanks for that link! Very helpful! Exactly the kind of ideas I've been circling around lately. OOP and the whole 'culture' that comes with that has my head spinning. I'm looking to simplify my process, big time.
Like for me Ruby on Rails is anything but simple, it's probably the most poorly designed major framework ever. It's nearly impossible to know what happened where and why. Rails used Dry to the extreme where a single line executes thousands of callbacks changing the whole apps global state. To me implicitly inheriting methods and propeerties from a cobbled web of classes sucks.
In programming abstractions are almost always leaky particularly in imperative languages. One size does not fit all. People should stop using Javascript frameworks completely all together because they create more problems than they solve. They all have a learning curve, leaky abstraction, bugs and they all stifle our creativity one way or the other. Programming was so much easier before the nodejs and the responsive design era even if we did not have great tools we have today.
How about MongoDB vs Mongoose ODM? I feel like I have been through some bad experience when I was using Mongoose, as a newbie, not sure if it will be much more simple if I choose the pure MongoDB path.
Great video. Can we take this one level up and say that a good framework should be a non leaky abstraction of common patterns to solve a particular set of common problems ? I often find myself digging in AngularJS code to understand what the heck is going on. Shouldn't we design frameworks with similar attitude in mind that ideally doesn't require me as programmer to worry about internals of given framework ?
Do these videos help MPJ get a job or do they just inform his future employer that every Monday morning he's ill or hungover? Love the videos anyway mate!
Excellent video as always! Do you plan on doing a video about Rx anytime soon? I know they use RxJava for Spotify Android (I don't know if you guys also use RxJs for web or client), and I'd really like hearing about any shortcuts to learning to be productive with Rx, e.g., recurring patterns, how to get over main pain points, basic gotchas, etc. Thank you again!
+Eloi Simard Quesnel I'm not personally a big fan of Rx. The surface area of the thing is ludicrous and the observable pattern is really dubious when you spread them out all over your app instead of using it in a simple and structured form like it's done in Redux. You probably won't see an Rx episode from me, but possibly one that critisizes the observable pattern. ;)
It's really funny that you mention the use of Rx in Redux as I'm currently trying out redux-observable to handle side effects in a project, and my questions about Rx were mainly aimed towards using the library in this exact scope! I didn't learn Rx on its own so I'm ending up spending a lot of times debugging simple observer -> operator chains. Luckily this is only a side project so I can afford the overhead of learning Rx on the job. Anyways, I'm looking forward to that video! :3
redux-observable is SO weird to me. Observable is a performance optimisation pattern that you use in cases where it would be to expensive to re-render on every frame. With React/Redux, you don't have to bother with that because React takes care of the DOM diffing (or in the mapStateToProps thing in react-redux). Isn't the whole idea of Redux is to get rid of observables?
Yes of course! Redux-observable is only a midleware that wraps the dispatching of actions so you can observe your actions as they stream through your store, and expressively declare some side effects depending on the action type! It has nothing to do with rendering, it only observes what actions are dispatched. So let's say you have a text input which dispatches an update_input action on keydown and you want to do some type of api call as he types to try and guess what the user wants. With redux-observable you can decide to take any action of type update_input from the action observer, throttle them by some X amount of time in order to prevent making a call on every keydown event, make the api call, cancel it if new values come in, and return a new action that could be like show_input_options that ultimately modifies your store and updates the UI. This is not using the observable pattern to do any rendering logic, it is more to handle async /side-effect actions. Your actions + reducers, like always, end up triggering the renders.
What's the difference between a leaky abstraction and a highly configurable abstraction? It seems both require more than a glancing knowledge of the API.
+Noah Namey Noah, this was a really interesting question. I asked people at work, and one insight was that a highly configurable abstraction indicates that you don't need the abstraction. You would probably be better off not using the abstraction at all if you need lots of configuration.
funfunfunction I guess my next question, is where do you draw the line? Surely Angular, or Express are abstractions that can take quite a bit of configuration. So I wonder if the concept of "leaky" is relative.
funfunfunction So "leaky" is something to be aware of, not necessarily something to be avoided... ? Ehh... I think I'm drifting into pedantic PITA territory ;-)
I like your videos, but I think it would be um, kindof good to sometime to increase the complexity of the topics. Like how to use libchromiumcontent and brightray to make a simple something. or like i don't know something that is not easy.
+Alex Day maybe (although your suggestion sounds extremely specific rather than hard). Can you talk a bit about your background? the target audience of the videos are developers that are about one year into their first job.
Firstly I want to apologise if I sounded specific, (that thing I specified was what I had in my mind at that point, I could say like I want to know what I don't know, because how can you tell). I am a web developer, I have been doing rails and javascript and now a bit of rust (thanks to you, for bringing that up in one of your videos), and I have been doing that for like 4 5 years now,, 2 years industry experience and 3 years of experience that the industry doesn't care :P . I just thought it would be good sometimes to do a little hard videos like you do unusual ones like haskell, that was of-course I didn't realize the target audience.
Hey Alex! It's really cool to have you following the channel. That said, I think that you are probably a little past the skill level I am targeting. I am planning to do some videos on data structures and patterns in the future, you might glean some from that. But that said, I think that you are at a point where you should start teaching yourself. ;)
funfunfunction I think it's not well known and incredibly powerfull, sometime dangerous, here's a pen addressing proxies that you might enjoy, is it good practice who could say. codepen.io
+Ян Такушевич Again, the advice is not to avoid leaky abstraction. That would be unrealistic advice. The point of the video is to be aware of the leak and the cost it brings with it.
I had the same thought and came to this conclusion.. thanks to so other vids from mpj. The first abstraction of web 2.0 was splitting css js and html into seperate files which enables you see clearly how each is composed. But this showed its flaws only later where our apps became hard to understand because the logic can touch all of the above parts and keeping trwck of them became a mess.. thus we wher wrong about the initial abstraction. Frameworks attempts to rectify this with isolating css html and js into components where they can live as theyre own entities. This solves many issues and we ican deduce that the abstraction now looks more like what a framework would propose. Thus leaky abstractions was prevailent in version 1 css html and js seperate , butooking at the problems we face with frameworks that too is a leaky abstraction... That said the problem is not if a abstraction is leaky but in the conceptualising of the abstraction, the more complex the more leaks. I think a good framework in this senario atttempts to make those leaks less, like the application of react hooks. Which is in itself a leaky abstraction but in a easy to understand way that makes it possible for the developer to mitigate those leaks better.
![АЛАУДИНОВ у Скабеевой: эти их ВСУ нас НЕ ДОГОНЯТ 😁 [Пародия]](http://i.ytimg.com/vi/an0anqU4WGQ/mqdefault.jpg)
you and westworld makes monday a nice day
I have admire for your encourage to stay curious at the end of the video. I believe that is one of the most important qualities in a developer
You should create more than one video per week :) Really cool stuff!
He's said before his videos take quite a while to make. Doing 2 a week wouldn't be viable.
Great video, love these videos of more general development topics!
+Risto Novik me too! Glad that they are appriceated!
Idem
Hey MPJ. First of all, I really like your videos, thanks for the great work :). I think this video however gives a different meaning to the term leaky abstraction than the common one, or at least how I understood it from Jeff Atwoods post.
Afaik: a leaky abstraction leaks the thing it is abstracting, not how it is abstracting it. So I wouldn't call that http library leaky on your criteria; you do not need to understand http because of its error handling. In fact, I'd say it makes it less leaky; without it, you would need to understand how error codes work in http.
To give an example of what would be leaky (to me): you have an OEM, and you can navigate through your objects like this: class.students. but because you also need the homework of each student you do 'student.homework' for each student. Now you run into the N+1 problem. But to understand this you need to understand how the SQL works. The ORM abstracts away SQL, but a little bit of it leaks through.
Actually, I'd say hashes are leaky to (for at least one, but I think its most common use). If you use a hash for security (for instance a passport) you need it to be slow. This means not only do you need to know the algorithm of the hash, you need to know the Big Oh complexity of its best implementation.
Anyways, I think the problem is subtle but useful. the http lib you mention isn't leaky, but you need it to be; you actually care for http return codes while contacting the server because for instance 404 is valid and needs to be handled, whereas a leaky abstraction leaks its underlying stuff, so you cannot suffice by only learning the abstraction, you need to understand what it is it is abstracting (again, ORM is a great example; you cannot really use it if you don't understand how a relational database works)
Hey MJP... I think the one thing missing here is the context on how we create abstractions in our code and steps we can/should take to avoid leakage, like: determinism, understanding what we are encapsulating (scope), decoupling, test writing with leak exposure in mind, etc.
Your examples are good to define it, so nothing wrong there... I just hate the idea that programmers might frame this only in the context of choosing libraries. It is much more prevalent in the way we construct our code and think about it.
Love your stuff MPJ. Thanks for putting in the effort to make them
nice explanation. I'd suggest 'market' as an example of an everyday abstraction. in reality its an incredibly complex interaction of shifting behaviour patterns but the abstraction allows me to say something like "There's a lot of uncertainty in the market" and make sense.
intestines? Let's abstract out those details and just call it guts. No matter. Mondays would suck without MPJ to get me started. Thanks for another great video.
I propose the term "toight" as a label for non-leaky abstractions. So SHA1 is a toight abstraction :)
My code is mostly sinking abstraction - it only add complexity without simplifying anything. But, hey, it's OOP!
Goooood Monday Morning MPJ!!
One of the important concepts I've been waiting for and is as-usual fun and good!!
Love your videos!! Regarding not using libraries like "axios" - well I guess people who worked with web applications before whole this "npm" wave were used to jQuery dealing with browser implementation nuisances. And, though I haven't used "axios" myself yet, I kind of assume, that if I use it, I will never have to deal with browser specific issues. Also - you mention using "internal function" to make requests. I think having internal wrapper is actually a bad idea if there's team of more than one. If you are going to use a wrapper, use external, well tested and well documented one. But I 100% agree, that doing a wrapper on top of a library is probably the worst way. As you say the order of preference is: Raw Function > 3rd party wrapper > internal wrapper > internal wrapper on 3rd party library.
I love the way you explain things.
+Junkyards Would Be Graveyards thanks!!!
Hello!
I've watched your videos for a while, and they're generally both interesting and educational. This one was especially good. Thank you for the effort you're putting in!
I dislike one thing about this video: you're contributing to people thinking complexity is the same thing as complicatedness. If you'd like to keep it simple, I suggest sticking to one and ignoring the other. Your examples seemed to be about complicatedness.
Hope you keep making these videos!
Stay safe,
Teodor
+Teodor Heggelund hey theodor, you talk about these words like they have firm definitions somewhere, which they don't. I have NO idea what complicatedness is and how it differs from complexity.
+funfunfunction in theory I subscribe to rich hickeys definition of complecting/complexity/simple/easy definitions that he talks about in "simple made easy" but I find it super hard to use that terminology in practice when talking.
That's a great talk.
I'd love to hear what you think about ClojureScript some time. But I'm afraid it would end up like your (excellent) videos on Haskell, not easy enough to get many viewers.
If you try to do abstraction in C++, you'll end up making over 9000 levels of depth of templates!
I remember an abstraction in a C++ lib that meant you defined a template class, which inherited from another template class. Then you defined three member classes inside your class there - which the parent template class would then inherit from!
The keywords you called abstraction, especially in programming, I do call them as 'Blackbox' because it works beyond my understanding :)
I have an idea for a video (series).
I personally would find it really interesting to view the source code of something you have written (preferably a semi-serious web application). I have been looking at your Github but could not find anything with a larger code base (such as an app).
So, I would like to see a series, of maybe 30-min episodes where you code something up, maybe comment on some of the things that you do and in some cases refer to previous videos. So that one could not only follow along during the coding process but also later view the code at for example Github.
This would be really interesting to me =)
+Johan Gudmundsson yeah, many people have suggested this. It's really tricky though, even a simple application is hundreds of hours of work, and not exactly neat 30 minute episodes with pedagogical illustrations. The format is tricky. I know the need to see a cohesive picture of these things, but I'm not quite sure how to deliver it.
I feel a lot of new programmers (especially students) tend to jump on buzzwords like Axios because they hear it from middle or senior programmers and feel they need/should to use it. Sometimes they miss the reason of using something simpler or less featured like Fetch to do something simple. The hype gets in the way 😕 and they end up building a bloated app. In some ways the hype that surrounds frameworks and libraries is much like other cultural bandwagons outside of programming depending on the person.
Next video: "How to make non-leaky abstractions". or something of that kind please.
That's a big, hard question, not readily answerable on UA-cam. I'd recommend taking a master's degree or better in computer science, then ten or more years of experience building software...
A few principles I keep close to heart, are SRP and DRY.
SRP is the Single Responsibility Principle. I am happiest with a piece of code if it does _one_ thing, and does it well. In other words, it has a single responsibility.
DRY is Don't Repeat Yourself. It combines well with SRP, since if you need the same piece of code in more than one place, you probably need to package it for reuse instead of writing it again.
My technique is:
"Wait for at least 3 duplications before making abstraction"
From my personal experience, I found that making abstraction immediately after you found duplication will mostly leads to leaky and wrong abstraction. The pattern is not fully aware yet but programmer (including me) will always have an urge to abstract the duplication. At this point I have to assume a lot about which concept can encapsulate duplication nicely, and mostly the assumption will be a lot better if I wait for third duplication.
Dealing with 2 duplications is much easier than dealing with wrong abstraction.
Chakrit is bang on!
Chakrit Likitkhajorn True. A few factors that come in to play though: 1 You might foresee that you will need the duplicated code before you have used it more than two times. If you write som kind of code related to 2d/3d objects, you will probably put your code for finding the distance between to points in a function right away. (Unless you have that formula in some library to begin with) 2: Will writing a general function be a complex pice of work? Or will it simply be copying a piece of code into a new function? (I would gladly copy 5 lines of code into a function, even if I only used it twice throughout my code. Well, unless I had to make some complicated structure to map my arguments and such.) Or maybe something in between? 3: How much code is each duplication? If you in som form or manner calculate what can be abstracted to A+B*C seven times in your script, is it any good abstracting this away with a function? The ApBtC function might just confuse stuff. As MPJ said: it can be a complicated topic.
Great explanation of leaky abstractions!
Probably I haven't been listening carefully enough but I didn't get the idea. I got that things with simple interface is good.. Sort of like Unix gnu tools..
But I didn't get why if a library throws an error on http it's now a leaky abstraction? Just because it handles something differently?
Doesn't sha1 trow an error in case of invalid params? I'm not arguing that leaky abstraction is somehow mythical but it's hard to me to get the point.
Because they assume that http error should be encapsulate with javascript error.
And most cases, it should not.
Javascript error such as "undefined is not a function" and http error should be handle very differently. But axios just automatically transform the network error into javascript error. Therefore in many cases, developer need to separate these 2 kinds of error once again in "catch" block.
If sha1 throw an error, I will handle it along the line of "null is not a function". Because it means that basically something is seriously wrong along the programming logic. Maybe someone forget to assert something. It is "unintended" error.
But many times http error is "intended error", which happen because of user, not the programming itself.
I'm not an Axios user any more, but my feeling is that Axios throwing and Fetch not throwing are simply the assumptions their authors have made about what a user expects to happen when server error responses happen, and not a case of leakiness:
I faced the exact same API situation as you and I had the same reaction but in reverse when I moved from Axios to Fetch and I still find it really odd that Fetch doesn't reject on 500-errors. I actually felt it was a case of over-abstraction -- smoothing-over basic flow logic and requiring more lines of logic to sort out normal responses from problematic ones. But I see now how you could see it the other way. In any case, I don't consider Axios leaky because of this.
That said, the fact that Axios returns a native Error object, rather than their own error-state object does strike me as hugely impure (in fact most FP programmers I know think throwing at all is fundamentally impure), so it does not surprise me that you prefer Fetch over Axios because of this.
I learned something new, thank you!
great video. I enjoyed it and learned something valuable. thanks!!
Great video as always mpj!
Have been watching your videos for a week now. You have an absolutely lovely insights about "things" and general concepts. I'v heard you were working at Spotify. I'm the"CTO" & founder of a 5 years french startup (360medics) and i'd have questions about tech team organization and management that i'd love to ask you about (we just finished our 2nd fund raising and are currently growing/organizing). Any chance we could discuss a few difficulties we stumble upon / compare with your own experience in the companies you worked at ?
+Public Domain Movies drop me an email at mpj AT iteam DOT se
Tks ! We'll do
Would you consider redux a leaky abstraction? My thoughts are these. It claims to solve a lot of problems and because it is small it can easily be implemented and used and the abstraction seems legit, use flux as your pattern and only action can mutate state, easy enough, but as you said this is not always the case so you now need to start unraveling all the libs added to redux inorder to make it do what you want. Thus the abstraction sounded simple and seems to be adding benefit but as soon as the use case starts getting complictated it could potentially force a complete rebuilt or some other costly affair... thanks for great show.
thank you mpj for all your great videos, but i really want to know, how do you document your code?, do you use a specific tool?, or you just use comments in the code?, i really have problems with this topic, we used to work with the program case complete, but i want to know what everyone else is using.
+Luis Villamil Santa Cruz great idea for an episode!
I love this channel!
I think one of the biggest leaky abstraction is the web form.
I've been thinking about this a lot lately. I've fallen into this habit of chasing the general case too much. What I'm really chasing is simplicity, but in most cases it makes things incomprehensibly complex. Using generic code is simple, but writing it is not!
Also, crucially, 'simple' is not the same as 'easy'. And library development is neither. :-)
Very true. Rich Hickey gave a great talk a while ago on the difference between 'simple' and 'easy':
www.infoq.com/presentations/Simple-Made-Easy
Mike Talbot - Thanks for that link! Very helpful! Exactly the kind of ideas I've been circling around lately. OOP and the whole 'culture' that comes with that has my head spinning. I'm looking to simplify my process, big time.
+Gert Sønderby this!
Like for me Ruby on Rails is anything but simple, it's probably the most poorly designed major framework ever. It's nearly impossible to know what happened where and why. Rails used Dry to the extreme where a single line executes thousands of callbacks changing the whole apps global state. To me implicitly inheriting methods and propeerties from a cobbled web of classes sucks.
In programming abstractions are almost always leaky particularly in imperative languages. One size does not fit all. People should stop using Javascript frameworks completely all together because they create more problems than they solve. They all have a learning curve, leaky abstraction, bugs and they all stifle our creativity one way or the other. Programming was so much easier before the nodejs and the responsive design era even if we did not have great tools we have today.
How about MongoDB vs Mongoose ODM? I feel like I have been through some bad experience when I was using Mongoose, as a newbie, not sure if it will be much more simple if I choose the pure MongoDB path.
Great video. Can we take this one level up and say that a good framework should be a non leaky abstraction of common patterns to solve a particular set of common problems ? I often find myself digging in AngularJS code to understand what the heck is going on. Shouldn't we design frameworks with similar attitude in mind that ideally doesn't require me as programmer to worry about internals of given framework ?
Hey MPJ, what is your opinion on MOOCs and other online learning paths such as Free Code Camp?
Do these videos help MPJ get a job or do they just inform his future employer that every Monday morning he's ill or hungover?
Love the videos anyway mate!
Excellent video as always! Do you plan on doing a video about Rx anytime soon? I know they use RxJava for Spotify Android (I don't know if you guys also use RxJs for web or client), and I'd really like hearing about any shortcuts to learning to be productive with Rx, e.g., recurring patterns, how to get over main pain points, basic gotchas, etc. Thank you again!
+Eloi Simard Quesnel I'm not personally a big fan of Rx. The surface area of the thing is ludicrous and the observable pattern is really dubious when you spread them out all over your app instead of using it in a simple and structured form like it's done in Redux. You probably won't see an Rx episode from me, but possibly one that critisizes the observable pattern. ;)
It's really funny that you mention the use of Rx in Redux as I'm currently trying out redux-observable to handle side effects in a project, and my questions about Rx were mainly aimed towards using the library in this exact scope! I didn't learn Rx on its own so I'm ending up spending a lot of times debugging simple observer -> operator chains. Luckily this is only a side project so I can afford the overhead of learning Rx on the job. Anyways, I'm looking forward to that video! :3
redux-observable is SO weird to me. Observable is a performance optimisation pattern that you use in cases where it would be to expensive to re-render on every frame. With React/Redux, you don't have to bother with that because React takes care of the DOM diffing (or in the mapStateToProps thing in react-redux). Isn't the whole idea of Redux is to get rid of observables?
Yes of course! Redux-observable is only a midleware that wraps the dispatching of actions so you can observe your actions as they stream through your store, and expressively declare some side effects depending on the action type! It has nothing to do with rendering, it only observes what actions are dispatched.
So let's say you have a text input which dispatches an update_input action on keydown and you want to do some type of api call as he types to try and guess what the user wants. With redux-observable you can decide to take any action of type update_input from the action observer, throttle them by some X amount of time in order to prevent making a call on every keydown event, make the api call, cancel it if new values come in, and return a new action that could be like show_input_options that ultimately modifies your store and updates the UI.
This is not using the observable pattern to do any rendering logic, it is more to handle async /side-effect actions. Your actions + reducers, like always, end up triggering the renders.
5:00 why??? internal server error... "it is what it is"
6:00 err?? binary continue.. "because I said so"
3:00 os? stop. "so what"
How many days are in a year if 60 seconds are in one minimum????
JS Objects are a leaky abstraction:
var x = new Boolean(false);
if (x) {
// this code is executed
}
I did not know that. Totally unexpected:
- the use of `new Boolean(false)` instead of `false`
- the code is executed
Will because Javascript is the language designed in about a week.
Hey MPJ just asking out of curiousity(and because i someday want to start a channel myself) do you script your content?
+ReaperPlayzLeague I talk about this in the behind the scenes video!
Is there any way to pair program with you?
I have never "istnalled" anything
What's the difference between a leaky abstraction and a highly configurable abstraction?
It seems both require more than a glancing knowledge of the API.
+Noah Namey Noah, this was a really interesting question. I asked people at work, and one insight was that a highly configurable abstraction indicates that you don't need the abstraction. You would probably be better off not using the abstraction at all if you need lots of configuration.
funfunfunction I guess my next question, is where do you draw the line? Surely Angular, or Express are abstractions that can take quite a bit of configuration. So I wonder if the concept of "leaky" is relative.
+Noah Namey oh those are definitely leaky as hell.
funfunfunction So "leaky" is something to be aware of, not necessarily something to be avoided... ? Ehh... I think I'm drifting into pedantic PITA territory ;-)
+Noah Namey exactly. Well, ideally we wouldn't want leaky abstractions but we don't live in a perfect world.
I like your videos, but I think it would be um, kindof good to sometime to increase the complexity of the topics. Like how to use libchromiumcontent and brightray to make a simple something. or like i don't know something that is not easy.
+Alex Day maybe (although your suggestion sounds extremely specific rather than hard). Can you talk a bit about your background? the target audience of the videos are developers that are about one year into their first job.
Firstly I want to apologise if I sounded specific, (that thing I specified was what I had in my mind at that point, I could say like I want to know what I don't know, because how can you tell).
I am a web developer, I have been doing rails and javascript and now a bit of rust (thanks to you, for bringing that up in one of your videos), and I have been doing that for like 4 5 years now,, 2 years industry experience and 3 years of experience that the industry doesn't care :P .
I just thought it would be good sometimes to do a little hard videos like you do unusual ones like haskell, that was of-course I didn't realize the target audience.
Hey Alex! It's really cool to have you following the channel. That said, I think that you are probably a little past the skill level I am targeting. I am planning to do some videos on data structures and patterns in the future, you might glean some from that. But that said, I think that you are at a point where you should start teaching yourself. ;)
+funfunfunction :) oh thats cool. will wait for those. :))
have you talked about meta programming in JS?
+Adam Crockett nope! That's indeed an interesting episode idea!
funfunfunction I think it's not well known and incredibly powerfull, sometime dangerous, here's a pen addressing proxies that you might enjoy, is it good practice who could say. codepen.io
define nonce
***** in the UK nonce means a sex offender so I'm not really following you..
That would be something I want to watch :)
Nonce defined: E56988534F7F817945F7CEE5CABCB
The shiny side of your lamp looks like a knife that' aiming at you and it irritates me. Still love your videos.
Thanks for your feedback on my apartment two years back, I'll go right back and fix that! :)
Awesome!
4:01
is it a joke? But you showed "npm istnall sha1" but should be "npm install sha1".
Thanks for great videos.
Andrii Mutylo npm has a famous alias isntall -> install
Thanks I did'n know that.
OMG that was so awkward! the alias 'unisntal'l should be created!! So funny and useful!
If only CSS had the alias 'dipslay'
4:03
npm isntall xD
So React.js is a leaky abstraction. Don't use it!
+Ян Такушевич Again, the advice is not to avoid leaky abstraction. That would be unrealistic advice. The point of the video is to be aware of the leak and the cost it brings with it.
I had the same thought and came to this conclusion.. thanks to so other vids from mpj. The first abstraction of web 2.0 was splitting css js and html into seperate files which enables you see clearly how each is composed. But this showed its flaws only later where our apps became hard to understand because the logic can touch all of the above parts and keeping trwck of them became a mess.. thus we wher wrong about the initial abstraction. Frameworks attempts to rectify this with isolating css html and js into components where they can live as theyre own entities. This solves many issues and we ican deduce that the abstraction now looks more like what a framework would propose. Thus leaky abstractions was prevailent in version 1 css html and js seperate , butooking at the problems we face with frameworks that too is a leaky abstraction...
That said the problem is not if a abstraction is leaky but in the conceptualising of the abstraction, the more complex the more leaks. I think a good framework in this senario atttempts to make those leaks less, like the application of react hooks. Which is in itself a leaky abstraction but in a easy to understand way that makes it possible for the developer to mitigate those leaks better.