Why are we still teaching programming like it was a new emerging technology that nobody knows anything about, and not a well explored subject with at least 50 years of solid history?
Why are the lessons like an arts and crafts course, where we just let people build something, instead of a literature course, where we read and analyze classics, and learn from the experience of others?
And why are we surprised when we discover that every generation just reinvents the mistakes of the previous one?
@deshipu I'm not buying this. It's not that easy because "code is not literature"  Imho it's just more time effective to teach best practices and then learn when to deviate from them. I never got the feeling that we know nothing about programming during my studies.
The problem with reinvention is a problem of historical literacy. Although I'm also not convinced reinvention is always bad, maybe the world just wasn't ready back then. (resurgence of FP etc)
Still learning what has worked in the past and what's been tried would make a better education in general.
Maybe one should see the historical context as essential. Otherwise everyone will do the evolutionary steps for herself. From BASIC via C to FORTH and lisp / Ada / Haskell, to OO and back.
The tragedy is that a lot of people get stuck at the OO BASIC step and think they have seen everything.
@ckeen @deshipu Yeah I can get on board with that. I'd very much enjoyed a code reading and a code history class, I just don't think code reading should be our main teaching instrument.
One problems that I also see is that more and more universities teach OO only. You have to get lucky and take a class with a professor that uses an other language than Java to learn anything else. (though the other extreme, a different language in every course, can also be very straining)
@fap @ckeen I think that code reading is generally a very underappreciated skill, and that a lot of people who leave the university thinking that they already know everything they will need at their work suddenly discover that they are not prepared to handle a legacy codebase and to review the code written by their team mates. And reviewing code could be such a great homework for university — everybody gets some classic piece of code, and they have to review it and propose improvements...
@fap If you don't like comparison to literature (I'm not saying code is literature, by the way, I'm just referring to the mode of learning), then take architecture. We don't give aspiring architects a few basic engineering principles and say "now go design buildings until you are good at it". A huge part of the education is learning about old techniques and styles, even though the technology has made many of them obsolete. They still learn about gothic cathedrals there.
@pasqui023 @Azure @deshipu @fap Similar here; my Intro to Software Engineering course taken a year ago covered a bunch of "here's examples of what not to do", giving reasons rather than merely rambling off best practices. Therac-25, FBI Virtual Case File, London Stock Exchange, and several others (including finding one of our own and making a presentation on it).
@digitalfox @pasqui023 @Azure @deshipu Interesting, we certainly heard about software failures like the Mars Climate Orbiter and what they did wrong but it's not like we read any code from those projects or studied their design. Did you discuss those projects in greater detail? Any online resources online you can recommend?
But that's not really what I'm looking for. Reading ancient assembly code targeting an unknown platform without much guidance is not exactly my favorite pastime. xD
Something like "The Architecture of Open Source Applications"  but with negative examples would be interesting.^^
@deshipu CompSci lecturer here.
IMO there are 2 big things going on.
First, we still don't know all that much about how to teach software engineering; even in software engineering, there is still intense debate about which methodologies are good: I'm not only referring to agile/waterfall/whatever, but also testing methodologies, design methodologies, as well as questions like “does static typing prevent bugs” (spoiler: it does).
Second, there is no incentive for lecturers to give a damn. :(
@deshipu on that I think teaching the basics of code and then getting those learning into the open source community might be a cool thing, showing them some common mistakes or even some funny hysterical ones.
Teaching someone how to use the resouces available to them (or better teach them how to learn to use things like say a search engine, and let them go their own way)
I find learning in creative fields is WAY too restrictive and marking is way too limiting.
@Azure @deshipu Most CS programmes have courses on algorithms and datastructures. Arguably, any program is simply a concrete instance of these. So we don't analyze programs but we do analyse algorithms and we learn from the experience of those who invented better ones.
Many CS programmes also have courses that teach e.g. the lambda calculus as an underlying universal formalism.
Programming in a particular language is a very specific skill and I do think learning by doing is an important component.
@deshipu @martensitingale There are at least some places that do some history. Not reading the CODE per se, but looking at the development of ideas over time and why people did one side over the other and the like. I think those tend to wait until later years and get shoved into topic-oriented classes.
@Azure @martensitingale I think that looking at the actual code is really a very important part of it, and even better, stepping through that code, or changing something in it, so that you actually *feel* how it works. There is a huge difference between being told something and actually trying it. On the other hand, that would require at least a basic familiarity with the programming languages of the time — which might not be such a bad idea either, to be honest.
@Azure I don't feel competent to set a curriculum for 4 years of university, but I would imagine it to be organized by topics, for instance, you could explore different approaches to graphical user interfaces (starting with Smalltalk, through early DOS programs, early Windows, then maybe Delphi, Java (swing and gwt, etc.), up to modern API). Or maybe compilers, starting with some early stuff like COBOL and ALGOL, and exploring different approaches up until today. This kind of stuff.
You're really on the mark with the comparison between CS education & arts and crafts classes.
Having taken CS courses at a school where it's part of the engineering program and another where it's liberal arts, the way it's taught really differs from even engineering programs. The general lack of focus on history and justifications for best practices is weird.
In terms of the 'classics', we really do have some good readable open source candidates.
The plan9 implementations of standard unix shell utilities are amazing examples of beautiful, clean, concise C code. But I get how someone who hasn't read the plan9 source would think that all non-trivial C code is either messy, proprietary, or too big and context-dependent to show to students.
I haven't ever seen well-written non-trivial java code, though.
A big problem I have with CS pedagogy is that it has an emphasis on principles divorced from practice, with the principles standardized by bodies that are largely unconcerned with practice. (Students who have never written non-trivial projects write endless trivial ones with strange demands based on 25 year old Sun marketing material, while being tested on their ability to parrot back that marketing material.)
Code reading can help add context. I push for language variety, personally.
@enkiv2 Isn't that pretty normal in Academia in general? Even if you turn to poetry, what you discover are "canonical" interpretations and analyses of classics, which you basically are supposed to learn and emulate.
I have nothing against small projects — a lot of small projects of which some are failed and some successful let you learn more, than one huge, inevitably failed project.
Small projects are different from trivial projects. In this particular case, unrealistic toy projects are chosen because they best illustrate principles that, in non-trivial projects, are almost never actually true.
I may be lucky, because none of my lit classes expected me to memorize other people's canonical interpretations of classic works to the exclusion of the creation of my own!
@deshipu Is vs. ought.
My contention is that programming is language, and thus literature, yet our pedagogy largely insists that programming is math, and thus STEM.
One can say that programming ought to be both, but that doesn't mean that programming is both.
Does engineering (broadly) involve the production and consumption of texts? Yes. Does that make the production and consumption of texts the subject of engineering? Or is writing and reading (broadly) a subject onto itself?
@deshipu Engineering is not literature. That does not mean the language arts employed by engineering is thus best studied as engineering. Insofar as engineering uses tools of literacy, those tools of literacy are the subject of literacy.
Gardening is not a sport (usually). That does not mean the physical exercise employed by gardening is thus best studied as gardening. Insofar as gardening uses the tools of physical fitness, those tools of physical fitness are the subject of physical fitness.
@deshipu Ah, but programming isn't engineering. Just as programming isn't math.
There happen to be some engineers who write programs in the course of their work. But most programmers don't do anything resembling engineering.
Corporate title inflation notwithstanding.
@deshipu Your very last sentence here is the very first time I've heard anyone make a cogent counterargument to my programming is not engineering assertion. Most are too busy insisting (incorrectly) that programming is math by virtue of logic.
But "buidling and maintaining of public infrastructure" circumvents that, as it doesn't depend on a postulated basis in math.
Thank you, this gave me something the chew on. I'm not won over, but at least its an argument that requires consideration.
@beadsland To be honest, I'm a math major, but in the 20 years of my programming career I never really had to use any of my math skills in an actual practical case. Sure, they come in handy when playing with code, but the professional work is mostly about solving trivial-but-not-obvious problems discovered in practical use. And I believe that the main focus of engineering is exactly that — solving problems with technical means, preferably with minimal amount of those technical means.
@deshipu When interviewed by Cosmopolitan, Grace Hopper said of programming "It's just like planning a dinner!"
One could say that planning a dinner (especially, when planning for predelictions of guests) is all about trivial-but-not-obvious problems. Does that make it engineering?
Should catering be taught as hospitality engineering? Or can we agree that trivial-but-not-obvious problems is not strictly the domain of engineering.
The infrastructure assertion makes for a stronger argument.
@deshipu Also, I'm not convinced that programming qualifies as "technical means". There are technical aspects, techniques, to writing and composition in any genre, but that doesn't make writing a "technical means".
@deshipu Insofar as programming is taken up in the construction of public infrastructure, I will grant that the construction of such public infrastructure is, indeed, engineering.
However, most of those involved in any given public infrastructure engineering project are not engineers and are not doing engineering. They're doing architecture, project management, pile driving, crane operation, ironworking, masonry, pipefitting, carpentry, landscaping… Very few are engineers doing engineering.
@beadsland Back in the days there used to be coders, who would take the math formulas and convert them into assembly, and assemblers, who would take the symbolic code and convert it into machine code, and transcribers, who would take that code and type it out onto punch cards. There used to be computer operators, who run those punchcards through the computer, attach the printed results and send it back. All those positions succumbed to automation nowadays. Only engineers and architects are left.
@deshipu And then folk like Grace Hopper invented programming languages. Which allowed trivial-but-not-obvious business problems to be solved without resorting to math.
The languages were still symbolic, but in the way that languages, qua languages, are symbolic. It wasn't engineering, but communication.
Programming using languages was something new, different from math, assembly, transcription, computer operation, architecture, and yes, different even from engineering.
@beadsland So you are right that programming is not engineering, just like, say, roads are not engineering. They are just tools that are mostly useful in engineering tasks. Of course, you can use programming for, say, art (though most artists are actually part-time engineers, especially when they do things at scale), entertainment, education, science, leisure, etc. — it's just not the biggest and most visible use.
@deshipu Agreed. Bricks can be used in art. But the biggest and most visible use of bricks is in building construction.
An engineer, I think we can both agree, was involved in the construction of such buildings. (Just as an engineer was involved in the fabrication of such bricks.)
But those who operated the mixers and mortared the walls, most of those were not engineers and were not doing engineering.
Interestingly, those jobs are typically paid very well without resort to title inflation.
@deshipu Right. The engineering was there. If the engineering wasn't there, you couldn't do the programming. That doesn't make programming engineering.
You couldn't do papermache without materials & chemical engineering to make paper and paste either. Doesn't make paper mache engineering.
Engineering was part of building Microsoft Word just as engineering was part of building the Brooklyn Bridge. But most of those doing work on either project were not engineers and were not doing engineering.
@deshipu *notices the absence of a question mark where a question mark was due*
*wishes once again for a typo revision feature*
@beadsland Well, maybe I'm weird, but I do think that organizing a big and complex enough event (be it a dinner, a conference or a rock concert) involves a lot of engineering work. Of course if it's a tea for 3 people, the engineering aspects become so trivial, that they practically disappear, and the task can be handled without much engineering training.
Gardening is engineering too, when done at scale. Or, say, opera — all those stage engineers are there for a reason.