Yeah, absolutely. FWIW, the repo notes:

"Direct File interprets the United States' Internal Revenue Code (26 USC) as plain language questions, the answers to which should be known to taxpayers without need of external instructions or publications. Taxpayers' answers are then translated into standard tax forms and transmitted to the IRS's Modernized e-File (MeF) API, which is available for authorized public use."

So in theory it's useful now, but as you say it could easily change.

Piggybacking, I think the "hard part" also includes the decades of success that the tax prep lobby's had in protecting its business interests at the cost of US citizen's welfare. Although the number of states that provide free direct filing has grown from last year -- which I only remember to be substantially less than the 25 who do so today -- it's unclear what the problem is with the remaining 25 including DC where I live

Right, politicians and officials working on behalf of the tax-filing lobby could introduce lots of changes to the tax code with a view to making this software useless.

Imagine this source code becoming the unit tests for the legal code. Future tax-code changes would be accompanied by corresponding changes in GitHub. Inconsistencies would surface as new code and tests break the old ones. As courts introduce new nuances to the law's interpretation, new unit tests would follow.

This wouldn't replace human judgment; nobody in power would allow that. But even the capriciousness of politics can be expressed as Boolean logic (var isDeductible = taxpayerIsMe && !taxpayerIsYou). The tests could at least memorialize all the pork.

> Taxpayers' answers are then translated into standard tax forms and transmitted to the IRS's Modernized e-File (MeF) API, which is available for authorized public use

The interoperability with the revenue system is provided by a different project, and this API is also used by turbotax and the like. It won't be going away.

The interoperability is not the hard part.

I do not know of this capability currently, but if it has enough for eFile, it can also be used to generate a paper return.

I wouldn't say interop is a huge deal, the main time and cost sink is translating the recursive Gordian knots of tax law into a logically cohesive structure that can be evaluated programmatically. And then you (ideally) must prove its correctness.

Imagine pair programming with a tax lawyer. I'd rather eat my own hands.

Sounds like a business opportunity.

That's reactive programming in Java, where you return a callback to be run when an operation completes.

The giveaway is the Mono<T> return type.

My eyeballs bleed, and I'm pretty comfortable with Java for many years.

I see the most of it stems from reactive-style programming (reactor.core.publisher.Mono).

Maybe they just tried to fit into one screen? Anyway I'd ask to simplify it, if I was a their team lead.

Is this what people have to do when they don't have the C# async/await autogenerated state machine?

Yes and no. This is a common pattern, but implemented very lazily. Most of this can (and probably should) be refactored out to separate classes/functions.

But no, I don't think this would faze most Java devs. It's ugly and bad practice, but more or less acceptable depending on personal taste. It works, at least.

Point of interest: LLMs tend to go too far in the opposite direction with code like this. They will break everything apart into functions or classes, even trivial one-line lambdas. I find that even more obnoxious than the monstrosity you linked.

I can tell you as a person working in a spring boot webflux shop that is pretty bad code. You really don’t want to nest that much. Using atomic references outside the reactive flow is a huge red flag that they don’t know how to program in webflux properly. Not that webflux is easy to use at all and the dx is garbage.

I've seen similar things, in Java as well as some other languages. It's obviously not the preferred way of doing it.

I don't really know Java, but .flatMap(...) seems to be equivalent to C# .SelectMany(...) which famously can be interpreted as a monadic bind operator.

The C# query syntax

  from x in xs
  from y in GetYs(x)
  from z in GetZs(y) ...

is equivalent to

  xs.SelectMany(x => GetYs(x).SelectMany(y => GetZs(y).SelectMany(z => ...)))

which is similar to monadic do-notation in Haskell.

So since there is monadic Scala code elsewhere in the project, I wonder if this is a result of someone thinking in Scala and translating it into Java in their head.

It is if you’re doing government style work and you want have a job for life creating code that nobody else can read.

Or if you’re in the business of selling extremely wide aspect ratio monitors.

The atomics are goofy, but reactor can often lead to messy code structure when you actually need sequential blocking behavior.

It's very common to see from devs that don't really grasp reactive programming. You often see similar things in Angular projects because of RxJS.

> .onErrorResume

I dislike Java but if it can get me back to the On Error Resume Next days I might reconsider.

If you are a non-Java developer, it does look daunting. But in my opinion it’s much much better use of the Java streams api and reactor library that I have seen compared to most shitty corp firms.

I saw an internal “sso” auth app that iterated a byte array and concatenated the values into a string instead of base64 encoding it when I worked at HP/HPE/DXC

Looks like callback hell, but in Java. Async/await would solve it, but it's Java.

Fuck no, it's not. But I've seen it because it gets promoted by some smartass tech lead chasing so called webscale performance. But they never do comparative benchmarks against regular blocking code for fear that it would demonstrate the true nature of their head trip. Then they leave to go shit elsewhere and leave other people to deal with the consequences of their hubris.

Really puts that whole "our wonderful journey" "our incredible team" post into context, haha.

Just another shitty Java middleware that never amounted to anything, 200000 lines of code that don't express even a handful of ideas.

Wow, that's frustrating code. I feel vindicated in using an ultrawide to code with. When I mentioned on here I use it because sometimes you have to work on code with super-deep indents I got downvoted to negative infinity for shitty code management.

Another way of saying this: Creative Commons, based in California, USA, did not publish a license that can be used by one of the largest domestic authors of software.

Less snarkily, I do wonder about the discrepancy there.

I moved this from https://news.ycombinator.com/item?id=44187512

It's probably a boilerplate notice put on all releases. Sometimes they aren't even allowed to explicitly state that something was excluded, so they have to put that notice on all releases, so there's no way to infer which releases have exclusions.