Comment Old story, lots of details published years ago (Score 0) 96
This was documented in great detail by a number of people years ago.
This was documented in great detail by a number of people years ago.
Fox opinions usually tend to be vicious personal attacks and unsubstantiated innuendoes--and sometimes outright lies. MSNBC opinions are presented in a much more civilized manner, and are less often blatant distortions of the facts.
Those people would reply that only the Christian religion is legitimate.
The bottom line of this story is a mistake that is a peril to virtually all large complex systems -- in particular (of interest to this forum), software-based systems. I see this mistake made in large complex (are there any other kind?) military systems, especially distributed ones -- my primary field of professional expertise. The context for this mistake often is that the system integrator usually prematurely farms out system components to subcontractors in as many politically important states and subcontractors as possible. Moreover, there is a DoD bandwagon called Modular Open Systems Architecture, which (like capitalism, as we have seen all too clearly) can be misapplied and exaggerated. Wouldn't I just love to describe some (very expensive) real examples
"Software engineer" encompasses a wide range of activities. I am considerably over age 40 yet I could never be replaced by (even multiple) 20-year olds. Two reasons are:
1. I have one foot in academic research, and have been not just following but advancing the state of the art and publishing hundreds of papers in scholarly journals and conferences for decades;
2. One of my job functions is to show up at the scene of a software disaster in my firetruck, assess the management and technical situation, make recommendations for how to recover, and (if allowed, which is not always) work hands-on with the engineers to help design and implement corrective software. After decades, you name it, I've been there and done that. No one much younger than I am can have had all that experience and be able to cost-effectively diagnose and solve software engineering problems. It's like internal medicine physicians: older ones have assimilated more and have deeper broader insights than younger ones.
What an ignorant comment. Just because you don't like something (and not just music) doesn't mean it is bad. Most of the composers we consider masters today received considerable criticism in their time. Each musical "period" uses its own "language" -- if you don't understand the language, you probably won't like (or at least fully appreciate) the music. Sometimes gaining sufficient understanding to appreciate something new, whether wine or music or sculpture, etc., takes time and even effort. You have to decide whether it seems to you to be worth the time and effort. I found that taking the time and making the effort to appreciate Messiaen paid off in great joy. I have not considered it worth my time and effort to appreciate Cage. That's a matter of personal judgment and not a criticism of Cage, who is very highly regarded by experts.
Pokémon are part of popular culture.
Would you prefer an encyclopedia that ignores popular culture and only talks about science and classics?
Yes--yes I would. Popular cuture" is an oxymoron.
The U.S. hasn't had an operational battleship in quite a few years. Aircraft carriers an be viewed as mobile U.S. military airports and thus are an effective tactical and strategic weapon. The only other ships scary to our enemies are our submarines, which are strictly strategic.
The Arsenal ship was very controversial for a number of reasons (e.g., lack of sufficient self-defense) and so was overcome by events: "The U.S. Navy has since modified the four oldest Ohio-class Trident submarines to SSGN configuration, allowing them to carry up to 154 Tomahawk cruise missiles using vertical launching systems installed in the tubes which previously held strategic ballistic missiles." [Wikipedia]
There is a vestigial article on embedded software on Wikipedia: http://en.wikipedia.org/wiki/Embedded_software.
A key aspect is that embedded systems and software are "reactive" in that they receive information (data, signals, etc.) from devices external to the computer system, process it, and usually (but not necessarily) send data out to devices external to the computing system. A real-time embedded system (not all are) has time constraints for completing all three of those steps.
A case can be made that programming an embedded (often real-time) system is harder than programming a non-embedded -- called a "transformational" (for obvious reasons) system. The increased difficulty is due to the programmer typically having to deal with the exogenous devices at a very low level, requiring detailed understanding of the devices' hardware. Embedded software programmers usually have some degree of electrical and/or mechanical and/or
A counter-argument can be made that programming an embedded system is at least often easier than programming a non-embedded one. That argument is based on several considerations. Embedded software is usually smaller size (e.g., lines of code) than most non-embedded software -- but in number of application domains (such as certain parts of telecommunications and military systems) the embedded software is 10's of millions of source lines of code. Another consideration is that the embedded system application software development systems and operating systems are almost always simpler than those of non-embedded systems. Whether that indeed makes embedded programming easier-- more difficult -- is specific to the systems, and also a matter of opinion.
So can just anyone be a programmer? Here I ask "Can just anyone be an embedded systems programmer -- good enough to be successful?" I assert that fewer people can be successful embedded -- especially real-time -- programmers.
I provide one piece of anecdotal support for my assertion.
In one of my former lives, I was on the faculty of both the Computer Science Department, and the Electrical and Computer Engineering Department, of Carnegie Mellon University. I created and led one of the largest research projects -- it was for embedded real-time systems -- moreover, distributed ones, thus adding a whole new dimension of complexity. We implemented our distributed real-time OS kernel directly on the bare hardware of multiprocessor nodes which we created by modifying Sun boards (a donation from Bill Joy), and then interconnected those with an Ethernet. (Yes, you can create a real-time Ethernet, or even a real-time system using standard Ethernet--a non-trivial topic out of scope here.) At that time, the standard practice for academic OS research was to implement on top of a *NIX. I was the thesis advisor to five CS Ph.D. students and five ECE Ph.D. students, all of whom did their thesis work in the context of my research project. In addition, I taught cross-listed courses attended by both CS Ph.D. students (a Ph.D. was the only CS degree CMU offered at that time) and ECE M.S. and Ph.D. students.
My experience, which was the consensus of a small group of other faculty I consorted with, was the anecdotal support I referred to: we agreed that in general our experience (note the two qualifiers) was that it was easier to educate an ECE student to be a good embedded programmer, than it was to educate a CS student (having a non-engineering -- usually math, physics, or CS bachelors or masters degree) to be a good embedded programmer. To grossly over-simplify it: the software-minded students were trained to think in terms of system and software abstractions, and lacked the fundamental mindset of an engineer that even a few EE courses (e.g., control theory) would have imbued; and most lacked even rudimentary knowledge of and experience with device hardware. The ECE students also thought in terms of abstractions -- system and hardware, and software to a lesser depth than (most of) the CS students; and their perspective was that of an engineer. They needed additional education in relevant CS principles (e.g., theory of algorithms, formal methods, software engineering).
..and the point being missed is that you can be someone who worked on cars their entire life, have a mechanical engineering degree, too - those are the guys who work on F1 cars.
The best candidates will have proper academic training AND drive. They're not exclusive!
I grew up taking apart 8-bit machines, hacking opcodes in memory and messing with analog phone lines. First I wanted to know how stuff worked.. then I wanted to know WHY stuff worked.
YMMV. It's not black and white.
I know a kid who has been a real car whiz all through his teen years. He buys cars, fixes them up, and sells them. When he graduated from high school he had a choice to make: a trade school for auto mechanics, or a B.S. in mechanical engineering. He wisely chose the B.S. He still spends hours every single day buying, fixing, and selling cars. He has a B average in his mechanical engineering education. He loves the theory and principles he learns in his courses, despite having to learn how to use tools like differential equations etc -- just like he had to learn how to use tools to repair auto engines and transmissions. His college requires two internships during the four years. He was hired by a military lab when they saw a kid with both self-taught experience and intense love for the field, plus one who is doing well in the theory and principles. The military facility kept him on the payroll after his first internship, committed to have him back for his second internship, and said they intend to hire him permanently when he gets his B.S. -- but he thinks he may prefer to get an M.S. in mechanical engineering because the B.S. coursework has been so valuable to him in his work with the military. This kid is going to be a big success. I know software engineers (note I didn't say programmers, they are not engineers, but the same goes for them too) who have followed this same combined path. If you don't want to get a formal degree in CS, you're almost certain to turn out to be a technician like many (if not most) programmers are. We need good technicians so that's great too.
I've noticed several design suggestions in your code.