Programming Things I Wish I Knew Earlier 590
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 RTFA (Score:4, Informative)
I think that anything that reads "___ things to know about ____" or similar gets instant hits on
-1, Boring from me; hope it helps others.
I wish I'd known that CMS's are really hard (Score:3, Informative)
And that's before you get into the really difficult stuff (that very few have managed to master) of getting a website that is easy to navigate and intuitive to use
until you find out why Python doesn't do the job (Score:4, Informative)
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.
What I want people to remember (Score:5, Informative)
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.
Re:Comment your code (Score:5, Informative)
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? ).
Re:xargs mapreduce? (Score:4, Informative)
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 [wikipedia.org] implement the "map" part of MapReduce.
One more tip (Score:3, Informative)
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!
Yes, and no (Score:3, Informative)
Some oversimplified philosphy, some good hints. Programmers and SysAdmins who do a lot of resource management eventually become managers. This isn't neccessarily a bad thing, as the world needs more managers with extensive experience with that which they are managing, and the respect of those people they are managing. It's true that it's silly to adopt some software, technology or process just because it's new. But Ted seems to be resistant to any change, which is not good either. The problem with "don't fix it if it ain't broke" reasoning is..what do you do when it eventually breaks? This is a mistake made by many in process control / automation eniveronments: failure of a part which is so obsolete that it has become difficult and expensive to obtain a replacement. Just try to find a new motherboard with an ISA bus these days. Or a composite monitor. The same thing can happen with software and the OS..where are you going to find a guy who knows enough about that old Kaypro which was running some COBOL software on CP/M, which controlled the electroplating machinery? This is why companies have lifecycle management, so that the pain of switching to newer software / hardware comes with predictable cost and timetables instead of sudden, possibly prolonged unavailability and expensive, awkward, band-aid fixes.
This flows into the idea of organizational amnesia, where important processes become lost. This is perhaps best illustrated by the US DoE forgetting how to make this secret substance called FOGBANK, which is a critical component of H-bombs. Upper management felt as though, because there was no need for additional H-bombs, the process was unimportant, and didn't take into account that H-bombs become (more) dangerous with advancing age, and eventually these needed to be replaced. It took considerable time and money to re-engineer FOGBANK.
These are both examples of failure to consider that all equipment wears out, and failure to plan for long-term needs.
Re:This is te problem with Linux (Score:3, Informative)
Re:This is te problem with Linux (Score:2, Informative)
whatis apropos
LISP/Scheme (Score:5, Informative)
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.
Re:3 things I've learned. (Score:5, Informative)
I like this take on it [yosefk.com]: 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.
Re:One more tip (Score:5, Informative)
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.
Re:Comment your data too! (Score:3, Informative)
The boss wanted everything in XML, since that was extensible, but then went halfway because raw images don't encode well in XML. So we maintained the dataset in XML and binary.
But as a result, I was able to keep around all versions of the binary-to-xml converter in the current code base. With some unit tests, and some comments, it really helped explain ancient data.
I enjoyed reading your comment. Thanks.
Re:The hard way is more fun (Score:3, Informative)
Re:Comment your data too! (Score:3, Informative)
Yes, and if you use units (and generally you do) then make it clear what units each parameter expects. I am in crypto and I am always guessing if things are in bits or bytes. In physics it is even more important - fortunately students of physics will probably be more inclined to describe the units they expect. Also, the names of the parameters are even more important than those in the source files. Basically, if you have e.g. a configuration file, it should be thought of as part of the user interface.
Re:until you find out why Python doesn't do the jo (Score:3, Informative)
Hell, I got an N900 6 months ago, and it's already EOL'd as far as updates to the OS are concerned.
I suppose I could wait till there's a port of Android or something, because the three coders on the project are doing a fine job, in less than a year I'll have the same functionality as a 3210.
Or you can read a little farther and see that upgrades are already available: http://en.wikipedia.org/wiki/MeeGo [wikipedia.org]
Re:Comment your code (Score:3, Informative)
x = y + 4;
it's more like
x = y+4;
So you explain *what* you're doing in HIGH LEVEL terms, and set CONTEXT. And you don't comment each line, you comment each group of lines that do one thing.
And I also disagree with your 'despise' thing. It's very, very rare that code is over commented, and in most cases failing to correct comments helps create bugs, because it shows you weren't able to understand the code well enough to explain it to others, chances are there's a bug there goes way up. I also find that after I've written code, then's a good time to read it over and comment it. I find lots of bugs that way, and the code ends up much better. Not doing that wastes time in the long run because you'll find the bugs the hard way.
Re:Oh if you find yourself repeating some code (Score:3, Informative)
The code in question (9 lines actually) is:
Ironically, making your code less object oriented (ie. screw encapsulation) fixes this problem.
Re:Comment your code (Score:3, Informative)
Re:Comment your code (Score:3, Informative)
I really think that means that you need to become better acquainted with those tools. specifying what you intend to happen is a lot easier than specifying how to do it. The first is a specification, the second is an implementation. Consider, I can specify a sqrt function by simply saying the result squared should be within some error tolerance of the input; that is a long way from writing an implementation of a square root function. Likewise, I can specify a sort function (the output list should contain exactly the same elements as the input list, and they should now be in order with respect to a comparison operator) without ever doing anything as complicated as actually implementing quicksort, or mergesort, or heapsort or ... Try looking at the tools and what they can do and you'll satrt to get the idea.