#this also applies to anyone else reading this who is interested in collaborating on dumb projects like this i have no art skills and very ve | Explore Tumblr Posts and Blogs

arecomicsevengood · 6 years

Text

Stuart Immonen Superman Comics Circa 1998

There’s a lot of “best of the year” lists that appear at the end of the year, but after that flutter of activity, tied to commercial imperatives, there are moments for reconsideration, as we approach the year to come and ask ourselves what it is we want. So now is as good a time as any to talk about some Superman comics Stuart Immonen drew some twenty-odd years ago. The artist announced earlier this year that he was “retiring” from comics, but this didn’t mean he was going to stop making comics, just that what he did would be “personal” work, in collaboration with his wife. They recently launched a comic on Instagram, and they’ve done some graphic novels together previously, none of which I can recommend.

I do think it’s interesting that these personal works are scripted by his wife, rather than him writing them himself, though; because back in the nineties, working for DC, he took a few stabs at writing. This was done within a framework that must’ve removed some of the risk involved: The four monthly Superman series that together constituted a weekly serial split between different creative teams had him drawing Karl Kesel’s scripts for a few years before he took over a separate title for his own. In my mind, much of the overall plotting would be hashed out at a conference, and then kept coordinated by an editor. Ideally this process would be oriented around what it was each individual creative team wanted to write and draw: Immonen’s artwork was a little softer than his compatriots, a little more likely to seem like he could’ve drawn romance comics in a different era, maybe younger than the others and more interested in youth culture and fashion, probably more likely to admire Jaime Hernandez. Maybe all this just manifests in the context as being the one who could draw women, but in a era where none of the Superman comics are showy about what they do and all aspired to being solid and well-crafted, his were the most enjoyable.

This softness I appreciate in this work isn’t really present in his subsequent work, which is sharper, shinier, where figures and their wardrobes seem consistently sculpted out of plastic. Part of it’s the coloring, but there also seem to be changes in how scripts call for layouts. He’s also maybe working with ink wash underneath the digital coloring and delineating more how he wants values of light to be approached, I don’t know. I don’t really want to diminish the work the man’s been doing in the years I haven’t been reading superhero comics. I can look at the years of intervening work and see how the choices he’s making are confident ones, the result of years of drawing action comics. I haven’t really read any of them, but that’s not to say I wouldn’t.

Still, if you’re anything like me, you probably generally think that comics created by one person are better than those made in a collaboration mediated via a written script, so if I’m going to read anything by the guy, it’s going to be work created under those circumstances. I’ve heard that DC sort of has structures in place against writer-artists: this is why those “Bizarro World” anthologies where they brought in alternative cartoonists forced them all to collaborate with each each other. Maybe this rule was a little looser with the Superman books: After John Byrne relaunched the line in the mid-eighties, both Dan Jurgens and Jerry Ordway would write and draw chunks of their subsequent runs. Otherwise it’s pretty rare: The only other thing I can think of would be that Rick Veitch Swamp Thing run, the circumstances of its ending probably be why they don’t let that happen too often. A little after Immonen and Kesel did the event The Final Night, Immonen wrote and drew a 4-issue miniseries spotlighting the Legion Of Super-Heroes character Inferno. It’s not good or anything, but it does seem to revolve around the strengths or interests I understand him having at this time: It’s a comic about a young woman, hanging out in the mall with a group of other young women, who might be understood as punks, as some are homeless. Before Immonen worked for DC, his initial small-press work, Playground, made in collaboration with his future wife, was described in “punk rock” terms. He states in the Inferno letter column his goal was to make something someone who didn’t read other DC Comics could read and enjoy. I don’t think it gets anywhere near being able to achieve that, it’s confusing on multiple levels. The covers are probably the most memorable part, but because you can track those down easy enough, I’ll include a bit of interior sequential art.

Not long after that, he took over writing Action Comics. I haven’t read that many of those either! I had stopped reading the Superman comics regularly not long before this happened. It was during the time period when Superman had electric powers and a blue costume. I was in middle school. I found out he’d started writing when I found a couple issues in a bargain bin and picked them up, but I didn’t get back in the habit of reading Superman comics, as the story was pretty difficult to follow if you attempted to only read the series with the best art. He also didn’t really work as a writer for that long: After a little while, Mark Millar gets credited for providing scripts.

But a little while back, around the time I wrote that post about why I’m willing to read superhero comics with some degree of hope that they’ll be good, I ordered a three-issue arc that seemed kind of self-contained. Looking online, it seemed like after the whole “electric Superman” story wrapped up with a special called Superman Forever, each of the four monthly books told their own stories, set in different historical eras, for a few months. Immonen’s Action Comics issues had covers suggesting they were united in progressing from one to the other. I was pretty into them, though in some ways it was an unsatisfying experience. The first issue in the arc is drawn by a fill-in artist, the third part focuses on this separate narrative thread- It’s narrated by this new villain, with god-like powers, who I guess was behind the whole “multiple timelines” thing in the first place, so you there’s exactly one fairly self-contained normal Superman comic written and drawn by the dude, though that third issue kinda rules, as aside from the narration, you’re reading all the normal Superman storytelling stuff happen wordlessly, calling attention to the clarity of the storytelling. It might fail to live up to expectations for a third act based on the way serialization has it setting up the next big arc, but as an episode in itself, this would be a pretty fun surprise to come across in your pile of the week’s comics. Which, if you remember that post, was exactly what I claimed to be looking for.

