This is a minor continuation of my thoughts from The Law of the Excluded Middle does not apply to Programming Languages.
One sure sign that you have mastered a language is when you can create a fairly comprehensive list about what sucks about the language (while simultaneously appreciating why some of this suckiness is a necessary evil).
When you first meet a new language that floats your boat, there is a tendency is to fall in love. This happened to me not too long ago with Erlang. You think, "This language is great. Such and such is so hard to do in Language X and look how easy it is in Language Y.
Well, much like in the real world of human relationships you don't really know what love means until you get married! When you get married to a language (commit to developing a multi-year non-trivial system in it) then your love is surely tested. You learn about the languages warts and its tendency to leave its socks outside the hamper, squeeze the tooth paste from the top and leave the toilet seat in an inconvenient position!
If you still love the language with its warts and all, then you have some of the necessary (but not necessarily sufficient) hallmarks of a master. Either that, or you ave a really good therapist.
p.s. Erlang and I broke up but we are still friends! On a happier note, my long term mistress (Mathematica) and I are really making sparks fly! Hope C++ doesn't catch us.
Subscribe to:
Post Comments (Atom)
6 comments:
I would argue that you've mastered a programming language when you can write its compiler.
That is neither a neccessary or sufficient condition!! Knowing how to write a compiler is a specialized skill. Being a compiler writer for a language means you have a very good understanding of its specification but that does not imply you can use the language well.
It may not be sufficient, but I think it's necessary, and I don't think that writing a compiler is a specialized skill (although writing a parser generator is, as are the myriad optimization strategies).
Compilation (mapping the abstract syntax of the new language into terms of a language you already understand) is something people already do informally, but formalizing it gives you a technical basis for reasoning about it.
Without that basis, I think people wind up falling into comments like "C++ is teh suck" and "Ruby is beautiful because you just type what you think." I'm not trying to make fun of those people, because I think there's actually a rigorous technical statement behind those vague semi-reasonings, but it can't get out without the sort of formalization that compiler-writing requires.
You make some interesting points and I’d agree with you if you were right but your not. :-)
When I use the term "programming language" I am referring to something a lot bigger than its formal definition.
To master modern C++ you need to be a master of the language itself AND all the artifacts of the language. For example, iostreams, stl, idiosyncrasies of the gnu compiler and to a certain extent things like Makefiles, Boost, CPPUnit, etc.
All these things are part of the milieu of C++ development. On any given day I may say "C++ sucks" but what I really might mean is that the tools that are available to me, suck. Or that compile times are particularly bad on the system I am working on, etc. The same would apply to Java, Erlang, etc.
Having deep undertsnading of the mapping of a language to machine primitives may give me a deeper appreciation and understanding of the language and would certainly help me write cleaner code but unless I am a user of the lanaguage (in the full sense implied by the above) I can never be a master.
Here is another example from our day jobs writing trading systems. We are given the specifications of a trading system and we translate those specifications into executable code. In the process we learn a lot about algorithmic trading but that does not give us the right to call ourselves traders. Nor can traders, with deep understanding of trading systems and theory, necesarily translate that knowledge into an algorithm.
I think someone could write a really good C++ compiler using straight C and not learn a thing about how to do good OO programming or good generic programming. If you don’t know both of these well, you can’t call your self a master of C++. Likewise, I can easily imagine a master of OO, generic programming and the like who did not know enough about parsers, code generators and optimization to write even a half decent compiler.
OK I'm wrong. I took the subject of your post as "how do *you* know when you have mastered a new programming language" rather than "how do I ...?"
I think we're arguing two different sides of the same coin. Especially as it concerns the STL and Boost, library development drove language development, and vice versa.
It's just like the historical interplay between physics and mathematics, I think. Often, new discoveries and insights in physics drive inquiry into new branches of mathematics, and often new branches of mathematics offer insights into existing physical problems. Is physics "bigger" than its mathematical basis? Yes, clearly, but can you make a concise argument that a falling apple follows the same law as the "falling" moon without that basis? I don't think so. A physicist isn't an engineer, just like we're not traders -- but the physicist provides the logical basis for the work that the engineer does.
In my opinion ("wrong" as it is), that's exactly the situation we're in as programming practitioners -- except the mathematical basis for our work is formal logic, and a compiler (having nothing to do with parsers and optimization strategies) is a logical formula that explains what a language is. Programs (whether in C++ or Mathematica) are proofs -- http://homepages.inf.ed.ac.uk/wadler/papers/frege/frege.pdf -- and in my opinion that fact informs both our ability to assemble/understand libraries (just as the authors of the STL and boost operate from that basis) and our ability to synthesize our knowledge of all programming languages into a unified framework.
Just my humble opinion.
BTW, the "your wrong" comment was meant to be tongue-in-cheek. It comes from one of my favorite Robin William's quotes: "If you were right, I would agree with you."(Awakenings)
We should continue this debate over drinks next week.
Post a Comment