lol the chat ate him alive for getting the first question wrong, meanwhile 80% of JS devs would also get it wrong.... the "senior netflix engineer btw" in the chat was gold lol
That question is the equivalent of "you drive a car? Name all the assembly plants where all the parts in your car were manufactured". Obviously you don't need to know that if you just want to drive a car. Unless that's why I still can't pass my driving exam...
@@ThePrimeTimeagen But ask yourself; why would you ever care about the value _after_ an iterator is already done, unless you manually handled the iteration?
"return" in generators is perfectly ok and I'd say a must: there are ton of problems where you want to early stop a generator. The issue is with "return " which is... odd.. at least.. A generator should yield values, and [eventually] end (return), it's not expected to return values. (btw, C# "solved" the ambiguity using "yield return " and "yield break" instead of reusing an existing keyword)
25:49 I think prime is wrong here. I am pretty sure that this is how generator functions work in almost every language. Remember that the end of the function has an implicit empty return. If returned values in generators were also included in the iteration, then this generator function* whatever() { for (const elem of ["fist", "second", "last"]) { yield elem } } would produce "first", "second", "last", undefined and to get the obviously intended results of "first", "second", "last" you would have to do something like function* whatever() { for (const elem of ["fist", "second", "last"]) { if (elem === "last") { return elem } else { yield elem } } } which is just ridiculously stupid
I remember the days when EcmaScript didn't even have proper classes. Back in my day, we used functions named in PascalCase and then prefaced calls to them with the "new" keyword.
The so called and sometimes taught nowadays as "factory functions". Dude I had a huge clarifying moment last week when I finally decided to dive deep in understanding prototyping, inheritance and composition. Everything made sense afterwards, it was kinda of a cascade effect in my mind. But now I realize that javascript isn't well designed as some other languages.
@@jmfariasdev It's just another thing that can be done well or poorly. Like anything else, it is a matter of learning from prior examples and then finding new ways to put ideas together.
I started with VBS yeah, but after leanring a little bit (which was a lot for a 12yo) but the first real one was js? but not to well, and the first really learnt was python
This was fun! IIFE - Immediately invoked function expression. I've heard it pronounced 'iffy' most of the time. 11:49 - I've definitely modified a few built-in prototypes in order to get Vue2 to work in an HTML Application / .hta file. mshta.exe uses an ancient JavaScript engine, so some monkey patching was absolutely required to get things to work at all.
@24:18 In the example there's an output in the middle with comment on the right "// [1, 2, 3]" without "4" so the return statement is not returning a value (which sounds silly). I heard about generators, never used them, forgot about them but here I was right (because of the example). :-)
Extra info about question 1. The prints for 4, 5 and 6 are sync in the javascript engine while 1 is queued in the engine. 5 is not implemented in the engine (not ecmascript) but still queues on the engines task queue. The setTimeout callback is added to the runtimes event loop and would not work at all in a pure javascript engine evaluation (it is a webAPI that requires a runtime). Writing my own super basic javascript runtime in C was great for learning how javascript runtimes work.
Here's a hot take: HOW OFTEN in your day-to-day work do you need to know in which order these will execute? I mean, yes, you need to know there IS an event loop, and that there are certain steps within that loop that execute in a certain order, but how often do you need to KNOW THE EXACT order, or even ALL of the steps that execute within an event loop cycle? I mean, in the rare event that you do need to debug these (and that's when you run into a mix of setTimeout(..., 0) and setImmediate and Promise.resolve()), it shouldn't be that hard to google it out? Seriously, questions like that remind me of a meme about the Mendeleev's periodic table of elements, which he created specifically so that chemists DIDN'T need to memorize all the data about the elements, and then you get school teachers who FORCE the students to memorize it... -_-
You know what would be interesting? A replay iterator that aside from next, return and throw also has a reset function. That way you don't have to keep a reference around to the original generator function. You can just reuse the current iterator. One that could also have niche usecases would be the caching replay iterator that, when reset, it doesn't have to recompute the original values, since it would have stored those values in a cache. That does defeat the purpose of generators somewhat, since they normally allow for a low memory footprint during iteration, but when caching you do still have that footprint. In such a case the only benefit would be is that you're fetching the values lazily, so you don't have to construct a full list of values before iterating over them.
Man I'm glad I don't have to do JS professionally anymore. My guesses were: 4, 5, 6, 2, 3, 1; A: true, B: false, C: true, D: (hesitated) true, E: true; (so same as prime); I hesitated and picked E The explanations by Lydia were awesome by the way, I was skeptical at first expecting a wikihow-level video
Regarding the second question - not everything outside of constructor is added to the prototype, only method declarations. Try defining any property like class A{ myarrow = () => 1 myprop = {} myfunc = function(){} mymethod(){} // this will be on prototype } they're gonna be different for each instance. this is pretty obvious for objects and arrow functions especially - would be wild if that object was shared and how would this binding even work on each instance if it's shared?
The worst part about the generator one: when you have yield 1; yield 2; return 3; you actually get it.next(); //1 it.next(); //2 it.next(); //3 but when you do [...it]; //1, 2 it.next() // undefined Why does one go to 3 and the other one only to 2? Guess it still calls next() again, doesn't yield but returns, so it is done and the 3 disappears into thin air? Weird... either return (different from undefined) should not be allowed or it should behave the same way... 🤷♂
Got the first one right! The first three all delay it by one tick, the second three all do it immediately. As such you get the immediate ones in order, then the delayed ones in order.
The iterator example has the same behavior in Python. If you return a value from a Python generator that value is part of the StopIteration error. There's also a similarity in Go's channels; each read from a channel gives back a value and a bool that says whether the channel is still open. When you range a Go channel it returns a 0, false and the false breaks the loop.
I dont have much JS experience and async will always be my bane in any language possible, therefore i failed the first miserably. The second was actually simple, just know what points where. Third I only knew because That's what she said! She already shown it and I'll refuse to accept it as logical.
A coding language is just like a spoken language - go with the flow and learn and use what's necessary and useful in your situation but you don't have to learn complete dictionaries or grammar books which makes you a bit better but it's not worth the effort - you soon forget all that you don't use in real world! That's why you have to repeat vocabulary a lot when you want to learn efficiently. Save yourself time and get started with real problems you want to solve - one after another! That's how you get better in coding!
It's not specified by spec, but some browsers/engines will add additional random time to the timeouts to mitigate Spectre attacks. Though, this can be disabled and it's not an important part of the question itself.
@@blenderpanzi It's not important to the question, because its a general question about the expected behaviour, given that you know the spec; not the internal workings of specific browsers and the random value that determines the timeout.
oO i went completly overboardwith the contructor analysis : thinking stuff like: but once its instantiated it may be bound to the new this object or whatever :D
Even with optionals a generator function could not simply return “nil” when it’s done because generators can yield undefined, null and a hypothetical Optional.nil value.
The last one is weird in the sense that manually calling count() will give you all 3 values. Only when value === 3, done === true. Which is not consistent with using [...it] or for of. It's the inconsistency that is the problem. Manually calling next() respects the return value, while using the other 2 methods does not.
the first question. setTimeout with 0 responds differently in every browser when used in combination with promises. Well I can remember it was IE that did it different from the other browsers.
Generator work the same way in PHP except that in PHP you can get the return value if you want by calling a specific method. I don't know how it work in other languages
As someone who barely knows JavaScript (straight up because I never use it), I learned a few things: 1. There are multiple event queues (microtasks and macrotasks). Why? No idea, but they exists. 2. That you should only use 'return' when using generators in JavaScript because of the way they work.
What's the point of having instance methods on the prototype if there are static methods (on the class). I don't get what's the difference here. I thought like every array would spawn with it's own copy of push().
Here is another test. The key question is "does 3 resolve before 2?". (result in reply): console.log(1) setTimeout(() => { console.log(2) }, 1); //SomeLongFunction let a = 0; for(let i = 0; i < 1_000_000_000; i++){ a += 1; } setTimeout(() => { console.log(3) }, 0); //SomeLongFunction let b = 0; for(let i = 0; i < 1_000_000_000; i++){ b += 1; } console.log(4)
I remember the require('bluebird') times, I still failed the test. Somehow, a new stack has emerged (micro/macro) from my POV, with the chat even saying animation queue too ? I think spending so much time and energy delivering and learning tools, services, devops etc etc... makes us not having time to even learn that much of the language :x
I''ve used generators for writing scripts. I needed to fetch all pages from OKTA and on every page perform some actions. Generator was a clean way on performing that. Obviously I could put it inside a loop but c'mon, I am a functional BRO
Haven't been playing with JS for a long, long time... I see it now has generators and a semi-decent event loop, glad it picked up some cues from more competent languages, like Python. *_*hides*_*
I haven't modified the prototype exactly like this, but I just slapped a method onto a Map. Like const myMap = new Map(); myMap.sillyFunction = () => { return "do silly things" };
Looks like a taxonomic evolutionary hierarchy. If this is the case, Wolf should extend Canine and Dog should extend Wolf. Although I would not build a class hierarchy like this in code. It’s too brittle. What if we discover at some point that dogs don’t descend from Wolves but some other canine ancestor?
Even more hilarious is that generator "functions" (a terrible name to call an object with shared mutable state) were added to ECMA in 2015. So there is no excuse of this being tossed into JS at its creation as a trivial web scripting language that was never intended to support programming at the scale it is now. Someone thinks this is a cool language feature.
I think it's a good decision for the value when done to not be handled by the for of loop, but I wished there was syntax to actually handle the done value at the end, something like a finally block with an argument: ``` for (const value of generator()) { console.log(value); } finally (finalValue) { console.log(finalValue) } ```
Just tried a few generator function, or better Iterators . Why would you return a value from Iterators. Adding a "return" value looks like a bad practice, since it confused even a senior.
JavaScript is like English (as a second language) to me. I can use it perfectly fine with what I have learned even if I haven't learned everything there is to learn.
The key is in “ value of” count. But this is good 😊! And it was fun 🤩! Who doesn’t love ❤️ pop quizzes and that too in JS! Lol 😂. Thank you Lydia & Prime! It.close() lol 😂!! - Amy
I'm confused. If you create a promise and do nothing else, the provided function will not run? (5) So, a promise is not lazy/deferred? Wow! And people say Java is bad LOL!
About question 1, we hired a guy once that wrote code like that with resolves, classes, pipes and stuff like that there. I removed all those stupid tools with procedural js and the programm worked 12 times faster. Instead of taking 2 minutes to create the same content it now takes 10 seconds. So I consider using that stuff bad practice and honestly very bad coding. I understand that it should help you with bigger programs. But if you program gets 12 times slower because of crap like that it's a dead end. I come from game developement and crap non game "master" programmers use would never fly on my board,
lol the chat ate him alive for getting the first question wrong, meanwhile 80% of JS devs would also get it wrong.... the "senior netflix engineer btw" in the chat was gold lol
I'm glad he got it wrong. I feel better about getting it wrong too.
That question is the equivalent of "you drive a car? Name all the assembly plants where all the parts in your car were manufactured". Obviously you don't need to know that if you just want to drive a car. Unless that's why I still can't pass my driving exam...
The order question is stupid, if your code relies on that this order is maintained in order to work, your code is wrong. No wander not many know it.
80%? lol my bet is more than 95%
I don't think 80% of JS devs understood any of them
Every time I start to think I know javascript, I watch videos like this and realize how wrong I am
As a non-JS dev, reading this is horribly confusing; I'm glad I don't have to deal with this.
As someone who grew up with jQuery, I am screaming
@@KeremyJato there are 3 languages I hate, PHP, Java, and JavaScript. I can tolerate the last one, but it is mostly Hate Driven Development
Me too, and then I realize I just mess with it until it does what I expect it to do.
If it was just interpreted at runtime that would be one thing. The fact that you have to interpret whether it's a pointer or not is insane.
Things I learned from this:
- Promise callbacks are microtasks, not tasks
- "return" in generators is valid
return emotionally hurt me
@@ThePrimeTimeagen But ask yourself; why would you ever care about the value _after_ an iterator is already done, unless you manually handled the iteration?
"return" in generators is perfectly ok and I'd say a must: there are ton of problems where you want to early stop a generator. The issue is with "return " which is... odd.. at least.. A generator should yield values, and [eventually] end (return), it's not expected to return values.
(btw, C# "solved" the ambiguity using "yield return " and "yield break" instead of reusing an existing keyword)
@@IMJambyyield break sounds like a nicer syntax than return.
@@IMJamby stop early you say? sounds like an exception to me -- python
25:49 I think prime is wrong here. I am pretty sure that this is how generator functions work in almost every language. Remember that the end of the function has an implicit empty return. If returned values in generators were also included in the iteration, then this generator
function* whatever() {
for (const elem of ["fist", "second", "last"]) {
yield elem
}
}
would produce "first", "second", "last", undefined and to get the obviously intended results of "first", "second", "last" you would have to do something like
function* whatever() {
for (const elem of ["fist", "second", "last"]) {
if (elem === "last") {
return elem
} else {
yield elem
}
}
}
which is just ridiculously stupid
var ass = new Promise(() => whatever.next()).await //gachiHYPER
Comment above says it all 👌
Lua Coroutines don't do this. You would have to
function whatever()
coroutine.yield(1)
coroutine.yield(2)
return 3
end
or handle the final `nil`.
I remember the days when EcmaScript didn't even have proper classes. Back in my day, we used functions named in PascalCase and then prefaced calls to them with the "new" keyword.
The so called and sometimes taught nowadays as "factory functions". Dude I had a huge clarifying moment last week when I finally decided to dive deep in understanding prototyping, inheritance and composition. Everything made sense afterwards, it was kinda of a cascade effect in my mind. But now I realize that javascript isn't well designed as some other languages.
@@jmfariasdev the inventor of JavaScript made it in just over a week iirc.
@k98killer people that architects and design programming languages are in another level that's for sure.
@@jmfariasdev It's just another thing that can be done well or poorly. Like anything else, it is a matter of learning from prior examples and then finding new ways to put ideas together.
Ok thats it! Im taking javascrip proficiency out of my CV. thanks!
More of these, that was fun!
God, I was laughing so hard when he was wrong in the last question 😂
20:20 javascript does have Option, it's constructor for html element
GOTO considered harmful
JS considered deadly and dangerous
"you don't know javascript"
i know, i wanna keep it that way
Don't hate a language you aren't good at, it's fashionable to hate on JavaScript but it's a very powerful language when used properly
Maybe I should learn Blazor & just run C# in the browser instead.
Bingo
Yes
I actually switched smoothly from watching Anchorman 2 to Prime. The legend continues.
Every day I thank the lord for not learning Javascript as my first language (visual basic chads rise up)
Commodore Basic V2
python (normie first language but at least it's not js)
You and me both..!
I hate .js and all the (copy-paste integraded) JS into other New ones.
Creates a web of a
mess and slow af code.
I started with VBS yeah, but after leanring a little bit (which was a lot for a 12yo)
but the first real one was js? but not to well, and the first really learnt was python
same garbage @@ゾカリクゾ
This was fun!
IIFE - Immediately invoked function expression. I've heard it pronounced 'iffy' most of the time.
11:49 - I've definitely modified a few built-in prototypes in order to get Vue2 to work in an HTML Application / .hta file. mshta.exe uses an ancient JavaScript engine, so some monkey patching was absolutely required to get things to work at all.
Lydia's slides are beautifully mind-blowing, does anyone know what she uses to make them?
Probably a computer 🤓💻
she use keynote ( i hear her answering your question once)
Senior dev vs junior interview questions
@24:18 In the example there's an output in the middle with comment on the right "// [1, 2, 3]" without "4" so the return statement is not returning a value (which sounds silly). I heard about generators, never used them, forgot about them but here I was right (because of the example). :-)
JavaScript is like government bureaucracy: everybody depends on it, but nobody really understands it.
my_obj.__proto__ = "We're all adults here, I can modify whatever I want"
Extra info about question 1. The prints for 4, 5 and 6 are sync in the javascript engine while 1 is queued in the engine. 5 is not implemented in the engine (not ecmascript) but still queues on the engines task queue. The setTimeout callback is added to the runtimes event loop and would not work at all in a pure javascript engine evaluation (it is a webAPI that requires a runtime). Writing my own super basic javascript runtime in C was great for learning how javascript runtimes work.
Javascript has an exponential learning curve
22:46 prime liking for await makes so much sense when you consider that he used to work with a lot of rxjs
1:35 I work with JS almost daily and I don't know what's the right order
If I was working with a codebase where knowing that order is necessary to maintain or debug it, I'd seriously reconsider my life choices.
Here's a hot take: HOW OFTEN in your day-to-day work do you need to know in which order these will execute? I mean, yes, you need to know there IS an event loop, and that there are certain steps within that loop that execute in a certain order, but how often do you need to KNOW THE EXACT order, or even ALL of the steps that execute within an event loop cycle? I mean, in the rare event that you do need to debug these (and that's when you run into a mix of setTimeout(..., 0) and setImmediate and Promise.resolve()), it shouldn't be that hard to google it out?
Seriously, questions like that remind me of a meme about the Mendeleev's periodic table of elements, which he created specifically so that chemists DIDN'T need to memorize all the data about the elements, and then you get school teachers who FORCE the students to memorize it... -_-
You know what would be interesting? A replay iterator that aside from next, return and throw also has a reset function. That way you don't have to keep a reference around to the original generator function. You can just reuse the current iterator. One that could also have niche usecases would be the caching replay iterator that, when reset, it doesn't have to recompute the original values, since it would have stored those values in a cache. That does defeat the purpose of generators somewhat, since they normally allow for a low memory footprint during iteration, but when caching you do still have that footprint. In such a case the only benefit would be is that you're fetching the values lazily, so you don't have to construct a full list of values before iterating over them.
1:56 - looking at this, tells me: JS, you're drunk. Go home!
Man I'm glad I don't have to do JS professionally anymore. My guesses were: 4, 5, 6, 2, 3, 1; A: true, B: false, C: true, D: (hesitated) true, E: true; (so same as prime); I hesitated and picked E
The explanations by Lydia were awesome by the way, I was skeptical at first expecting a wikihow-level video
Regarding the second question - not everything outside of constructor is added to the prototype, only method declarations.
Try defining any property like
class A{
myarrow = () => 1
myprop = {}
myfunc = function(){}
mymethod(){} // this will be on prototype
}
they're gonna be different for each instance. this is pretty obvious for objects and arrow functions especially - would be wild if that object was shared and how would this binding even work on each instance if it's shared?
It just wouldn't have a bound this simple
The worst part about the generator one:
when you have yield 1; yield 2; return 3; you actually get
it.next(); //1
it.next(); //2
it.next(); //3
but when you do
[...it]; //1, 2
it.next() // undefined
Why does one go to 3 and the other one only to 2? Guess it still calls next() again, doesn't yield but returns, so it is done and the 3 disappears into thin air? Weird... either return (different from undefined) should not be allowed or it should behave the same way... 🤷♂
Got the first one right! The first three all delay it by one tick, the second three all do it immediately. As such you get the immediate ones in order, then the delayed ones in order.
The iterator example has the same behavior in Python. If you return a value from a Python generator that value is part of the StopIteration error.
There's also a similarity in Go's channels; each read from a channel gives back a value and a bool that says whether the channel is still open. When you range a Go channel it returns a 0, false and the false breaks the loop.
I dont have much JS experience and async will always be my bane in any language possible, therefore i failed the first miserably.
The second was actually simple, just know what points where.
Third I only knew because That's what she said! She already shown it and I'll refuse to accept it as logical.
you pretty much had my thought process on 2 and 3
2 easy
3 i know she said it, but i refuse to believe it
Feeling less alone with my skill issues
A coding language is just like a spoken language - go with the flow and learn and use what's necessary and useful in your situation but you don't have to learn complete dictionaries or grammar books which makes you a bit better but it's not worth the effort - you soon forget all that you don't use in real world! That's why you have to repeat vocabulary a lot when you want to learn efficiently. Save yourself time and get started with real problems you want to solve - one after another! That's how you get better in coding!
AFAIK there's no setTimeout() of 0 ms, it's rounded up to 50 or something. For security reasons or something.
It's not specified by spec, but some browsers/engines will add additional random time to the timeouts to mitigate Spectre attacks. Though, this can be disabled and it's not an important part of the question itself.
@@dealloc Well, I guess anything >6 will make it last out if those no matter what.
@@blenderpanzi It's not important to the question, because its a general question about the expected behaviour, given that you know the spec; not the internal workings of specific browsers and the random value that determines the timeout.
Thank god I write C
Finally, a safe language.
wish I could find a job in C
Rust us rusty though!
Because C has no footguns at all
@@spicybaguette7706 it does, but they are much more reasonable
all for loops initialize from outside(where the counter starts) and iterate on the inside, similar to slicing :: ``` include:exclude
```
You know it gonna be a nice spicy react when the video is nearly 3x the size of the original video 😩👌🔥
"Hi, I'm Lydia"
Prime: ~pause video~ "I really want"
oO i went completly overboardwith the contructor analysis : thinking stuff like: but once its instantiated it may be bound to the new this object or whatever :D
Binding is done on the fly! That allows a lot more memory saving
Breathable interface ironically killed me XD
Even with optionals a generator function could not simply return “nil” when it’s done because generators can yield undefined, null and a hypothetical Optional.nil value.
"why is that valid? I don't know, that's just what happened in the 7-day cocain rage that was javascript's birthing." classic Prime.
The last one is weird in the sense that manually calling count() will give you all 3 values. Only when value === 3, done === true. Which is not consistent with using [...it] or for of. It's the inconsistency that is the problem. Manually calling next() respects the return value, while using the other 2 methods does not.
the first question. setTimeout with 0 responds differently in every browser when used in combination with promises. Well I can remember it was IE that did it different from the other browsers.
Generator work the same way in PHP except that in PHP you can get the return value if you want by calling a specific method. I don't know how it work in other languages
This Lydia didn't carry my burdens
I create massive amounts of Node code with async generator functions. Chain them together for cool on cruise control.
The first one is literally the same question I give to all folks on interviews lol.
Not being a JS/Node dev: is the order/behaviour specific to the V8, is it guaranteed that other engines would behave the same way?
Yes. It's by spec. If an engine does it differently, file a bug report!
You are correct, at least in the past. Previously it had different order in different browsers. Need to check how is it now.
Everyone: *JS is Awesome for coding!*
Me: *Can I kill it now?*
without strong understanding nature of promises - its pain in the ass) but its not so hard, just 1 day of digging helps me a lot
15:02 he became a Believer 💀
As someone who barely knows JavaScript (straight up because I never use it), I learned a few things:
1. There are multiple event queues (microtasks and macrotasks). Why? No idea, but they exists.
2. That you should only use 'return' when using generators in JavaScript because of the way they work.
It’s such a ghastly language. I’ve had to dive into it from time to time over the years, but do the minimum I need and get out.
@@nisonaticthanks for the explanation
and this smells more like a hack than an actual solution
its coming out as we speak
What's the point of having instance methods on the prototype if there are static methods (on the class). I don't get what's the difference here. I thought like every array would spawn with it's own copy of push().
This was pretty fun
it was humiliating
Here is another test. The key question is "does 3 resolve before 2?". (result in reply):
console.log(1)
setTimeout(() => {
console.log(2)
}, 1);
//SomeLongFunction
let a = 0;
for(let i = 0; i < 1_000_000_000; i++){
a += 1;
}
setTimeout(() => {
console.log(3)
}, 0);
//SomeLongFunction
let b = 0;
for(let i = 0; i < 1_000_000_000; i++){
b += 1;
}
console.log(4)
in chrome I get 1-4-3-2
I barely use promises and async... Glad I got one right for the first task.
javascript, i love it
Hyenas are actually part of the larger cat family not canines as odd as that seems looking at them.
Naming my class Prototype
I worked on code like q1 for 2 years. I don't understand still.
Generators are first class in v8 long before async/await arrived. For several years people were using generators to achieve async/await style code.
I remember the require('bluebird') times, I still failed the test. Somehow, a new stack has emerged (micro/macro) from my POV, with the chat even saying animation queue too ?
I think spending so much time and energy delivering and learning tools, services, devops etc etc... makes us not having time to even learn that much of the language :x
generators are great memory savers
I''ve used generators for writing scripts. I needed to fetch all pages from OKTA and on every page perform some actions. Generator was a clean way on performing that. Obviously I could put it inside a loop but c'mon, I am a functional BRO
You can't know JavaScript. JavaScript knows you.
please make more videos like this
Ohhh, so when you walk over a Map or Set they use generator functions. I always thought generator functions were kind of weird loops with no use case.
SetTimeout is put on the callback queue
Seeing that js doesn’t include the return value in the generator makes me prefer python’s exception-as-end generator model
Haven't been playing with JS for a long, long time... I see it now has generators and a semi-decent event loop, glad it picked up some cues from more competent languages, like Python. *_*hides*_*
Ever wondered how all this would look if IE vbscript won over Netscape javascript instead? :)
Lydia is so good at this!
I haven't modified the prototype exactly like this, but I just slapped a method onto a Map. Like const myMap = new Map(); myMap.sillyFunction = () => { return "do silly things" };
08:15 is a vulnerability waiting to happen
Looks like a taxonomic evolutionary hierarchy. If this is the case, Wolf should extend Canine and Dog should extend Wolf. Although I would not build a class hierarchy like this in code. It’s too brittle. What if we discover at some point that dogs don’t descend from Wolves but some other canine ancestor?
Sooo what if we discover dogs aren't canine? In a world of what ifs you won't get anything done
Modifying the prototype is like dropping acid.
Not for everyone.
Even more hilarious is that generator "functions" (a terrible name to call an object with shared mutable state) were added to ECMA in 2015. So there is no excuse of this being tossed into JS at its creation as a trivial web scripting language that was never intended to support programming at the scale it is now. Someone thinks this is a cool language feature.
Thought some drum and bass had started after a previous video…
Turns out you are always learning JavaScript, the learning is never done.
JS gigabrains flexing they can overcome any handicap. Back to easy C for me
I think it's a good decision for the value when done to not be handled by the for of loop, but I wished there was syntax to actually handle the done value at the end, something like a finally block with an argument:
```
for (const value of generator()) {
console.log(value);
} finally (finalValue) {
console.log(finalValue)
}
```
fun fact: the james webb space telescope runs on javascript.
"Fun"
Fcking hell....
How did we end up here.
Just tried a few generator function, or better Iterators .
Why would you return a value from Iterators.
Adding a "return" value looks like a bad practice, since it confused even a senior.
JavaScript is like English (as a second language) to me. I can use it perfectly fine with what I have learned even if I haven't learned everything there is to learn.
while (!generator.done) { console.log('i am cooking here')}
An opportunity to use 2 rare control structures - while and a generator.
People like her remind me how much I have left to learn
Question 2 D, the solution is right but the explanation is wrong. The prototype is Dog not Object, as you have two instances of the prototype Dog.
What's the name of the font she is using?
Anyone?
The key is in “ value of” count. But this is good 😊! And it was fun 🤩! Who doesn’t love ❤️ pop quizzes and that too in JS! Lol 😂. Thank you Lydia & Prime! It.close() lol 😂!! - Amy
Why do JavaScript have _two_ event queues?
don't get puzzled by the looks of setTimeout( ...whatever, 0) (emphasis on zero)
Zeroth.
I'm proud of you son
:(
I'm gonna stick to memorizing the ABC's. I"m up to Q and feeling confident.
Someone knows typescript + Appwrite (database) + Stripe? And wants to earn some quick money by helping?
I'm confused. If you create a promise and do nothing else, the provided function will not run? (5) So, a promise is not lazy/deferred? Wow! And people say Java is bad LOL!
I LOVE javascript.
About question 1, we hired a guy once that wrote code like that with resolves, classes, pipes and stuff like that there. I removed all those stupid tools with procedural js and the programm worked 12 times faster. Instead of taking 2 minutes to create the same content it now takes 10 seconds. So I consider using that stuff bad practice and honestly very bad coding. I understand that it should help you with bigger programs. But if you program gets 12 times slower because of crap like that it's a dead end. I come from game developement and crap non game "master" programmers use would never fly on my board,
I don't monkey patch, I Dogpatch.