11–20 of 103 posts
"You shouldn't be allowed to write a library for use by other people until you have ten years of programming under your belt. If you think you know better and ignore this rule, then one day you will come to realize the mental suffering that you have inflicted upon others, and you will have to live with that knowledge for the rest of your life." stunning.
[update: I've got hold of some of the code. Here's a copy of one of the programmes http://pastie.org/4615158 ] I have an awesome story that i think I've told before, but I'll tell it again anyway :) My father-in-law is a pharmasist. back in the early 90s computers were starting to make their way into Pharmacy and the first few pharmacy sortware packages appeared. this increased with time, as you'd expect. At some poi…
I wonder how much that initial version changed during the 20 years of maintenance. I find it hard to believe that someone was maintaining it for 20 years without improving the quality (of the code/design) and making it easier to maintain. Have you seen the code base of the initial version or of the version that is currently being used?
I disagree with this one. Clear, readable code is... clear and readable. It's like not bothering to format text in a textbook because "the meat of the matter is in there, so who cares?"
Of course substance is more important than style in programming, but style also helps and is it really that much effort to make sure your code is readable for the next guy who comes along?
[update: I've got hold of some of the code. Here's a copy of one of the programmes http://pastie.org/4615158 ] I have an awesome story that i think I've told before, but I'll tell it again anyway :) My father-in-law is a pharmasist. back in the early 90s computers were starting to make their way into Pharmacy and the first few pharmacy sortware packages appeared. this increased with time, as you'd expect. At some poi…
I wonder how much that initial version changed during the 20 years of maintenance. I find it hard to believe that someone was maintaining it for 20 years without improving the quality (of the code/design) and making it easier to maintain. Have you seen the code base of the initial version or of the version that is currently being used?
The short answer to your question is no, I didn't see any evidence of improved structure or practices at all. All variables global. goto ftw. no procedures/methods/functions at all. He's never even heard of the concept when I tried to explain.
[Edit: managed to get hold of some of the code (see parent) and it looks like I was wrong on the indentation - he did start to use it at some point]
It's a mistake to introduce new programmers to OOP before they understand the basics of breaking down problems and turning the solutions into code. Given how well I remember my classmates with little-to-none programming experience struggled with understanding pointers while not being able to write the simplest algorithms, I thought this was a no-brainer. Is it really a controversial opinion?
It's a mistake to introduce new programmers to OOP before they understand the basics of breaking down problems and turning the solutions into code. Given how well I remember my classmates with little-to-none programming experience struggled with understanding pointers while not being able to write the simplest algorithms, I thought this was a no-brainer. Is it really a controversial opinion?
I haven't heard anyone argue against it, but for a very long time every single curriculum out there started with either Java or C++, and had to talk about object quite early on (you can't print "hello world" in Java without it, and you can't use C++ streams either).
And arguments I've heard about that practice as a proxy for your question, indicate that it is (or at least, was between the late '90s and the late '00s) controversial.
Of course, various programs (web apps) are IO-bound. And gcc -O0 should still outperform Python/Ruby/etc.
CS programs should be burnt to the ground. And in their place we should build up three separate things. First, software trade schools that are actually good (e.g. not ITT). Second, for reals software engineering majors at colleges, that are heavy on things like practical programming, tools (version control, issue tracking, automated build systems), refactoring, teach multiple languages (javascript, python, ruby, SQL, etc.), and only delve into theoretical underpinnings as warranted (compare electrical engineering vs. physics programs). Third, legitimate Computer Science programs that are contractually limited to about 5% of the current CS student capacity for at least the next two decades and which teach a very mathematics heavy and science focused CS program and have zero expectation that the graduates of the program will go on to write software in industry after graduation.
If you hold an opinion, look at the evidence backing it up. If it's not strong, reduce your confidence. Or even better: Gather evidence, then form your opinion. And remember: Anecdotes don't count. I wish more of my colleagues would do this, but it seems most of them haven't heard of very many software-related studies.
If you want to learn more, I recommend http://www.neverworkintheory.org/ as a starting point. After reading some papers, you'll be surprised how limited our evidence-based knowledge is. Looking at software engineering studies made me realize that I'm not allowed to poke fun at psychology anymore. Even that field is more evidence-based than ours.
I would go farther in regard to the Computer Science point. CS programs should be burnt to the ground. And in their place we should build up three separate things. First, software trade schools that are actually good (e.g. not ITT). Second, for reals software engineering majors at colleges, that are heavy on things like practical programming, tools (version control, issue tracking, automated build systems), refactori…