|
The only reason I can find for reading technical papers is to learn something.
I don't read language specifications because their purpose is not to facilitate learning.
Instead, I read the books written by guys that, besides the knowledge they posses, have the ability to teach people and make them absorb that knowledge.
I bet you all have in mind such great books (and authors).
If I would start writing compilers, I would definitely read the language specifications. But that's not the case.
Cheers,
Mihai
|
|
|
|
|
An author of a mass-market book may not include everything in the spec, and, especially in the case of .net languages, may actually spend much more space the basics of the framework it interacts with. The spec is the authority of the language; it contains everything, in detail.
Certainly if you want to learn the language and its framework, buy a mass-market beginners' book and get started. But as you become more sophisticated, you will likely need to advance to a more "professional level" book and eventually you should read the spec so you can get the most from the language.
|
|
|
|
|
I think that every language feature should be documented somewhere else than in the specs, like in a good book or an online tutorial.. You'll find something about everything somewhere, and anything is easier to understand than the specs.
|
|
|
|
|
elektrowolf wrote: like in a good book
They're never complete enough.
elektrowolf wrote: easier to understand than the specs
If you don't understand the spec, get out of the business.
|
|
|
|
|
PIEBALDconsult wrote: They're never complete enough.
Can you give me a concrete example of a language feature you would not find in a book?
PIEBALDconsult wrote: If you don't understand the spec, get out of the business. Big Grin
I didn't say I don't understand them, I said they were more difficult to understand. I think you cannot doubt that.
|
|
|
|
|
hehe, anyone here able to finish read C# Language Specification?
I have meaning to read it few year ago but haven't start anyway.
|
|
|
|
|
Several times.
Same for the CLI spec.
Makes good bathroom reading (if you can print it out).
|
|
|
|
|
leppie wrote: Several times
Each new version.
leppie wrote: print it out
Absolutely, I can't read anything that big online.
|
|
|
|
|
That's how I learned the language. Tried the "Professional C#" book first, but that thing had thousands of pages and still was very shallow, so I downloaded the spec, and read it.
Maybe I should add that the last version of the C# spec I read was 2.0. Haven't used C# much in the last four years.
|
|
|
|
|
Nemanja Trifunovic wrote: "Professional C#"
The one from Wrox? That was the text book for the C# class I took in 2003. Yeah, it's awfully shallow for how thick it is. And, of couse, it presents very poor practices; like data access in the GUI.
I also have "C# for Dummies", which is certainly a better beginner book.
But most often, I refer to MSDN or the spec.
|
|
|
|
|
|
Nemanja Trifunovic wrote: That's how I learned the language.
Really? I mean, in the specs, the framework functions are not documented. You may have understood the syntax after reading the specs, but have you been able to create a running application?
|
|
|
|
|
why bother?
by the time you've finished reading it, MS will have released another two versions of the language.
|
|
|
|
|
Yes, but the updates are smaller.
|
|
|
|
|
I code in the Klingon manner - I create the spec as I code! I challenge any spec to a Klingon death match!
|
|
|
|
|
I first read the C# spec back in 1999; at that time no compiler was available, so reading the spec was the only way to learn (and get excited) about it.
I have since read some "historical" language specs: Dartmouth BASIC (1964), BCPL (1967), B (1972), C (1974). Finding compilers for these (and not more modern variants) may be impossible.
|
|
|
|
|
|
OK, if you have "The * Programming Language" book, that's usually as good (and as hard to read), but I don't have patience for books that are fool of pictures and "real world" samples (what is real world for a book author may not be real world for the readers). Anyway, the official spec is my first step to learning a new language, and of course it serves as a reference later.
|
|
|
|
|
I agree with you. "Reading the Spec is the most reliable way to learn a programming language".
But the first time you do it, it hurts and takes time.
But since programming language specifications have much in common independent of the language at hand, the benefit of having studied the spec for language A will pay off for language B.
|
|
|
|
|
I've read the spec for language B (and even C and D), but I haven't heard of language A.
|
|
|
|
|
Same here
|
|
|
|
|
Nemanja Trifunovic wrote: "real world" samples
Especially as examples need to be simple yet language features (or rather, their interaction) mostly have to deal with high complexity.
Learning by spec only works for people who learn a spoken language by reading a grammar book, though.
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel] | FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server
|
|
|
|
|
yes, only a few pages, and for most of the time, I use high quality open source projects codes as my spec and coding standard.
Regards,
unruledboy_at_gmail_dot_com
http://www.xnlab.com
|
|
|
|
|
Usually I read the language reference, but never the specification. (That's for the compiler guys )
And, as libraries tend to get bigger and bigger (.NET ...), only parts of their reference.
|
|
|
|
|
I'd love to read the reference, just not enough time, I know theres loads of stuff in there I would just love to use if I only knew it was there. Problem is I keep falling asleep....
Never underestimate the power of human stupidity
RAH
|
|
|
|