But this strategy is especially awful if you know you
    don’t plan to ever actually learn the language, but you
    turn out to be wrong. It ends up that you find yourself
    using it on a regular basis, and hilariously, you don’t
    even notice this for years and years.

This is especially true of my relationship with Javascript. First I held it at arm's length, then I learned a bit when jQuery and other frameworks were first released...at least enough to get by. Then, about 3 years later, CoffeeScript came out and I embraced that. Now I find myself, thanks to AngularJS, back at Javascript, and truly embracing the language for the first time.

Javascript will never be my favorite language, but after 10 years of finding every way to avoid using it directly, and 2 repentant years of truly mastering it, I can at least finally say that I know it well.

Could you explain some of the reasons for needing a client side framework for a web app? I've always just used requirejs and wrote modules and that has worked for me as I try to keep as much server side as possible, but I realize my experience in the industry is limited so I wanted to hear some arguments for client side frameworks. I've been flamed in a few freenode channels just for bringing them up.

I'd like to answer this.

You're separating layout logic/codes to client side.

Not only that but your server side code is now basically a web service, usually Restful. So it's real slim and all it does is serve data. And your client side will be the one responsible for rendering the data.

This also may forces your layout code to be front end, which people can steal, but it put more emphasis on the value of your data. Then again you can steal webpage design css/html all the time... likewise with javascript anyway.

And another reason for using client side MVC is because they want their web application to act like an application and less of a webpage so you'll hear the term single page application a lot. It's a whole a trend, they created AJAX so it's less like a webpage more like a web application.

Of course it depends on your project/website and it requirement and if it's more like an application or more of a website.

There are some drawbacks to this, SEO namely for angular but you can have work around like phantomjs. Not so much for ember.js (I'm about to learn ember soon...).

Imagine you're building a desktop application that does something like take a bunch of sensors from an attached serial port device and displays configuration of them + a table of their values updating in real time.

You wouldn't create every GUI element from scratch. You'd use the built-in Windows components (these sorts of apps are almost always windows-exclusive).

Now imagine you're building a web app that does the same thing, except now it's hosted on the embedded system and you get to it via web browser. You're going to want it to behave like a desktop application. Adopting client-side GUI frameworks like ExtJS was so common you wouldn't think twice about it. The reusable components make it much closer to a desktop application than a website.

If I were still building applications like that, I think I would still use ExtJS, warts and all. It's perfect for table-and-tree-driven application.

Nowadays, if I want to build SPAs, I use AngularJS. It's hard to overestimate just how much of a revelation that kind of client-side framework is.

TL;DR - In industry you often can't keep much server side. Instead you have to talk to lots of services and APIs directly from the browser. Additionally, you may need standardized GUI components that are familiar to people who only use desktop programs for the most part. Those two areas are admirably served by client-side frameworks like AngularJS in the first instance and ExtJS in the latter.

The Mode View * client side frameworks help to separate concerns of storing the data relevant to your app (models), creating the abstractions responsible for displaying the models to the user interface (Views), and managing the routing of your app (* or sometimes called controllers) within your application. These separations help to make code in your application more reusable, easier to debug, and easier to modify.

What helps immensely in learning new programming languages quickly, but also in spotting tricky bugs and increasing general software engineering skills is studying programming languages as a discipline of CS: learning how languages are implemented, what are the core paradigms, what are the design choices invented so far for common issues etc. There is a fantastic book called "Programming Language Pragmatics" that is readable and very good in teaching the practical aspects of this:

http://www.amazon.com/Programming-Language-Pragmatics-Third-...

Exactly. All you really need to know is how to accomplish things in functional, OO and procedural languages. The advice given in the article is very nearly syntax based, not conceptual. Which is nearly useless if you're going very far from C/++.

If you're in a procedural language the questions is: what's the for-loop?

If you're in an OO language: are there iterators, how do I use them?

If you're in a functional language: what the syntax for mapping, etc.

I feel like understanding the author really when thinking about my first contact to "foreach" in C#.

to me foreach

1) had a totally different syntax then the rest of the language (It felt painful as if somebody mixed up German Gamma with English words --- http://forum.werder.de/showthread.php?4107-My-lovely-mister-... )

2) seemed to have no use (I did not yet make any magic with Arrays...)

3) was difficult to read

4) nothing I would understand (back then)

so I closed my eyes for it...

Nowadays I believe it is a must have, whenever you are doing magic with an array. And for me it became a very powerful tool.

> Python’s primitives aren’t actually objects.

As an expert Python programmer, I don't understand what is meant by this.

This is just a guess, but in ruby, you can perform methods directly on any value, such as "3.succ", which returns 4. I don't think that works in Python. Ruby allows you to extend any class with more methods, so you could create your own function and apply it directly to a number. In Python, you would need to pass that number into a function.

E.g. Ruby: (3.7).round opposed to Python round(3.7)

Agreed. Surely all Python objects are (*PyObject)s? Some values, such as integers, are cached in certain cases. But they are all PyObject pointers. Perhaps the author can clarify?

Might mean __dict__, but it's a silly point to make since underneath that and the rest is *PyObject.

"In general, as long as you’re staying largely inside the world of what I call “BOLS” (Block-Oriented, Lexically-Scoped) Languages, such as C, C++, VB, Java, C#, PHP, Lua, Python, Ruby or perl, you can in fact learn enough pidgin to get by very very quickly with this method. Granted, in those last three languages it will be obvious to experienced programmers that you’re writing inelegant code. But you can get by, is what I’m saying."

Just in those last three languages?

This process is much easier if you're working with a "mentor". If there's someone there who knows the language already and can do code reviews, it's a much more realistic option.

Without a safety net, it's so easy to make horrible mistakes without noticing.

down for me. Here is google's cached version: http://webcache.googleusercontent.com/search?q=cache:h4Bfye0...

"Teach yourself" is actually a fancy-pants way of saying "learn".