From the article: "The impossible challenge with Docker is to come with a working combination of kernel + distribution + docker version + filesystem. Right now. We don’t know of ANY combination that is stable (Maybe there isn’t any?)."
What combination of Docker version + distro + kernel + filesystem are you running, and how stable is it?
I've seen many glowing references to Feynman's Lectures on Physics, but this is the first time I've seen them called a failure. Could you share a bit more about why they're considered a failure?
The lectures are well-regarded by many, but it's been argued that they're ineffective for teaching undergraduate students the process of solving physics problems.
Feynman himself was an exceptional mathematician, and used a very mathematical approach to solve problems. But once arriving at the solution, he identified a concise intuitive explanation, which he then presented to others. Everyone was impressed with the brilliant intuition, but it didn't accurately reflect the more laborious and mechanical approach he used to solve the problems [1]. The Lectures of Physics are similar: a series intuitive explanations that would be difficult to discover independently without actually working through the math.
Problem with these lectures is, they require too much work for a layman to benefit from them; at the same time, they are too elementary to be useful for a seriously interested person (say, an engineer). The book may still be good for schoolchildren who are interested in physics. I find more traditional courses, such as Berkeley Physics Course, more informative.
Member of the peanut gallery here, and I fully agree with Renner1. I occasionally do front end development work, and the pace of change makes life very difficult.
Imagine someone who last wrote a Python/Ruby/C/Java application 5 years ago - they could hit the ground running and learn a few new best practices and tools in 1-2 new weeks.
Compare that to someone who wrote a JS app 1-2 years ago - they have months of catching up to do. It feels like the JS landscape is changing so fast that keeping up with things is a full-time job.
I actually just went through this myself. I had last done frontend work in about 2010, maybe a little in 2011, and realized my skill set was probably getting stale, so I asked my boss if I could do frontend for a bit, with the understanding that I'd underperform. He said sure.
I've left and returned to C++ a couple of times. Same for Java. Most recently, I did some Ruby dev in 2015 after last doing it in 2006. In all of these instances, while there was some library and language churn, it was pretty easy to pick up. C++ lambdas are just cleaner syntax for functors, and the better optimizers and reworked libraries mean they're more widely usable, but no big deal. Java has a streaming library now and lambdas of its own, but it's largely syntax sugar, and even if Grade has largely replaced Maven, the concepts and issues are roughly identical. Bundler was new to me, but why it existed was transparent and its relationship to gems was clear, so only an hour or so of work was enough to get me up to speed. I assumed web work would be similar.
I felt like I was relearning from scratch. jQuery was gone; use anything else. There are several different build systems, all slightly incompatible with each other, to replace YUI compressor and Closure. Prototypes are gone, classes are in. Underscore is gone, and a richer class library is in, but it's not widely supported, so you have to cross compile, for which you need source maps. Some best practices became worst (shove all the JS into one file is the new hotness), but apparently may go to worst (fracturing is better due to HTTP/2 push).
I have actually seen this before: Windows, as it switched from the 3.1/95 series to the COM-heavy NTs, had churn like this. So did Carbon to Cocoa, and arguably Cocoa prior to 10.3 and after, and again once ARC was introduced. But those were single events, whereas this seems, from where I sit, to be a sustained burn.
It really depends on what your goal is. You don't need to buy into any of it and still write high quality software. Concat & minify is still there like it always was (what tools you use to get this done is really irrelevant). You don't need to use Node, NPM, webpack, rollup, babel/buble or classes because today that means you're obligated to use all the tooling and compilation. Not to say that these things dont add value, but the value is greatly overhyped for projects that are not Facebook or Google sized. Virtual dom, Promises, rAF, Canvas, CSS3, new web APIs are definitely worth learning because they provide huge value and will be around for a long time. There has certainly been a shift towards declarative/functional/immutable paradigms in JS but that doesnt mean it works better for all cases.
Might as well do a shameless plug here. If you don't want to learn the current hotness-of-the-month. I've written domvm [1] to be small, fast, fully free from dependencies and build/tooling requirements. It uses virtual dom concepts under the hood, so you get the benefits of both declarative templates and imperative views in pure JS and a very small learning curve.
Believe me when I tell you that you can still write complex-yet-maintainable, performant web-apps with just your browser and vim/notepad w/syntax coloring.
If you're looking to be employable, though, you'll probably need to learn Angular/React/Vue and everything that comes with them ;)
>It really depends on what your goal is. You don't need to buy into any of it and still write high quality software.
Unless you also make the decisions at the company you work for, no you really can't.
What you said only applies to people making those decisions for their teams or working alone. Others are at the mercy of whatever BS du jour they'll be asked to code in.
Good point. But if you come to a team where the environment is already set up for you, then at least you avoid the headache of choosing/debugging every nut and bolt of the system just to begin writing code.
If you're in a position to define the stack, you have to weigh the benefits vs churn very carefully.
This situation is way better than everyone having an in-house "library" that you have to learn, which is what it seemed like what happened a few years ago (it would be something in house, layered on top of jQuery or whatever).
I prefer mocha to qunit and I'm a fan of coffeescript (ES6 can wait. I love the existential operator). My company had made a few decisions before ember-cli that weren't on the Ember Happy Path. I've tried to stick to those decisions to avoid making people learn a different stack. It's not that easy to rip and replace pieces of Ember.
A, but there's a catch! I've asked for a company's range many times, and they have yet another non-answer answer: "we don't have a firm range in mind, we're confident compensation won't be an issue for a top candidate".
It's a game of chicken. The best counter I have is "what is the top of your range if we have a perfect fit?", but even that doesn't always work.
At this point, I'm sick of games. If a company refuses to disclose a salary range and/or insists on getting me to quote a number, I lead with $2X0 and see what happens. 80+% of companies aren't willing to hit that high, and the other 20% have been more interesting roles at higher quality companies.
What combination of Docker version + distro + kernel + filesystem are you running, and how stable is it?