There’s also an original graphic novel that’s a little later still, “End Of The Century,” which seems like it’s partly tying up a long-running subplot in the Superman comics about Lex Luthor and his wife. It honestly has WAY too much plot, and too many narrative threads, and it’s all still fairly generic. While I picked it up hoping to see cool visual storytelling, the amount of story there is to tell gets in the way. The visual art is good, Immonen’s linework shifts to be a little finer. There’s also this weird thing where real images are photographed/scanned and inserted like they’re laying on the edges of the page, which is dumb, but the technology to achieve this effect was probably only recently made available. There’s also some sepia painted pages, and the most likely reason the “graphic novel” exists is because Immonen wanted to do the painted pages and have the time to work on them. That’s as good a reason as it is to try writing comics for a few years because you’ve drawn them for a few years and writing doesn’t seem hard and you would get paid more, and reasoning resulted in work I thought was better than what you usually get.

Ambition is a wild thing, in that it can really just stir inside you feeling frustrated even as you have no idea what you want to do with it in particular. It can easily be applied to other people’s ends. Work might be personal not because of the importance of what “the artist” has to say but because it’s an outgrowth of a personal relationship. It’s worth noting, looking at his career, the importance of cultivated professional relationships: He had those comics scripted by Mark Millar, and decades later they did a comic together which has probably resulted in a development deal and a sizable paycheck. He did two creator-owned comics with Kurt Busiek, largely forgotten I’d say, and then worked with him on a Superman comic which is pretty well-regarded. He’s collaborated with both Warren Ellis and Brian Bendis multiple times. It is sensible to view all those professional relationships as having had their respective culminations, while working with one’s wife is more of an ongoing long-term project.

At the same time: Having someone write for you, and what they see as your skillset, is going to present different challenges than seeing what you can do and pushing yourself, even if the latter results in what can be easily described as failure. It’s fine either way. Career paths in the arts are always going to be weird and haphazard, because there are so many decisions to make in creating a piece of art that progress is never going to be linear. I don’t know if any of these collaborations embraced what I like about his work, but maybe what I like in his work isn’t what he sees as his strengths, but is just what was emblematic of his style at the point in time I was initially exposed to it. The questions of who we are in relationship to others vs. what our true potential is is always up for negotiation.

I think those Superman comics excel because I came to them with very particular set of expectations. Not only can I not expect anyone else to share those expectations, I don’t even really want to convince anyone to have them: There’s no small part of me that thinks of the fact that I tracked them down to write about them is in some ways squandering some bit of potential inside myself I can’t expect anyone else to care about. I don’t know what 2019 looks like, though I hope I won’t spend too much of it looking back twenty years at comics from 1999. I don’t like doing this thing where I try to make something “personal” to rationalize my talking about some some comic while actually just talking in vague generalities because I’m very reticent to talk about myself, but I’ll probably continue to do so. I’m probably not going to spend the next year looking at Stuart Immonen’s Instagram feed. But here at the end of this year, as I contemplate my own inertia and depressive laziness, I have to give an honest accounting and give it up to that dude for putting in the work.

5 notes · View notes

warninggraphiccontent · 5 years

Text

26 April 2019

InCiSE-ive analysis

Which country has the world's most effective civil service? The latest International Civil Service Effectiveness Index (InCiSE), a collaboration between IfG and the Blavatnik School of Government with support from the UK civil service, was published yesterday and has some of the answers. It also has lots of interactive charts and the data behind them. I'm really pleased to have played a small part in the project - I think it's a great example of how data can enable the right conversations (we know an index can never be definitive, but it's prompted lots of talk about which countries should be learning what from elsewhere and what else would be worth including).

I think it's also a great example of a much-maligned chart type - radar charts - being used to convey data very clearly (here's a version from me). I'll write a short post on that soon (I already have some dreadful radar-related puns lined up, but further ones welcome). In the meantime, you can read a quick summary by me; an excellent comment piece from Blavatnik's Calum Miller on how the UK did so well despite, well, you know; a report from Civil Service World; and the report itself, the technical details behind it and some case studies of how the InCiSE framework could be applied to countries not included in the index. The 2017 version is here.

