It is interesting in that I find that Coursera courses highlight the flawed learning processes she mentions quite well. I often find myself watching the videos, thinking I get it, buzzing through the usually basic follow-up questions, and moving on. Likely that material won't last in my brain for very long in a quickly usable fashion.
Coursera simply mirrors collegiate pedagogy: a professor lectures you for an hour, you take a quiz here and there, and then there are some larger assessments that prove mastery. Study habits and methods are entirely left up to the student. You could employ Dr. Oakley's methods, whatever works for you, or just breeze by without truly internalizing anything.
Coursera's missing one powerful dynamic of a traditional university, however: incentives to remember beyond a class.
Say you coast your freshman year without internalizing: you'll pay the price the following year or when you take some cumulative assessment like the MCAT.
With Coursera everything still feels very disjointed. Even in the specializations, knowledge doesn't need to compound for success. You can easily succeed in edutainment mode. Why take notes when you can use your hands for popcorn?
They said Groupon is one of the "examples of successful Chicago based startups". So it's no longer a startup. And it IPOed recently whereas Orbitz IPO'ed in 2003 so it's not a recent startup.
I like these "You CAN do X with Y!" types of posts - especially when it's not the same drum being banged over and over.
I think there's a really big part of this case study that isn't mentioned (perhaps because there is currently no data): bringing on more engineers. It really seems as if the number of C++ developers ready to be a part of the startup ecosystem is small. That is the impression that sites like HN leaves me with at least.
He acknowledges its real power when talking about templates. That's what this feature is about: make template metaprogramming accessible, and the regular developers of the world will be more inclined to make use of the features.
Agreed - but this is why modern features should be paired with modern tools. A simple hover-over or click through in an IDE to show what the function signature looks like is pretty basic these days. Autocomplete on what that auto variable's API offers getting better and better as well.
I do not consider the API of a reasonably complex construct "obvious". That is often where IDEs shine for me - in java or any other language that can gather that info for me. It's scenarios where I don't have to go to cppreference.com, because the IDE is going to give me what I want directly.
I used to really be anal on making every single line explicit: no shortcuts. But over time, especially with increasing my usage of templates, I've come to relax on these things and prefer to put my efforts in good variable names and trusting the compiler.
I'm not saying you should use auto for basic types (especially ones that can be easily cast into each other - that shit gets dangerous). I am saying that auto is extremely powerful when working with most interesting APIs. The most recent example I have is a lot of things I end up doing with chrono.
There really is... diff tools that point to the compiler (or a parse tree for dynamically-typed languages) could be so much smarter than what we have now.
From my perspective this is fundamentally flawed logic. Why would you want to depend on a tool when you don't have to? Why would I want to hover over all sorts of auto variables to figure out their type when I could just read it instead?
Speaking as someone who has done a lot of C++ work with nothing more than Emacs, I don't think there is any particular value or virtue in using only the sort of tools that were available in the 80s. The problem of finding out exactly what sort of thing you are dealing with did not start with auto (the elements of expressions have never been labeled with their type), and I think better tools are the way to the solution. C++ is actually a good language for this, as as little as possible is left to be decided at runtime.
With regard to the hovering issue specifically, there can be a great deal of visual clutter from type names that is a hinderance to understanding most of the time; now you only have to see it when you need it. That is only the start, however; a decent IDE should, for example, make it easy to go from there to the declaration of the type, should you want to.
If I'm not going to depend on the IDE to tell me what a deduced variable type is, you can bet your ass I'm going to want to depend on it for autocompleting some of the insanely long type names are: std::chrono::steady_clock::time_point gets old real quick - and so does stead_clock::time_point (if you want to include the namespace).
It is interesting in that I find that Coursera courses highlight the flawed learning processes she mentions quite well. I often find myself watching the videos, thinking I get it, buzzing through the usually basic follow-up questions, and moving on. Likely that material won't last in my brain for very long in a quickly usable fashion.