While trying to answer questions on SO site (particularly C++ questions) I find that most of the times one person or the other includes a quote from the standard. I myself have hardly read the language spec. Even when I try to read it, I can't get my head around the language used in the specs. So, my question to become a good developer in a particular language is it essential to read its spec and know all its dusty corners which invoke undefined/implementation defined behavior?
closed as primarily opinion-based by gnat, GlenH7♦, user40980, Dan Pichelman, Bart van Ingen Schenau Sep 1 '13 at 9:04
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
As one of the guilty parties, I'll add my 2¢ worth. No, I don't think it's necessary. Unfortunately, in C++ it's closer to necessary than almost anybody would like -- i.e., as Bjarne put it, C++ is "expert friendly". You need to be aware of a lot more details than anybody would like to be able to use it well. While probably true to some degree in almost any case, this is much less true in many (most?) other languages.
The other side of it is that a lot of times people are asking about relatively subtle details of the language that, quite frankly, darned few people really know off the top of their head, so those of us who provide answers about them often have to look up the details to be sure we're right. I also find that quoting from the standard has a tendency to prevent a lot of arguments -- even when I do know an answer, it'll frequently be questioned (to at least some degree) if I just say: "here's how it is." If you quote the standard, far fewer people will argue, so it can save time and effort in the long run.
Ultimately, I think knowing the standard (or the dark corners of the language) really well is less important to programming per se than to mentoring others about the language -- even cases where you just say "don't go there!" About the only programming to which it's important is writing code that actually works with the language (tokenizing, parsing, analyzing, etc.)
I would say that knowing the spec inside out is not a requirement to knowing how to program in C++ or even to become a excellent C++ programmers.
I would say though that being able to find information from the spec is important, if there is a part of the language that you are using that isn't very well documented.
It is also important knowing where your compiler doesn't meet the spec if you want you code to protable between compilers.
No it not essential to be a good developer in a particular language. However it helps a ton when answering a question in a definitive way. So StackOverFlow users use it a lot.
The Common Lisp Hyperspec is a really useful bit of documentation. I refer to it a lot.
I've read the Haskell spec, which is useful not just for the language definition but also because it contains source code for the Haskell Prelude. Reading the Prelude code gave me a good grasp of common Haskell idioms.
I do read language standards on occasion, but not everybody does. Certainly it's possible to be a very good developer without ever touching one.
What you need is the knowledge of the parts of the language you're going to use, and somewhere to go to find out about what the stuff you don't understand in other people's programs does. You don't need to know exactly what constitutes undefined behavior if you make sure you never go near it.
To give an example, in C++ you could avoid starting any identifier name you write with an underscore. There are rules as to what names starting with underscores are reserved for the implementation with what linkages that you could learn, or you could just stop writing your own identifiers with leading underscores.
I've read an annotated version of the C# Spec (for version 3 I think). I can't say that I learnt anything mindblowingly new (I'm sure I learnt a bit but nothing stands out in my mind) but I did get a a deeper understanding of why things are the way they are. I found the annotations really valuable where they explored compromises that had been made in one or another. For me at least, this background knowledge makes things stick in my mind much better and I think I'm a much better developer as a result.
I don't think not reading language specs themselves keeps anyone from being a good programmer, but reading them certainly wouldn't hurt. Reading specs straight through is boring as heck, and I don't blame anyone for not doing so, but reading specs in pieces when working on related items isn't so bad and I find I retain more over time doing it that way anyway.
I learned C# from the language spec, which I believe was floated at least a couple of years before Visual Studio.NET was released. But that was more of a matter of just taking note of what was different from Java - I don't know if it would be such a good way to learn a language that was a lot different from what I already knew.
I never read specs because I mostly use newer languages that don't have a formal, legalese spec yet. My main languages are Python and D and AFAIK neither one has a formal spec, i.e. one whose intended audience is language lawyers/implementers, not average users.
Once. I read the Java Spec. The only reason I read it was I was competing nationally in Java Programming for FBLA (Future Business Leaders of America) and thought it would give me an edge.
It was helpful, but the ROI (return on investment) was too low for me to do it again.
Once I had insomnia for a few days so I read the whole ECMA published C++/CLI spec. What a great read.
Knowing the C++ spec (being able to look things up, or quote it on StackOverflow) is relatively important for C++ because the language has lots of undefined behavior that compiler implementers can do whatever is convenient with those undefined areas. Just because your compiler accepts the code and just because it runs correctly doesn't mean it's portable. You may be relying on features of your architecture, features of your operating system's ABI/API, or features of your compiler (or of a particular version of your compiler). So to know what's portable C++, and what guarantees you can rely on, you need to refer to the spec. Your compiler won't know.
Most other languages leave a lot less program behavior explicitly undefined, so you refer to the spec to the extent that you find it useful as an API reference.
I used to be the unofficial "language lawyer" for C where I used to work. I had the official ANSI X3J11 spec, and got to answer all the weird "is it supposed to do that?"-type questions. You definitely don't need it to do 95%+ of the coding most shops do, but it can be handy in those cases where you run into some odd corner case that the compiler manual doesn't even try to explain.
Depends how big the Spec is. The C# Spec is big and has a lot of complicated language, so I've never read it.
I did learn C# through the usual ways of Experimenting and Googling and only after I got a good understanding I read small parts in the spec, mainly about Bitwise operators because I needed it.
At some point I decided that I want to write a compiler for .net, so I did read large parts of the CIL/CLR spec (and forgot about most of it again).
On the other hand, I did read the Lua spec prior to using it, mainly because it was cheap ($17 as a printed book) and very small, with only ~100 pages that are also written in 'easier' english.
But then again, Lua is much much simpler than C#.