Unsure I can fully carry on with this workshop
Author
I'm not writing this to be offensive, aggressive or hostile but I'm wondering if I'm better off going back to my existing resources to learn C#.
The reason I feel this way is that the principal text, the 'C# language specification 1.2' is a reference and not a learning text, which needs a more natural writing style even more than the Mona Lisa needs to sit on a whoopee cushion in order to lighten up. For example towards the bottom of p53 we have this gem:
'Within all source files of a program, namespace-member-declarations within namespace-declarations that have the same fully qualified namespace name are members of a single combined declaration space.'
Ooooh I've reread that one a few times; believe me. By the end of the sentence I've forgotten what the first part was. I can count 4 technical phrases there that I, as a beginner have to juggle in my mind to get the meaning. 2 of the phrases are in italics, presumably to make them the significant part of the sentence. But that only serves to further overload the one or two containers in my mind which hold new concepts waiting to be internalised. Now I've focused on one small part of the text to make my point and other parts are clear. But as a beginner I don't know if that bit is a significant bit I'm not getting.
I would question any well meaning advice that told me to stick with it; it will become clear. This is where I come to make things clear in the first place. That is what (I presume) any learning text would aim to do. But as I said I think the text we are using is a not a learning text but instead a reference text. It's more suitable to people comfortable with the concepts of programming or even someone who already knows C# than a rookie like me.
Just in case anyone would aim the argument at me that maybe I'm just not up to the challenge I would, somewhat defensively I admit, say that I have a degree level education, a higher than average IQ (and old & ugly enough to admit that IQ tests and college degrees don't prove that much), I can follow other learning texts on C# much more easily, and I've programmed a level of a shoot em up using a simpler language. I feel that, with dedication, I'm up to the C# challenge. But while there may be other learners who find the principal text ok to work with, there may be others like me who don't.
I am not having a go at the organisers of this course. I think it's a wonderful idea and I have the greatest respect for all contributors. Indeed I found the previous course on c++ to be the single greatest learning tool for that language. To be able to write about a confusing point and get multiple feedback from learned and generous people is in some ways as good as having multiple mentors sitting next to you - what could be better? But that course relied on the 21 days book by Jesse liberty which was designed as a learning text. Was it in the public domain at the time? I don't remember. Maybe a limiting feature is that there are fewer resources for C# which are widely available.
I am hesitant to type out and post these frustrations since I do not wish to offend anyone or start a 'lively and frank conjecture of opinions' which may generate more heat than light. I think I will try to follow this course since I feel it really comes into it's own when learners post questions and get good answers which I read attentively. But it would be a shame to feel that I am not as attentive to the source material from which the questions arise simply because it confuses me.
I share your frustration with the technical terms and the difficulty of reading the specification. And yes, I believe it was one of the few available free resources that were discovered for this workshop.
On the other side of the coin...of the other languages I've learned, most were from text books so were somewhat easier to digest, were taken in smaller bites and had much more acutal use earlier on than this workshop. However, later on when I programmed professionally with the same languages, I often found the need to go to the technical specifications in order to solve an elusive problem. At first this was very difficult to do, mainly because I hadn't been exposed to the technical documentation books early in my learning experience, so I didn't know what was available and where. Also, this lack of early exposure was a disadvantage because I had not necessarily been exposed to the "technical jargon" that was used to describe concepts in the technical manuals.
So, although I feel your pain, I think eventually it will result in an overall better learning experience since we will have learned not only where to find the documentation we need later, but also, have a good handle on the jargon we can use to discuss, and read about the finer details.
Remember we only can retain at most 70% of what we learn on a pass. I'm keeping the questions and answers where I can see and review them often in order to try and solidify the verbage in my mind, just like I would do for a college class.
Do I think this is difficult, heck yes. Do I think you can do it, of course.
Don't stress over every concept, remember we haven't even coded anything yet. It will take years to get ALL this information in your head. In a company you don't expect a beginner programmer to be really good at a language for about 2 years, and that is after they have been programming for 6 months or better in the college environment. You give them simple programs to write, let them make mistakes and reinforce what they have learned with the next project until it comes fairly easily to them. At that point you can load them up higher complexity projects. We are in the same boat.
The first coding project will highlight the gaps in what we have learned. At that point I will go back and read over the sections I need to read, helping to solidify them in my mind. I don't know about you, but a lot of the technical doc won't make sense to me until I see it in my own code or use it to express my own logic. That's when it really starts to sink in for me. It will also help me to be able to see how other people use the same language to create their own versions of the same programs.
[Edited by - April on July 16, 2007 6:25:13 AM]
On the other side of the coin...of the other languages I've learned, most were from text books so were somewhat easier to digest, were taken in smaller bites and had much more acutal use earlier on than this workshop. However, later on when I programmed professionally with the same languages, I often found the need to go to the technical specifications in order to solve an elusive problem. At first this was very difficult to do, mainly because I hadn't been exposed to the technical documentation books early in my learning experience, so I didn't know what was available and where. Also, this lack of early exposure was a disadvantage because I had not necessarily been exposed to the "technical jargon" that was used to describe concepts in the technical manuals.
So, although I feel your pain, I think eventually it will result in an overall better learning experience since we will have learned not only where to find the documentation we need later, but also, have a good handle on the jargon we can use to discuss, and read about the finer details.
Remember we only can retain at most 70% of what we learn on a pass. I'm keeping the questions and answers where I can see and review them often in order to try and solidify the verbage in my mind, just like I would do for a college class.
Do I think this is difficult, heck yes. Do I think you can do it, of course.
Don't stress over every concept, remember we haven't even coded anything yet. It will take years to get ALL this information in your head. In a company you don't expect a beginner programmer to be really good at a language for about 2 years, and that is after they have been programming for 6 months or better in the college environment. You give them simple programs to write, let them make mistakes and reinforce what they have learned with the next project until it comes fairly easily to them. At that point you can load them up higher complexity projects. We are in the same boat.
The first coding project will highlight the gaps in what we have learned. At that point I will go back and read over the sections I need to read, helping to solidify them in my mind. I don't know about you, but a lot of the technical doc won't make sense to me until I see it in my own code or use it to express my own logic. That's when it really starts to sink in for me. It will also help me to be able to see how other people use the same language to create their own versions of the same programs.
[Edited by - April on July 16, 2007 6:25:13 AM]
That is the reason that there are tutors, so if you come across some techno-babble in the reading then you can ask us and we will try to explain it in "English".
Yes some of the wording they use is a little over the top but from what I have seen as technical documents go this is a great read.
So just feel free to ask questions, that is why it is a workshop. If you notice I try to answer any questions as quickly as I can so that people can keep going on with their learning. Yeah some times that is a bit of a pain to keep on top of it, but it is the only way to help keep people from going crazy over some of the wording used in the specification.
As for using a language specification for learning, yeah it is tough, but it is FREE. That is a pretty important part. Also I have learned that no matter what book you get, you get the author's take on what is important. They always seem to leave out stuff that I think it would have been really nice to know. Following the language spec means that you will get it all, even if it is a bit hard to read at times.
As for this; 'Within all source files of a program, namespace-member-declarations within namespace-declarations that have the same fully qualified namespace name are members of a single combined declaration space.'
What it is saying is that in a project in which you have one namespace, even if it is spread across multiple files that they are all in the same group.
Let me show you what I mean.
In the example above you can see that we have two classes in different files, but in the same namespace. You can call the other class without having to qualify the namespace because they exist in the same namespace. Now where this become really useful is when you are creating a large project and have multiple .dlls all in the same namespace. You can call classes in the other other .dlls (you have to include the .dll reference in the project) without having to do anything but just call the class, no namespace reference is needed.
Hope that clears that up.
theTroll
[Edited by - TheTroll on July 16, 2007 6:43:25 AM]
Yes some of the wording they use is a little over the top but from what I have seen as technical documents go this is a great read.
So just feel free to ask questions, that is why it is a workshop. If you notice I try to answer any questions as quickly as I can so that people can keep going on with their learning. Yeah some times that is a bit of a pain to keep on top of it, but it is the only way to help keep people from going crazy over some of the wording used in the specification.
As for using a language specification for learning, yeah it is tough, but it is FREE. That is a pretty important part. Also I have learned that no matter what book you get, you get the author's take on what is important. They always seem to leave out stuff that I think it would have been really nice to know. Following the language spec means that you will get it all, even if it is a bit hard to read at times.
As for this; 'Within all source files of a program, namespace-member-declarations within namespace-declarations that have the same fully qualified namespace name are members of a single combined declaration space.'
What it is saying is that in a project in which you have one namespace, even if it is spread across multiple files that they are all in the same group.
Let me show you what I mean.
file A.cs_____________________________________________________________namespace MyProjectpublic class A( public int DoSomething() { B b = new B(); int temp = B.DoSoemthingElse(); })file B.cs_____________________________________________________________namespace MyProjectpublic class B{ public int DoSomethingElse() { A a = new A(); int temp = A.DoSomething(); }}In the example above you can see that we have two classes in different files, but in the same namespace. You can call the other class without having to qualify the namespace because they exist in the same namespace. Now where this become really useful is when you are creating a large project and have multiple .dlls all in the same namespace. You can call classes in the other other .dlls (you have to include the .dll reference in the project) without having to do anything but just call the class, no namespace reference is needed.
Hope that clears that up.
theTroll
[Edited by - TheTroll on July 16, 2007 6:43:25 AM]
As with all technical documents it is a little dry, as TheTroll says you can ask the 'experts' on the forum to clear up any confusion and techno-speak for you.
However I would recommend supplanting your learning here with outside resources, such as other learning aids. There is a general C# tutorial in the Workshop opening post, plus a great many others accessable through almighty Google.
In addition when learning C# I found I got tired of reading occasionally, so in those cases I found Microsoft's Absolute Beginners video series and their Soup to Nuts web casts invaluable.
http://msdn.microsoft.com/vstudio/express/beginner/windows/tier1/
http://msdn2.microsoft.com/en-gb/vcsharp/aa727132.aspx
However I would recommend supplanting your learning here with outside resources, such as other learning aids. There is a general C# tutorial in the Workshop opening post, plus a great many others accessable through almighty Google.
In addition when learning C# I found I got tired of reading occasionally, so in those cases I found Microsoft's Absolute Beginners video series and their Soup to Nuts web casts invaluable.
http://msdn.microsoft.com/vstudio/express/beginner/windows/tier1/
http://msdn2.microsoft.com/en-gb/vcsharp/aa727132.aspx
Author
Having read many forums from many websites I started the original post picking my words very carefully because it's so easy on the web to offend when you don't mean to, or get curt & patronising replies when you don't feel you deserve it.
I think it's a reflection on this forum that I should get such encouraging and helpful responses so fast. Thankyou for the replies; I'm sorry I wasn't able to offer up anything more constructive than a bleat, although I thought the Mona Lisa whoopee cushion comparison wasn't too bad. Now, where's that damn 1.2 specification...
I think it's a reflection on this forum that I should get such encouraging and helpful responses so fast. Thankyou for the replies; I'm sorry I wasn't able to offer up anything more constructive than a bleat, although I thought the Mona Lisa whoopee cushion comparison wasn't too bad. Now, where's that damn 1.2 specification...
I've found the best way to make the C# specification seem crystal clear is to find a copy of the C++ specification and read that for a while.
Seriously.
Seriously.
Quote:Original post by jpetrie
I've found the best way to make the C# specification seem crystal clear is to find a copy of the C++ specification and read that for a while.
QFT!
Just a quick thought, most (all?) of the words in italics in the reference are things that they've defined with those long, tedious things like so:
foo-bar:
this
that
So if you see that, just try to think of what it is conceptually, rather than the specific way that they've defined foo-bar to be a set of non-parenthesis characters followed by a '.' and then a bar, or w/e. Just remember that a foo-bar is the thing that defines a Bar.
foo-bar:
this
that
So if you see that, just try to think of what it is conceptually, rather than the specific way that they've defined foo-bar to be a set of non-parenthesis characters followed by a '.' and then a bar, or w/e. Just remember that a foo-bar is the thing that defines a Bar.
Quote:Original post by jpetrie
I've found the best way to make the C# specification seem crystal clear is to find a copy of the C++ specification and read that for a while.
Seriously.
Why exactly? Just curious...
Just because the C++ specification is signifigantly more formal in its language and organization than the C# specification. So after you spend time digging through that mess trying to figure out what the correct way for a compiler to be handling some edge case, the C# specification looks refreshingly simply in comparison.
(Of course, reading the C++ specification purely to disambiguate the C# specification for the goal of learning C# is not exactly the greatest of ideas; kind of inefficient.)
(Of course, reading the C++ specification purely to disambiguate the C# specification for the goal of learning C# is not exactly the greatest of ideas; kind of inefficient.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement