I cut my teeth on an Apple II! Learned programming in assembly language on a Z80 processor. And quickly moved to Fortran and C. I have been out of the electronics and computer programming for over 20 years and am just amazed at what the people can now program. Gone are the days of trying to fit code into 2K of memory!
With my youngest starting college, I am once again getting reacclimated with C++ and am amazed at the extension of this programming language. Then I discovered visual C++. WOW! Even an oldtimer can get into the new stuff!
Remember the Intel MDS80, the development system for the MCS-48 series processors? If I remember right the system had two 8" floppy drives, and that's the machine we used to write the 1K of code we squeezed into an 8048. At one point the place I worked at had lost the ability to move the source code out of the MDS80 and its 8" drives, so I once had to type all the code into my new flagship machine, a `286 PC clone. It was a huge improvement, though, because I could assemble (not compile, this was Assembly) in as little as five minutes. Yup, just type into the command line on the PC, and walk down the hall for a cup of coffee. When I came back from the cafeteria I'd pull a windowed part out of the uV eraser, burn the HEX file with my Needham programmer and start debugging the latest change.
There isn't a day I don't marvel at how far embedded software development has come, and what what the next big change will be.
Very nice historical synopsis on coding! I always appreciated having to learn assembly as it gave me an understanding of what was really happening at the bit level, but I also deeply appreciate the evolution of higher level programming languages to get the job done. I think it is important for an engineer to learn low level programming so that they have low level control when needed, but can also use higher level languages to implement solutions that meet customer and project criteria and compatibility requirements.
Nice retrospective, Cabe. I think the time will come when all engineers will have to have good programming skills when they leave college (not just one or two classes in programming). I don't think that mechanical engineers will be able to avoid it. From what I can tell, though, engineering curriculums don't seem to be making that a priority yet, but I think the time is coming.
Charles, now a day’s programming and computer literacy is a mandatory for all the engineering branches. Even mechanical and civil graduates are doing programming courses, inorder to grab a job in IT domain. Moreover, now a day’s most of the branches had introduced C/C++ programming in their curriculum either as main subject or elective.
The thing is, when I was covering app programming, everything was about getting simpler and also being more visual, so even people who didn't have coding expertise could use visual tools to code to build applications. Is something similar happening in the engineering world? I am not super up to speed on CAD tools, but I imagine there is a similar trend there, no?
When I was in school FORTRAN counted for foreign language credit. We ran stacks of punchcards to the VAX gnomes. Many a student broke down in tears when they accidentally dropped their stack of (unnumbered) cards.
In the DOS days I was a BASIC guru and a whiz with Turbo BASIC.
"Electrical engineering is without a doubt one of the fastest growing disciplines today. Between the constantly changing curricula and rapidly advancing technology, engineers are required to keep themselves up-to-date with the latest tech and tools."
Cabe, we can say electrical engineering is the mother of modern engineering. In 70's there are only 3 branches like electrical, mechanical and civil. Later electrical branch is divided in to electronics, computer, communication etc. While I done my graduation in 90's all such divisions are under the electrical department.
Electrical and electronic engineering are quite a bit different from program writing, probably almost opposites. Yes, engineers do need to understand a lot about computers if they are qoing to design a system that uses or interfaces with a computer, but really, desgining circuits that actually function and are constrained by cost and size limitations is a quite different thing than creating code that is so very bloated that one person can't even read all of it, let alone understand exactly what it is doing.
William, learning a tool or software for professional work and learning a programming language is different. In some of the tools, command line access and writing scripts are very much requires for executing the batch file during simulation or synthesis. Such command line access may be difficult for most of the non-IT professionals.
That is for certain. The ability to make the process between program writing and the production of correctly functioning code can be quite daunting at best.
The closest I get to embedded code is writing detailed functional specifications that describe both the "screens" and the I/O actions in sequential detail. The challenge is that in addition to creating the description of what happens when everything goes exactly right, it also needs to describe what happens when things don't function correctly. That part requires an excellent understanding of the entire non-software portion of the system, and sometimes requires extensive discussions with the person writing the actual code. The problem there is that most programmers don't seem to be quite normal people. It is not clear to me if it is programming that makes them that way, or if they are programmers because they are that way.
Seriously doubt he ever really uttered it, but IBMs Thomas Watson supposedly said in the 1940s that there would only ever be a need for about 5 computers in the United States. Microcomputers changed that whole paradigm.
They came on the scene when computer science was making some great strides, and application software written by companies other than the computer manufacturer was really coming into its own.
BTW, AutoCAD was hardly the first Computer Aided Design software. There were numerous, completely incompatible and incomprehensible electonic drafting programs before it. AutoDesk had the vision to see that the PC would grow up.
As for Java, don't slight the contributions of Sun co-founder Bill Joy in the development and emergence of the language. Interestingly in light of recent issues with security, the license has always included a caveat that it was not to be used to program safety systems - medical, missiles, or nuclear sites.
AutoCAD wasn't the first drafting program at all, but that is when they started. Now they are an industry standard. The first "modern" as we know it CAD package that stuck. Keep in mind, Photoshop wasn't the first graphical program. The iPOD wasn't the first MP3 player either. But they are now considered the most important.
WilliamK, I agree with your perspective on the need for other skill sets beyond programming. The biggest challenge over the last number of years, and continuing into the future, is the need for multidisciplinary engineering teams that combine a broad set of capabilities from mechanical, to electrical, to electronic design and software. There's no doubt that engineers need to understand how software works but everyone doesn't need to have specific programming skills themselves.
I agree apresher. I hired a couple of CS majors for my embedded designs and quickly found that they really didn't have the proper skill set for developing embedded designs. I'm sure there are CS guys that can get the job done, but EEs perform much better with the limited resources (execution speed, memory, etc) of an embedded design and the EEs also do a better job at troubleshooting system errors since they have a better understanding of glue logic and the other components in a system.
tekochip- I think you hit the nail on the head with "limited resources." Based on my experience in interviews and seeing CS's in action, it seems many CS schools don't touch on coding efficiency.
Now that I think about it, I haven't seen strong evidence CS schools even touch on good code. Graduates seem to hit the field either "having the knack," or (to paraphrase Steve Martin,) "not have knack.)
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is