In some recent articles I have read I have found that in the programming ladder compiler design is always considered as highest level activity. Why is this so? Why not database design or network protocol architecture.
Here is one such article.
|show 1 more comment|
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
Well, AFAIKS, the basic idea with the list in the article you link to is: the more you have to do with algorithms the more complex the programming is. And continuing on that, I think I can safely state that by "programming" I don't just mean software development, but any kind of programming action (as the article states). Finding an optimal way to fit as many empty cans and bottles into a cardboard-box so as to minimize the trips to the garbage bin is definitely more complex than just throwing them in there and carrying them out in as many trips as needed.
With this in mind you can roughly divide the various portions of the list such that they contain only items that fall in to one of the following categories
At any rate, that's what I get from the article (and from your question), and I agree with this categorization. I.E. this is one way to categorize the complexity of a given software development task, and it would work well.
However, how to decide which one is the most complex item in one category is a different issue. Let's take the most complex ones, where we can safely say that we have compilers and 3d game engine development. Now, one of my college projects was the creation of a simple compiler for an even simpler pseudo-language. I did it, I passed the class. However I'm pretty sure that THAT task is far less complex than making the Unreal engine. On the other hand I've also made a basic game engine on top of OpenGL (ES 1.0). Even though it can only be used for "2d looking" games (only uses ortho projection and does animated sprites via textures on quads) it can theoretically be called a 3D game engine, as it is some sort of a game engine and it uses a 3d graphics library. Sadly, in this case as well I'm sure it was NOT a more complex task than developing the gcc. Such fine categorization depends strongly on context.
Actually, the article states
I think there is no common consensus about what you state in your title. Of course, design of programming languages (and implementing a compiler for it) is a sophisticated task, at least more sophisticated than programming your video recorder (although - thinking about some videorecorders - ... Im am just kidding).
Designing a simple mini-language is not hard at all. But the task gets very sophisticated when you want to design a new, useful general programming language which really has advantages about existing mainstream languages. It needs a fair amount of background theory, a lot of knowledge about strengths and weaks of existing programming languages, and some good ideas how to improve that. Typically, to gain that kind of knowledge one will need several years. And I guess there are far more application programmers than language designers around.
So IMHO design of new general language is correctly placed somewhere in the bottom area of the list, but other programming tasks from that list also, and depending on the case those tasks may be at least equally sophisticated, only different. And don't forget the difficulty level is somewhat dependendent on the person who has to solve that task.
I think the same psychological mechanism is at play here as in the use of "it's not brain surgery" phrase. People generally agree that brain surgery is a task for the brightest because they have no idea of what's required to do neurosurgery successfully. However, they perceive this unknown task extremely complicated, hence the phrase that puts "brain surgery" at the bottom of the imaginary list where easiest tasks are at the top.
Similarly, it does not look like the author is sufficiently familiar with all the tasks on his list. For example, programming industrial control using ladder diagrams could be as complicated as industrial control using micro-controllers; the difference is in the language that is used to address the complexity of the task.
Moreover, lots of very complex tasks are missing from the list. For example, programming in microcode is ostensibly missing from the list*.
I have done several tasks from the bottom of the author's list, including designs of several simple special-purpose programming languages. I must say that the level of complexity cannot be pinned down to a specific kind of a task, only to a specific task. For example, I participated in building an enterprise application that is far more complex than an average programming language (and it included two programming languages of its own).
* I am unsure of the placement of microcode programming on the ladder: I suspect that it might be complicated, but I don't want to repeat author's mistake of assigning a disproportionally high weight to an unfamiliar task.
Well, i do agree that it is very specialized field, however it is not the highest level activity. I think it is more complex to architect an application with multiple external communication channels for an enterprise environment.
Being a high level compiler designer is very specialized and narrow set of skills that one may get only by working for that industry in several years. However, that compiler building industry might be a 1-2% of overall software development market.
However, i do agree that a good level of compiler process understanding is required to build really fast and responsive applications in any particulate language.
For example, in .NET framework languages, it is good to have understanding how MSIL is working. You can view the MSIL code with the help of a utility called Intermediate Language Disassembler (ILDASM) . This utility displays the application's information in a tree-like fashion.
I don't know if it is actually so or not. But I agree that there is a definite appeal there.
I'd speculate that this appeal may be because compiler design "closes the loop", so to speak: the compiler is a central tool of systems programming, and the cross-disciplinary difficulty of compiler design makes it the crux in terms of being able to understand the entire system.
So, if you're putting together a set of CS degree requirements, and you want the degree to represent some level of general mastery of the field, it makes sense to include a compiler design course.