Using common functional tools can be a great way to simplify code like the example here, but as with most programming techniques, it can easily backfire in real-life scenarios.
There have been a number of times I've seen junior developers who are high on functional/immutable paradigms commit mazes of mapping, filtering, rolling and unrolling, resulting in something that's hard to understand and hard to debug.
Even in the example here, while it's obvious what the replacement code _does_, it's less clear what it's _intending_. I actually had to refer back to the original code to understand that the thing we were trying to generate were IDs of some sort.
Functional paradigm's problems are severe but people dismiss them as something we'll grow out of. If you can't tell what the code is intended to do, then the "savings" of functional are spent on more comments and documentation. Which is worse than the previous state of affairs.
It's also a little bit of Paul Graham's fault with his silly accumulator challenge. Not every language needs closures, and because closed over variables act as global variables, they might even undo the progress we've made in adopting structured programming. But by framing accumulator-capable languages as being more "powerful" now nobody wants to forgo them.
I've seen a-million-and-one junior developers screw up for-loops, too, with overly complex code that's hard to understand and debug. That's in no way unique to FP.
I would need at least 3 more pieces of data -- the other (experience_level, programming_style, bug_rate) tuples -- in order to judge whether this constitutes a pattern which is best avoided.
> I've seen a-million-and-one junior developers screw up for-loops, too, with overly complex code that's hard to understand and debug.
Everything can be abused. I see people doing side effects in their mapper callbacks, deeply nesting ternaries and switch and if/else statements, mutating far off objects, and just generally making code way more complex than it needs to be. Usually, this is from junior devs, but not always.
In the right hands, functional programming in JS can be very powerful. It can be easier to reason about (linear data flow, declarative code), and more performant (immutable data structures, transducers). In the wrong hands, it can be even more opaque than imperative, procedural code.
What tends to be absent in the simple analysis that leads to these kinds of hammer-to-all-nails solutions is a full enumeration of the classes of errors or intractable problems in the domain, and how the proposal does or does not address each.
This blogpost does not even attempt such an enumeration, but instead appeals to aesthetics.
FWIW I went through a period of using map and filter a little bit, went, "that's nice", and then resumed using for loops, sometimes with comprehension syntax to sugar it up. Both methods basically cover ways to specify simple iteration and selection. But I know which one is going to port better across the majority of environents: the plain for-next, and if a complex iteration is called for, the while loop. It puts the data allocation where I can see it, and it maps to the single-threaded computing model that is still the default today.
If I want a more complex query, I am going to start wanting a more expressive query language than either imperative or functional selection and iteration can provide by themselves. Left outer joins do not come easily to either method. Neither does constraint logic programming. You obviously can implement those things, but it isn't blindingly obvious, and when your problem grows to need a very broad expression of selection and iteration, it is those kinds of tools that you really need to aim for.
Complaints About "Considered Harmful" Titles Considered Harmful...
I like the colorful history of this phrase, and how it usefully marks the following argument as an unbridled assault against purportedly common wisdom, so we can treat it with the huffy disdain with which we should normally treat such cheeky endeavors.
It feels to me like something a motivated open source project could do well, too. What's the thing that will get people to pay for this? Slick team/enterprise features?
As you correctly guessed, we're planning to provide features that would be useful to teams and larger organizations. Shared commands, integrations with custom internal tools, shared instant knowledge base and so on.
Got stuck at the paywall -- Do they link out to or otherwise name the dataset? When my kids start thinking about what they want from their post-secondary education, this is the sort of thing I wouldn't mind having on hand.
It hadn't even occurred to me that there were serious academic attempts at visualizations of this sort. In addition to OP, this whole discussion is full of great alternatives to d3-force (my usual go-to). Kudos to all!
I believe you're incorrect, Johnny five supports both runtime models.
Was playing with Johnny Five yesterday (while they were releasing 1.0, fun to watch), and was deploying my node project code to my Tessel 2, which then ran independently of my laptop.
I was amazed at how easy it was to go from 0 to deployed code running reliably on the (detached, untethered) dev board. At least when working with the Tessel 2, they really think through the dev experience end-to-end.
Make Magazine's Make Controller Kit followed the same model. Unfortunately, it was maintained by one guy during nights and weekends (which meant it was never well supported and became deprecated before it was useful). Still, the model of allowing developers to learn robotics in whatever language they're comfortable in is fantastic for making the field accessible to newcomers!
I tried my hand at an MCK because I could do it from ActionScript, a language I was already comfortable with. Asking users to learn both about controlling hardware and a new programming language/model simultaneously steepens the barrier to entry versus decoupling those things.
For those who aren't familiar, Gerrit (the code review system used by Android at this point, think GitHub Pull Requests but better/worse) uses "Anonymous Coward" naming for those users it doesn't otherwise have a good name for.
Others point out this usage probably finds its origin in Slashdot culture, which is likely true, but also probably a ternary relationship in this instance.
Longtime D3 (even Protovis) user here. I think you're very correct in that D3 itself is not a good choice for "a simple chart or graph". If that's all I needed, I'd stick with HighCharts, or ggplot, or any of dozens of other libraries that do simple charts well, and often with a lot more batteries included. My unsolicited advice would be to consider staying away from D3 until you need it.
But if you're doing anything remotely bespoke, with any sort of custom interaction or transition, or anything in which you need to multiplex several datasets in a single set of visualizations, this toolkit is hard to beat.
My favorite personal D3 use case so far is modified animated scatter plots/beeswarms using force layouts. Immortalized for me in the "Four Ways to Slice Obama’s 2013 Budget Proposal" ( https://archive.nytimes.com/www.nytimes.com/interactive/2012... ), I've found that set of techniques useful for visualizing business processes in my own work over the years.
I've yet to encounter anything else that comes close to enabling those kinds of data visualizations. It's the "funky abstractions" some folks have trouble with that enable me to swap out X or Y scales with intuitive animations by literally replacing a single object and then re-invoking an idempotent render() function. Working with D3 is the most productive I've ever been in my life from a data visualization standpoint, and I suspect that will continue to be the case for some years.
