|
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
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