Elsewhere... Owen Boswarva took exception to DCMS describing data as 'fuel' (though I've definitely found myself accidentally calling it that from time to time...). It reminded me that Rachel Coldicutt started a spreadsheet to record such data metaphors. And that the ODI's strategy has some useful 'scenarios'. And that we once idly came up with some at the Institute, moving from data mining and data wrangling to data gardening (it's a wild world out there, you choose what to cultivate and how to landscape it) and data carpentry (you start with a big block of the whole world and then plane and shave it down, I think). I actually can't remember if we made all of those up or if we genuinely saw them somewhere.

It's just a few days until our next Data Bites event, which should (like the last one) be great fun as well as extremely interesting. Come! (And put Tuesday 4 June in your diary for the next one.)

Somebody said to me a few weeks ago that my hometown is only ever on the news when there are vox pops on Brexit to be conducted or something bad has happened. I'm therefore very relieved this morning that this wasn't a lot worse.

And I think, remarkably, that's the only mention of Brexit in this week's newsletter. Let's see how long that lasts...

Gavin

Today's links:

Graphic content

USA

Explore a detailed view of the Mueller report (Axios)

It's been at least five minutes since a bar chart race so here's one on Democratic candidates for president (Google Trends)

Everything's deadlier in the South (Axios)

Why you should never start a trade war with an autocracy* (The Economist)

Who’s Running for President in 2020?* (New York Times)

Elections

Spain's general election 2019: all you need to know (The Guardian -problem solved?)

Where are local elections taking place in England? (House of Commons Library)

Walt domination

Disney Faces Fresh Criticism After Heir Calls Iger’s Pay ‘Insane’*(Bloomberg)

Every Company Disney Owns (The Big Picture)

#dataviz and #ddj

The Upshot, Five Years In* (The Upshot)

Preview: The 20th Century in Infographics (May 2019) (Sandra Rendgen)

A very strange chart? (via Eric William Lin)

How we mapped rent affordability using the Ordnance Survey’s Open Zoomstack map tiles (BBC Visual and Data Journalism)

Everything else

Rich nations urged to prepare workers for age of automation* (FT)

Which countries eat the most meat? (BBC News)

What the Airbnb surge means for UK cities (BBC News)

Ministerial directions (IfG)

Sport

Can anyone break Alan Shearer's Premier League goals record? (BBC Sport)

The Premier League teams’ ineptitude index 2018-19 (The Guardian)

Meta data

Leadership

UK fails to fill role of national statistician* (FT - my take, Will's less critical though not contradictory one)

Pleased to see statistical leadership will be the focus of a systemic review by @UKStatsAuth as outlined in the new Office for Stats Regulation business plan (via Hetan Shah)

Long reads

The Fragmentation of Truth (danah boyd)

The Real Stars of the Internet* (New York Times)

One country blocks the world on data privacy (Politico)

Location

How can we bring transparency to urban tech? These icons are a first step. (Sidewalk Talk - although..., and indeed...)

Is data literacy being taken seriously enough in the UK? (diginomica)

Why Google Maps and Citymapper are terrible for walking directions*(Wired)

Geospatial Commission making geospatial data more accessible(Geospatial Commission - though as Owen Boswarva points out, one of its partner organisations is missing. This one)

AI, algorithms, automation

Western AI researchers partnered with Chinese surveillance firms* (FT)

A new alphabet for Europe: Algorithms, big data, and the computer chip(Brookings)

WE’VE BEEN WARNED ABOUT AI AND MUSIC FOR OVER 50 YEARS, BUT NO ONE’S PREPARED (The Verge)

Removing unnecessary processes the right way (MoJ Digital and Technology)

Complex automation won't make fleshbags obsolete, not when the end result is this dumb (The Register)

Some AI just shouldn’t exist (Vox)

This thread has quickly become a really great discussion on AI and government in history (via Michael Veale)

Everything else

What does it mean for NHSX to be an ‘open source’ organisation?(Technology in the NHS)

China’s unchecked expansion of data-powered AI raises civic concerns*(FT)

On openly publishing government algorithms (via Tom Forth)

You can lead a person to data, but you can't make them use it (Nesta - discussion here and here)

Government immigration database 'deeply sinister', say campaigners(The Guardian - although...)

The only way to rein in big tech is to treat them as a public service (Nick Srnicek for The Guardian)

Opportunities, etc

ODCamp is looking for a London venue (ODCamp)

JOB: Senior policy adviser, National Data Strategy (DCMS)

WORK: Help DfT scope out a data strategy (via Giuseppe)

OPPORTUNITY: Applications for @DataSciCampus sponsorship for UK public sector analysts to undertake the MSc in Data Analytics for Government starting in the 2019/210 academic year are now open (via Dave Johnson)

And finally...

Logos

Ranking UK Parties Logos (Election Maps UK, via Marcus)

Lost logos of the London Boroughs (@LCCmunicipal)

32 Game of Thrones Data Visualizations (Jeffrey Lancaster, via in other news)

The Man Who Solved ‘Jeopardy!’ (FiveThirtyEight, via Tess)

Everything else

Perception (Steve Stewart-Williams)

The price of fish (via Devin Pope)

More Amazing Cutaways Of London Underground Stations (Londonist)

How did the qwerty keyboard become so popular? (BBC News)

Queen Elizabeth II just turned 93 years old. See her banknote evolution.(Norbert Elekes)

0 notes

techscopic · 6 years

Text

I Don’t Hate Arrow Functions

TL;DR

Arrow functions are fine for certain usages, but they have so many variations that they need to be carefully controlled to not break down the readability of the code.

While arrow functions clearly have a ubiquitous community consensus (though not unanimous support!), it turns out there’s a wide variety of opinions on what makes “good” usage of => and not.

Configurable linter rules are the best solution to wrangling the variety and disagreement of arrow functions.

I released proper-arrows ESLint plugin with several configurable rules to control => arrow functions in your code base.

Opinions are like noses…

Anyone who’s followed me (tweets, books, courses, etc) for very long knows that I have lots of opinions. In fact, that’s the only thing I’m an expert on — my own opinions — and I’m never at a loss for them!

I don’t subscribe to the “strong opinions, loosely held” mantra. I don’t “loosely hold” my opinions because I don’t see any point in having an opinion if there isn’t sufficient reason for that opinion. I spend a lot of time researching and tinkering and writing and trying out ideas before I form an opinion that I would share publicly. By that point, my opinion is pretty strongly held, by necessity.

What’s more, I teach based on these opinions — thousands of developers in different companies all over the world — which affords me the opportunity to deeply vet my opinions through myriad discussion and debate. I’m tremendously privleged to be in such a position.

That doesn’t mean I can’t or won’t change my opinions. As a matter of fact, one of my most strongly held opinions — that JS types and coercion are useful in JS — has been shifting lately, to a fairly significant degree. I have a much more rounded and deepened perspective on JS types and why type-aware tooling can be useful. And even my opinion on => arrow functions, the punchline of this article, has evolved and deepened.

But one of the things many people tell me they appreciate about me is, I don’t just state opinions, I back those opinions up with careful, thought-out reasoning. Even when people vehemently disagree with my opinions, they often compliment me on at least owning those opinions with backing.

And I try to inspire the same in others through my speaking, teaching, and writing. I don’t care if you agree with me, I only care that you know why you have an technical opinion and can earnestly defend it with your own line of reasoning. To me, that’s a healthy relationship with technology.

Arrow Functions != functions

It is my sincere belief that the => arrow function is not suitable as a general purpose replacement for all (or even most) function functions in your JS code. I genuinely don’t find them more readable in most cases. And I’m not alone. Any time I share an opinion like that on social media, I often get dozens of “me too!” responses peppered in with the scores of “you’re totally wrong!” responses.

But I’m not here to rehash the entire debate over => arrow functions. I’ve written extensively about my opinions on them, including these sections in my books:

“You Don’t Know JS: ES6 & Beyond”, Ch2, “Arrow Functions”

“Functional-Light JavaScript”, Ch2, “Functions Without function“ (and the preceding section on function names).

Whatever your preferences around =>, to suggest that it’s only a better function is to be plainly reductive. It’s a far more nuanced topic than just a one-to-one correspondence.

There are things to like about =>. You might find that surprising for me to say, since most people seem to assume I hate arrow functions.

I don’t (hate them). I think there are definitely some important benefits.

It’s just that I don’t unreservedly endorse them as the new function. And these days, most people aren’t interested in nuanced opinions in the middle. So since I’m not entirely in the pro-=> camp, I must be entirely in the opposition camp. Not true.

What I hate is suggesting they’re universally more readable, or that they’re objectively better in basically all cases.

The reason I reject this stance is because I REALLY DO STRUGGLE TO READ THEM in many cases. So that perspective just makes me feel dumb/inferior as a developer. “There must be something wrong with me, since I don’t think it’s more readable. Why do I suck so much at this?” And I’m not the only one whose impostor syndrome is seriously stoked by such absolutes.

And the cherry on top is when people tell you that the only reason you don’t understand or like => is because you haven’t learned them or used them enough. Oh, right, thanks for the (condescending) reminder it’s due to my ignorance and inexperience. SMH. I’ve written and read literally thousands of =>functions. I’m quite certain I know enough about them to hold the opinions I have.

I’m not in the pro-=> camp, but I recognize that some really do prefer them, legitimately. I recognize that some people come to JS from languages that have used => and so they feel and read quite natural. I recognize that some prefer their resemblance to mathematical notation.

What’s problematic IMO is when some in those camps simply cannot understand or empathize with dissenting opinions, as if there must just be something wrong with them.

Readability != Writability

I also don’t think you know what you’re talking about when you talk about code readability. By and large, the vast majority of opinions on code readability, when you break them down, are based on a personal stance about preferences in writingconcise code.

When I push back in debates about code readability, some just dig in their heels and refuse to support their opinion. Others will waive off the concerns with, “readability is all just subjective anyway”.

The flimsiness of that response is stunning: two seconds ago they were vehemently claiming => arrow is absolutely and objectively more readable, and then when pressed, they admit, “well, I think it’s more readable, even if ignorants like you don’t.”

Guess what? Readability is subjective, but not entirely so. It’s a really complex topic. And there are some who are undertaking to formally study the topic of code readability, to try to find what parts of it are objective and what parts are subjective.

I have read a fair amount of such research, and I’m convinced that it’s a complicated enough topic that it can’t be reduced to a slogan on a t-shirt. If you want to read them, I would encourage you doing some google searching and reading of your own.

While I don’t have all the answers myself, one thing I’m certain about is, code is more often read than written, so perspectives on the topic which ultimately come from “it’s easier/quicker to write” don’t hold much standing. What needs to be considered is, not how much time do you save writing, but how clearly will the reader (future you or someone else on the team) be able to understand? And ideally, can they mostly understand it without pouring over the code with a fine-toothed comb?

Any attempt to justify writability affordances with unsubstantiated claims about readability benefits is a weak argument at best, and in general, nothing but a distraction.

So I roundly reject that => is always and objectively “more readable”.

But I still don’t hate arrow functions. I just think to use them effectively, we need to be more disciplined.

Linters == Discipline

You might be of the (incorrect) belief that linters tell you objective facts about your code. They can do that, but that’s not their primary purpose.

The tool that’s best suited to tell you if your code is valid is a compiler (ie, the JS engine). The tool that’s best suited to tell you whether your code is “correct” (does what you want it to do) is your test suite.

But the tool that’s best suited to tell you if your code is appropriate is a linter. Linters are opinionated collections of rules about how you should style and structure your code, so as to avoid likely problems — according to the authors of those opinion-based rules.

That’s what they’re for: to apply opinions to your code.

That means it’s almost certain that these opinions will, at one time or another, “offend” you. If you’re like most of us, you fancy yourself pretty good at what you do, and you know that this thing you’re doing on this line of code is right. And then the linter pops up and says, “Nope, don’t do it that way.”

If your first instinct is sometimes to disagree, then you’re like the rest of us! We get emotionally attached to our own perspectives and abilities, and when a tool tells us we’re wrong, we chuff a little bit.

I don’t get mad at the test suite or the JS engine. Those things are all reporting facts about my code. But I can definitely get irritated when the linter’s opinion disagrees with mine.

I have this one linter rule that I enabled a few weeks ago, because I had an inconsistency in my coding that was annoying me on code re-reads. But now this lint rule is popping up two or three times an hour, nagging me like a stereotypical grandma on a 90’s sitcom. Every single time, I ponder (for just a moment) if I should just go disable that rule. I leave it on, but to my chagrin.

So why subject ourselves to this torment!? Because linter tools and their opinions are what give us discipline. They help us collaborate with others.

They ultimately help us communicate more clearly in code.

Why shouldn’t we let every developer make their own decisions? Because of our tendency toward emotional attachment. While we’re in the trenches working on our own code, against unreasonable pressure and deadlines, we’re in the least trustable mindset to be making those judgement calls.

We should be submitting to tools to help us maintain our discipline.

It’s similar to how TDD advocates submit to the discipline of writing tests first, in a formal set of steps. The discipline and the bigger picture outcome of the process are what we value most, when we’re level headed enough to make that analysis. We don’t institute that kind of process when our code is hopelessly broken and we have no idea why and we’re just resorting to trying random code changes to see if they fix it!

No. If we’re being reasonable, we admit that the overall good is best served when we set up reasonable guidelines and then follow the discipline of adhering to them.

Configurability Is King

If you’re going to knowingly subject yourself to this finger wagging, you (and your team, if applicable) are certainly going to want some say-so in what rules you’re required to play by. Arbitrary and unassailable opinions are the worst kind.

Remember the JSLint days when 98% of the rules were just Crockford’s opinions, and you either used the tool or you didn’t? He straight up warned you in the README that you were going to be offended, and that you should just get over it. That was fun, right? (Some of you may still be using JSLint, but I think you should consider moving on to a more modern tool!)

That’s why ESLint is king of the linters these days. The philosophy is, basically, let everything be configurable. Let developers and teams democratically decide which opinions they all want to submit to, for their own discipline and good.

That doesn’t mean every developer picks their own rules. The purpose of rules is to conform code to a reasonable compromise, a “centralized standard”, that has the best chance of communicating most clearly to the most developers on the team.

But no rule is ever 100% perfect. There’s always exception cases. Which is why having the option to disable or re-configure a rule with an inline comment, for example, is not just a tiny detail but a critical feature.

You don’t want a developer to just have their own local ESLint config that overrides rules while they commit code. What you want is for a developer to either follow the established rules (preferred!) OR to make an exception to the rules that is clear and obvious right at the point where the exception is being made.

Ideally, during a code review, that exception can be discussed and debated and vetted. Maybe it was justified, maybe it wasn’t. But at least it was obvious, and at least it was possible to be discussed in the first place.

Configurability of tools is how we make tools work for us instead of us working for the tools.

Some prefer convention-based approaches to tooling, where the rules are pre-determined so there’s no discussion or debate. I’m know that works for some developers and for some teams, but I don’t think it is a sustainable approach for generalized, broad application. Ultimately, a tool that is inflexible to the changing project needs and DNA of the developer(s) using it, will end up falling into obscurity and eventually replaced.

Proper Arrows

I fully recognize my usage of the the word “proper” here is going to ruffle some feathers. “Who is getify to say what is proper and not?”

Remember, I’m not trying to tell you what is proper. I’m trying to get you to embrace the idea that opinions about => arrow functions are as varied as all the nuances of their syntax and usage, and that ultimately what is most appropriate is that some set of opinions, no matter what they are, should be applicable.

While I’m a big fan of ESLint, I’ve been disappointed by the lack of support from built-in ESLint rules for controlling various aspects of => arrow functions. There are a few built-in rules, but I’m frustrated that they seem to focus mostly on superficial stylistic details like whitespace.

I think there are a number of aspects that can hamper => arrow function readability, issues that go way beyond what the current ESLint ruleset can control. I asked around on twitter, and it seems from the many replies that a lot of people have opinions on this.

The ultimate linter would not only let you configure rules to your liking, but build your own rules if something were lacking. Luckily, ESLint supports exactly that!

So I decided to build an ESLint plugin to define an additional set of rules around => arrow functions: proper-arrows.

Before I explain anything about it, let me just point out: it’s a set of rules that can be turned on or off, and configured, at your discretion. If you find even one detail of one rule helpful, it would be better to use the rule/plugin than not.

I’m fine with you having your own opinions on what makes => arrow functions proper. In fact, that’s the whole point. If we all have different opinions on => arrow functions, we should have tooling support to let us pick and configure those different opinions.

The philosophy of this plugin is that, for each rule, when you turn the rule on, you get all of its reporting modes on by default. But you can of course either not turn the rule on, or turn the rule on and then configure its modes as you see fit. But I don’t want you to have to go hunting for rules/modes to turn on, where their obscurity prevents them from even being considered. So everything comes on per rule.

The only exception here is that by default, all rules ignore trivial => arrow functions, like () => {}, x => x, etc. If you want those to be checked, on a per-rule basis you have to turn on that checking with the { "trivial": true } option.

Proper Arrows Rules

So what rules are provided? Here’s an excerpt from the project overview:

"params": controls definitions of => arrow function parameters, such as forbidding unused parameters, forbidding short/unsemantic parameter names, etc.

"name": requires => arrow functions to only be used in positions where they receive an inferred name (i.e., assigned to a variable or property, etc), to avoid the poor readbility/debuggability of anonymous function expressions.

"location": restricts where in program structure => arrow functions can be used: forbidding them in the top-level/global scope, object properties, export statements, etc.

"return": restricts the concise return value kind for => arrow functions, such as forbidding object literal concise returns (x => ({ x })), forbidding concise returns of conditional/ternary expressions (x => x ? y : z), etc.

"this": requires/disallows => arrow functions using a this reference, in the => arrow function itself or in a nested => arrow function. This rule can optionally forbid this-containing => arrow functions from the global scope.

Remember, each rule has various modes to configure, so none of this is all-or-nothing. Pick what works for you.

As an illustration of what the proper-arrows rules can check for, let’s look at the "return" rule, specifically its "sequence" mode. This mode refers to the concise return expression of => arrow functions being a comma-separated sequence, like this:

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Sequences are typically used in => arrow function concise returns to string together multiple (expression) statements, without needing to use a full { .. } delimited function body and an explicit return statement.

Some may love this style — that’s OK! — but a lot of folks think it favors clever terse style coding over readability, and would prefer instead:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Notice that it’s still an => arrow function and it’s not even that many more characters. But it’s clearer that there are three separate statements in this function body.

Even better:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

To be clear, the proper-arrows rules don’t enforce trivial styling differences like whitespace/indentation. There are other (built-in) rules if you want to enforce those requirements. proper-arrows focuses on what I consider to be more substantive aspects of => function definition.

Concise Summary

You and I almost certainly disagree on what makes good, proper => arrow function style. That’s a good and healthy thing.

My goal here is two-fold:

Convince you that opinions on this stuff vary and that’s OK.

Enable you to make and enforce your own opinions (or team consensus) with configurable tooling.

There’s really nothing to be gained from arguing over opinion-based rules. Take the ones you like, forget the ones you don’t.

I hope you take a look at proper-arrows and see if there’s anything in there which you could use to ensure your => arrow functions are the best form they can be in your code base.

And if the plugin is missing some rules that would help define more proper arrows, please file an issue and we can discuss! It’s entirely plausible we may add that rule/mode, even if I personally plan to keep it turned off!

I don’t hate => arrow functions, and you shouldn’t either. I just hate uninformed and undisciplined debate. Let’s embrace smarter and more configurable tooling and move on to more important topics!

The post I Don’t Hate Arrow Functions appeared first on David Walsh Blog.

I Don’t Hate Arrow Functions published first on https://appspypage.tumblr.com/

0 notes

suzanneshannon · 6 years

Text

I Don’t Hate Arrow Functions

TL;DR

Arrow functions are fine for certain usages, but they have so many variations that they need to be carefully controlled to not break down the readability of the code.

While arrow functions clearly have a ubiquitous community consensus (though not unanimous support!), it turns out there’s a wide variety of opinions on what makes “good” usage of => and not.

Configurable linter rules are the best solution to wrangling the variety and disagreement of arrow functions.

I released proper-arrows ESLint plugin with several configurable rules to control => arrow functions in your code base.

Opinions are like noses…

Arrow Functions != functions

But I’m not here to rehash the entire debate over => arrow functions. I’ve written extensively about my opinions on them, including these sections in my books:

“You Don’t Know JS: ES6 & Beyond”, Ch2, “Arrow Functions”

“Functional-Light JavaScript”, Ch2, “Functions Without function“ (and the preceding section on function names).

Whatever your preferences around =>, to suggest that it’s only a better function is to be plainly reductive. It’s a far more nuanced topic than just a one-to-one correspondence.

There are things to like about =>. You might find that surprising for me to say, since most people seem to assume I hate arrow functions.

I don’t (hate them). I think there are definitely some important benefits.

What I hate is suggesting they’re universally more readable, or that they’re objectively better in basically all cases.

What’s problematic IMO is when some in those camps simply cannot understand or empathize with dissenting opinions, as if there must just be something wrong with them.

Readability != Writability

Any attempt to justify writability affordances with unsubstantiated claims about readability benefits is a weak argument at best, and in general, nothing but a distraction.

So I roundly reject that => is always and objectively “more readable”.

But I still don’t hate arrow functions. I just think to use them effectively, we need to be more disciplined.

Linters == Discipline

You might be of the (incorrect) belief that linters tell you objective facts about your code. They can do that, but that’s not their primary purpose.

That’s what they’re for: to apply opinions to your code.

I don’t get mad at the test suite or the JS engine. Those things are all reporting facts about my code. But I can definitely get irritated when the linter’s opinion disagrees with mine.

So why subject ourselves to this torment!? Because linter tools and their opinions are what give us discipline. They help us collaborate with others.

They ultimately help us communicate more clearly in code.

We should be submitting to tools to help us maintain our discipline.

No. If we’re being reasonable, we admit that the overall good is best served when we set up reasonable guidelines and then follow the discipline of adhering to them.

Configurability Is King

Configurability of tools is how we make tools work for us instead us working for the tools.

Proper Arrows

I fully recognize my usage of the the word “proper” here is going to ruffle some feathers. “Who is getify to say what is proper and not?”

The ultimate linter would not only let you configure rules to your liking, but build your own rules if something were lacking. Luckily, ESLint supports exactly that!

So I decided to build an ESLint plugin to define an additional set of rules around => arrow functions: proper-arrows.

Proper Arrows Rules

So what rules are provided? Here’s an excerpt from the project overview:

"params": controls definitions of => arrow function parameters, such as forbidding unused parameters, forbidding short/unsemantic parameter names, etc.

"location": restricts where in program structure => arrow functions can be used: forbidding them in the top-level/global scope, object properties, export statements, etc.

Remember, each rule has various modes to configure, so none of this is all-or-nothing. Pick what works for you.

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Some may love this style — that’s OK! — but a lot of folks think it favors clever terse style coding over readability, and would prefer instead:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Notice that it’s still an => arrow function and it’s not even that many more characters. But it’s clearer that there are three separate statements in this function body.

Even better:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Concise Summary

You and I almost certainly disagree on what makes good, proper => arrow function style. That’s a good and healthy thing.

My goal here is two-fold:

Convince you that opinions on this stuff vary and that’s OK.

Enable you to make and enforce your own opinions (or team consensus) with configurable tooling.

There’s really nothing to be gained from arguing over opinion-based rules. Take the ones you like, forget the ones you don’t.

I hope you take a look at proper-arrows and see if there’s anything in there which you could use to ensure your => arrow functions are the best form they can be in your code base.

The post I Don’t Hate Arrow Functions appeared first on David Walsh Blog.

I Don’t Hate Arrow Functions published first on https://deskbysnafu.tumblr.com/

0 notes

techscopic · 6 years

Text

I Don’t Hate Arrow Functions

TL;DR

Arrow functions are fine for certain usages, but they have so many variations that they need to be carefully controlled to not break down the readability of the code.

While arrow functions clearly have a ubiquitous community consensus (though not unanimous support!), it turns out there’s a wide variety of opinions on what makes “good” usage of => and not.

Configurable linter rules are the best solution to wrangling the variety and disagreement of arrow functions.

I released proper-arrows ESLint plugin with a variety of configurable rules to control => arrow functions in your code base.

Opinions are like noses…

But one of the things many people tell me they appreciate about it me is, I don’t just state opinions, I back those opinions up with careful, thought-out reasoning. Even when people vehemently disagree with my opinions, they often compliment me on at least owning those opinions with backing.

Arrow Functions != functions

But I’m not here to rehash the entire debate over => arrow functions. I’ve written extensively about my opinions on them, including these sections in my books:

“You Don’t Know JS: ES6 & Beyond”, Ch2, “Arrow Functions”

“Functional-Light JavaScript”, Ch2, “Functions Without function“ (and the preceding section on function names).

Whatever your preferences around =>, to suggest that it’s only a better function is to be plainly reductive. It’s a far more nuanced topic than just a one-to-one correspondence.

There are things to like about =>. You might find that surprising for me to say, since most people seem to assume I hate arrow functions.

I don’t (hate them). I think there are definitely some important benefits.

What I hate is suggesting they’re universally more readable, or that they’re objectively better in basically all cases.

The reason I reject this stance is because I REALLY DO STRUGGLE TO READ THEM in many cases. So that perspective just makes me feel dumb/inferior as a developer. “There must be something wrong with me, since I don’t think it’s more readable. Why do I suck so much at this?” And I’m not the only one who’s impostor syndrome is seriously stoked by such absolutes.

And the cherry on top is when people tell you that the only reason you don’t understand or like => is because you haven’t learned them or used them enough. Oh, right, it’s my ignorance. SMH. I’ve written and read literally thousands of =>functions. I’m quite certain I know enough about them to hold the opinions I have.

What’s problematic IMO is when some in those camps simply cannot understand or empathize with dissenting opinions, as if there must just be something wrong with them.

Readability != Writability

Any attempt to justify writability affordances with unsubstantiated claims about readability benefits is a weak argument at best, and in general, nothing but a distraction.

So I roundly reject that => is always and objectively “more readable”.

But I still don’t hate arrow functions. I just think to use them effectively, we need to be more disciplined.

Linters == Discipline

You might be of the (incorrect) belief that linters tell you objective facts about your code. They can do that, but that’s not their primary purpose.

That’s what they’re for: to apply opinions to your code.

I don’t get mad at the test suite or the JS engine. Those things are all reporting facts about my code. But I can definitely get irritated when the linter’s opinion disagrees with mine.

So why subject ourselves to this torment!? Because linter tools and their opinions are what give us discipline. They help us collaborate with others.

They ultimately help us communicate more clearly in code.

We should be submitting to tools to help us maintain our discipline.

No. If we’re being reasonable, we admit that the overall good is best served when we set up reasonable guidelines and then follow the discipline of adhering to them.

Configurability Is King

Configurability of tools is how we make tools work for us instead us working for the tools.

Proper Arrows

I fully recognize my usage of the the word “proper” here is going to ruffle some feathers. “Who is getify to say what is proper and not?”

The ultimate linter would not only let you configure rules to your liking, but build your own rules if something were lacking. Luckily, ESLint supports exactly that!

So I decided to build an ESLint plugin to define an additional set of rules around => arrow functions: proper-arrows.

Proper Arrows Rules

So what rules are provided? Here’s an excerpt from the project overview:

"params": controls definitions of => arrow function parameters, such as forbidding unused parameters, forbidding short/unsemantic parameter names, etc.

"location": restricts where in program structure => arrow functions can be used: forbidding them in the top-level/global scope, object properties, export statements, etc.

Remember, each rule has various modes to configure, so none of this is all-or-nothing. Pick what works for you.

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Some may love this style — that’s OK! — but a lot of folks think it favors clever terse style coding over readability, and would prefer instead:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Notice that it’s still an => arrow function and it’s not even that many more characters. But it’s clearer that there are three separate statements in this function body.

Even better:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Concise Summary

You and I almost certainly disagree on what makes good, proper => arrow function style. That’s a good and healthy thing.

My goal here is two-fold:

Convince you that opinions on this stuff vary and that’s OK.

Enable you to make and enforce your own opinions (or team consensus) with configurable tooling.

There’s really nothing to be gained from arguing over opinion-based rules. Take the ones you like, forget the ones you don’t.

I hope you take a look at proper-arrows and see if there’s anything in there which you could use to ensure your => arrow functions are the best form they can be in your code base.

I don’t hate => arrow functions, and you shouldn’t either. I just hate uninformed and unenforced debate. Let’s embrace smarter and more configurable tooling and move on to more important topics!

The post I Don’t Hate Arrow Functions appeared first on David Walsh Blog.

I Don’t Hate Arrow Functions published first on https://appspypage.tumblr.com/

0 notes

suzanneshannon · 6 years

Text

I Don’t Hate Arrow Functions

TL;DR

Arrow functions are fine for certain usages, but they have so many variations that they need to be carefully controlled to not break down the readability of the code.

While arrow functions clearly have a ubiquitous community consensus (though not unanimous support!), it turns out there’s a wide variety of opinions on what makes “good” usage of => and not.

Configurable linter rules are the best solution to wrangling the variety and disagreement of arrow functions.

I released proper-arrows ESLint plugin with a variety of configurable rules to control => arrow functions in your code base.

Opinions are like noses…

Arrow Functions != functions

But I’m not here to rehash the entire debate over => arrow functions. I’ve written extensively about my opinions on them, including these sections in my books:

“You Don’t Know JS: ES6 & Beyond”, Ch2, “Arrow Functions”

“Functional-Light JavaScript”, Ch2, “Functions Without function“ (and the preceding section on function names).

Whatever your preferences around =>, to suggest that it’s only a better function is to be plainly reductive. It’s a far more nuanced topic than just a one-to-one correspondence.

There are things to like about =>. You might find that surprising for me to say, since most people seem to assume I hate arrow functions.

I don’t (hate them). I think there are definitely some important benefits.

What I hate is suggesting they’re universally more readable, or that they’re objectively better in basically all cases.

The reason I reject this stance is because I REALLY DO STRUGGLE TO READ THEM in many cases. So that perspective just makes me feel dumb/inferior as a developer. “There must be something wrong with me, since I don’t think it’s more readable. Why do I suck so much at this?” And I’m not the only one who’s impostor syndrome is seriously stoked by such absolutes.

What’s problematic IMO is when some in those camps simply cannot understand or empathize with dissenting opinions, as if there must just be something wrong with them.

Readability != Writability

Any attempt to justify writability affordances with unsubstantiated claims about readability benefits is a weak argument at best, and in general, nothing but a distraction.

So I roundly reject that => is always and objectively “more readable”.

But I still don’t hate arrow functions. I just think to use them effectively, we need to be more disciplined.

Linters == Discipline

You might be of the (incorrect) belief that linters tell you objective facts about your code. They can do that, but that’s not their primary purpose.

That’s what they’re for: to apply opinions to your code.

I don’t get mad at the test suite or the JS engine. Those things are all reporting facts about my code. But I can definitely get irritated when the linter’s opinion disagrees with mine.

So why subject ourselves to this torment!? Because linter tools and their opinions are what give us discipline. They help us collaborate with others.

They ultimately help us communicate more clearly in code.

We should be submitting to tools to help us maintain our discipline.

No. If we’re being reasonable, we admit that the overall good is best served when we set up reasonable guidelines and then follow the discipline of adhering to them.

Configurability Is King

Configurability of tools is how we make tools work for us instead us working for the tools.

Proper Arrows

I fully recognize my usage of the the word “proper” here is going to ruffle some feathers. “Who is getify to say what is proper and not?”

The ultimate linter would not only let you configure rules to your liking, but build your own rules if something were lacking. Luckily, ESLint supports exactly that!

So I decided to build an ESLint plugin to define an additional set of rules around => arrow functions: proper-arrows.

Proper Arrows Rules

So what rules are provided? Here’s an excerpt from the project overview:

"params": controls definitions of => arrow function parameters, such as forbidding unused parameters, forbidding short/unsemantic parameter names, etc.

"location": restricts where in program structure => arrow functions can be used: forbidding them in the top-level/global scope, object properties, export statements, etc.

Remember, each rule has various modes to configure, so none of this is all-or-nothing. Pick what works for you.

var myfunc = (x,y) => ( x = 3, y = foo(x + 1), [x,y] );

Some may love this style — that’s OK! — but a lot of folks think it favors clever terse style coding over readability, and would prefer instead:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Notice that it’s still an => arrow function and it’s not even that many more characters. But it’s clearer that there are three separate statements in this function body.

Even better:

var fn2 = (x,y) => { x = 3; y = foo(x + 1); return [x,y]; };

Concise Summary

You and I almost certainly disagree on what makes good, proper => arrow function style. That’s a good and healthy thing.

My goal here is two-fold:

Convince you that opinions on this stuff vary and that’s OK.

Enable you to make and enforce your own opinions (or team consensus) with configurable tooling.

There’s really nothing to be gained from arguing over opinion-based rules. Take the ones you like, forget the ones you don’t.

I hope you take a look at proper-arrows and see if there’s anything in there which you could use to ensure your => arrow functions are the best form they can be in your code base.

The post I Don’t Hate Arrow Functions appeared first on David Walsh Blog.

I Don’t Hate Arrow Functions published first on https://deskbysnafu.tumblr.com/

0 notes