These are the most presumptive headlines. Programmer encapsulates many disciplines just as a writer encapsulates those who write comics, novels, plays, ads, articles, law and speeches. Stop assuming everyone is a web developer. And don't deign to tell programmers what they should know.
+1. Expected a serious list, instead I saw stupid Ruby/JS/HTML garbage. And no, I do not need to know "100 Vim Commands" - because Visual Studio is "100" times better.
Here is the real list:
1) know one modern web tech;
2) know one OOP language;
3) know one functional language;
4) be familiar with one dynamic language;
5) remember where to look up theoretic bits like algorithms.
I disagree on 5). You should probably be at a bare minimum familiar with different types of data structures and how they work. Knowing where to look up "theoretic bits" isn't actually useful. As a programmer, you should know when a dictionary might sace you time, just as one scratch of the surface example.
> Note that this list is itself a list of lists, and thus in theory satisfies the normal criterion for inclusion here; however, it has not been included, since the purpose of the article is to serve as a directory to other lists of lists.
Hands up: who had heard of "docking" in the sense of http://x86.cs.duke.edu/~brd/Teaching/Bio/asmb/current/Papers...? For me, that didn't even come from the same ballpark. And that is after I accepted that CSS cheat sheets and type theory were in the same ballpark.
Yeah, that confused the crap out of me. I opened the paper and started reading the abstract, and was still confused. Took a lot of flipping through it to realize that it has something to do with molecular bonds and protein folding, maybe. :)
I don't know why "what every computer scientist should know about floating-point arithmetic" is not in here. Ruby or the last framework are just fads, but IEEE754 is here to stay and nobody know how to use it (and I never remember the details myself, I'm always struggling).
I like to tell IEEE754 as an improvised story, because it's so rich in history as far as data types go.
They were first introduced in 1941 on the German made Z3 compuer. Whic means, yup, we can blame nazis for 0.1+0.2 == 0.30000000000000004
In all seriousness, more programmers need to understand this. I've seen more than a few beginners go rant about how awesome their language X is when contrast against language Y because language Y has bugs like 0.1+0.2 ... then they're blown away when the see their language too has the same "bug".
Scheme programmers don't have that problem, because Scheme is one of the few languages that does math in a sane manner. The whole inexact-by-default behavior of most languages with literals expressed as decimals is somewhat nutty.
For all the flexibility provided by Scheme's structure (shared with other lisps), the thing I wish more languages would borrow from scheme is the numerical tower, which doesn't need Lispish syntax or any of the other features of Scheme that most people object to.
I think it's a bit naïve, because transcendental number have no exact finite representation in any integral base.
Having arbitrary precision helps only in some cases.
Having arbitrary precision helps in all the cases where you start with something given as an exact decimal, and perform only operations which produce exact decimal outputs from exact decimal inputs, which isn't a particularly small set of use cases. Scheme's approach of using exact representations unless either an inexact one is explicitly requested or an operation is used which produces a result which has no exact representation is correct in the broadest number of cases at the expense if requiring a tiny bit of extra effort to exchange accuracy for efficiency where that is desired.
This is, IMO, clearly the best approach for a general purpose language, and far superior to the large number of languages which lack even a convenient syntax for exact decimal literals.
I totally agree. Unless we decide to leave the field of rational numbers (with exponents, trigonometrics or nth roots), there's little reason not to keep the exact rational number around.
Fortunately Haskell does this too with Data.Ratio!
frankly I don't really understand it. I mean we do real geeky numerical computations only once in a while for a week, and then we spend a few months on CSS IE compatibility. I never remember what kind of computations break my numbers in what ways and how I know if I can safely use == or not in my case (and if I can't, how big the epsilon should be).
Great resource, thanks. But oh man, typography, character sets, CSS3...you are going to have a lot of frustrated developers scrolling through this. :) Not many have a good handle on all three of those AND functional programming, and you know lots of people measure themselves against these lists...
Heh. But while it's silly to put too much into measuring yourself against arbitrary lists, reasonably good ones like this should at minimum be a guide to "Here be dragons". As in areas that are messy and/or otherwise complicated enough that you should make note so that you'll know to study them if needed in the future. Mixing metaphors while still staying reptilian, so that you don't one day ask yourself "Why have I found myself in an alligator infested swamp?"
The functional programming one is great. As a self-taught programmer who has mostly learned on the job, I've struggled with understanding functional programming (since I've never had the opportunity to use it for work), and that helped me along quite a bit.
Am I the only one who had to google the "docking problem"? I've been programming for over 30 years, and not once have I had to model the quaternary structure of complexes formed by two or more interacting biological macromolecules (http://en.wikipedia.org/wiki/Macromolecular_docking).
There are people (myself included) who cannot remember how exactly to use tar, the Unix command. For me it always goes like this: "Is it 'tar -fzhf... ' or 'tar -vgsf...'? Ok, I'll google it again, just this one time, promise".
I don't think it used to? I remember needing to explicitly state tar -xjf for bz2 stuff. I do it now reflexively. If it's handled correctly by -xf, that's awesome!
Yes, it does, but only GNU tar. I was using NetBSD when I stumbled over the fact that it couldn't 'tar xvf' my foo.tar.gz.
OTOH, I always have to look up unzip, because I fear that there is some option that I forgot. Well, most of the time I use a GUI for Zip, since they often decompress all over the folder unlike tars which are mostly contained in one single folder.
I remember 3 tar incantations (to created a compressed archive, list, or uncompress one) that I treat pretty much as unchangeable commands. Probably should just alias them. Everything else I'll look up..
