Programming Things I Wish I Knew Earlier
theodp writes "Raw intellect ain't always all it's cracked up to be, advises Ted Dziuba in his introduction to Programming Things I Wish I Knew Earlier, so don't be too stubborn to learn the things that can save you from the headaches of over-engineering. Here's some sample how-to-avoid-over-complicating-things advice: 'If Linux can do it, you shouldn't. Don't use Hadoop MapReduce until you have a solid reason why xargs won't solve your problem. Don't implement your own lockservice when Linux's advisory file locking works just fine. Don't do image processing work with PIL unless you have proven that command-line ImageMagick won't do the job. Modern Linux distributions are capable of a lot, and most hard problems are already solved for you. You just need to know where to look.' Any cautionary tips you'd like to share from your own experience?"
I just RTFA. It isn't that good. These aren't many tips and they also don't seem to be too specialized. Most of them are already known or predictable. I can say that I didn't learn anything from TFA.
/.
I think that anything that reads "___ things to know about ____" or similar gets instant hits on
-1, Boring from me; hope it helps others.
Have you heard about SoylentNews?
Don't program in C if Python will do the job.
But in a lot of cases, Python does not do the job. It doesn't do the job on iOS because Apple has explicitly banned everything but Objective-C++. It doesn't do the job on Xbox 360 or Windows Phone 7 because IronPython uses Reflection.Emit, and the version of .NET used by XNA doesn't support Reflection.Emit. And it doesn't do the job on Nintendo DS because the runtime uses up a lot of the available 4 MB of RAM.
Don't assume that, even six months from now, you're going to remember why you did things a certain way.
And the corollary: Don't assume you're going to be the one modifying the code a year or two from now.
Either way: Add comments liberally. Even if you're a conservative.
#DeleteChrome
> As for the indents that people are talking about, tabs are more reasonable now than they used to be, but you're giving up screen space for them
Why would you be giving up screen space with tabs? On most text editors for programming people can adjust the tabs to display as whatever indentation they want. So if someone wants to view tabs as 2 spaces and another prefers 4 and another prefers 8, they don't have to change anything in the code if their editors are already set up for that.
The disadvantage of tabs is where you have some stuff that requires you to use spaces in (text string etc) and for some reason you want certain parts of it to align with your indents. Or you are mixing your indentation - spaces and tabs (try not to do that OK? ).
I guess I'm an idiot, but.. err... did someone REALLY use mapreduce to solve an argument passing problem (the domain of xargs), or is the writing just shit?
xargs and its successor GNU parallel implement the "map" part of MapReduce.
apropos
I wish I'd know about LISP 25 years ago. Stupid people told me it was "for processing lists." If only I'd known better. Functional programming gives you wings and a jet engine.
I wish I hadn't paid too much attention to people with limited imaginations. Just because they're older, have more money and shout louder doesn't mean they are clever or wise.
C++ is way over-rated but it's worth knowing because it's so widely used. Don't let it detract you from mastering C and learning scripting languages. Understanding object-oriented design is more important than knowing the latest trendy language.
Objective-C.
Just because software is Free/Open doesn't mean it's "cheap" and poor quality. I could have saved myself 2-3 years there.
Ignore Windows and it will ignore you.
Stick Men
I like this take on it: redundancy is bad, but the primary way of avoiding redundancy, factoring things out into libraries or frameworks, introduces dependencies, which are also bad. Which is worse? Depends, but I think dependencies are worse in more cases than people believe. I personally like to depend on something only when it's a big enough chunk of code to be worth adding a dependency for, has a clean API, and has an active and interested maintainer.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Visual Basic - Don't. Just don't.
It's always great to learn a language then have the company change it so drastically in the next version that all your knowledge of the language is useless. I don't believe it'll be the last time that happens either. I do know I will never bother to learn another MS programming language again.
Good luck to all you C# programmers when they switch to C#.NET, or whatever they call the next one. Hope you like reading!
C# is already .NET, there has never been any other version.
And what about C++, hmm? That's a language that went from "C with classes" to a multi-paradigm language with a sprinkling of template mate-programming programming thrown in! The shift was so huge, in most compilers, the standard libraries have two versions, a legacy and a modern template version.
I had to re-learn C++ several times. Some of the new features are so advanced, that not even all compilers support it. Things like "partial template function specialization" are only turning up now, 10 years after standardization. It's a language where I was shocked to learn that there were entire language features I wasn't even aware of after having used the language in production code for 20 years! That kind of thing has never happened to me before or since with any other language.