I occasionally run across this term. If the members of this group have a clear boundary between themselves and members of other groups, then please tell me the names of the other groups. If what members of those groups work on is not intuitively obvious, than will you give me a super brief description of what those group do? Thanks so much.
Regarding the term I asked about (and the others presumably), is this term relevent today? Does it have a precise meaning that a professional should clearly understand. Thanks if you can help.
Thanks for showing me that. The reference to the term I ran across recently was from a 2000 book on preparing for technical interviews. The focus of the book was getting ready for answering questions like "what is recursion and how would you apply it?" This book made a few references to "Systems Programmers and Web Programmers." This Wiki entry seems consistent with that ("systems programming aims to produce software which provides services to the computer hardware") since as far as I know, all web programming is application programming. I'd be interested in knowing if it makes sense to group programmers into those two sets before further categorizing them?
The wiki definition was quite good.
.
I managed a Systems programming group during the 70s and 80s, we considered that we worked on the infrastucture software whereas the application guys looked after the busines programs. It was an IBM mainframe site and IBM delivered a DIY computer system. Their guys put in the hardware and gave you a bunch of tapes to instal the software, you had to tailor it to your requirements, what hardware you had , what priorities etc etc, this was of course followed by regular PTF (program temporary fix- what a misnomer- tapes) to correct errors. We also installed OEM software where IBM's ogffering was poor or not available and wrote general macros, high performance subroutines. Oh and we provided a debuging service to the application guys.
To sum up the Systems Programmers were the Creme de la Creme of the programers, we always recruited the worst applications programmers as they had had the most experience of debugging
I jest.
There are gradations. In older schools of programming, you had the Apps gurus, the Systems gurus, and some "power programmers" who weren't necessarily writing systems code but who WERE taking advantage of really advanced design issues not normally covered by the Apps gurus.
The ultimate systems programmer writes operating systems and modules within the operating system, intrinsically and inextricably linked to the O/S. (The "inextricable" part comes from USA requirements for specific interfacing rules when dealing with an O/S, to prevent "spoofing" and other means of invading the O/S.)
Next below that comes device-driver and system service writers. The latter two are similar in many ways. Device drivers interface directly to a device and provide I/O services to users wanting to use that device. Therefore, they must know the nature of the O/S and its interfaces. Service providers include things like TCP/IP services, terminal services, FTP services, and various other things that are separable from the O/S but that when present, usually must interact with it on an intimate level.
Somewhere in here is the language writers - creators of compilers and interpreters for the languages we use. The language writers must totally understand the hardware and the O/S as well. They are the folks whose skills allow us to turn A = B + C into a sequence of instructions like
Code:
MOVF B, R0
ADDF C, R0
MOVF R0, A
Next in line come the gurus of middle-ware, the software that stands between the O/S and an end application. These things must be written efficiently but can make use of the device drivers and other services available from the inner layers of the O/S. A case in point is the way ORACLE works on many systems. A support task sits in the background. When you ask for data, a child process gets spawned to service your request. The parent ORACLE task is a traffic cop, more or less.
Middleware can usually be identified by its ability to be customized or further programmed beyond its base level. Access is NOT usually middleware - more like a tool, see below. More complex DB software that uses ODBC or other API software to allow external programs to define "things" COULD fall into the middleware category. Middleware is usually the software on which you erect the supporting scaffold to build your specific application. Access meets this latter part of the definition, so I would not dispute the argument if you chose to make it - that Access is middleware. Since it CAN talk to ORACLE while you build your application, you might have a point.
Other types of middle-ware include the writers of SSL or other utilities that support the creation of message digests and file encryption/decryption. They can use standard file I/O services but often need to write supporting DLL files to provide an API for you user code.
Below the middle-ware gurus we find the toolsmiths. They are close to the middle-ware gurus and I would not be surprised to find that some folks don't see the distinction. Tool smiths write tool programs that help applications programmers do their jobs. These tools might use only the published interfaces of an O/S, driver, or item of middleware. The tools are often at the same level of complexity as an applications program, with the single distinction that they are too generalized to fall under the final category.
At the far end of the list (away from O/S), you find the applications gurus who know how to make things work when solving real-world problems. The apps folks have a business issue to solve and must know as much - or more - about their problem as they know about programming.
I would not wish to demean anyone. This isn't as much a top-to-bottom hierarchy as much as it is a left-to-right array showing fine (and arguable) gradations from O/S to applications, where as you go more towards the Apps side, you are more and more likely to have a primary topic of interest as the driving force in programming. More to the O/S side, your problem IS the computer and not some external business issue.
Another difference is that the farther towards the O/S you go, the more you need to know the hardware's limitations. The more towards the Apps you go, the more likely it is that you will be using tools and middleware that hide the hardware from you.
These days, the distinctions have blurred a lot and I won't quibble with anyone who says that "X" should be before "Y" in my list. Folks who WOULD quibble will find no resistance on my part, because only the two endpoints are fixed. In between, it is a free-for-all to decide the order of programmer types.
Web programmers fall into the applications side since their application is using web design tools and the web server middle-ware or service (one of the blur cases) to build some pages that target the application.
So ... to answer the question: Yes, it makes sense to group programmers into their fields of expertise, with the understanding that it is closer to a continuum than a quantum leap between the sub-disciplines.
Another way of looking at it is that programmers can be System programmers or application programmers in the same way that surgeons can be brain surgeons or heart surgeons etc. One is not better than the other - they just have different areas of expertise.
In my career I have done both at different times. The skills are transferable in the same way that surgeons skill is transferable.
