While I don't agree with everything the guy says, this is a huge pet peeve of mine: if someone says "C/C++" all the time, it is likely that they are skilled at neither, because anyone who has done significant programming in both knows quite well that the two are quite different in practice.
for M-L, brush up on your basic* math, and jack up on the probability and statistics. an eetsy beetsy volume on numerical computing, just enough to understand machine representation of numbers and enough to understand errors (and their propagation!) should be enough.
don't hesitate to read engineering texts. the first few chapters of various DSP texts should give you an idea of what to look for ("oh, so it's loops over real-valued vectors! cool!") but if you read EE texts, feel free to ignore complex variables (unless your earlier math text was good enough to introduce them as vectors of two components :-)
An interactive language, preferably Octave/Matlab should come handy.
None of this will make sense right now, but hints are supposed by like that ;-)
--
[Edit:
* basic as in naive set theory, ability to reconstruct and prove properties of Real numbers using Dedekin-cuts, basic proof techniques, sequences, series, limits, functions as sets, basic trigonometric functions, the derivative and the anti-derivative, and most importantly understanding the various type of integrals, specially the Reimann. touching "real analysis" from the standard and Non-Standard angles should be enough. All this could be done in 2-3 months with the right texts. This is the minimal you will need to understand things; the basic properties of the logarithms should come handy, specially converting between logarithms of different bases (you will be working on bases 10 and 2, while the natural number is more prominent in engineering than CS.)
]
I would add Linear Algebra to mahmud's (great) list of mathematical "stuff to learn". A lot of ML needs Linear Algebra . (e.g Neural Networks, SVMs .. )
Thanks for taking over the thread for me plinkplonk. I posted a dense teaser and went to bed, then work for the rest of the day. You pretty much answered all subsequent questions the way I would have :-)
Let me add that beginners couldn't go wrong with mathematics texts by Serge Lang, first-rate mathematician and master teacher.
Plenty of books at the graduate level - Spivak's Calculus and Rudin's Introduction to Functional Analysis should get you most of the way through mahmud's list of things to learn
After all these, you should be able to pick and choose for yourself. Enjoy!
I hear what you are saying. By "grad level" I only meant that you need to be very comfortable with doing proofs to make any progress. Clumsy phrasing on my part.
I am completely self taught in mathematics (and computer science).I have no real idea what is undergrad level and what is grad level in a real university. It took me a good long while before I tackled Spivak :-D. Apologies for any confusion caused!
Oh, it wasn't really saying anything; I thought you knew something I didn't. I got Spivak hearing that it would be good, and it is, I really like his writing style, but its going to take me a long while before I can tackle Spivak.
How did you get to the point you could tackle Calculus? I still don't know how to convince myself if my answers are correct or if I'm making assumptions that I shouldn't.
EDIT for Reply: Thanks for the link to Strang. I think I'll begin reading it this weekend. :)
"How did you get to the point you could tackle Calculus? "
After working through Strang's Calculus and learning how to tackle proof questions (strangely enough I got confident enough to attempt proof questions after working through a good chunk of "Concrete Mathematics" (Knuth)) I then found what was impenetrable before in Spivak looked attemptable, if not easy. It helps that the end result of most proof questions are known in advance and the problem is finding/writing down the proof itself.
Might be some confusion here between Spivak's "Calculus on Manifolds" and his book just called "Calculus." The former is a more advanced book that might be used for part of a beginning graduate course. I say there might be confusion mainly because _I_ got quite confused when someone mentioned "Calculus" and I assumed they were talking about "Calculus on Manifolds."
Rudin's "Principals of Mathematical Analysis" is an excellent intro to real analysis for self-study. Axler's "Linear Algebra Done Right" is good for linear algebra. Neither makes any effort to bridge the gap between theory and application, so if that is a difficulty, you might need other texts as well.
Learning to think in C++ is much closer to learning to think in Java
This is where I stopped reading. He mentioned "modern C++" many times, which actually should mean that C++ moved away from rigid pseudo-OO GoF-inspired structures, Java-style.
Java itself is a simplified snapshot of much older C++ (circa mid-90s) but equipped with garbage collection. Memory management is an interesting, actually, since C++ doesn't rely on heap allocation nearly as much as Java does.
Well, long story short: no, "thinking in Java" is a terrible, terrible way of describing how C++ programming should be done.
Thinking in _modern_ C++ is supposed to feel like you're trying to bolt on Haskell's type system on top of C.
I'm not sure that's descriptive so much as an ideal.
In practice (mentioned this in the blog comments as well) I've found that the C++ world is somewhat divided between what I'll label the Boost and Qt camps.
Boost, as kind of a conceptual child of the STL, has extended more along the axis of exploring what's possible with the language, at times at the cost of pragmatism. The Qt camp, on the other hand, tends to hide most of the heavy use of generic programming in private classes and exposes more simplified APIs, typically with minimal use of templates in public APIs.
I personally, as a former long-time KDE developer, fall firmly in the Qt camp and it shows in the way that I write C++. It's also the style that's been preferred in the two companies where I've been employed as a C++ developer.
Which is modern is mostly a semantic issue. I'd wager that while advanced template programming is more cutting-edge, it's also not in fact the way that very much C++ today is actually written, which is the definition of modern I was working with.
The book that defines the genre ("Modern C++ Design", by Andrei Alexandrescu), is all about template metaprogramming. I'd say that's the end of the semantic debate.
Maybe you could say that I'm in a "camp", but the C++ style that Qt uses is based on the outdated notion that compilers can't keep up with the "modern" features of C++. That style is antiquated.
Current compilers still generate huge binaries for code that makes excessive usage of templates; I've personally had to rip out a lot of heavily templated code in the last year for that reason.
They also still (with the Intel compiler as a notable exception) generate nonsensical error messages when templates are used heavily.
The latter reason is one of many that a lot of C++ programmers don't do well with heavy template usage. One naturally could fault those programmers, and I think that's half-way fair, but in designing reusable APIs, API usability is and should be a concern. The corollary seems is obviously a bad principle when applied to (graphical) interfaces: if the users weren't so dumb it'd be easy to understand. I believe the same holds true, generally, for API design.
Half-way related, I'm personally quite a fan of Designing Qt-style C++ APIs:
As for "modernness" the point still stands; when some people say, "modern music" they mean "avant garde". Others mean "the stuff on the radio". I mean the stuff on the radio; Alexandrescu is the avante garde.
Compilation speed and incomprehensible compiler errors remain an issues for template heavy code but this is the first time I've heard complaints about binary size. Can you educate?
Theoretically the incomprehensible compiler errors will go away in the next couple years as compiler writers integrate C++0x "concepts."
Every specialization of a template creates a new instance of it with new symbols. With heavily nested templating that can add up quite quickly.
The most problematic case at my last company was where there were several hundred specializations (just one-liners) one after another in some of the error handling code. Each of those specialized several more templates. I managed to shave a few dozen MB off of the binary size (and remember, larger binaries == more cache pressure) by replacing the templates with a base class and virtual function.
The first was in the parts of the SAP R/3 kernel that I touched while working in the LinuxLab there (I can't say authoritatively for the entire kernel), the second was at Native Instruments, largest pro-audio software company. Naturally the largest C++ Open Source project, KDE, tends towards Qt-style (being built on Qt). I'm not sure for Mozilla and OpenOffice.
At the latter company we had about 30 developers, on average quite good. There were a couple that were into advanced template techniques, but the usage of such in the code was usually quite limited.
My feeling, though this could probably be better answered by folks that are fans of said template techniques, is that the primary usage of such happens in academia and smaller shops.
That might be your modern C++ (and perhaps the ideal), but the variety that I've seen to be the de facto standard in corporate projects is basically just as he described: like Java.
Well the defacto standard for most corporate projects seems to be java... So it doesn't surprise me that even people not using java would still write java-like code.
I think that flows in both directions. Java was modeled after the way that corporations used C++ and much current usage of C++ is influenced by people coming from Java.
I am (a little) surprised at how well the C example reads vs the C++ version. I would have thought that an OO design pattern (here, Observer) is where C++ syntax would be a better fit.
"But C++ often hits a sweet-spot between languages where high-level abstractions are available with the raw power of C when you need it." He then goes on to say he uses Ruby and not Python. Is Ruby missing nice C integration? Python is oft-touted as the sweet spot here, although I have to confess I haven't done a whole lot of Python/C or Python/C++ integration.
I just like Ruby more. You can connect both Python and Ruby to C APIs, and I've done so in the past from Ruby.
C++ integration is usually moderately more annoying since once you start moving beyond ordinal types cross-language communication becomes hairier. C ends up being the lingua franca between programming environments a lot of the time.
It is just as easy to extend any of the scripting languages with C++ as it is with C. SWIG and other systems like XS have built-in support for C++. Even if that weren't true, you can just make your interface header files 'extern "C"' yet enjoy the superior power of C++ in your implementation files.
There is no reason to favor C over C++ when extending a scripting language.
I think he meant that if you were going to pick one language that was both high level and perform well it would be C++. To do better you would have to, as you suggest, split it in to two languages.
In Smalltalk/X, you can just inline C in a method. There are ways of doing that for Ruby as well. It's also fairly easy in Smalltalk generally to do callouts to a DLL, or to implement your own "primitive" method in C.
Tcl is actually the sweet spot in terms of its C API - you can do pretty much anything you can do in the language itself, and more. And it's all very nice code to work with.
It looks to me in the C version, he only frees the first listener. The C++ version also provides the listeners as a set. The C version doesn't mind if you add the same listener multiple times, so to be apples to apples you'd use a vector, but the code wouldn't change otherwise, so no problem there.
in std::cout << "Whoopee." << std::endl;
is std::endl putting a newline char after "Whoopee. "?
Anyway in the C example it could have been written puts("Whoopee."); instead of printf("Whoopee. \n");
puts() places a \n after the char * it accepts as an argument.
