|
Fresh lemon juice and a light sprinkling of white sugar; never syrup.
|
|
|
|
|
megaadam wrote: This is not an answer, it is just a reflection...
He's a novice. I don't think he should START OUT with reflection. Surely, that can come later... 
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
|
|
|
|
|
megaadam wrote: I have seen even experienced Java coders with very vague understand of what a stack is
FFY. 
|
|
|
|
|
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.  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.
|
|
|
|
|
Quote: 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.
My 'first' was BASIC and no, I don't.
|
|
|
|
|
Now that you mention it... I should have qualified it: The first serious language...
(I started with BASIC, too, when the language was so basic that variables were named A - Z, A0 - Z0 up to A9 - Z9. 286 numeric variables maximum, and 26 string varibables A$ - Z$. You are right: That doesn't bring up any joyful memories. In fact, I had suppressed that memory entirely.
|
|
|
|
|
I can't say I have many fond memories of the languages I subsequently worked with: Fortran, Coral and Pascal. It was only when I got to use C, fairly late in my career, that I started to feel at home.
|
|
|
|
|
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 an excuse  . Lots of Linux fans insist that the only efficient way of solving a problem is through a 1970s style command line interface (not just for developers - there are lots of end user Linux tools with a CLI). When Windows Phone failed, and *nix solutions took nearly 100% of the phone market, noone ever asked for a CLI on their Androids or iPhones. A GUI is perfectly fine in a phone context, but lots of Linux fans still detest it on the desktop, refusing to use a GUI themselves, and usually very reluctant to develop good GUI end user tools.
So while some semi-oldtimers say "OK, we'll tolerate fullscreen editors like vi, but no more - no VS-type IDEs!", I think that their days are counted. Android proves that even in the Linux world, CLI is dead and GUIs have come to stay. Right now, most people belive that the Android or iPhone (they are not that different!) UI is the way a phone is; there are virtually no alternatives. For software development, there most certainly are alternatives to VS / WPF. It seems more like those who frown at VS / WPF do so because they see VS / WPF as a too strong competitor to their own favorite IDE. If users still stick to it after ten years, there may be reasons for it. After ten years as a developer, you cannot possibly have overlooked the alternatives.
|
|
|
|
|
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.
|
|
|
|
|
RS-232 is still the most used communication interface in the industrial world. Pieces like actuators, detectors, various generators, PLCs are still controlled through RS-232 and RS-422 ports, with adapters and interfaces that often need a direct control on the pins because they are of course not standard. MODBUS specifies link layer strata only for RS-232 and TCP/IP and every other interface uses virtualizers which have to be configured if not resoldered to comply with pinout restrictions.
The FP format affected me when writing custom assembler libraries for high speed copmputations on complex data in real time. I had to convert data from single and double precision to fixed point without using the slow CISC instructions provided by IA-32.
Stack frames are a freaking-need-to-know when inserting Assembler snippets and calls inside a mixed C#/C++/VB6 environment, not knowing it means a GPF and software crash.
Rotary phones... no those aren't a thing anymore, they just ended up into the quoted text because you like to mix apples, oranges and shotguns to prove points that you cannot (Schopenhauer's book works only on those who dind't read it).
I'm working on scientific software which has to take vital decisions in real time inserted on production lines, with equipment that ranges from brand new to 30 years old.
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 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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
