I'm a bit puzzled about the exact level this is pitched at.
The intro seems to be aimed at someone who already knows enough to be building web apps (albeit with difficulty). "Here's a description of a bad experience trying to solve an Angular problem. Sound familiar?"
But then it switches gears and what follows seems more appropriate for a reader who is completely new to programming. "Let me define terms like 'bug', 'comment', 'function call' and 'loop' for you."
(Maybe the actual audience is people who have recently started trying to build web apps (or something of the kind) without learning the fundamentals, and have been barely surviving by copy-and-pasting things? It doesn't look like it from the other articles on the blog.)
I'm also not sure what our hypothetical beginner is supposed to do with this little glossary. On its own, it seems to me it has the exact same problem the author described earlier in the context of Angular documentation: you don't know what X means, so you look it up, but it's defined in terms of Y and Z which you also don't know. So you look up Y and it's defined in terms of P, Q, and X. Etc.
I think this sort of little glossary of basic terms is potentially useful, but only in the context of something -- e.g., perhaps the author's book -- that introduces these terms gradually, in an order chosen for ease of learning, and in a context where most of what's going on is something other than "here are some definitions to learn".
Exactly. I read the intro and was confused by the sample SO answer, so I thought "why not put this dictionary idea to the test?". I tried to look up the words from the post that I didn't know: minifier, injector, controller... nope!
FWIW, software engineering is _RAMPANT_ with people who are very very poor at teaching, mentoring, and even just explaining things.
I suspect this is because many practitioners had to learn through hard-knocks and entirely by themselves and as a result feel that everyone has to go through the same "rite of passage" of suffering as a clueless newb.
While it is fairly easy for new folks to find "getting started" materials or for pros to get advanced information, there's a huge valley where confusion is the norm and one is reduced to getting down-votes and withering commentary on stackoverflow for deigning to ask a basic question without already knowing the answer.
I think understanding terminology definitely helps but the problem is more deep-seated. One could remain completely baffled with the example Angular answer even knowing the technical meaning of all the terminology.
I think part of it is someone sees a question and thinks "Well why didn't you just google xyz?" without realizing that the only way to know to google xyz is to already know the answer to the question posed.
OK, that Angular example triggered me. This is exactly why I couldn't make heads or tails of my Angular caching issue - because all answers on SO were like this.
And indeed the Angular documentation does not help at all. It's awfully abstract, and I always had the impression it's trying its best to avoid telling you what you actually need to do in order to achieve X, for most values of X.
This kind of non-documentation, coupled with the fact that Angular is IMO overengineered, drives me crazy.
That's why it's always a good idea to look into other frameworks and languages :)
I had to do some Java stuff in university so I knew the concept of dependency injection. But in JavaScript it isn't used that often.
Probably because "classes" are simply functions there and you can store a function in a variable and pass it around without thinking about its "real" name, which already decouples things quite nicely.
One thing bothered me slightly - It describes bugs as "a mistake in the code" but I suspect a more accurate description would be an "unintended outcome of a piece of code" or something to that effect.
I do think this would be helpful for people just learning to program. When my daughter was introduced to programming at school they used the term "procedure" to describe a function or method. I noticed that wasn't listed as a synonym, which would be helpful.
So, good for the general public and good for new programmers. When I get people in the lab that want to "learn programming" this is where I will send them first. It will make all of the other programming introductions much easier to follow for someone with no prior experience.
Edit: Glad to see that it is the start of an intro programming book. All intro programming books should start with an intro to terminology. One other thing missing besides "procedure" -- coding. They use it at the end of the page, but it is nowhere else on the page.
Yes, you need a vocabulary, so this is a great idea, but the the vocabulary here is not as generic as the author would like to think. For example: type, variable, value will trigger discussions when people have a different background.
(Also there are some mistakes/typos, fe parenthesis iso parentheses )
I agree. Clearly the author has a particular aim in mind, which seems to be teaching Ruby and/or Javascript; for a generic, introductory glossary I wouldn't include so much OO terminology; not only is OO quite tricky to grasp, but in some places it artificially limits the definitions, e.g. "The programmer can define more complicated types using classes".
I think it's sensible to move definitions like "class", "instance", "instance variable", "method", "object", "member function", "member variable" and "instantiate" to a separate glossary, which can be a bit more in-depth. Other glossaries could then deal with other common-but-more-specialised sub-topics too, like logic (booleans, AND, NOT, short-circuiting, lookup/truth tables, predicates, branches/clauses, etc.), syntax/structure (blocks, tokens, keywords, scope, statements, expressions, modules, namespaces, etc.), and so on.
Anecdotally, my first programming language was Python, which I managed to teach myself procedurally. OO only "clicked" for me after a couple of years of undergraduate CS courses, in Java, Python and C.
One idea would of course be to make the [references] into actual links to the target word, kind of ... odd not to do that in a document delivered as a web page.
The intro seems to be aimed at someone who already knows enough to be building web apps (albeit with difficulty). "Here's a description of a bad experience trying to solve an Angular problem. Sound familiar?"
But then it switches gears and what follows seems more appropriate for a reader who is completely new to programming. "Let me define terms like 'bug', 'comment', 'function call' and 'loop' for you."
(Maybe the actual audience is people who have recently started trying to build web apps (or something of the kind) without learning the fundamentals, and have been barely surviving by copy-and-pasting things? It doesn't look like it from the other articles on the blog.)
I'm also not sure what our hypothetical beginner is supposed to do with this little glossary. On its own, it seems to me it has the exact same problem the author described earlier in the context of Angular documentation: you don't know what X means, so you look it up, but it's defined in terms of Y and Z which you also don't know. So you look up Y and it's defined in terms of P, Q, and X. Etc.
I think this sort of little glossary of basic terms is potentially useful, but only in the context of something -- e.g., perhaps the author's book -- that introduces these terms gradually, in an order chosen for ease of learning, and in a context where most of what's going on is something other than "here are some definitions to learn".