Book Recommendation
-
Which books would you recommend to someone who is novice to programming and have interest to dive in to the world of software development. I am specifically asking for .NET Technologies.
TutorialsPoint has some nice online tutorials, e.g. C# Tutorial[^] Bit dated, they use VS2010, but a good introduction to C#, they even have an online IDE to dabble in.
-
Which books would you recommend to someone who is novice to programming and have interest to dive in to the world of software development. I am specifically asking for .NET Technologies.
I personally found "CLR via C# 4th Edition" very helpfull.
"Coming soon"
-
I personally found "CLR via C# 4th Edition" very helpfull.
"Coming soon"
-
Along with my previous suggestion of following some formal courses, if you can't or don't want and you are starting from zero following the self taught way, I suggest you Teach Yourself the C# Language in 21 Days, SAMS publishing. I do not have any experience with that specific book but at the time I used the VB6 edition. It is not the best way to learn and will yield only mediocre results without a more abstract knowledge of programming itself but I managed to learn how to program (very badly but usually getting the results I wanted) aged 14.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
I managed to learn how to program (very badly but usually getting the results I wanted)
It's like that for all of us. You can't expect to code perfectly from the beginning. I have noticed that the quality of my code has improved steadily over the years as I have learnt new best code practices from every project I've been involved in.
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain -
den2k88 wrote:
I managed to learn how to program (very badly but usually getting the results I wanted)
It's like that for all of us. You can't expect to code perfectly from the beginning. I have noticed that the quality of my code has improved steadily over the years as I have learnt new best code practices from every project I've been involved in.
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark TwainAye but the difference in thought pattern I experienced from self taught to formally taught was amazing - so much that it later made me choose Computer Engineering instead of Computer Science due to the stronger focus on thought pattern and problem solving. Then I started working and my code and solutions improved dramatically over the years and are improving more and more with each project.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
Aye but the difference in thought pattern I experienced from self taught to formally taught was amazing - so much that it later made me choose Computer Engineering instead of Computer Science due to the stronger focus on thought pattern and problem solving. Then I started working and my code and solutions improved dramatically over the years and are improving more and more with each project.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
Cool. I think I've always had the correct thought pattern. For me, the code quality improvements have mostly come from knowing what can be done, how you do it in the best way, what functionality your chosen frameworks have to offer and what technologies to use. In the beginning, I would do something that may have worked, in a strange and complicated way simply because I didn't know that a better and easier way existed. The how-to knowledge comes from experience over time, but also from sharing ideas with your fellow collegues. Nobody knows everything about everything... :-D I shudder when I look at code I wrote 10 years ago (in the cases where I actually understand what it does and remember that it WAS in fact I who wrote it and not a five year old on drugs) :~
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain -
Not really beginners stuff, but the "C# in a nutshell" series from O'Reilly by Albahari is amongst my favourites: C# 7.0 in a Nutshell - About the Book[^]
I got quite a bit out "HeadFirst C#) while I was teaching myself C#. Head First C#, 3rd Edition - O'Reilly Media[^] I was already a proficient C/C++ programmer so I don't claim I was a total newb. My first C book was "The C Programming language" by Kernighan and Ritchie (original edition, yes I am pre-dirt). I am a huge fan of the Steve Oualline's work also. His Practical C Programming and Practical C++ Programming were very helpful to me in my progression. Horribly obsolete from a toolchain standpoint, but his explanations of the languages themselves (at least as they were in the 90's) are extremely clear and logical.
-
This is not an answer, it is just a reflection... Is it this person that wants .NET or is it your idea? Personally I would recommend building programming knowledge on a solid foundation from the ground up. With a language that does not need specific frameworks and IDEs. I have seen even experienced Java coders with very vague understand of what a stack is, makes me a tad sad. But maybe that is just me. :cool:
... such stuff as dreams are made on
megaadam wrote:
have seen even experienced Java coders with very vague understand of what a stack is, makes me a tad sad.
I belong to the generation knowing what a stack is. An interrupt handler. How a virtual function is (or rather: ways that it can be) implemented. What microdoce is. And then I know car drivers who can't explain how a combustion engine works. They can't explain a gear box. Or why a car is packed with relays while you home isn't. Yet they can make use of a car for getting work done, even though the inner mechanics are unknown to them. Sometimes, knowing the inner workings can be a barrier. There are certain aspects of C#/WPF dependency properties and bindings that I do not know how are (or might be) impelemented, and that takes a lot of my attention: I am not capable of just using it without knowing the workings, as the younger generation does, but spend significant energy on trying to deduce from the behaviour how it is done. (No, I have not gone into the source code. Maybe I should.) There will always be a far more things that you do not know how works than those you understand. Try to always understand the workings one layer down from what you "have to" understand, but not ten levels down. You don't have to understand the theoretical models of P/N-junctions to program C#. You may not even need to know the static and dynamic link locations of a stack, whether stack frames are allocated continously or on a heap, whether or not threads stacks link back to the stack frame from which it was started, differences in stack allocation for processes vs. threads. What you need to know is at a far more elementary level. Like the gearbox in you car: You need to know to use a higher gear at higher speeds, lower gear at lower speeds. And if you have an automatic gearbox, you don't even have to know that.
megaadam wrote:
With a language that does not need specific frameworks and IDEs.
Like, "I would recommend learning to drive a car that doesn't have a synchronized gearbox, but requires you to double-clutch, to make you understand how the real thing is". ... I guess that I disagree. Both with cars and IDEs.
-
megaadam wrote:
have seen even experienced Java coders with very vague understand of what a stack is, makes me a tad sad.
I belong to the generation knowing what a stack is. An interrupt handler. How a virtual function is (or rather: ways that it can be) implemented. What microdoce is. And then I know car drivers who can't explain how a combustion engine works. They can't explain a gear box. Or why a car is packed with relays while you home isn't. Yet they can make use of a car for getting work done, even though the inner mechanics are unknown to them. Sometimes, knowing the inner workings can be a barrier. There are certain aspects of C#/WPF dependency properties and bindings that I do not know how are (or might be) impelemented, and that takes a lot of my attention: I am not capable of just using it without knowing the workings, as the younger generation does, but spend significant energy on trying to deduce from the behaviour how it is done. (No, I have not gone into the source code. Maybe I should.) There will always be a far more things that you do not know how works than those you understand. Try to always understand the workings one layer down from what you "have to" understand, but not ten levels down. You don't have to understand the theoretical models of P/N-junctions to program C#. You may not even need to know the static and dynamic link locations of a stack, whether stack frames are allocated continously or on a heap, whether or not threads stacks link back to the stack frame from which it was started, differences in stack allocation for processes vs. threads. What you need to know is at a far more elementary level. Like the gearbox in you car: You need to know to use a higher gear at higher speeds, lower gear at lower speeds. And if you have an automatic gearbox, you don't even have to know that.
megaadam wrote:
With a language that does not need specific frameworks and IDEs.
Like, "I would recommend learning to drive a car that doesn't have a synchronized gearbox, but requires you to double-clutch, to make you understand how the real thing is". ... I guess that I disagree. Both with cars and IDEs.
It almost seems you "want" to misunderstand what I am saying. :cool: So please let me try again. I am saying if you learn WPF and WPF only you can of course become a great WPF coder. But I think there is some risk that you will be conceptually be stuck in "WPF is programming" which will hurt you outside that bubble. And I have observed this phenomenon. You have observed the flipside of it. Both exist. I think the first is worse, that's all.
... such stuff as dreams are made on
-
It almost seems you "want" to misunderstand what I am saying. :cool: So please let me try again. I am saying if you learn WPF and WPF only you can of course become a great WPF coder. But I think there is some risk that you will be conceptually be stuck in "WPF is programming" which will hurt you outside that bubble. And I have observed this phenomenon. You have observed the flipside of it. Both exist. I think the first is worse, that's all.
... such stuff as dreams are made on
I have observed the same thing, but much stronger, in networking. 9 out of 10 Comp.Sci graduates believe that TCP/IP is networking. If you try to introduce them to e.g. connect ID (rather than the full IP address and TCP port no), to end-to-end routing at the physical layer, out-of-band signalling or different addressing schemes, they give you a blank stare: That's not the way it is done! You see it in all sorts of software: Whatever concept or abstraction you try to introduce, a farir share of programmes will answer "Oh, but we don't need that, we will just so so-and-so using our old tools". People will always be stuck in their old habits, at least until they have been forced to work with five or six alternate ways of doing things. But one way must be the first! It is far better to make C# and Visual Studio your first, much better than assembly language (or even K&R C), vi and gcc. The major disadvantage is that if you are later forced to work in K&R C using vi as you "IDE", it feels like moving from a modern apartment into a stone age cave. The first language / environment you learn is like your first sweetheart - you'll carry joyful memories from that time for the rest of your life. I started (serious) progrmming in Pascal, and 30+ years later, I still miss some of its features in today's languages. Similarly, you must expect people who start out with WPF / VS to have sweet memories of that when they are forced to switch to vi (and I won't blame them :-)). I don't think that is a good enough reason for making a poorer choice for a beginner's toolset.
-
-
Along with my previous suggestion of following some formal courses, if you can't or don't want and you are starting from zero following the self taught way, I suggest you Teach Yourself the C# Language in 21 Days, SAMS publishing. I do not have any experience with that specific book but at the time I used the VB6 edition. It is not the best way to learn and will yield only mediocre results without a more abstract knowledge of programming itself but I managed to learn how to program (very badly but usually getting the results I wanted) aged 14.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
Teach Yourself the C# Language in 21 Days, SAMS publishing.
This. The SAMS books are a great starting point. While some criticize the series -- these are a starting point, not the ultimate resource. Most programming books are far too complicated for beginners, and often more complicated than necessary for experienced programmers learning a new skillset. The SAMS books will walk you through discrete lessons, each is doable in an "hour". The first 8 lessons (or so) are typically chaff to an experienced programmer, but for a beginner they walk you through the basic concepts AND use practical lessons to cement the learning. Please note that learning a languages is only a tiny part of programming. While you'll pick up smatterings of concepts along the way, it's critical to learn logical programming, data structures, screen design (if doing GUIs), etc.
-
That was meant ironically, wasn't it? I've got that book, and read significant parts of it. It provdes lots of information for the (very) experienced / advanced programmer. I would certainly recommend it, but for that audience, not for the beginner.
-
megaadam wrote:
have seen even experienced Java coders with very vague understand of what a stack is, makes me a tad sad.
I belong to the generation knowing what a stack is. An interrupt handler. How a virtual function is (or rather: ways that it can be) implemented. What microdoce is. And then I know car drivers who can't explain how a combustion engine works. They can't explain a gear box. Or why a car is packed with relays while you home isn't. Yet they can make use of a car for getting work done, even though the inner mechanics are unknown to them. Sometimes, knowing the inner workings can be a barrier. There are certain aspects of C#/WPF dependency properties and bindings that I do not know how are (or might be) impelemented, and that takes a lot of my attention: I am not capable of just using it without knowing the workings, as the younger generation does, but spend significant energy on trying to deduce from the behaviour how it is done. (No, I have not gone into the source code. Maybe I should.) There will always be a far more things that you do not know how works than those you understand. Try to always understand the workings one layer down from what you "have to" understand, but not ten levels down. You don't have to understand the theoretical models of P/N-junctions to program C#. You may not even need to know the static and dynamic link locations of a stack, whether stack frames are allocated continously or on a heap, whether or not threads stacks link back to the stack frame from which it was started, differences in stack allocation for processes vs. threads. What you need to know is at a far more elementary level. Like the gearbox in you car: You need to know to use a higher gear at higher speeds, lower gear at lower speeds. And if you have an automatic gearbox, you don't even have to know that.
megaadam wrote:
With a language that does not need specific frameworks and IDEs.
Like, "I would recommend learning to drive a car that doesn't have a synchronized gearbox, but requires you to double-clutch, to make you understand how the real thing is". ... I guess that I disagree. Both with cars and IDEs.
A car driver is an operator, i.e the END USER. A programmer is an engineer, if a car gets in the market and it's realized by someone who dind't know what he was doing bad things are bound to happen.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
Which books would you recommend to someone who is novice to programming and have interest to dive in to the world of software development. I am specifically asking for .NET Technologies.
Why not start agnostic to any technology? If this person is really interested in software development as a discipline get a set of "The Art of Computer Programming" by Donald Kunth. Might as well just jump right in. :-}
-
A car driver is an operator, i.e the END USER. A programmer is an engineer, if a car gets in the market and it's realized by someone who dind't know what he was doing bad things are bound to happen.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
The world is not split in two: End users and builders/developers/engineers. You find end users at all levels. A programmer is the end user of a compiler. Or an operating system. Or an IDE. This holds particularly true for a novice programmer. An engineer / developer creating an IDE, or a new compiler, is an end user of some of his tools. He definitiely is an end user of the CPU. The CPU architect is an end user of logic gates. ... And so on. An end user is anyone that uses any technology without being involved in the creation or modification of that technology. When you play the role of an end user, you don't have to know anything about how things are implemented, but sometimes it is of great help. The question is where to draw the line: As a car end user you should know the difference between an electric motor and a combustion motor, but you need not know the details of different kinds of suspension. A programmer needs to know the difference between source code, a compiled library and an executable, but will a novice programmer need to know the details of a stack frame? Lots of things that mattered thirty years ago to "end users" doesn't matter today. Then, you certainly should know how to replace the spark plugs and headlight bulbs. With electric cars and LED headlights, that knowledge is about as useful as knowing how to shoe a horse. When did you last experience a flat tire? When was the last time the cooling agent in your engine was boiling and you should know that you must let it cool down before you remove the lid to add some cold water from that mountain creek runnning along the road? (That wasn't uncommon when I was a boy, but I haven't seen it for at least thirty years now.) There are similar things in programming. As a student, I learned about 1- and 2-complement, about normalised and un-normalised and hidden bit floating point. What use is there of that knowledge today? Even that stack frame static link is more or less of historic interest only. RS232 pinouts are history. Rotary dial analog phones are history. But once upon a time, even end users would have to know lots of these things. I think that the "semi-old guys" tend to be ones being most insistent on recently-abandoned technology being essential for the upcoming crop of engineers / developers / programmers. Those old enough to have seen four or five generations of technology pass by, are more relaxed and can more easily accept that yet another technology is turning into obsolence. Sometimes, all we wait for is
-
The world is not split in two: End users and builders/developers/engineers. You find end users at all levels. A programmer is the end user of a compiler. Or an operating system. Or an IDE. This holds particularly true for a novice programmer. An engineer / developer creating an IDE, or a new compiler, is an end user of some of his tools. He definitiely is an end user of the CPU. The CPU architect is an end user of logic gates. ... And so on. An end user is anyone that uses any technology without being involved in the creation or modification of that technology. When you play the role of an end user, you don't have to know anything about how things are implemented, but sometimes it is of great help. The question is where to draw the line: As a car end user you should know the difference between an electric motor and a combustion motor, but you need not know the details of different kinds of suspension. A programmer needs to know the difference between source code, a compiled library and an executable, but will a novice programmer need to know the details of a stack frame? Lots of things that mattered thirty years ago to "end users" doesn't matter today. Then, you certainly should know how to replace the spark plugs and headlight bulbs. With electric cars and LED headlights, that knowledge is about as useful as knowing how to shoe a horse. When did you last experience a flat tire? When was the last time the cooling agent in your engine was boiling and you should know that you must let it cool down before you remove the lid to add some cold water from that mountain creek runnning along the road? (That wasn't uncommon when I was a boy, but I haven't seen it for at least thirty years now.) There are similar things in programming. As a student, I learned about 1- and 2-complement, about normalised and un-normalised and hidden bit floating point. What use is there of that knowledge today? Even that stack frame static link is more or less of historic interest only. RS232 pinouts are history. Rotary dial analog phones are history. But once upon a time, even end users would have to know lots of these things. I think that the "semi-old guys" tend to be ones being most insistent on recently-abandoned technology being essential for the upcoming crop of engineers / developers / programmers. Those old enough to have seen four or five generations of technology pass by, are more relaxed and can more easily accept that yet another technology is turning into obsolence. Sometimes, all we wait for is
Member 7989122 wrote:
There are similar things in programming. As a student, I learned about 1- and 2-complement, about normalised and un-normalised and hidden bit floating point. What use is there of that knowledge today? Even that stack frame static link is more or less of historic interest only. RS232 pinouts are history. Rotary dial analog phones are history. But once upon a time, even end users would have to know lots of these things.
You just described my last 6 years of work.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
Ehsan Sajjad wrote:
I am specifically asking for .NET Technologies.
Too bad. I would have recommended the Harry Potter books, but wizardry is more useful in the javascript/jquery area... :doh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark TwainI like the Terry Pratchett "Disc World" books better. Harry Potter series is good but comes in fourth behind any of the Douglas Adams books (2nd), or William Gibson books (3).
"Newer" is not automatically better, just different.
-
Member 7989122 wrote:
There are similar things in programming. As a student, I learned about 1- and 2-complement, about normalised and un-normalised and hidden bit floating point. What use is there of that knowledge today? Even that stack frame static link is more or less of historic interest only. RS232 pinouts are history. Rotary dial analog phones are history. But once upon a time, even end users would have to know lots of these things.
You just described my last 6 years of work.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
You just described my last 6 years of work.
So you are working in a computer museum? :-) Serously: I am curious - can you give us some details? Are you really using 1-complement ALUs? (Which machines in regular operation use 1-complement today?) There are non-754 FPs out there, but in which ways does the actual format affect you? If static link affects you (as in Pascal), what do you need to know underneath the source code level? RS-232 certainly is relevant in a few contexts. Mostly, newer standards have completely taker over. So what is your RS-232 application? There still are rotary dial phones out there, but I am surprised to here that anyone still do any development or other work related to such. So, I am really curious to know what kind of systems you are working with.
-
Which books would you recommend to someone who is novice to programming and have interest to dive in to the world of software development. I am specifically asking for .NET Technologies.
My recommendation would be 'C# 6.0 and the .NET 4.6 Framework' by Andrew Troelsen and Philip Japikse [^].