1. (Haskell) Propagating the myth that Haskell would do some automagic caching of function results.
(Haskell simply does call-by-need: square (x+1) evaluates to (x+1)*(x+1), but there's still only one (x+1) that gets evaluated.)
Signs that you're a bad programmer
121–130 of 131 posts
Re: Signs that you're a bad programmer
#122Some praise for this article: Identifying a set of patterns for sub-quality programming practise is useful in order to set about correcting those things esp. if you're in a mentoring position. I think it would have been nice to have given these names (like design patterns perhaps) and fleshed out their definitions further.
Yes, the author is more arrogant than desirable in his delivery but don't let that blind you to the good stuff. Some of the teaching analogies, in particular, I thought were good.
Re: Signs that you're a bad programmer
#123FTA: "Signs that you shouldn't be a programmer 1. Inability to determine the order of program execution Symptoms a = 5 b = 10 a = b print a You look at the code above and aren't sure what number gets printed out at the end" The answer is not always obvious. If the above code were in Java and print a was running in a different thread then it very well print 0, since a or b could be 0. JMM can really bite you if you do…
That's a pretty extreme case don't you think? You're certainly playing devil's advocate here. We all know what the author meant by this.
Re: Signs that you're a bad programmer
#124Oh man, I wish I had this at my last job half the team had over 50% of these symptoms, one guy had 90%. They believed, and had somehow convinced management, that they were great programmers! Some awesome practical examples from those guys below: Overheard statement "You know when I was in college I learned C. I just can't get the hang of these objects, so I try to avoid them". The guy who said this is now 34, and has…
ouch... I love the 'stop making this so complicated bit'. While some people really don't get it I'm pretty sure that most people could learn how to program with some competence. The only metric I've found to measure programmer competence reliably is how big a project you can manage to complete. Some people get stuck at around 100 lines, others in the thousands or tens of thousands, some can keep their rudder straight…
A good method. The skills required to create or navigate a codebase of 100, 5000, or 100,000 lines are different not only in degree but in kind. Behaviors optimal in the first case can be brutally maladaptive in the last, and vice versa. A preference for global variables or multi-threaded solutions says a lot about the size of project one is comfortable with.
But beyond the practical, what you're really measuring is the ability to break down a large problem, solve individual pieces, reason about how those interact, and iterate. That is the critical intellectual muscle that makes programmers reliably great.
I remember a few projects I abandoned when their size outgrew my ability to comprehend them. It took multiple attempts with new methods to break through certain complexity barriers. I could not write a program longer than about 500 lines until I had learned the practical use of subroutines and data structures. I could not write a program longer than a few thousand lines without a sense of taste when it came to objects and modules. And I could not write a program of significant size until I reliably turned out code that could be comprehended at a glance after months or weeks away, as my own throughput guaranteed it might be that long between visits to disparate parts of the codebase.
Re: Signs that you're a bad programmer
#125That was mostly high quality except for the wannabe "you might be a redneck" (shouldn't be a programmer) section at the end.
> (Functional) Manually caching the results of a deterministic function on ... Haskell
You still have to explicitly memoize at times in Haskell.
> refactor his old code with the goal of reducing its instruction count by 10:1 or more
What a loser! I go into my old code with a goal of 10000:1.
> Recursive subroutines that concatenate/sum to a carry-along output variable
This can be justified.
> Using strings/integers for values that have (or could be given) more appropriate wrapper types in a strongly-typed language
Not always worth it.
> Unit Testing, which you use at design time.
No, I don't.
> You don't use whitespace or indentation
If I'm not using whitespace, what am I supposed to indent with?
Re: Signs that you're a bad programmer
#126The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…
If readable chunks were all you cared about, why don't you just insert a few newlines and a single-line comment? I bet you actually do take some care to reduce coupling even when not intending reuse.
Re: Signs that you're a bad programmer
#127Here's a flaw which I've seen in several otherwise good programmers - forgetting that sometimes the core purpose of code is to be read and maintained by other human beings. Some of those other human beings may not have had the time to catch up on the latest/greatest language feature or 'trick' and may miss subtleties of your implementation. I get worried when I see someone take a mainstream language (C#, Java, Python…
Sometimes use of advanced facilities is a way of elevating your status over the uninitiated. Now that you've shown weakness, I'm really going to pour it on!
Re: Signs that you're a bad programmer
#128The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…
Am I the only one that thinks the original author's use of the term cohesion is wrong? I thought the goals were: high cohesion and loose coupling. http://en.wikipedia.org/wiki/Cohesion_(computer_science) http://en.wikipedia.org/wiki/Coupling_(computer_science)
I'm surprised anyone noticed this. Yes, I agree.
Re: Signs that you're a bad programmer
#129Funny that he has this under "Signs that you shouldn't be a programmer": "you think the presence of code in a program will affect its runtime behavior, even if it is never invoked". Anyone who has written code in C can probably cite an anecdote where exactly this was the case, be it from a compiler bug or as fallout from a memory corruption bug. Maybe we should add "does not understand the von Neumann architecture" t…
This happens in JVM languages as well. Most optimizing compilers will do things differently depending on what happens elsewhere in a function, even if it's "dead code" (and especially if it's dead code that the compiler is too stupid to realize is dead).
Granted this usually only affects runtime speed, but in some circumstances things can get worse (multithreaded programs are particularly susceptible to such optimizations, especially if they're not written correctly - yes, the real problem may be that you've written your code wrong, but there are very real situations where the presence of dead code can change the optimization path taken enough so that it either works or doesn't, which is a very real effect).
And that's even before we take into account compiler bugs, which just make things worse.
Re: Signs that you're a bad programmer
#130Earlier quoted context omitted.
ouch... I love the 'stop making this so complicated bit'. While some people really don't get it I'm pretty sure that most people could learn how to program with some competence. The only metric I've found to measure programmer competence reliably is how big a project you can manage to complete. Some people get stuck at around 100 lines, others in the thousands or tens of thousands, some can keep their rudder straight…
A good method. The skills required to create or navigate a codebase of 100, 5000, or 100,000 lines are different not only in degree but in kind. Behaviors optimal in the first case can be brutally maladaptive in the last, and vice versa. A preference for global variables or multi-threaded solutions says a lot about the size of project one is comfortable with. But beyond the practical, what you're really measuring is…
Hah! I remember that... I was still a kid, I really wanted to write a music composition program. One attempt after the other, this giant, monolithic piece of spaghetti. I just could not be done. Around the 700 or 800 line mark I lost overview and it would grind to a halt forever more subtle bugs to fix.
This went on for weeks, maybe even months.
Then a friend told me the magic words: "structured programming". I went to the library and read a book (I forgot the title, I think it was by Wirth).
Within 3 days I had it up and running.