Mostly opinions of an angry C programmer. Disagree with all of them. Too context specific. For example, testing. It is generally a good idea, but you don't always want to invest the time if it will have a negative return. Small projects or throw away work are two conditions where this would be true.
guys,<p>>The first language should NOT be the easy one, it should be >one that sets up the student's mind and prepare it for >serious computer science.
>C is perfect for that, it forces students to think about >memory and all the low level stuff,<p>as one low-level programmer to another, I hate to break it to you, but "low level programming" is not "serious computer science". the two have very little to do with each other.
One that really stood out to me:<p><i>6. The use of try/catch exception handling is worse than the use of simple return codes and associated common messaging structures to ferry useful error messages.</i><p>I think this really depends on the language. In erlang I absolutely hate exceptions because they don't really make sense in a functional language (which let's say erlang is for the sake of this argument). Threads run functions with only the function's parameters as state. It doesn't make sense to have to worry about a function <i>stopping</i> half way through, especially when most functions already pass up tuples looking like {error,E} or {success,S}. If you have to worry about exceptions as well, now you have to handle the error tuple and the exception case, and usually both cases are getting the same code so you have to go make a new function to call for that case. This gets messy. If a thread crashes it crashes, otherwise it should be passing up the error tuple; there's no reason for exceptions.<p>On the other hand I think exceptions make a lot of sense in python, and I think the python community has incorporated them in a standard way which makes sense, so that handling exceptions in python is actually easier then passing back different error codes and what-not (no atoms in python).
I do sort of agree with the try/catch criticism. I know what it achieves and why we need it but I don't agree that it's the best or even most intuitive error handling mechanism. I personally prefer returning error messages in place of or alongside expected data structure outputs, such as the common paradigm in JavaScript where async functions return error info (or null) as the first parameter in the supplied callback before returning the actual data (if no error) in the subsequent parameters.<p>I do somewhat agree with the OOP criticism as well. I find the best programming achievable is by mixing strategies and not adhering strictly to any one philosophy. Java's OOP is so inflexible and limiting that it takes a significant amount more effort to get basic work done. It may lead to a somewhat more manageable codebase at first, but I feel experience in your language of choice can bridge the gap between such a strict static-typed language vs a more elegant but potentially messier dynamic-typed language in this respect.<p>Finally I do agree that C should be taught before you learn any other programming language...but not to such a degree that you need to be able to build the best Javascript engine in the world from scratch before you move onto another programming language. The goal of programming is to build software that saves you time, after all - you aren't saving much time with as high a barrier to entry as mastering the fundamentals of C. It is important for theory discussion as well as learning the best way to code a lot of logic in many other languages, but I feel an abstracted language has failed if it hasn't done enough of the work for you to refactor your code properly in the first place. Loop unrolling, seriously? I like that I learned why it's important...but I shouldn't ever have to do that in any decently programmed higher level language.
There can only be controversy when either the truth isn't clear, or it doesn't matter. If we knew the answer, and it mattered, everyone would do it that way (and those who didn't would lose to those who did). e.g. religious wars:<p><pre><code> vi vs emacs
OO vs fp</code></pre>
One opinion of mine is "code is also configuration". If you structure the code right, I see nothing wrong with putting stuff that many people see as configuration in the code. I do Java programming, and I think that frameworks like Spring are overrated. There is nothing very different from stitching together dependency injection with XML than with Java code. It is a pattern, not a framework. But the Spring trend is hard to walk against, it is so strong. I am getting tired of this occupation.
I disagree with most of them and seemed to be biased towards a specific language the poster of the opinion liked/understood best or against one they disliked.
Really surprised at the amount of hate for Python significant indentation. I've only used Python a little, and I expected to hate that too, but found it wasn't really so bad. I thought my experience was pretty common, and that by now most people either thought it was a great idea or at least found it tolerable. But "it was a bad idea" is currently favored 43 to 5. Maybe not many Pythonistas have seen this page yet.
13. Most programmers think they know what they're doing but actually are "incompetent". (There are Usenet posts going back to 80's documenting this fact.) How am I defining "incompetent"? In my definition it means writing software that any reasonably skilled hacker can cause to "malfunction", i.e. not perform as expected by the programmer, which depending on the program may or may not present a security risk. The number of "competent" programmers i.e. those whose programs are immune to the acts of reasonably skilled hackers, is very small. They are a rare commodity. In sum, there's lots of reasonably skilled hackers and very few competent pogrammers. There is no licensing body for programmers. Anyone can call themselves a "professional programmer".<p>Note: If a programmer only writes programs for her own use, "competency", as defined above, is all but irrelevent. Whatever works.<p>Controversial, but true.
I don't agree with many of the points, but having taught a lot of beginners while loops, they are often very confusing to people.<p>I usually end up explaining them like a repeat...until, which usually makes more sense to non-programmers.