It's interesting that javascript can be both functional and object oriented. I'd love to have more time to dig into the differences between the two paradigms and learn about which features of a given language are a hard-stop from using it in one style or another. I had no idea that built-in map() and reduce() functions are a feature of functional languages. This seems very familiar from Ruby. Javascript failing silently is an intimidating feature and we'll have to be extra vigilant about syntax and the rules that are in play. I found most if not all of this chapter interesting, although portions of the reading (notably some computer science terms) I didn't understand fully.
I do think the reading was valuable. It's a very short chapter but lays out something of a high level map/orientation for Javascript. I personally find it a great resource to later revisit and look into the different languages that influenced js.
I'm not exactly what it means that js is always deployed as source code, and what different js engines exist and why. This ties into my general lack of understanding about how js works outside the browser. That the js engines are able to fix some of the quirks adds to the bafflement.
This chapter had an amazing amount of content. There are so many nuances to javascript's prototypal inheritance and many quirks of the language itself to be aware of. bind apply and call made appearances yet again, they seem to be a staple for some of the more advanced usages in the language, as they are used in calling generic methods. I feel like throughout the readings and augmenting each one is a picture of javascript as a whole, deeply flawed but with bright clever hacky spots that are the product of developer's creativity in getting the desired behavior out of that flawed system. Again I'm aware of the transition that javascript is in the process of making towards sensibility and ameliorating the flaws of the language by borrowing familiar patterns from other languages and baking them into yet another layer of abstraction.
I appreciated the author's layout and presentation of the material in this chapter as four distinct layers, each of which utilizes the characteristics of the previous layers. This makes the material more approachable in the sense that you can start and struggle through the lower layers and work through the material progressively. It also seems that some of the conceptual leaps demanded by the reader of Eloquent Js are smoothed out with additional explanation and examples in this text, with the penalty of length.
I do think the reading is valuable. Again, I won't say that I was able to assimilate all of the concepts presented in this chapter but all the ideas have had contact with my mind and will be allowed to simmer on a backburner. I believe this will be helpful because the chapter shows a lot of what is possible in javascript and also shows beneficial bits about the pitfalls and best approaches with the reasons laid out. Javascript is a stranger creature than I had first imagined. I hope that if I encounter a use case that was presented it will trigger a little content alert in my brain and I'll be able to revisit the text for clarification.
I believe these readings and learning a second language in general is beneficial for highlighting the attributes of my 'first language' ruby. Inheritance for example seems a lot more straightforward in ruby compared to javascript but also illuminate some of the complexities that ruby hides away to be so user friendly. The additional clarity of this chapter helped clear up some of the confusion I had from the previous readings.
Inheritance and the javascript workarounds for things continue to be somewhat mysterious. Making super calls in the part about constructors inheriting from other constructors is pretty confusing with another appearance of call and swapping the this.
Another interesting confusing bit was the mention of frames and windows each being their own realm, and being careful making assumptions about checking an instance in different realms because the instances are created fresh when the 'realm' is created. Interestingly enough there are ways to get passed the realm barrier also.
The concept of generic methods had my brain spinning slightly as it opens up a whole other level of possibility and complexity in ways that hadn't previously existed in my brain. Want to call an array method on a string? No problem. Perhaps I never reached far enough into ruby to find a lot of subtle nuance or perhaps it feels that way because I have been working in ruby for 5 months but the nuances and strangeness of javascript seem to be much closer to the surface. You spend relatively little time in javascript land before its quirks come out to play.
I had originally started reading Eloquent Javascript before starting Turing and it's interesting to revisit the material with the additional experience I've gotten in my studies in the meantime. Javascript is strange and new in the way that the functions behave. They can be stored as values of a variable (the variable can be reassigned), or declared via function blah() {...}; which automatically removes them from the normal top to bottom flow and places them at the top of their scope so they can be used by other functions, but can be ordered in a way that makes sense within the whole of the code.
I find it interesting that Javascript has found itself so popular that the new js compilers like Babel are introducing syntactic sugar so that js looks and acts more like other languages. In the reading the author speaks about a new variable keyword called let that allows block scoping. From my wanderings I found several others that are a part of es6 (i.e. const).
Another mysterious aspect of js is its treatment of arity, in which the language does not complain about the number of arguments but instead performs some action, an action which you can take advantage of in the case of the author's example about 'optional' arguments by having them defined in the functions parameters and checking if they've been passed by asking if they are undefined (the default quirk of js is to assign undefined to parameters that aren't passed but exist in the function's definition.
Having a function return another function is baffling but seems like could be made to do neat tricks. I appreciate the author's description of this as 'freezing' the code and having the outside function be the frozen code's handle. I don't think I understand the reprocussions fully but the description got me slightly closer.
I really liked the author's treatment of the tradeoffs between elagance and efficiency. Additionally the coverage of functions for their values or for their side-effects alongside a definition of 'pure' functions gives me a place to start in terms of having an idea about these harder computer-science topics that I might be asked about in job interviews (and that might also enable me to have the conceptual understanding to make decisions about the code I'm writing).
The author gets into some really great high-level discussion about abstraction in this chapter. This high level talk is interspersed with what feels like to me is some heavy duty conceptual lifting in the examples he shows. It seems like the method of exposition he espouses is to show a function as if it didn't exist as a built-in feature, then later is like 'welp, turns out this is a js method alredy' and then dives into some really non-idiomatic examples that I find difficult to decipher.
The powers of the methods bind, call, and apply seem mysterious and great. I'll say honestly that a lot of the material presented in this chapter seems over my head. I remember trying to pick up this book as one of my first resources to learn how to program and feeling pretty alright until the exercises in chapter 4 (definitely not a source for those easy wins that might convince a person to keep at it).
In this chapter I made some tenous connections from the powerful and mysterious trio mentioned above to a technique that I've seen floating around the internet called 'currying' and I think it turns out to be the same technique the author is utilizing with functions returning functions. The idea is that a functions variables can be partially defined ahead of time and then later filling out the rest. The 'partial application' of a function. I cannot independently conceive of a scenario in which I would reach for such a technique but this feature of javascript does indeed seem powerful.
The bit about abstraction being a compromise between human readability and machine efficiency is an interesting one. It has recently come to my attention that ruby itself is an abstraction(the ruby core is written in C). Additionally the trend of Babel and other transpilers seems to be in the same category of creating wrapper languages for the benefit of syntactic sugar.
Really appreciated the history section of chapter 6. I like hearing about history and the development of a language or concept so that it gives me a larger context to know the 'why'. Javascript indeed has 'methods' and these are properties of an object that have functions associated with them. Prototypes are the steps up the ancestry chain where methods are looked for when they don't exist on the instance.
A slight clarification for bind and apply is that the first argument is used to give the context for this. Still highly confusing however.
Constructors seem to create instances of an object and the differentiation is that they are capitalized (this is the convention that sets them apart from normal functions). new is the keyword that endows them with their constructorness. An interesting and confounding thing is that properties come in two flavors, enumerable and non-enumerable, enumerable ones being all the ones we create by simply assigning them. You can redifine a property from an objects prototype on the instance and create prototype-less objects using Object.create(null);.
The bit on polymorphism ties in with some of the concepts I've been reading about in Sandi Metz's book POODR about defining interfaces and 'duck' typing. As long as an object responds to the same messages it doesn't matter what sort of object it is. These concepts seem advanced and I hope that I'm able to see some more good examples of where and why these techniques are powerful (they make up the essence of OO design and are the reason for it).
The example program he showed to exemplify these concepts I found particularly dense.... each function seemed like a confusing nesting of operations that take a lot of tracing to figure out what is exactly happening, especially as some of the material presented depends on material presented further down and it was difficult bouncing back and forth to try and see what was interacting with what. I wonder if it would be possible to have more readability or clarity, or if that is simply the style of coding that javascript is naturally inclined to and simply takes some getting used to.
It's interesting that the author finishes the chapter with some kind of warning about inheritance being slightly 'dodgy' in that while other OO techniques such as encapsulation and polymorphism are used to separate code, inheritance essentially ties the code together and works against overarching OO principles. Again I am reminded of POODR and Metz's insistence on reducing dependencies. These topics are ones I hope to develop more understanding of with continued learning and 'levelling up' as a developer because understanding the benefits and trade-offs will make the difference between a junior and senior (conceptual deep waters)
This is a great resource that spells out exactly some of the things that make javascript so finnicky. I especially liked the table showing results of typeof... it's really all over the place.
It's somewhat comforting to have a source like this that has strong opinions on whether you should use an approach or not. Coming into it not knowing and with so many nuances to the language itself, this is a big help.
I do think it was valuable. It repeated much of the same content again but in a different way with plenty of examples. This reading is another source I'll have bookmarked and ready to go when I'm starting to experience discord between my expectations and javascript reality.
I thought the short blurbs about type casting were confusing... that you could do '' + 10 === '10' //true or +'10' === 10 //true. Some of the in depth discussions were also over my head.