Because in 2021 developer tools are fundamentally not profitable. Jetbrains is the exception, not the norm. Developer tools are loss leaders for large corporation to acquire developer goodwill and mindshare. Previously we sold developer tools/PaaS. Programmers do not like to pay for their tooling. You have to sell to management, and when your target is management, then the metrics are completely different from what developers want.
This is why no-code and low code are so much more successful than developers tooling startups in terms of revenue and profitability. The people using are the same people who are running the business. The value proposition is clear. "Better developer experience" alone is not sufficient for selling to enterprise. And programmer productivity cannot be quantified in lines of code written. This is hard point to explain and get across on HN because this forum is inherently dismissive of the value of RPA and RAD software.
Over-monetizing their dev tooling was a significant contributor to Microsoft's loss of dev mind-share over the last decade. Free software took over the world because any kid in their bedroom could download Linux/GCC/MySQL for free.
Want to work in .NET/MSVC? You just run into barriers (gimped "express" versions, no free documentation etc.) Yes this has changed now, but it's been a long time coming.
> Programmers do not like to pay for their tooling.
Because it is too much work to convince the company that spending $500 on JRebel to have me not go on Hacker News for 5 (and it turns into 15) minutes while the thing compiles (my last company). I also have no real stake in whether the product ships in one month or two so I am not paying for it myself.
To pay for tooling, productivity needs to be a priority. I have never worked anywhere where productivity was discussed.
I don't think you have this right. The problem is not paying for developer tools, the problem is investing your time in proprietary solutions that might go away any time. For a long and resilient career developers have to stick to tools and technologies that are not dependent on ephemeral corporate support.
> 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.
> Programmers do not like to pay for their tooling.
I can't count how many times I see someone using Sublime Text professionally who hasn't paid for it. If anyone should have empathy for a developer, it's a developer, likewise with someone who can afford it. Once I put this together, I realized developer tools are for the most part a business dead end.
The kinds of tools like those in the article suffer from being outside of the "main loop of coding".
What is the main loop? Well, as it's defined since the rise of interactive computing, it's typing in the editor, compiling, then testing and debugging.
Thus we optimize for:
1. Typing code fast(or typing less code)
2. Compiling code fast(by doing less compilation)
3. Minimizing testing and debugging time(by narrowing our definitions of testing to that which is easy to automate).
The main loop of coding is not software development. It does not study the domain problem, define new benchmarks for success, untangle communication issues, or refine principles of development. It is a path to coder flow state, feature factoryism and shipping the org chart. These things sort of resemble development - a happy coder delivering features within a definite architecture does serve someone at some point - but also manifest dysfunction. Development failing is just shrugged off as bad programming or bad management.
Tools like a Whyline or Reflexion models are not in the main loop. They are an invitation to look carefully at whatever horror has been wrought and address it at a deep level. But that really needs a researching mindset, not a shipping one.
In practice, the available tools very slowly move in the direction of the suggestions of research. There are improvements, but they need projects that put together the pieces and make it a goal from the language design(the main interface) upwards.
As many on this discussion have noted, JetBrains tools not only don't collect dust, they are widely used, and the company is profitable. The company is privately held. I hear that they are constantly turning down investments. This proves 1) there is money in tools; 2) The VCs who routinely say "there is no money in tools" are insufficiently imaginitive, which is not surprising if you've spent any time with VCs.
Why is JetBrains so successful where others have failed? A few thoughts:
- Intellij was released in 2001. Eclipse was a close competitor for a while, which made no sense to me. Intellij just worked, and it was intuitive. I found Eclipse to be uglier, slower, flakier, crashier, and far less intuitive. Haven't heard of it in years.
- It was always the case that at least some version of Jetbrains tools are zero cost. I got hooked on it early on. I have been using emacs far longer, and yes, while a sufficiently dedicated developer can make emacs behave like an IDE, it really isn't one. Intellij just worked out of the box. In the preceding two decades, there were high-end development tools available (Lisp machines and their all-encompassing environments, Lucid for C++, Purify for C/C++ memory problems, Atria, Rational. Trivia: Did you know that Purify was founded by Reed Hastings, the guy who went on to found Netflix?) The tools were expensive, and I don't think there were free versions. These companies all went out of business, or were acquired.
- Jetbrains is incredibly focused. Having been through several VC-funded technology companies, I can easily see how VC brain farts can destroy a company's focus. (This dynamic isn't entirely the VCs fault. Founders stretch the truth to get funded, and then VCs insist on the fairy tales they've been told.)
- Jetbrains has expanded to other languages, and other kinds of tools (besides just refactoring Java code). The number of languages, technologies, and frameworks that they support is just mind-boggling.
- Consistent focus on improving developer's lives, through steady improvements in functionality, performance, and quality, over 20 years at this point. They started far ahead and have widened the gap.
OPs tools look useful. I suspect they would attract a much wider audience if made available through Jetbrains products.
The common thread I see in this is people pouring their heart and soul into a super awesome tool, and then moving on with their lives. The tool was made for one version of one language, and the world moves on, too. But then I think about the tools that I do use.
Package distributions. Good word, I am not happy here. Still an unsolved problem in general, some languages tackle it better than others.
Testing frameworks. It's getting better. Big props to zig, for including tests for free with comptime. But in general, it's piles of code that somebody maintains for each language. Often, there are multiple tools because the language devs don't pull them into first-class components.
Debuggers. There's pretty good tools out there. They're clunky to use, but there are multiple front ends that can handle multiple languages, thanks to a common data format.
Code formatters. Props to zig, go, and rust for building these in. But for most languages, it's DIY.
Common theme here: all of this stuff is fairly generic, but each language tends to do its own thing. Tools aren't officially part of the languages, neither are they generic. Except debuggers! There's a common interface, DWARF support becomes a part of the language, and (another key point) language devs use it -- so they don't rot.
Developer tools can be magic, but unless they're generic, I expect them all to rot.
Edit: Oh, I forgot documentation generation -- like debugging, there's been some convergence around some generic tools and it's pretty easy to build support into / on top of a language. And newer languages use these tools internally to build their docs. Great!
And how could I forget compilers! LLVM might save the day for all of this stuff (except versioning and distribution... ick). Build a tool that can grok LLVM-IR, and you've solved the problem for most languages out there.
This is all rather vague. These tools collect dust because software nowadays doesn't only have to be written, it needs to be maintained and adapted. And these examples weren't because they weren't useful enough. Sure, they worked at their specific task... but none of them was a game changer or enhanced the power of the developer in general. It's not that dev tools are not used, just that most of them are directly written by the programmers that need them, for their own use, without much care for life expectancy or limitations. Just to get that thing done when they need it. I don't really understand much the point of the article. If an idea is good, well executed and presented to its target audience, maybe it won't eat the world, but it will have decent chances to not collect dust.
In my opinion this article is a cry from people that don’t understand how to find a market fit and then “sell” their idea. I think it’s pretty typical point of view from academics that their idea is ground breaking and should be know by everyone. However, things don’t work like that in the real world. Meritocracy doesn’t make the best tool rise to the top. You also need to solve a problem for a huge amount of people and then do a bunch of PR and educate.
> These tools collect dust because software nowadays doesn't only have to be written, it needs to be maintained and adapted.
Everyone loves making and using a new, shiny, "life changing" tool. Very few people would stick around at a job (or indeed, apply for a job) to maintain that tool.
Creation is easier compared to understanding and adaptation to change.
Developers chasing their tail writing clever programs to read spaghetti code instead of not writing speghetti code.
I get it. The problem is very attractive. I get turned on thinking about it too but I would rather programmers knew how to compose code that other humans could read instead of dreaming about using AI to read incomprehensible first drafts.
Teaching other developers how to write code is not fun I guess. I'm guilty too. I pull up a PR and scroll down and find a loop with some IFs and God forbid a map or some other inline atrocity sitting in a well named method with well named variables (they sort of get it)...and there I am trying to judge intent. I give up and just go to lunch in disgust, I don't have time to teach someone how express intent, nor do I have time to guess the intent. It's obvious that the code is looping over some list and digging into an object and blah blah...but why!??? The important part.
When I'm long dead maybe we will require programmers to write code that other people can understand.
Sure, stand-alone developer tools mighte be collecting dust, but many tools are simply baked into the things we develop with.
* Extensive debugging tools are now built into browsers.
* Most popular languages have extensive linters, formatters, and code quality tools.
* Tools like Hot Loading and Live View simply become part of the language you're using. Heck, Hasura and Postgraphile are essentially just a set of tools with some very intelligent wiring.
* Profiling is basically standard on all popular languages
* Storyboard and component driven design means you can quickly translate a lot of design work to code.
1. IDE dependency. If you have to use IDE X to get the feature, then your tool will live and die by IDE X. A lot of development tools lose their user base when an IDE or editor falls out of favor.
2. Language/compiler specificity. This one is rough, because most dev tools are dependent on language tooling to do the magic. Productivity hitches are different in different languages. In a day, I may work with Python, Go, JavaScript, SQL, bash/zsh and several DSLs. If your tool doesn't work with 2-3 languages I use, I may never even notice your tool. A lot of static analysis based tools work well with C and Java and nothing else. It's kind of the SmallTalk trap: amazing tools, but you have to use SmallTalk to use them.
3. Solving stuff that really doesn't matter to the programmer. As a manager and as a business owner a 15% in developer productivity is great. As a programmer, I'm not even going to notice that I'm getting 15% more done. And even if I do, it may not even matter.
> The reason that Reflexion Models are obscure while Mylyn is among the most popular Eclipse plugins is quite literally because Gail C. Murphy, creator of Reflexion Models, decided to go into academia, while her student Mik Kersten, creator of Mylyn, went into industry.
> Other fields of computer science don’t seem to have such a giant rift between the accomplishments of researchers and practitioners.
I'm not sure that's actually true. I can't think of a field I've studied where research generated software from a decade ago still worked out of the box. If you write software for Java 7 that proves your concept is feasible, the existence of Java 14 doesn't disprove it, so nobody funds the research to port it. This is as true for bioinformatics as compilers.
There's also a pretty strong hurdle in simply educating the software development community. I suspected if you did a sufficiently large poll of developers, less than 5 percent have set a breakpoint and used a debugger in the past year. It seems even renowned experts believe debuggers are not valuable[1]. And I suspect at least half of people who claim proficiency in git can't correctly explain the difference between the rebase and merge commands.
And that, IMO, is the mystery we need to explain. If the hypothesis is that weak but free tools are undercutting the market for advanced tools, why don't developers learn and use the tools freely available to them? Are the tools too hard to learn, not powerful enough, or something else? I suspect there's a time tradeoff going on -- learning how to use a tool takes time, so if you believe you have a slow method that will solve the problem, you might prefer it to investing in learning something new. Especially outside the research lab, where there is uncertainty that any given tool will actually solve the problem at hand, and a researcher hasn't handcrafted a tutorial to make your assigned task feasible.
Debuggers are very specific tools, and I've never really liked them.
Basically, you get a tiny view of what your code is doing, and have to slowly build a mental model of what's going on through time. I have found that prints and code reading (in a good IDE which is able to track variable references!) are often enough, and usually faster,for the kind of software I write.
Now, things are getting better: mozilla's RR is a game changer(reverse debugging on actual, large projects ), and more recently, pernosco (built on RR but very close to science-fiction) has at long last made me like debuggers again.
I use breakpoints when software supports it out of the box. Unfortunately, many third-party tools, IDE and Jupyter extensions in particular, are often of poor quality/WIP, are hard to use and can, at times, break my environment. For this reason, when a tool requires that I install additional packages, I am usually pretty reluctant to give it a try.
Curiously, even seemingly simple tools, like variable explorers, are usually implemented relatively poorly in most IDEs. I like JetBrains's implementation most, but it isn't without issues.
BTW, anybody has any recommendations for good and reliable, developer tool for Python and R?
The problem really is a lack of solutions that just work with no setup required.
The only two environments I have used where things just worked were VB.NET using Visual Studio while at uni and Dart using the IDE/editor they bundled in the early days (I think they discontinued it).
Every other time I have attempted to get a debugger working for a language I have spend hours without getting anywhere.
I use very few developer tools, mostly because I couldn't get them to stop doing things I hated, or because I couldn't get them to stop doing things I didn't need, or because I couldn't get them to stop doing things I didn't understand. There's a common theme there.
The autocompletion stuff really bothered me because I know what I want to type, my fingers are already doing it, and I had to stop them. I don't want to learn to retype just for this tool. No.
Certainly, some of them seemed like they would benefit from some kind of beginner mode, intermediate mode, and so on. I remember not having touched Visual Studio for over a decade, and then looking at it and feeling like a chimp dropped into the cockpit of an F-15.
I'm the opposite. I had mixed feelings about developer tools, but they got much better once I started to embrace them instead of trying to customize them each step of the way. After you adopt such way, it's hard to come back.
I am used to completely not worrying about formatting. Sometimes if I want some fast code I type it in a single line with semicolons, press Ctrl+S and VSCode automatically formats the entire file according to the "official" language formatting guide.
Same with autocompletion. I program in OOP languages, so I really like long names such as AbstractMachineDevicePool. I really like that I can write AMDP, press ctrl+space, enter and it puts AbstractMachineDevicePool into my code.
Ironically, and perhaps opposite to the point you're trying to make, this is part of the reason I prefer to evolve my Emacs towards being an IDE than to use an actual IDE. Bolting advanced tooling onto Emacs takes lots of ongoing work, but at the end I can be damn sure I actually understand what the tooling is doing, and why - and I can easily patch any piece of it to stop doing things I hate or don't need.
I can totally sympathize with this idea. When you pick a tool to make a specific task easier, you want it to do exactly that.
I see this all the time in conversation (with younger developers, mostly). They find it very difficult to understand how one can possibly survive without an (advanced) IDE, and most likely look at me as exactly that chimp.
I'm a very basic user of IDEs. I don't use almost any of their advanced features, nor do I memorize anything beyond the most basic shortcuts. I can't even justify the investment to learn them properly, as context may require me to change IDEs (and that context is often an accumulation of grievances).
On the other hand, I live inside the CLI, have no trouble composing basic tools to do what I want, and has been so for ages.
I'd much rather have a toolbox of individual tools that I can choose from and mix-and-match over time, than a fancy all-in-one powertool that would trap me with sunk costs like a bad marriage.
I understand where you're coming from, but it also sounds similar to insisting on hand saws and hammers, because chainsaws and nail guns have too much complexity.
My research is also on dev tools, and I have tried to get my research findings adopted. It is hard. Companies often want to release incremental, small features, not major UI overhauls.
Even when I've done research at companies or been funded by them to study their products, it is virtually impossible to get it adopted into the product. Again, the incentives and motivations of PMs are very different than researchers.
Companies often want to release incremental, small features, not major UI overhauls.
Speaking as a product leader who has been in a position to decide on these, I'm not opposed to major UI overhauls, but many that have been proposed to me:
- Are motivated by a design team that wants to justify their jobs or make a mark on a product, with the UI considerations secondary.
- Have major issues and design weaknesses themselves.
- Throw out important aspects of functionality in an attempt to be "fresh and simple".
- Ignore that we had our last major overhaul 12 months ago, and that one was in response to the major ovehaul 24 months ago.
Requiring evolution rather than revolution is a hedge against these problems. I'm not generally opposed to overhauls because I'm familiar with the importance of UI. For example, I'm very unhappy with Robinhood as a trading platform, but damn, switching to Fidelity is painful because their UI is so terrible.
I wish I more consistently got to work with talented designers. I put a lot of effort into getting good designers, as poor designers can wreak havoc.
"They later wrote a Java version, jRMTool, but it’s only for an old version of Eclipse with a completely different API. The code is written in Java 1.4, and is no longer even syntactically correct. I quickly gave up trying to get it to run."
"A few years back, my advisor hired a summer intern to work on MatchMaker. He instantly ran into a barrier: it didn’t work on Java 8."
"A couple years ago, I tried to use the Java Whyline. It crashed when faced with modern Java bytecode."
He's answered his own question. Developer tools wear out quickly as their environment changes. Unless they have support that keeps up with the development environment, they die.
I completely get how hard it is to sell tools to developers, but I am not sure everyone gets the why.
I would pay $1000 tomorrow for an Emacs that doesn't flicker and is several times faster, and is easier to extend and modify -- and I'll give the money happily, convinced that I made a fantastic bargain.
I'd happily pay a monthly subscription for a compiler SaaS that makes my production binaries as small and fast as possible (and be integrated in a CI/CD system so the binary never touches my computer and just gets deployed to production).
But there are three problems.
1. The commercial entity developing the tool might fall on hard times and give up. What are the programmers relying on the tool to do? Most companies also never open-source their stuff once they go belly up either. You will be stuck with a non-updated tool whose value (and thus part of your value as well) will only be declining with time.
2. Nobody is interested in investing real money and professional programmers to make the open-source and free software better. You have stuff like `semgrep` and many others that are barely limping along -- and they deserve A LOT OF LOVE! We will all benefit from them! But the incentives just aren't there for the players who can make the true difference.
3. Our employers are unwilling to absorb the costs for better tooling. The minute you ask for a commercial license for something you are met with "why are all other 20 million Python programmers doing just fine without it?" and the discussion immediately falls apart.
In order to never suffer from #1 we all stick to the lowest common denominator which is both logical and sad.
To solve #2, charity funds should be given to professional teams that specifically tackle tooling.
Not sure #3 can be solved. Culture changes are extremely hard and even when they happen they are as slow as a glacier moving. On the other hand, I've paid for commercial tools in the past when I was convinced they'll increase my productivity. So sometimes we should view this as an investment.
I feel like every library, every framework, every programing language, compiler, database, VM, debugger, logger, tracer, metrics monitor, editor, source control, artifact manager, build tool, dependency manager, deployment automation, etc. are examples of developer tools that are not collecting dust.
My guess is that the tools which try to provide program synthesis just don't have good ROI, too costly to build and maintain in a working state and too hit and miss from the user, and that's why they've been collecting dust.
So let's get this straight. People on this thread work as programmers, and want to get handsomely rewarded for their work by their employer, but are, all too often, too tight-fisted to pay for tools -- made by people in the same industry as they are -- which will make them do their job better and deliver better results. What does this say about people in the profession? Shameful.
If somebody creates a product which I don't view as being worth the asking price I have no obligation to purchase it, regardless of whether I share a profession with the producer.
There's less money in developer tools than in selling to the general public.
I've seen some wonderful products, but it seems to be at odds with reasonable pricing because of the limited number of sales available.
I've seen some really interesting tools though. I remember trying purify once decades ago and it was like magic. It unobtrusively inserted itself into your code and found memory leaks and faults you never realized were there. And then I asked about pricing and it got into this complicated per-seat licensing nonsense that scared everyone away.
Same thing happened with electric cloud. I remember trying it out and it was very well done. It unobtrusively helped you run make. It figured out all your dependencies for real (it instrumented the filesystem accesses) and magically parallelized all your builds. And then pricing killed it all.
I think a Netflix model would have worked better. Provide a set of heterogenous dev tools for a low monthly fee, fund lots of individual tool developers, and be the tide that raises all the boats.
(coincidentally purify I believe came from reed hastings who also did netflix)
Taking a tool from an academic research project to an actual product is very difficult. This article points out several of the ones left by the wayside because the final leg of that journey is boring, tedious, and grueling. It’s kind of an obvious situation actually.
This is kind of what I was thinking. Most of these sound useful, but they also sound like situations where the primary end goal was a paper, not a polished, widely usable software product. The practical realities of what it takes for enterprise devs to adopt tools at a large-enough scale to make the tool sustainable are just too much for a single academic paper to overcome. In particular, these sort of tools feel too specialized to really catch on as a FOSS community project. For developers with limited free to time to 'volunteer,' they usually want to spend that time making "primary" contributions -- the actual systems and end-products -- rather than secondary contributions in the form of tooling.
Hence we see the tools that survive are tools that we first recognize as products, even if they're free. VS Code is a good example, I think. Or, if they're not free, they're paid for (e.g. Jetbrains), and the money makes maintaining/developing the tool sustainable.
Not to wax too poetic but it has the feel of academia trying to start a fire with a flint and not understanding that they have to properly construct the rest of the firestarting kit -- clear space, get kindling, arrange the rest of the wood, make sure it's all dry. They just see the sparks coming off the stone and keep asking "Why isn't this fire starting?"
Let me put it this way. Instead of saying, "Wow, this tool had promise, but it didn't catch on because (??) and because it didn't catch on it hasn't been maintained," the observation should be more like, "Hmm, maybe if this tool had been properly maintained it would have caught on by now."
We happily burn through tens of thousands of dollars in excess aws billing because we have cargo culted that optimization=bad, but we don’t want to spend $500 on an IntelliJ license
> About 10 years later, at the Human-Computer Interaction Institute at Carnegie Mellon, Amy Ko was thinking about another problem. Debugging is like being a detective. Why didn’t the program update the cache after doing a fetch? What was a negative number doing here? Why is it so much work to answer these questions? Amy had an idea for a tool called the Whyline, where you could ask questions like “Why did ___ happen?” in an interactive debugger
Am I just confused, or does it sound like program slicing (1979)?
[+] [-] hypermachine|5 years ago|reply
This is why no-code and low code are so much more successful than developers tooling startups in terms of revenue and profitability. The people using are the same people who are running the business. The value proposition is clear. "Better developer experience" alone is not sufficient for selling to enterprise. And programmer productivity cannot be quantified in lines of code written. This is hard point to explain and get across on HN because this forum is inherently dismissive of the value of RPA and RAD software.
[+] [-] initplus|5 years ago|reply
Over-monetizing their dev tooling was a significant contributor to Microsoft's loss of dev mind-share over the last decade. Free software took over the world because any kid in their bedroom could download Linux/GCC/MySQL for free.
Want to work in .NET/MSVC? You just run into barriers (gimped "express" versions, no free documentation etc.) Yes this has changed now, but it's been a long time coming.
[+] [-] MattGaiser|5 years ago|reply
Because it is too much work to convince the company that spending $500 on JRebel to have me not go on Hacker News for 5 (and it turns into 15) minutes while the thing compiles (my last company). I also have no real stake in whether the product ships in one month or two so I am not paying for it myself.
To pay for tooling, productivity needs to be a priority. I have never worked anywhere where productivity was discussed.
[+] [-] zarkov99|5 years ago|reply
[+] [-] dlojudice|5 years ago|reply
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.
[+] [-] pjmlp|5 years ago|reply
It is incredible how so many devs don't want to pay for tooling, yet expect people to pay them.
Here is an idea, what about being paid in the exact amount that one is willing to pay for their tooling.
[+] [-] amelius|5 years ago|reply
Apparently it is possible make $100k with an IDE color scheme:
https://news.ycombinator.com/item?id=26262989
[+] [-] dehrmann|5 years ago|reply
I can't count how many times I see someone using Sublime Text professionally who hasn't paid for it. If anyone should have empathy for a developer, it's a developer, likewise with someone who can afford it. Once I put this together, I realized developer tools are for the most part a business dead end.
[+] [-] emrah|5 years ago|reply
Maybe not for their personal/hobby projects, but they wouldn't be the ones paying for tools at work.
So it's the companies not willing to pay for dev tools or understand the value they can provide
[+] [-] chmod775|5 years ago|reply
There's a reason 98% of popular developer tools are FOSS projects.
[+] [-] megameter|5 years ago|reply
What is the main loop? Well, as it's defined since the rise of interactive computing, it's typing in the editor, compiling, then testing and debugging.
Thus we optimize for:
1. Typing code fast(or typing less code)
2. Compiling code fast(by doing less compilation)
3. Minimizing testing and debugging time(by narrowing our definitions of testing to that which is easy to automate).
The main loop of coding is not software development. It does not study the domain problem, define new benchmarks for success, untangle communication issues, or refine principles of development. It is a path to coder flow state, feature factoryism and shipping the org chart. These things sort of resemble development - a happy coder delivering features within a definite architecture does serve someone at some point - but also manifest dysfunction. Development failing is just shrugged off as bad programming or bad management.
Tools like a Whyline or Reflexion models are not in the main loop. They are an invitation to look carefully at whatever horror has been wrought and address it at a deep level. But that really needs a researching mindset, not a shipping one.
In practice, the available tools very slowly move in the direction of the suggestions of research. There are improvements, but they need projects that put together the pieces and make it a goal from the language design(the main interface) upwards.
[+] [-] geophile|5 years ago|reply
Why is JetBrains so successful where others have failed? A few thoughts:
- Intellij was released in 2001. Eclipse was a close competitor for a while, which made no sense to me. Intellij just worked, and it was intuitive. I found Eclipse to be uglier, slower, flakier, crashier, and far less intuitive. Haven't heard of it in years.
- It was always the case that at least some version of Jetbrains tools are zero cost. I got hooked on it early on. I have been using emacs far longer, and yes, while a sufficiently dedicated developer can make emacs behave like an IDE, it really isn't one. Intellij just worked out of the box. In the preceding two decades, there were high-end development tools available (Lisp machines and their all-encompassing environments, Lucid for C++, Purify for C/C++ memory problems, Atria, Rational. Trivia: Did you know that Purify was founded by Reed Hastings, the guy who went on to found Netflix?) The tools were expensive, and I don't think there were free versions. These companies all went out of business, or were acquired.
- Jetbrains is incredibly focused. Having been through several VC-funded technology companies, I can easily see how VC brain farts can destroy a company's focus. (This dynamic isn't entirely the VCs fault. Founders stretch the truth to get funded, and then VCs insist on the fairy tales they've been told.)
- Jetbrains has expanded to other languages, and other kinds of tools (besides just refactoring Java code). The number of languages, technologies, and frameworks that they support is just mind-boggling.
- Consistent focus on improving developer's lives, through steady improvements in functionality, performance, and quality, over 20 years at this point. They started far ahead and have widened the gap.
OPs tools look useful. I suspect they would attract a much wider audience if made available through Jetbrains products.
[+] [-] klyrs|5 years ago|reply
Package distributions. Good word, I am not happy here. Still an unsolved problem in general, some languages tackle it better than others.
Testing frameworks. It's getting better. Big props to zig, for including tests for free with comptime. But in general, it's piles of code that somebody maintains for each language. Often, there are multiple tools because the language devs don't pull them into first-class components.
Debuggers. There's pretty good tools out there. They're clunky to use, but there are multiple front ends that can handle multiple languages, thanks to a common data format.
Code formatters. Props to zig, go, and rust for building these in. But for most languages, it's DIY.
Common theme here: all of this stuff is fairly generic, but each language tends to do its own thing. Tools aren't officially part of the languages, neither are they generic. Except debuggers! There's a common interface, DWARF support becomes a part of the language, and (another key point) language devs use it -- so they don't rot.
Developer tools can be magic, but unless they're generic, I expect them all to rot.
Edit: Oh, I forgot documentation generation -- like debugging, there's been some convergence around some generic tools and it's pretty easy to build support into / on top of a language. And newer languages use these tools internally to build their docs. Great!
And how could I forget compilers! LLVM might save the day for all of this stuff (except versioning and distribution... ick). Build a tool that can grok LLVM-IR, and you've solved the problem for most languages out there.
[+] [-] slx26|5 years ago|reply
[+] [-] barefeg|5 years ago|reply
[+] [-] dstick|5 years ago|reply
[+] [-] phone8675309|5 years ago|reply
Everyone loves making and using a new, shiny, "life changing" tool. Very few people would stick around at a job (or indeed, apply for a job) to maintain that tool.
Creation is easier compared to understanding and adaptation to change.
[+] [-] datavirtue|5 years ago|reply
I get it. The problem is very attractive. I get turned on thinking about it too but I would rather programmers knew how to compose code that other humans could read instead of dreaming about using AI to read incomprehensible first drafts.
Teaching other developers how to write code is not fun I guess. I'm guilty too. I pull up a PR and scroll down and find a loop with some IFs and God forbid a map or some other inline atrocity sitting in a well named method with well named variables (they sort of get it)...and there I am trying to judge intent. I give up and just go to lunch in disgust, I don't have time to teach someone how express intent, nor do I have time to guess the intent. It's obvious that the code is looping over some list and digging into an object and blah blah...but why!??? The important part.
When I'm long dead maybe we will require programmers to write code that other people can understand.
[+] [-] NateEag|5 years ago|reply
At every job I've had, there were piles of code that went untouched the whole time I was there, and chunks that were undergoing constant evolution.
The former always massively outweighs the latter.
I'm a huge fan of readable code, and try to write it myself, but the truth seems to be that it doesn't matter as much as we wish.
[+] [-] thomascgalvin|5 years ago|reply
If a codebase is in development long enough, the probability of spaghetti code approaches 1.
Also, some of the spaghetti I've had to fight through wasn't my fault, just my responsibility.
[+] [-] SkyPuncher|5 years ago|reply
Sure, stand-alone developer tools mighte be collecting dust, but many tools are simply baked into the things we develop with.
* Extensive debugging tools are now built into browsers. * Most popular languages have extensive linters, formatters, and code quality tools. * Tools like Hot Loading and Live View simply become part of the language you're using. Heck, Hasura and Postgraphile are essentially just a set of tools with some very intelligent wiring. * Profiling is basically standard on all popular languages * Storyboard and component driven design means you can quickly translate a lot of design work to code.
The list goes on and on and on.
[+] [-] indymike|5 years ago|reply
1. IDE dependency. If you have to use IDE X to get the feature, then your tool will live and die by IDE X. A lot of development tools lose their user base when an IDE or editor falls out of favor.
2. Language/compiler specificity. This one is rough, because most dev tools are dependent on language tooling to do the magic. Productivity hitches are different in different languages. In a day, I may work with Python, Go, JavaScript, SQL, bash/zsh and several DSLs. If your tool doesn't work with 2-3 languages I use, I may never even notice your tool. A lot of static analysis based tools work well with C and Java and nothing else. It's kind of the SmallTalk trap: amazing tools, but you have to use SmallTalk to use them.
3. Solving stuff that really doesn't matter to the programmer. As a manager and as a business owner a 15% in developer productivity is great. As a programmer, I'm not even going to notice that I'm getting 15% more done. And even if I do, it may not even matter.
[+] [-] jldugger|5 years ago|reply
> Other fields of computer science don’t seem to have such a giant rift between the accomplishments of researchers and practitioners.
I'm not sure that's actually true. I can't think of a field I've studied where research generated software from a decade ago still worked out of the box. If you write software for Java 7 that proves your concept is feasible, the existence of Java 14 doesn't disprove it, so nobody funds the research to port it. This is as true for bioinformatics as compilers.
There's also a pretty strong hurdle in simply educating the software development community. I suspected if you did a sufficiently large poll of developers, less than 5 percent have set a breakpoint and used a debugger in the past year. It seems even renowned experts believe debuggers are not valuable[1]. And I suspect at least half of people who claim proficiency in git can't correctly explain the difference between the rebase and merge commands.
And that, IMO, is the mystery we need to explain. If the hypothesis is that weak but free tools are undercutting the market for advanced tools, why don't developers learn and use the tools freely available to them? Are the tools too hard to learn, not powerful enough, or something else? I suspect there's a time tradeoff going on -- learning how to use a tool takes time, so if you believe you have a slow method that will solve the problem, you might prefer it to investing in learning something new. Especially outside the research lab, where there is uncertainty that any given tool will actually solve the problem at hand, and a researcher hasn't handcrafted a tutorial to make your assigned task feasible.
[1]: https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/
[+] [-] Agingcoder|5 years ago|reply
Basically, you get a tiny view of what your code is doing, and have to slowly build a mental model of what's going on through time. I have found that prints and code reading (in a good IDE which is able to track variable references!) are often enough, and usually faster,for the kind of software I write.
Now, things are getting better: mozilla's RR is a game changer(reverse debugging on actual, large projects ), and more recently, pernosco (built on RR but very close to science-fiction) has at long last made me like debuggers again.
https://rr-project.org/
https://www.pernos.co/
[+] [-] dr_kiszonka|5 years ago|reply
Curiously, even seemingly simple tools, like variable explorers, are usually implemented relatively poorly in most IDEs. I like JetBrains's implementation most, but it isn't without issues.
BTW, anybody has any recommendations for good and reliable, developer tool for Python and R?
[+] [-] chillfox|5 years ago|reply
The only two environments I have used where things just worked were VB.NET using Visual Studio while at uni and Dart using the IDE/editor they bundled in the early days (I think they discontinued it).
Every other time I have attempted to get a debugger working for a language I have spend hours without getting anywhere.
[+] [-] at_a_remove|5 years ago|reply
The autocompletion stuff really bothered me because I know what I want to type, my fingers are already doing it, and I had to stop them. I don't want to learn to retype just for this tool. No.
Certainly, some of them seemed like they would benefit from some kind of beginner mode, intermediate mode, and so on. I remember not having touched Visual Studio for over a decade, and then looking at it and feeling like a chimp dropped into the cockpit of an F-15.
[+] [-] skocznymroczny|5 years ago|reply
I am used to completely not worrying about formatting. Sometimes if I want some fast code I type it in a single line with semicolons, press Ctrl+S and VSCode automatically formats the entire file according to the "official" language formatting guide.
Same with autocompletion. I program in OOP languages, so I really like long names such as AbstractMachineDevicePool. I really like that I can write AMDP, press ctrl+space, enter and it puts AbstractMachineDevicePool into my code.
[+] [-] TeMPOraL|5 years ago|reply
Ironically, and perhaps opposite to the point you're trying to make, this is part of the reason I prefer to evolve my Emacs towards being an IDE than to use an actual IDE. Bolting advanced tooling onto Emacs takes lots of ongoing work, but at the end I can be damn sure I actually understand what the tooling is doing, and why - and I can easily patch any piece of it to stop doing things I hate or don't need.
[+] [-] CrLf|5 years ago|reply
I see this all the time in conversation (with younger developers, mostly). They find it very difficult to understand how one can possibly survive without an (advanced) IDE, and most likely look at me as exactly that chimp.
I'm a very basic user of IDEs. I don't use almost any of their advanced features, nor do I memorize anything beyond the most basic shortcuts. I can't even justify the investment to learn them properly, as context may require me to change IDEs (and that context is often an accumulation of grievances).
On the other hand, I live inside the CLI, have no trouble composing basic tools to do what I want, and has been so for ages.
I'd much rather have a toolbox of individual tools that I can choose from and mix-and-match over time, than a fancy all-in-one powertool that would trap me with sunk costs like a bad marriage.
[+] [-] nikanj|5 years ago|reply
[+] [-] azhenley|5 years ago|reply
Even when I've done research at companies or been funded by them to study their products, it is virtually impossible to get it adopted into the product. Again, the incentives and motivations of PMs are very different than researchers.
[+] [-] acidbaseextract|5 years ago|reply
Speaking as a product leader who has been in a position to decide on these, I'm not opposed to major UI overhauls, but many that have been proposed to me:
- Are motivated by a design team that wants to justify their jobs or make a mark on a product, with the UI considerations secondary.
- Have major issues and design weaknesses themselves.
- Throw out important aspects of functionality in an attempt to be "fresh and simple".
- Ignore that we had our last major overhaul 12 months ago, and that one was in response to the major ovehaul 24 months ago.
Requiring evolution rather than revolution is a hedge against these problems. I'm not generally opposed to overhauls because I'm familiar with the importance of UI. For example, I'm very unhappy with Robinhood as a trading platform, but damn, switching to Fidelity is painful because their UI is so terrible.
I wish I more consistently got to work with talented designers. I put a lot of effort into getting good designers, as poor designers can wreak havoc.
[+] [-] k__|5 years ago|reply
[+] [-] Animats|5 years ago|reply
"A few years back, my advisor hired a summer intern to work on MatchMaker. He instantly ran into a barrier: it didn’t work on Java 8."
"A couple years ago, I tried to use the Java Whyline. It crashed when faced with modern Java bytecode."
He's answered his own question. Developer tools wear out quickly as their environment changes. Unless they have support that keeps up with the development environment, they die.
[+] [-] samatman|5 years ago|reply
He was writing a blog post to draw our attention to this problem, and succeeded.
[+] [-] ribs|5 years ago|reply
[+] [-] ok123456|5 years ago|reply
[+] [-] pdimitar|5 years ago|reply
I would pay $1000 tomorrow for an Emacs that doesn't flicker and is several times faster, and is easier to extend and modify -- and I'll give the money happily, convinced that I made a fantastic bargain.
I'd happily pay a monthly subscription for a compiler SaaS that makes my production binaries as small and fast as possible (and be integrated in a CI/CD system so the binary never touches my computer and just gets deployed to production).
But there are three problems.
1. The commercial entity developing the tool might fall on hard times and give up. What are the programmers relying on the tool to do? Most companies also never open-source their stuff once they go belly up either. You will be stuck with a non-updated tool whose value (and thus part of your value as well) will only be declining with time.
2. Nobody is interested in investing real money and professional programmers to make the open-source and free software better. You have stuff like `semgrep` and many others that are barely limping along -- and they deserve A LOT OF LOVE! We will all benefit from them! But the incentives just aren't there for the players who can make the true difference.
3. Our employers are unwilling to absorb the costs for better tooling. The minute you ask for a commercial license for something you are met with "why are all other 20 million Python programmers doing just fine without it?" and the discussion immediately falls apart.
In order to never suffer from #1 we all stick to the lowest common denominator which is both logical and sad.
To solve #2, charity funds should be given to professional teams that specifically tackle tooling.
Not sure #3 can be solved. Culture changes are extremely hard and even when they happen they are as slow as a glacier moving. On the other hand, I've paid for commercial tools in the past when I was convinced they'll increase my productivity. So sometimes we should view this as an investment.
[+] [-] didibus|5 years ago|reply
My guess is that the tools which try to provide program synthesis just don't have good ROI, too costly to build and maintain in a working state and too hit and miss from the user, and that's why they've been collecting dust.
[+] [-] gjvc|5 years ago|reply
[+] [-] dpatterbee|5 years ago|reply
[+] [-] denkmoon|5 years ago|reply
Yes
>want to get handsomely rewarded for their work by their company
I want a fair portion of the value I generate for my employer
> too often too tight-fisted to pay for tools which will make them do their job better and deliver better results
I usually don't control the purse strings. When I did freelance work the first thing I did was buy CLion.
>What does this say about people in the profession?
You tell me.
[+] [-] hinkley|5 years ago|reply
And I have two hobbies where I spend more on tools than I do for work. And tools for home repairs.
There just aren’t that many tools for me to spend money on these days, which is a shame.
I wonder if you could pull off a patreon thing where sponsors get early access?
[+] [-] m463|5 years ago|reply
I've seen some wonderful products, but it seems to be at odds with reasonable pricing because of the limited number of sales available.
I've seen some really interesting tools though. I remember trying purify once decades ago and it was like magic. It unobtrusively inserted itself into your code and found memory leaks and faults you never realized were there. And then I asked about pricing and it got into this complicated per-seat licensing nonsense that scared everyone away.
Same thing happened with electric cloud. I remember trying it out and it was very well done. It unobtrusively helped you run make. It figured out all your dependencies for real (it instrumented the filesystem accesses) and magically parallelized all your builds. And then pricing killed it all.
I think a Netflix model would have worked better. Provide a set of heterogenous dev tools for a low monthly fee, fund lots of individual tool developers, and be the tide that raises all the boats.
(coincidentally purify I believe came from reed hastings who also did netflix)
[+] [-] Lucasoato|5 years ago|reply
[+] [-] spfzero|5 years ago|reply
[+] [-] Gene_Parmesan|5 years ago|reply
Hence we see the tools that survive are tools that we first recognize as products, even if they're free. VS Code is a good example, I think. Or, if they're not free, they're paid for (e.g. Jetbrains), and the money makes maintaining/developing the tool sustainable.
Not to wax too poetic but it has the feel of academia trying to start a fire with a flint and not understanding that they have to properly construct the rest of the firestarting kit -- clear space, get kindling, arrange the rest of the wood, make sure it's all dry. They just see the sparks coming off the stone and keep asking "Why isn't this fire starting?"
Let me put it this way. Instead of saying, "Wow, this tool had promise, but it didn't catch on because (??) and because it didn't catch on it hasn't been maintained," the observation should be more like, "Hmm, maybe if this tool had been properly maintained it would have caught on by now."
[+] [-] nikanj|5 years ago|reply
[+] [-] jhgb|5 years ago|reply
Am I just confused, or does it sound like program slicing (1979)?