It's not the features that you stare at with no idea what they do that cause a problem. As you say, a quick look at the manual can help to sort that out (though it does add to the overall cognitive load). It's all the potentially subtle things that you don't even realise are features and so never look up and don't realise that, contrary to first inspection, the code is actually doing something subtly different to what you expect.
Math is all about being precise, logical.. Communicating exactly one concept at a time. Natural languages do neither.
Except math is almost never actually done that way in practice. Euclid was wonderful, but almost all modern math does not work that strictly (and Euclid really should have been more careful with the parallel postulate -- there's "more than one thing at a time" involved there). Yes, proofs are careful and detailed, but so is, say, technical writing in English. Except for a few cases (check out metamath.org, or Homotopy Type Theory) almost no-one actually pedantically lays out all the formal steps introducing "only one concept at a time".
Not every programmer deals with these [mathematical] questions regularly (which is why I donâ(TM)t think math is necessary to be a programmer), but if you want to be a great programmer you had better bet youâ(TM)ll need it.
I don't think you need math even to be a great programmer. I do think a lot of great programmers are people who think in mathematical terms and thus benefit from mathematics. But I also believe you can be a great programmer and not be the sort of person who thinks in those terms. I expect the latter is harder, but then I'm a mathematician so I'm more than read to accept that I have some bias in this topic.
Math IS sequencing. So is using recipes. That is how math works.
Math is a language. Just because you can frame things in that language doesn't mean that that language is necessary. Recipes are often in English. English is sequencing (words are a serial stream after all). That doesn't mean English is necessary for programming (there seem to many competent non-english speaking programmers as far as I can tell).
Disclaimer: I am a professional research mathematician; I do understand math just fine.
College education wastes countless hours teaching academic stuff that a great majority of programmers will not use on the job, while neglecting critical skills that could be immediately useful in a large
Of course there was a time when college education was supposed to be education and not just vocational training.
I think part of the problem is that "programming" is itself so diverse.
The other part of the problem is that math is so diverse. There's calculus and engineering math with all kinds of techniques for solving this or that PDE; there's set theoretic foundations; there's graph theory and design theory and combinatorics and a slew of other discrete math topics; there's topology and metric spaces and various abstractions for continuity; there's linear algebra and all the finer points of matrices and matrix decompositions and tensors and on into Hilbert spaces and other infinite dimensional things; there's category theory and stacks and topos theory and other esoterica of abstraction. On and on, and all very different and I can't even pretend to have anything but cursory knowledge of most of them
Calculus is perhaps not the best measure however. Depending on where you go in the programming field calculus is likely less useful than some decent depth of knowledge in graph theory, abstract algebra, category theory, or combinatorics and optimization. I imagine a number of people would chime in with statistics, but to do statistics right you need calculus (which is an example of one of the directions where calculus can be useful for programming).
Of course the reality is that you don't need any of those subjects. Those subjects can, however, be very useful to you as a programmer. So yes you can certainly be a programmer, and even a very successful and productive one without any knowledge of calculus, or graph theory say. On the other hand, there may well be times when graph theory, or calculus, or statistics could prove very useful. what it comes down to is whether you are inclined to think that way -- and if so it can be a benefit; if not it won't be the way you think about the problem anyway.
I've gotten a lot of mileage out of Python for cleaning and pre-processing CSV and JSON datasets, using the obviously named "csv" and "json" modules.
You may want to look into pandas as a middle ground. It's great for sucking in tabular or csv data and then applying statistical analysis tools to it. It has a native "dataframe" object which is similar to database tables, and has efficient merge, join, and groupby semantics. If you have a ton of data then a database and SQL is the right answer, but for a decent range of use cases in between pandas is extremely powerful and effective.
Because Ruby is my preference and I am more familiar with it, I can tell you that it is in continuous development, and bytecode-compiled versions are available (JRuby, which uses the JVM, and others). I do not know about Python in this respect because I haven't used it nearly as much.
Python has the default implementation CPython which compiles python to an interpreted bytecode; there's also Jython which compiles to JVM, and IronPython which compiles Microsoft's CLR. There's also Cython (which requires extra annotations) which compiles to C and thence to machine code, and numba which does compilation to LLVM. Finally there's Pypy which is a python JIT compiler/interpreter written in a restricted subset of Python.
So they mined the journal for words and phrases... meh, those aren't memes
They are memes in the sense that they are specifically finding words and phrases that are frequently inherited by papers (where "descendant" is determined by citation links), and rarely appear spontaneously (i.e. without appearing in any of the papers cites by a paper). An important feature is that their method used zero linguistic information, didn't bother with pruning out stopwords, or indeed, do any preprocessing other than simple tokenisation by whitespace and punctuation. Managing to come out with nouns and complex phrases under such conditions is actually very impressive. You should try actually reading the paper.
But the writers of TFA are still misusing the word
Actually no, they are not. By using citations to create a directed graph of papers they are specifically looking for words or phrases that are highly likely to be inherited by descendant documents and also much less frequently spontaneously appear in documents (i.e. not used in any of the cited documents). They really are interested in the heritability of words and phrases.
You are solely focused on bitcoin as an investment opportunity rather than its intrinsic utility.
Sure, but as far as intrinsic utility is concerned it doesn't matter when I get involved with bitcoin
I think the more interesting part is the fact that we have some decent mathematicians (in this case Adi Shamir among others) are setting about pulling the entire bitcoin transaction graph and doing some serious data-mining on it. The reported result sounds like a mildly interesting result that happened to pop up in the first pass.
Given the advanced tools available these days for graph mining (largely developed for social network analysis among other things) I suspect some rather more interesting results may start coming out soon. What may seem hard to track on an individual basis may fall somewhat more easily to powerful analysis tools that get to make use of the big picture. I bet there's some interesting info on cliques and exchanges that could be teased out by serious researchers with some decent compute power at their disposal. Pseudonymity may be even weaker than you might think.
Try pricing in Zimbabwean dollars - you'll see the same problem.
Well, you won't anymore because the Zimbabwe dollars were discontinued and the country now uses US dollars as its currency because price volatility made continued use of Zimbabwe dollars as a currency effectively impossible.
Now Zimbabwe had inflation not deflation, but the issue of volatility is the same: it makes things ultimately unworkable if it gets too high (even if it moves in a predictable way). When prices change significantly* by the minute and transactions take several minutes to complete then trouble may set in.
* significantly here means, say, double digit percentage change in price every minute. Bit coin is a long way from that currently, but is headed in that direction.
Being primarily a mathematician and not a computer scientist or engineer I've used Maple, Mathematica, Matlab, Magma and R. I've also programmed in Python, Perl, C, and Java and dabbled in things like Lisp and Haskell.
All the "math" programs on that list are terrible programming languages; they work great as interactive environments for doing (potentially symbolic) computation, but writing code in them? Ugh. If I actually have to write scientific computing code it's going to be in Python using numpy and sympy, or C if I need performance.
All the different math programs all have their strengths and weaknesses: Matlab kicks the crap out of the other for anything numerical or linear algebra related, both for ease of expression and performance; R has far more capabilities statistically than any of the others -- data frames as a fundamental data type make that clear; Magma is incomparable for the breadth and power of its algebra, none of the other come remotely close; Mathematica and Maple are