3 ms·
Learning how to use professional tools is just scratching the surface of what should be taught. How to design a program, how to document a program, software des
by rsj_hn 5y ago
Learning how to use professional tools is just scratching the surface of what should be taught. How to design a program, how to document a program, software design patterns and methodologies, how to refactor, secure coding patterns including at a minimum authentication, authorization, and audit systems, how to work with bug tracking systems and repositories, IDEs, unix and shell scripts, how to debug code, etc. Then they should display proficiency with assembly, c or c++, at least one scripting language and at least one higher level OO language and one functional language. Then they should also work on large software projects for practice. Then for electives they can focus on different areas of emphasis such as real time systems, AI, systems programming, database design, networking, web applications, etc.
Imagine you study civil engineering but all your classes are taught by physicists and mathematicians, and you are studying physics. Yes, this is all important foundational knowledge for engineering, and you can't be a good engineer if you don't know any physics. But engineering is not physics and to graduate civil engineers without actually teaching them engineering seems like a massive fail. Adding a "missing semester" in which they learn how to use some engineering software is just scratching the surface of what an civil engineering degree should require. That we have gotten away with this in CS-land is just because of the immaturity of the field, not because this is a good way of producing the software engineers that society needs.
- toomanybeersies 5y ago> Then they should display proficiency with assembly, c or c++, at least one scripting language... So graduates are expected to show proficiency in a minimum of 5 different programming languages? That sounds like an enormous waste of time.
- lostcolony 5y ago5 different programming paradigms. A single language can have multiple paradigms. Do you think there are tradeoffs worth considering between language paradigms? Is there a reason why you might want to write something close to the metal, vs something in a scripting language? Is there a reason you might want FP over OO for certain problems? I mean...my curriculum didn't explicitly call out languages anywhere, but along the way I picked up Python (intro class), Java (most classes), C and an x86 assembly (embedded class), C++ (graphics class)...and within two years of graduating I was wanting to learn a functional programming language, and changed jobs just to do it. Had I gone AI track I would have picked up a Lisp. It's not really that big an ask.
- toomanybeersies 5y agoWhen you put it that way, I sort of agree with you. I don't think whether a language is close to the metal or high level is an important distinction to be made in the context of learning computer science, but I do think that learning about different programming paradigms and concepts in the abstract is important. Learning x86 assembly for the sake of it isn't useful or educational. However, building an x86 compiler (or in my case JVM compiler) as part of a languages and compilers course is something worth doing.
- lostcolony 5y agoWell, I will say that the class that had us learn assembler started with (software) FPGAs, then assembler, then C. The idea being that it demystifies a lot of what is going on underneath your code. Does it actually help you write better code in most instances? Probably not. It's helpful if you're writing embedded things (and that was the whole gist of the class), but for many devs it's not that useful. But that knowledge is still comforting; I've met devs who didn't have it, and they felt a little uncomfortable that they didn't understand how the code they wrote actually affected the underlying machine. shrug Certainly, "our CS degree is good for anything that isn't too low level" isn't the vibe most universities are going for.