[dlojudice]

> Because in 2021 developer tools are fundamentally not profitable.

Interesting...

But monetization might not be the root of this since we have very sophisticated tools delivered as open source. The question then would be why the "dev comunity" is not interested in building tools like those mentioned in the article?

My guess is that tools like Reflexion Models doesn't ring any bells for junior/mid-level developers. They don't know exactly what to optimize when it comes to long-term maintenance. That's why we have so many parsers, linters, etc. and now typed languages (again!) and not Reflexion Models.

The other day I was looking for something similar to Reflexion Models: a tool that I could describe high level modules and its files (like a package), describe the dependency hierarchy between then and check if there is any calls between modules that break the hierarchy. For instance: getting a alert if there is a call to a repository from the a controller (DDD). It's a common problem for big teams with junior developers that could be solved by automation.

[gibb0n]

Hey I've recently been looking at http://www.structure101.com and it does exactly what you mention, and integrates with both your IDE and sonarqube

[kungito]

Senior developers with 20 years of experience do not "believe" in debuggers, IDEs or writing tests. Same things are reinvented every 3 months with a new name written in a custom font. We are in many ways still in the bronze age of software development.

[GiorgioG]

> Senior developers with 20 years of experience do not "believe" in debuggers, IDEs or writing tests.

Speak for yourself. I've been paying for my own developer tooling for 25+ years.

[MattGaiser]

What do you find to be worth purchasing?

[GiorgioG]

Off the top of my head:

- The JetBrains suite of tools (Rider, CLion, DataGrip, Webstorm)

- Sublime Text

- Prior to offering Visual Studio Community Edition, I used to pay for MSDN if my employer didn’t supply it.

- Beyond Compare

- Recently paid for Tabnine Pro, the jury is still out if this is worth it.

[heavenlyblue]

Debugger is just a nice interface for prints.

IDEs should be replaced with libraries that allow one to operate over the code (or make IDEs allow you to script their AST manipulators)

Writing tests is not connected to the two above.

[kaba0]

I’m sorry but that just means you have not have learnt how to use debug tools.

[heavenlyblue]

No, I know how to use them, except that in my cases I never need to look a the debugger because I rarely need to know the state of the program at a given time.

I need to know how the program ended up in that state. I can't reproduce this from a core dump or via a debugger.

[ynx]

> I can't reproduce this from a core dump or via a debugger.

Because you don’t know how to debug. Time travel debugging does exactly this.

[govtman]

You can... are you familiar with the concept of a call stack?

[dan-robertson]

That’s definitely not what a debugger is. You can’t add prints to a coredump and the run->add prints->compile->loop sucks a lot, especially if the bug is hard or slow to trigger.

I think the main promise of an IDE is being integrated. But maybe it could just be done with libraries.

[heavenlyblue]

> You can’t add prints to a coredump and the run->add prints->compile->loop sucks a lot, especially if the bug is hard or slow to trigger.

Yeah, but the core dump doesn't give you an answer on how the program ended up in failure state, does it?

[higerordermap]

Use something other than DDD?

[dmz73]

Debugger might be a nice interface for prints in kernel. It is also not usable with distributed systems where prints are also not all that useful and you need some kind of central logging. But developing a desktop application without debugger is like writing code with a line editor. It can be done but it is not very productive (I can still remember editing BASIC programs one line at the time).

[heavenlyblue]

I meant "prints" as in "logging events into a file".