Greetings everyone,
At my job I deal with a lot of embedded code, 98% of which is C although some bits are written in assembly. When I say a lot I mean dozens of divirgent versions(sometimes substantially modified, sometimes not) of a codebase that’s close to a million lines and thousands of files. It pulls a lot of legacy support as well as historical things we don’t have time to update.
I use SlickEdit as my IDE. The build system is complex, but let’s just say it involves Perl, Batch files, a tree of INI files and GNU Make and is compiled using GNU C. I get to fix mine and other people’s bugs in different version splits of this code base.
I am getting sick of trying to figure out how things work using grep! Tracking down global variables, messages, event flags, thread entry points, pipes, function pointers and callbacks, and even co-routines that are not clearly described somewhere is taking it’s toll on my soul. Sometimes I feel like a cryptographer trying to decipher the voynich manuscript.
[starts acting like a five year old]
There’s gotta be a better way than just grep and navigating using tags. I can’t believe nobody has yet made a usable static code visualizer, much less sometimes that lets you modify and write new code at a higher level. I have a makefile. Something can parse that makefile, figure out what defines and what includes is every single file in the project compiled with, it could even run the compiler and have it dump translation units. Now, I am not asking anybody to try to solve the halting problem, I just want some feedback about what I’m looking at! Static analysis can’t tell me everything in all cases, but for any information I want I will settle for a reasonable attempt of providing a non-exhaustive set.
When my cursor is sitting in a middle of a function, I want it to be constantly aware of the entry point to the entire program, loops and branches. I want a reasonable guess as to what thread(s) I could be in, what functions could’ve called me. I want to be able to without leaving this code view provide hypothetical facts ( e.g. It was this function that called me) and turn it on and off as an assumption. I want to be able to teach it about specific messaging mechanisms (pipe implementation, semaphores, etc.) and be able to follow messages down pipes reasonably. I want a reasonable guess as to what other threads the thread I’m in communicates with. I want a diagram for everything. I want it overlayed floating over the code on a single keypress and I should be able to navigate the code using any diagram be it a call graph, a co-routine guess, a pipe diagram, hypothetical call stack, etc.
If I’m sitting in a perl script I want color coding that is actually useful. Data type, branch, reg-ex and object sensitive. It’s not really helpful that it’s making “print” bold – that doesn’t make other people’s perl any more readable.
Just because it doesn’t know the instruction set of the assembly file I’m editing doesn’t mean it’s that hard to guess and color code accordingly. It’s assembly for fuck’s sake, it should be able to figure out the instruction set without me telling it about everything. I can touch up it’s guess later.
I want a hypothetical guess at potential timelines – as in there’s always easy to find functions that are guaranteed NOT to be running whereever you are in the code. For example if you are in a() and the only place a() and b() are launched is
f()
{
a();
b();
}
We can know that if we’re in a(), probably no other thread is running b(). Same thing with things like semaphores that can be used to guess at timelines. My grep is tired.
[stops acting like a five year old]
I’ve studied compiler design. I’ve studied programming languages. I’ve studied computability. I know how incredibly difficult what I described is to actually make into a commercial product. It seems static analysis people often generalize things as “Oh, halting problem, so we won’t even try”. Halting problem only tells us what we can’t do in every case, it tells us nothing about what we can’t do in some cases. Here, I can write you a useless program in ten minutes that finds some infinite loops, and always terminates - that doesn’t violate the halting problem. It’s hard, but it’s not much harder than things like voice recognition and face recognition, etc.
We’re living in 2007 now. We have incredibly fast CPUs, huge reserves of RAM and enormous hard drives. We have reasonably mature higher level languages. We have thousands of software engineers, some of them in very inexpensive parts of the world. The best we can do in the IDE arena is Visual Studio, Visual SlickEdit and SourceInsight? It’s color-coordinated notepad with some fancy toolbar buttons for two-letter VI commands, an ugly inflexible call graph generator and a checkbox GUI enabled version of Make, all of them slow as bloody hell. :dubious: End-user PC application developers at least have RAD tools like Delphi and while that’s better than nothing I strongly feel that the development tool arena is a good fifteen years behind the rest of the software world. The mere fact that there is no (to the best of my knowledge) good 3D static code visualizer is a testament to that. And as much as I hate UML and Java, why isn’t there something that gives you a UML view of a Java project, and allows you to edit code by visually modifying the UML rather than the code itself?
I’m kind of busy now but if this doesn’t change in a few years I’m going to start rounding up some brains and venture capital. I just described the above to a few friends and some said they’d pay thousands out of pocket to have something like that. Hell, I’d pay thousands. Maybe we’re just spoiled idiots. Who knows.
