I used to sell debuggers a decade ago. We even had reversible debugging. The amount of personal development productivity I had was unmatched; I’ve never gotten back to that point.
It is true, nobody wants to pay for engineering tools. I wish the author luck.
The market is so small, and there appears to be lots of premature optimization of the checkbook.
I remember many years ago trying out purify, and it revolutionized my debugging. The problem seemed to be that the program I wrote could be debugged by everyone - if you just got everyone a per-user license.
It would have been hard enough to justify a license for me (a person at the bottom with no power), it was impossible to justify a license for everybody.
> It would have been hard enough to justify a license for me (a person at the bottom with no power), it was impossible to justify a license for everybody.
"Floating" licenses are better here. In my experience, companies are reluctant to buy licenses for an entire team for something that's used only occasionally. It's easier to make them buy a few floating licenses to be shared by the team.
I am uncertain if floating licenses were available at the time. Even so, when floating licenses became popular, there was also the "license in use" denial problem.
Unfortunately there's another way to do this nowadays. Offer convenient tools with analytics, etc... (and coincidentally spy on everyone)
It's double edged: the co's that can afford to proactively seek better dev tools can also afford internal vanity projects to do them internally. So it becomes a political timing game for the project leads to move on etc. Not fun.
I found an easier path for dev tooling is focus on tools for non-traditional/non-fulltime coders, e.g., analysts, devops, secops, ... , for whom being able to code introduces a superpower, not an increment on status quo within a crowded space. It's a shame devs destroy our own potential.
That is a concern, but Pernosco is challenging to implement. We built on rr, which was already state of the art, and we've added a lot of secret sauce. Of course the smart big tech companies could duplicate it, but it is not simply a matter of putting a team together and grinding out the code.
About a dozen years ago my workplace built something like that in-house. I see you've made progress. You have the reverse dataflow. You can't debug an arbitrary firmware or bootloader or OS however, and you can't properly debug a bunch of interacting systems.
Simics also seems to have most of that. I last checked about half a dozen years ago, so the other features might now also be supported. It's not cheap, but you could model all the computers of a factory or aircraft all at once. You could then step forwards and backwards as desired, coherently examining the RAM and other hardware of all the computers as you please.
I wouldn't be surprised if dozens of similar tools have been built.
Out of those things, the one we do want is the ability to debug a collection of interacting distributed processes. Our goal would be a bit different though: splice together recordings from different nodes of a real system, rather than simulating all the nodes from the ground up. So our implementation approach will have to be different.
Fair, but that's not rr's target market. AFAIK Simics is not competitive with rr or Pernosco in recording overhead or scalability when you're debugging a Linux user-space application that executes, say, a trillion instructions.
Computing today looks different compared to 2009, AWS came out in 2006, the original iPhone came out in 2007. Why, then, would the market for debuggers and other developer tools still look the same as it did 10 years ago?
Coding bootcamps have sprung up and regardless of what you think of them, there are more developers today than before. The more developers out there, the larger the market to sell developer tools to. Auto-mechanics and other tradesmen have a couple thousand dollars worth of tools that they bought themselves. Why then are software developers so uniquely hard to sell to?
JetBrains, makers and sellers of Python-specific IDE PyCharm, seems to be doing okay.
With companies now tracking "developer velocity" as a metric (somehow), a tool that improves velocity seems like it would be an easy sell. If I can't rewind code execution in the debugger, I might as well just be printing variables to the screen. (Which is a time honored debugging method that will never die. But maybe it should.)
There's a B2C vs B2B question in there, but maybe the market is changing in the software developer tools market.
It is true, nobody wants to pay for engineering tools. I wish the author luck.