|
I agree with much of what you say; however, I disagree with your premise that a developer doesn't need to know HOW something works. Frameworks are created and abandoned with such intense frequency today that without understanding the basics of those frameworks, it is impossible to know how to proceed forward with the maintenance of software. Far too many developers seem to believe that the software life-cycle is write brand new, leave it and move to a new project. Instead, most software lives a long time with many changes needed through the years. Unless those initial developers and the maintenance engineers who come along have a mutual understanding of HOW coding works, the changes are doomed to fail.
Our industry is the current equivalent of urban development: tear down whatever currently exists and build new, over and over. That process keeps the money flowing and builders happy UNTIL there is no money to flow when the entire infrastructure breaks down. At that point, those who understand the basics survive, and those who do not become part of the unemployed masses.
|
|
|
|
|
I certainly think you should know the workings of the layer you build your software on, directly below your layer, but not ten layers down. But: You should distinguish between architecture and implementation: The data structures, interactions between functions etc. are essential. If your understanding of the layer below you breaks down if the 32 bit CPU is replaced by a 36 bit CPU (are they still made?), then you have spent your resources wrongly. Or, if the layer below is re-implemented in a different language, but offering the same call interface.
I am sceptical to the current trend of googling to find the call interface documentation, and start using it without knowning anything about the architecture below. If I complain, nine out of ten times someone suggests: But it is open software - you can download it and see how it works! ... No, the implementation is NOT the architecture! When you ask for an architetural drawing and is given a house, and told: You can make your own drawing of this house, can't you? then you are wasting my time.
You rarely find software "architectural drawings" by googling, that which is independent of coding / implementation. I see that as a big problem. Even more I am outright scared over how large fraction of young software developers, those educated after google, appears to think it is perfectly fine. If it works, there is nothing to worry about. If not, you google for a quick fix. Ask them why that fix cured the problem, and they shrug: "Don't know, but it works now. Good enough for me!" That is not a good approach for writing robust software. And lots of software written today is not robust.
|
|
|
|
|
I qualify as an "old timer" and am still working albeit about as far away from my earliest software work as could be.
I wouldn't use VI unless my life depended on it not because of any aversion to full screen editors. I'd rather use notepad.
Now as to "old timers" and abandoned technology, even though I spent first 15-20 years of my career programming ASM on various machines writing everything from OSs to devices driver, to compilers, etc. do I use ASM today, or prefer it? I use the most efficient tool appropriate to the task at hand.
As for teaching ASM, I do wonder where the ASM programmers will come from to write the inevitable code that cannot be written in C (or whatever high level language you choose). Somewhat amazing to me that a computer science major can graduate w/o understanding how a computer works, at least at the basic level of ASM.
Black Hats cannot be the ONLY folks that understand ASM or we're all in a lot of trouble.
|
|
|
|
|
The only programmers who really need to know the machine code (whether considered as binary instruction codes or symbolic assembly language) will be compiler writers. Knowing all the details of the instruction set, adressing modes, status bits etc. is highly specialized knowledgde, needed by very few others. It is like the huge matrix models managed by meteorology software, implementing trancendental functions for a math library or the light model of a 3D graphics package.
We didn't learn meteorology or FEM algorithms in college; those who need it, learn it at work (or maybe they study meteorology in college and learn programming at work). We did learn the transistor design for dynamic and static RAM cells - never needed it! We did learn the series expansions for trigonometric functions - never needed it. We did assembler programming exercises, and I did need it for about five years, but not for the last 30 years. We did learn nine (or was it eleven) different disk scheduling algorithms, made completely irrelevant by disks with megabytes of cache and virtualized track/sector numbers. We learned lots of ways to manage a heap; I used the knowledge for twentyfive years, fully convinced that nothing could beat explicit malloc/free. Then I read about CLR garbage collection (in "CLR via C#"), and had to admit that "Oops, I never though of that ... and that and...".
No doubt: CLR garbage collection is a lot smarter than any memory handling I have coded myself. Any modern compiler makes optimizations that you never would have thought of. My company develops processing modules for embedded systems: I don't think there is a single assembly instruction anywhere in our code. Even our in-house CPU extensions, on-chip "peripherals" (like BT radio, encryption unit, sensor interfaces etc.) are managed through general C library functions.
I am not sad that young programmers no longer learn the transistor design of a flip-flop, how to use Newton's method when implementing a math function library or to judge FCFS against elevator disk scheduling. Such knowledge doesn't help you write values to RAM in a better way, to aim that flame thrower in the right direction with higher precision or reliability, or to sort the queue of two entries in the most efficient way before sending the request to the disk.
Programmers still need an understanding of a lot of hardware aspects: Word length / numeric range and limited FP precision is one prime example. But that is on the architectural level, not implementation. We should be very much aware of where we spend teaching resources, spending time on essential problems first. Such as: Make sure that students learn about computational complexity, rather than optimized register use. Computer history can be fun, and can very well be presented in an appendix or a side bar, but students need to learn useful stuff before history.
|
|
|
|
|
|
That was in my mind too, but i thought it might look little complex to someone who is novice to programming
|
|
|
|
|
Then I suggest you follow some entry level course first (it should be possible to follow only slect courses at the local university without fully enrolling) because programming is first of all a forma mentis [literal: shape of the mind], a way to think, dissect and solve problems. It requires a lot of exercise and a bit of tutoring helps, epsecially with ome formal knowledge.
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
|
|
|
|
|
I got quite a bit out "HeadFirst C#) while I was teaching myself C#.
<a href="http://shop.oreilly.com/product/0636920027812.do">Head First C#, 3rd Edition - O'Reilly Media</a>[<a href="http://shop.oreilly.com/product/0636920027812.do" target="_blank" title="New Window">^</a>]
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.
|
|
|
|
|
Google.
It's free.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
yes but for a student i would prefer him to first do some reading
|
|
|
|
|
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
|
|
|
|
|
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...
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
modified 7-Feb-18 8:58am.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
I personally found "CLR via C# 4th Edition" very helpfull.
|
|
|
|
|
Yeah, can't get more novice than that.
... such stuff as dreams are made on
|
|
|
|
|
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.
|
|
|
|
|
Ironic? Qui? Moi?
Have a guess!
... such stuff as dreams are made on
|
|
|
|
|
Yeah, that's a good one, as i myself had read first few chapters but not able to finish the book yet
|
|
|
|
|
My recommendation would be 'C# 6.0 and the .NET 4.6 Framework' by Andrew Troelsen and Philip Japikse
[^].
|
|
|
|
|
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. :-}
|
|
|
|
|
Why not go down to the basics and buy a box of transistors and a soldering iron, putting together your own machine?
When my technical university started teaching computers around 197s, they actually had one computer (NORD-1) delivered as components. The professors though it a good idea that the students got hands on experience in building a computer, even though the architecture (down to the printed circuit boards) were pre-defined. Soldering it together was still considered a valuable learning experience. (I am not quite sure about the technology at that time - I believe it was a mixture of discrete transistors etc. and small scale integration chips, like the 74xxx series).
The oldest machine at my university, a GIER, had one side panel that was the control logic as a matrix of feritte cores, directly accessible so you could "microcode" it by pulling the conductors through or outside each core, changing the effect of each instruction code. Something like that could be very useful for a novice that really wants to get to the roots of programming
|
|
|
|
|
Well... it depends on if someone has that much time, what i wanted was to quickly get him up to speed to start understanding about c# and start writing small programs in C#, the time constraints applied to that guy and me too.
|
|
|
|
|