Software Tools of the Future

An anonymous reader writes "What are the sofware tools of the future going to be? It's an interesting question, with many facets. Here are some important trends in design and construction tool strategy, which will effect the kinds of software tools that will be delivered in the future. It looks at how to improve software development efficiency through visual modeling, generating code from abstract models, and systematic reuse."

Comments

Usability in Non-MS Environments

[The Raven]

I'm less interested in the new directions dev tools can take, and more interested in getting the good parts of existing tools more ubiquitous. MS tools (like the .NET Dev Studio) are very nicely created, with flexibility and convenience. I would like to see tools with the same capability for C on Linux.

A lot of developers poo-poo .NET programming like they poo-pood VB programming... but part of the reason for their popularity is the quality of their development tools. Bring some of those enhancements over to C on an alternate platform, and I think the results would be quite interesting.

Raven

Re:dubious

[Dolphinzilla]

thats a fact, Rational tools in my experience are way over-repesented - One group at work proudly used the Rational tools to generate some code - it was the most obscure code I had ever seen - it was not even clear what half the modules did or were suppose to do. They gave me an executable to take to a subcontractor and try out - the subcontractor laughed at it (and so did I...) There is no escaping these tools, we just need to minimize the wasted time they cause... IMHO

Radical Innovation

[LionKimbro]

Here's my set of software predictions. Some more detail to fill in for that other guy's blog entry.

Here we go:

• Refactoring Browsers - let you change the name of a class, method, whatever- and have perfect replacement across the project. This is important, because it means that our API's can feature consistent naming schemes, without a whole lot of upfront planning. These exist today, but not in common use.
• Spatial Code Browsering - The ability to organize our textual code in a shared diagram, so that we can arrange it the way that we think of it. Most of our code is text, for various reasons. But we tend to think of spatial relationships between blocks of code. There's no reason why we can't lay out the files spatially, share those spatial layouts, and browse those spatial layouts.
• Replay Debugging - You can make programs run in a virtual machine that tracks deltas over time, or keeps time slices. You can "rewind" or "fast forward" a test execution, introspecting into the state of variables at different points of time. If your debugger is smart enough, it can answer the question: "now how did THAT come to happen?" "Why did you do X? Why didn't you do Y?"
• Publish-Subscribe - Is it just me, or is publish-subscribing becoming more important? That's because we're going to component systems.
• Tuple Space(s). By my limited understanding, this is a model of programming where you have: A gigantic data store, and little micro-programs that pull and push data to the store. For example: Let's say you have a web-app. The web server receives a request, and pushes it into the store, in the form of a graph. So, for instance, you get the "request" node, and it links up to a node representing the time it was received, and it links up to the URL, and it links up to the response to be filled out, etc., etc.,. Then if a program knows how to fill out the response, it starts filling out the response as much as it can. For things that aren't at it's level of abstraction, it leaves for other programs. When things are fleshed out enough for those programs, they automatically jump into play, and fill out the rest. When it's all fleshed out, the web server recognizes that the "done" flag's set, takes the whole thing, ships it out, and then clears everything. What's new here is that what triggers programs/procedures is the state of the tuple store, the shared graph- programs register states that they can metabolize, and then when conditions are right, the programs are invoked. Your programs are collections of traps. Mixes declarative programming with imperative programming, in step with development of the semantic web.
• Non-boxy interface, Deep visualization - Our GUI tools are all "boxy," and there haven't been any real UI advances since MFC, and I do blame the API. It's easy to imagine API's that allow you to specify call-outs, how icons that contain icons are specified, the ability to compose and connect icons, etc., etc.,. But we're still in the images, rectangles, buttons, and tree views days, as far as easy-to-use API's are concerned. As SVG matures, I believe that our API's will get less rectangular, and give us visual and interactive power on the cheap.
• Social Help Documentation - I think we'll see integrated help documentation linking up with things like wiki and programmer's forums. So you'll be able to read a function's documentation, and see 17 examples of real use of the function and commentary. It won't be a seperate open-a-web-browser and search thing, it'll be easily available and connected with the deployed documentatio

Re:Exactly, tools are a crutch...

[Beek]

>However you have to be a master of the tool, rather than its slave unsure of how it does its magical stuff.

This is the key... The problem is that those who depend on IDEs can't function without them. You aren't a master if you can't do the task without the IDE. And if you can do it without the IDE, then it isn't really a crutch anymore, right?

>I've never really got why the die-hards hate any sort of automation in their environments.

They LOVE automation... They just want complete control. IDEs almost never give you that. make (or ant or whatever) is the ultimate automation environment, and it gives you that control. Sometimes you have to write code to do your task for you, and the problem with IDEs is that they rarely let you plug that functionality in easily.

>For instance, if you're in maintenace mode on a large codebase which you know nothing about, and you change a method's behaviour, what upstream code will that affect?

Unit testing ;-) But the Eclipse feature you mentioned is still extremely useful, and I don't think any dev be opposed to that, because it doesn't modify your code unexpectedly. It's when your IDE changes code silently when this becomes a problem. I've had Netbeans mutilate my tag libraries before. Stupid Netbeans (although version 4 is very promising).

Re:Buzzwords, psychology, and viewpoint relativity

[JKR]

One area I would like to see explored more is divorcing presentation from meaning (DPFM).

Yes, I couldn't agree more. On a similar theme, I'd like to see source control tools which store the parse tree of the code as the canonical source, rather than the ASCII (or Unicode, in the case of Java) source code. Then the local system regenerates the source on the users machine, with the correct local coding conventions, whitespace, indenting etc. No more "braces-go-here" wars, and tools which already use the parse tree (like Eclipse) have one fewer task to do on checkout of a large project.

Jon.

Source DB?

[Doc Ruby]

How about a SQL DB of source code, particularly C/C++? Just tokenized code, not the text of the source. SELECTing code by block inserts whitespace and comments according to user preferences. The compiler SELECTs code for generation, INSERTing large binary objects into other tables, including executables. Configuration options fill other tables. Scope is per block across the entire project, rather than the ancient file scoping paradigm. The entire filesystem granularity of C/C++ is a straitjacket.

Just the whitespace options would make it worthwhile for me. Then there's concurrency of team access, backups, distributed repositories, versioning, redundancy optimization, and all kinds of other better interfaces for the rest of our toolchain. That's the kind of bionic source infrastructure I'd like to see in my future.