Yes, the initial parts of the example could be accomplished with awk and xargs, but as the article goes on to demonstrate, even doing something like printing every nth element would be difficult.
I think the intent was for this to be more of a demonstrative example, and with a more complex, evolving, real-world processing pipeline, Akka streams could be really useful.
3. Check the "check/uncheck all" box (left of input box)
4. Observe strikethrough still present on "foo"
Digging in to the code[2], it looks like the "model-less" tenet caused the CSS class on the text and checkbox to go out of sync. In React, this would be a re-render and change in the virtual DOM, or in Angular, both would be bound to a shared model/scope.
If the simple TodoMVC example has a bug like this, the framework might not work too well for larger applications.
I like to put a summarizing comment in the code for lines that require justification like the ones you mention. That way the discussion happens on GitHub and the conclusion is in the code, where future developers will see it.
A good thing to think when you start adding documentation to the code is "Am I really writing readable and understandable code right now?". If you answer isn't yes without any hesitation, you usually need to refactor so other people can read your code instead of you needing to comment what you do.
Even in the movie 3 Idiots, at the end of the movie, the man with the pen points out that there's a reason for the complexity: bits of graphite flying around in zero gravity near instrument panels and people's eyes, etc.
Simplicity is great, but sometimes complexity is warranted. More importantly, assuming other smart people (many other smart people) are wrong without deep thought is not a good idea.
Not only graphite, but assuming a proper non-mechanical pencil, you'd end up with wood shavings in addition to the graphite bits flying about — which you could solve by adding a vacuum to the pencil sharpener, to capture the debris.
While I have worked through a decent amount of CLRS myself, I think there are much better ways to learn how to solve algorithmic problems. For example, programming competition books like Programming Challenges[1] forces students to solve real-world-ish problems according to performance constraints - a time constraint, either artificial (e.g., problem statement requires execution within 2 seconds) or actual (e.g., choosing an algorithm that is too slow means the sun will burn out before the algorithm terminates).
Books and contests of this nature teach algorithmic thinking, which is far more important than the actual algorithms themselves. It also provides a context for implementing these algorithms, which means the student gets to see the more practical aspects as well: testing it on corner cases, fighting with the chosen implementation language, relying on compiler optimization, etc.
If the goal of the undergraduate program is to develop practitioners of computer science, or even graduates headed for academia, algorithmic thinking is essential. I don't think CLRS is necessarily the best way to teach that, and it certainly isn't the only way.
It's possible that you're confusing programmers with computer scientists. Not all programmers are computer scientists, and vice-versa.
I understand that the title of the post is about books programmers recommend, but computer science extends far, far beyond programming and learning how to engineer solutions to real-world problems using algorithms.
The important parts to people doing research in algorithms are well-covered in CLRS, and that's part of why it's such an excellent book. It's full of rigorous proofs and a lot of theory, but that's because the point of the text is the design and analysis of algorithms themselves, rather than the application of them.
A university has an obligation to its undergraduate students majoring in computer science to teach them about computer science, and learning to think about designing algorithms, rather than merely learning about using them, is something that I would fully expect as an undergraduate majoring in computer science at any major university.
I suspect this is part of why more and more universities are offering degrees in Software Engineering, where the theoretical aspects of the field are not as important.
True with a tiny caveat. Having worked through a lot of a "lesser" book: The algorithm design manual, what I have found missing in other books or contest driven practice is any practice of proofs of correctness. While, these are certainly probably completely practically useless in a SWE job, they do provide a good foundation for computer science undergrads to develop some mathematical maturity necessary to explore other branches of mathematics, say in grad school or at work in a more quantitatively demanding job.
I second Programming Challenges. Its one of my all time favourites because it helped me in the past and is my go-to for sample programs when learning new languages.
Regarding the Coffeescript-Javascript difference, Coffeescript and Javascript can be used transparently in node. Once require('coffee-script') is run, the module replaces the require function with one that can load both Coffeescript and Javascript.
This means that if there is a file ./lib/foo.coffee, the following code in bar.js will work:
require('coffee-script');
var foo = require('./lib/foo');
Yes, some people may not like Coffeescript anywhere in their project, but this functionality makes it easy to add Coffeescript to an existing Javascript project or use Coffeescript modules as a blackbox in a Javascript project.
That's pretty cool. I didn't know that worked so seemlessly.
Nonetheless, in order to use a library, you must either read the documentation or the source. The biggest issue is that most CoffeeScript projects document with CoffeeScript. Technically, you could read the compiled source, but that's usually a non-starter unless I truly need your project. Otherwise, I'm more likely to find someone else that's solved the same problem, but has written their docs / source in JavaScript.
