An accountant does our taxes now, but up until a decade or so ago I was always impressed that I could file taxes and all necessary forms, for myself and my small business with dozens of employees, all using the $25 version of TurboTax.
It's been popular to dump on TurboTax for several years now, but I had a great experience using it.
I personally don't trust AI enough to say "here's my data, please do my taxes for me" yet, but you're right, I suppose that is just a matter of time...
That said, there's basically nothing stopping someone from creating fee software equivalent or better than TurboTax from scratch using AI. They can even decompile TurboTax source code as an input
These already exist though: FreeTaxUSA (http://freetaxusa.com), or if you prefer Turbotax itself, there's Credit Karma Tax (https://www.creditkarma.com/tax), which is a free, white-labelled version of Turbotax.
This is a well-written and quite diplomatic summary by Herb Sutter. I'm not plugged in enough to be sure he's correct that Stroustrup's opposition was the main reason the C++26 vote failed where others have passed, but it sounds plausible.
It also lists 6 possible paths forward for C++26 with pros and cons. I think they are roughly:
A. Skip an official C++26 standard but roll these features into C++29.
B. Remove contracts from C++26 and pass it.
C. Say "please" and vote again.
D. Tweak contracts regarding virtual functions and vote again.
E. Pass C++26 as many different countries' national standards rather than an international standard.
F. Do E and also consider leaving ISO and moving to ANSI/INCITS instead.
I think "guaranteed contract enforcement" should be added to item D since that is explicitly called out as the only technical proposal that would change some NB votes from no to yes.
What does guaranteed enforcement mean? Is it worth the trade-offs? There's a reason why most code turns assert off in production and only does it in debug builds. A lot of checks are certainly possible to run, but they're unreasonably expensive to run and so if the code is trusted to work, you wouldn't want to check that it's working correctly.
If, on the other hand, you mean only that, regardless of the status of a contract, if the compiler can detect that it would be violated, it must have failed to compile, I guess that would be all for that. On the other hand, the state of theorem provers that are able to prove things will and won't work is ... evolving. There will a lot of people be frustrated when they upgrade their compiler to a minor point release and suddenly a lot of code fails to compile because it always was broken but likely in an obscure situation that never happens in the real world.
I'm not sure I can express it better than the proposal to add the corresponding feature [0]:
> This extension addresses the Romanian National Body's (NB) concern by enabling the writing of an individual contract assertion that guarantees the program execution will not continue past the contract assertion if it is violated, regardless of the semantics of other contract assertions. This addition to the C++26 Contracts facility allows reliable use of enforced contract assertions in large codebases with mixed contract semantics and also in hardened libraries.
> Is it worth the trade-offs?
Apparently some people/NBs feel quite strongly that it is.
> There's a reason why most code turns assert off in production and only does it in debug builds.
There's also a reason some codebases define asserts that aren't turned off in production in addition to debug-only asserts. The proposal lists multiple under Section 3.1 Existing Practice.
> and so if the code is trusted to work, you wouldn't want to check that it's working correctly.
Right, but sometimes you might think the consequences of such blind trust being misplaced are worse than the performance hit.
Static detection of impossible-to-satisfy contract conditions would be interesting, but as you say the technology is probably not ready for the kind of widespread use that inclusion in C++ would entail.
I see. Somehow I missed that paper. I've seen it referred to, but never in a form where I could find it.
And now I'm even more confused. Why is this so critical that we can't say we're going to put it in another next version of the standard? Compile is regularly see things in the future version of standards and them implement early. I'm not disagreeing with the paper. I'm disagreeing that this is so critical it needs to abort the whole process.
> Why is this so critical that we can't say we're going to put it in another next version of the standard?
This feature was first proposed in 2004. In 2018, they were added to the draft of the standard, and then removed in 2019. So that already has been happening, for over a decade.
Part of the reason this is coming to a head is that it's already been a long time. Another reason is that some see contracts as fitting into the safety story for C++. Part of it is because, well, standards are done by the people that show up, and the people who show up care about this.
> I'm disagreeing that this is so critical it needs to abort the whole process.
It's a byproduct of how the process works. There are a series of votes, and they're not done by the same people. Some people voted yes to put them in, and then the vote after involved people voting no, they don't think they're good enough to put in. It is not so much that "this is so critical that it needs to abort the whole process," so much as it is "the final vote is the time when those people get to express their support or dissent." One of the proposals in the paper is that they could remove this feature, and then the rest would likely move forward. It will only hold up the entire thing if the people who are pro this feature landing decide that it's worth holding everything else up for.
Contracts failed in the past because it was so large. This was supposed to be a minimum viable proposal that would be extended over time. But one small group is demanding their extension now anyway.
More and more I'm on the side of those who are point at the 'no' votes as babies who can't work together. This is not a new thing and your preferred action isn't the best compromise, grow up. I know that is insulting, but it seems well deserved
I have a feeling that the paper isn't even a good way to solve their problem, but I can't quite figure out what would be better.
I was in the same boat as you with respect to that paper. I only know its number because Herb mentioned it.
The only red-string-on-a-cork-board I can connect is between guaranteed enforcement and the design decision that "contract assertions must not be used for error handling and input validation". The latter would seem to rule out guaranteed enforcement now and in the future and EWG apparently voted against P3911 back in January [0], so perhaps they think that they won't ever see guaranteed enforcement if contracts is left in the standard as-is.
That's all quite speculative, though, so take that with an appropriately-sized grain of salt/
Without guarantee they would end in the same mess as Python with its "types". A contract without guarantee (if compile-time or run-time) is just a hint, not a contract.
Yes, this image is hand-crafted art that looks cool, but in fact both approaches can and have have been automated!
- Astronomers have automated software that anticipates each streak based on the space object catalog and automatically removes satellites from long-exposure wide field-of-view images.
- Those whose job is to track satellites and update the space object catalog have software that anticipates each star location based on star catalogs, and automatically removes stars so they can see where the satellites are.
Stellar Science | Hybrid (USA) Albuquerque NM, Washington DC (Tysons VA), Dayton OH | Full time, interns/co-ops | U.S. citizenship required | https://www.stellarscience.com
Company: We're a small scientific software development company that develops custom scientific and engineering analysis applications in domains including: space situational awareness (monitoring the locations, health and status of on-orbit satellites), image simulation, high power microwave systems, modeling and simulation, laser systems modeling, AI/ML including physics-informed neural networks (PINN), human body thermoregulation, computer vision and image processing, high performance computing (HPC), computer aided design (CAD), and more. All exciting applications and no CRUD. We emphasize high quality code and lightweight processes that free software engineers to be productive.
Experience: Except for interns, we currently require a Bachelors degree in physics, engineering, math, computer science, or a related field. Masters or PhD is a plus. (Roughly 25% of our staff have PhDs.)
Technologies: Lots of C++23, Qt 6.9, CMake, git, OpenGL, CUDA, Boost, Jenkins. Windows and Linux, msvc/gcc/clang/clangcl. AI/ML and analysis projects use Python and C++. Web projects use Java and Typescript/React. We're a bit behind the curve on developer AI adoption, and we're okay with that.
Python is famously built around hash tables. So much so that several versions ago they made an improvement to the hash table implementation, and the entire language became several percent faster.
However, I'm surprised to see no data structures at all with O(log(N)) complexity. Surely there are some use cases for which that's desirable?
One reason you don't see a data structure with O(log(n)) operations in this list is that priority queues/heaps are not a built-in type. Weirdly, there isn't a type for them at all, just a bunch of functions (good luck if you use them wrong). https://docs.python.org/3/library/heapq.html
There isn't a type for them for the same kind of reasons that `join` is a method on the joining string. That is, it lets you reuse that code for multiple sequence types, including ones that don't exist yet. This is just something that happens with ad-hoc polymorphism, but it's also good to keep class interfaces small and implement other functionality in terms of them. Herb Sutter would approve.
Making the functions into methods wouldn't make them easier to use, it would just make the abstraction feel more familiar to those from a Java tradition rather than a C++ one.
With the current implementation you can accidentally use first heapify_max and then heappop (forgetting the _max), accidentally append something through the normal list append method, change the priority of something unknowing that that breaks the invariant, or run into problems with "Tuple comparison breaks for (priority, task) pairs if the priorities are equal and the tasks do not have a default comparison order".
These headaches could have been mostly removed if these were in a class. And the option to use a custom sequence type could have surely been preserved.
Not true. I just bought No Man's Sky on a Steam sale a few months ago and have been having a blast with it - only very occasionally neglecting my adult duties because of it.
Stellar Science | Hybrid (USA) Albuquerque NM, Washington DC (Tysons VA), Dayton OH | Full time, interns/co-ops | U.S. citizenship required | https://www.stellarscience.com
Company: We're a small scientific software development company that develops custom scientific and engineering analysis applications in domains including: space situational awareness (monitoring the locations, health and status of on-orbit satellites), image simulation, high power microwave systems, modeling and simulation, laser systems modeling, AI/ML including physics-informed neural networks (PINN), human body thermoregulation, computer vision and image processing, high performance computing (HPC), computer aided design (CAD), and more. All exciting applications and no CRUD. We emphasize high quality code and lightweight processes that free software engineers to be productive.
Experience: Except for interns, we currently require a Bachelors degree in physics, engineering, math, computer science, or a related field. Masters or PhD is a plus. (Roughly 25% of our staff have PhDs.)
Technologies: Lots of C++23, Qt 6.9, CMake, git, OpenGL, CUDA, Boost, Jenkins. Windows and Linux, msvc/gcc/clang/clangcl. AI/ML and analysis projects use Python and C++. Web projects use Java and Typescript/React. We're a bit behind the curve on developer AI adoption, and we're okay with that.
It's been popular to dump on TurboTax for several years now, but I had a great experience using it.
I personally don't trust AI enough to say "here's my data, please do my taxes for me" yet, but you're right, I suppose that is just a matter of time...
reply