Computer science is no more about computers than astronomy is about telescopes.
-- Edsger Dijkstra
That's for good reason. Academia is for teaching you known facts and theories, and how to think for yourself. Experience in an industry teaches you how to do a particular type of work so that other people are willing to give you money in exchange for your labor. These are inherently different activities, though the former can weed out some inappropriate candidates for the latter.
IMO the right thing is to offer degrees in Software Development, which would include some classic CS curriculum but by no means all, and we could have discussions about the right way to teach programming without people getting bent out of shape that Programming Is Not CS.
It's like only teaching general relativity and then making someone a civil engineer - after all they know the fundementals of gravity so the bridge should stay up!
The article sounds like Dijkstra in 1988. My bet is another 22 years won't change anything.
You don't expect a mechanical engineer to know the chemistry of a steel melt, and you don't expect a chemist to know about engines.
Yet in CS we either teach the detailed chemistry and expect the student to pick up the engineering themselves - or we teach just engineering without explaining what a metal is
Sort of like a linguistics professor saying "I never talk".
Linguistics is the study of language, but CS at its core is the study of algorithms and theory. A CS prof never coding is more akin to a Physics professor never designing his own bridge. Sure, he technically could if he wanted to, but that's probably still better left to the engineers.
Dijkstra said (rightly, IMO) "Computer science is no more about computers than astronomy is about telescopes." I think a corollary to that is that it's also not about programming/coding per se, but the theoretical study of techniques we use when building programs.
A Computer Science theoretician's work is somewhat more closely tied to programming. I mean, let's be serious.
And that is a big issue. A license created to meet the needs of business 40 years ago would certainly have required learning COBOL. A license created 20 years ago would have no relevance to web development. One created today would likely be geared towards the needs of large organizations with large code bases - which would put most agile development techniques, languages, and practices off the table.
For better or worse the programming world has diverse communities with rapidly changing, diverse needs, and no possible solution has any hope of fitting all of them.
As for the relevancy of licensing, I think there is a certain degree to which one could start certifying software engineers on a project management perspective, because the principals of how one approaches a project and brings it to completion aren't that different from any other project in any other industry. If you're running your project correctly, programming is maybe 10% of the project. That other 90% has a lot to learn from the rest of the industrial fields to catch up and start adopting standard practices.
A user's requirements are going to be the same no matter what programming language you use. The way you test the software is going to be the same no matter what programming language you use. Within a specific programming paradigm, how you build the software is a shear matter of syntax, all the parts are going to have to be the same. Just as you can have a suspension bridge versus a stone bridge, I think you could study object oriented programming versus functional programming, and I don't see any reason why we shouldn't expect professional, licensed software developers to know both.
COBOL, C, C#, Clojure, C-whatever-next, it doesn't matter. Wood, stone, and iron. The principles haven't changed much at all.
Huh?
Project management on a website that has an incremental 1 week release cycle has no relationship to project management of an internal database upgrade that is planned for 6 months or project management for developing a shrink wrapped game over 2 years.
The problems, documents, workflow, problems, types of people you need involved, etc are radically different in these three cases.
A user's requirements are going to be the same no matter what programming language you use. The way you test the software is going to be the same no matter what programming language you use. Within a specific programming paradigm, how you build the software is a shear matter of syntax, all the parts are going to have to be the same.
I disbelieve.
I've been in a situation where I was creating a reporting system, and was sitting in a group of people building a website. There was absolutely no similarity in requirements, testing, rollout procedures, and turnaround expectations between me and the other developers. This despite the fact that we were working in the same organization, on projects specified by the same product managers!
As for a specific programming paradigm comment, the statement seems to me to be vacuously true because you define "paradigm" to include the internal structure of the software, or else false. Because I've seen many cases where two people deliver essentially the same functionality using the same basic toolkit, but the internal organization, pieces, etc are completely different.
COBOL, C, C#, Clojure, C-whatever-next, it doesn't matter. Wood, stone, and iron. The principles haven't changed much at all.
Huh? COBOL doesn't even have recursion. C has function pointers but no closures. C# has closures but no Lisp style macros. Clojure has all of the above. The capabilities of the languages are different, and therefore the proper design and structure of software is as well.
Also where principles have not changed, people's understanding of them may. For instance take test driven development. It isn't new - when Larry Wall delivered Perl 1 in the mid-80s it came with a reasonably complete test suite. When CPAN was founded in the mid-90s the whole perl Makefile.pl, make, make test, make install routine was already standard. And the result was that Perl got a good name for being portable in practice.
However as recently as a decade ago you'd have been hard pressed to find many advocating a test driven style of development. Problems existed that it would work well for. Useful enough tools existed for people to take advantage of them. But there wasn't wide spread acceptance of that knowledge.
Today if you are a programmer and don't know the basics of unit testing, you need some remedial re-education. And a lot of organizations don't use it.
In short unit testing today is where source control was in the late 90s which is where structured programming was in the 80s. It is a good idea. It is widely recognized to be a good idea. But it is a good idea that is more honored by the breach than the observance in your average programming shop.
Also, many students fail to connect what they learn in one class to what they learn in another. Thus, we often see students with high grades in algorithms, data structures, and software engineering who nevertheless hack solutions in an operating systems class with total disregard for data structures, algorithms, and the structure of the software.
That is to say pass fail grading of programs, grading should be similar to an English class how you express it is just as important as what you express.
I had two classes this past quarter taught by a professor with a very different grading system. He used a program he wrote called the "code critic" to have us submit exercises into his grading queue. Only working code could be submitted and we could only have three assignments in the queue at once. He would then use his program to return the code with criticism added on any lines not to his liking and mark the assignment as "Not done," "Almost done," or "Done." If he didn't mark it done, we had to fix the code in response to criticism. These criticisms were very picky, even sometimes dealing with the naming of functions and variables.
At the end of the quarter we were graded on how many assignments we were completed, and how much we grew as programmers. If our assignments at the end of the quarter did not require any resubmissions, this was reflected in our grade.
I think this method was an extremely effective alternative to traditional grading. I learned more about programming and style in both C++ and Lisp in these two classes than I have in any other classes to date.
Ugh. Asking a CS major to adhere to naming conventions is like asking an art major to color within the lines. It has very little to do with computing.
Also remember, this is the guy who gave the world C++
"Also remember, this is the guy who gave the world C++". Yes, one of the most popular object oriented languages that is still suitable for systems programming. What of it? For all the complaining about C++ as an ideal tool, it's been incredibly successful as a practical tool. I don't use it, but I have a lot of respect for what it has done.
I entered college in 1987. Windows 2.x had just come out (I think)---OS/2 wasn't even being designed as of yet. The Intel 386 had just come out, and major application design in PCs in assembly had just passed in favor of C or Pascal. I couldn't even have comprehended my job today (programming wise---web based applications written in PHP) back then.
Yes, there hasn't really been anything "new" in the past 20 years (except maybe for ubiquitous networking) but the details sure have changed a lot.
The same is true for double-majoring. I have a friend that wanted to double major in CS and linguistics to do AI, but he was told that he couldn't. Instead, he has to stick around for an extra year to get two distinct degrees. He's had to waste time because some of the courses he needed to take required you to have declared a major in that field.
This is from a school that probably has a more vocationally applied view of a CS degree. We are, for instance, required to take two semesters of software engineering. They're obviously interested in giving a student an education that will be useful in the industry, but they also have inane rules like the one described above.
What is productive is gaining acknowledgement that this problem exists, as that is the (cliche) first step. I believe this is a serious problem. I've seen the sub-par software, code, and the people writing it for years - it's not changing through academia or industry. Both sides continue to address their needs independent of one another, and that is far from optimal.
Many of the finest professionals I have met in the industry cannot say more than a few positive words about their CS programs. Most of them will also recommend against pursuing the degree if you actually want to excel with code.
Agreed, the fix(es) will not be an easy find, but it is far from impossible. This needs to be taken care of - I'd love to be able to tell friends that want to be a good coder that they can go to school for that.