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

I've already seen one post dissing code generators

[Jack William Bell]

I've already seen one post dissing code generators, but I expect to see that general class of software development tool to greatly increase in popularity over the next couple of years...

Why? Well mostly because they are getting better. Many of the newer code generation tools are very flexible and have some ability to preserve changes to the code; making them easier to fit into real development cycles. Also we are already seeing 'just in time' code generation as an optimization tool; that functionality, when combined with runtime environments like the Java Runtime or the CLR, is going to get easier and more powerful.

So, in the end, we may see developers tweaking code generation templates and filling in design forms/creating design diagrams in order to create some classes of software -- business software and game levels would probably benefit greatly from this scenario.

Obviously there are other classes of software development which would see much less benefit...

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).

Buzzwords, psychology, and viewpoint relativity

[Tablizer]

There have been a lot of attemps and experiments since the early 1970's to improve the software development and management process. However, there has not been any magic bullet. Most improvements are incrimental and often disputed.

Graphical tools have generally proven ineffective because there is no one "proper" viewpoint. All the possible viewpoints needed by different departments or situations cannot fit onto the same sheet of paper or screen without being messier than the coded counterpart.

Another thing the article mentions is getting closer to how the user thinks about things. The problem with this is that everybody thinks differently. There is no one "right" way to think and the variations are wide. Plus, people with different ways of thinking have to use the same software or same information. Delivering different viewpoints of the same info leads to the next item:

One area I would like to see explored more is divorcing presentation from meaning (DPFM). Rather than use linguistical syntax to store algorithms and attributes, if such information was treated more like a database, then one's view of the algorithms and information could be altered to how a given developer or user wants to see it.

It is roughly similar in concept to Microsoft's .NET run-time engine in which different languages compile to the same thing, but perhaps use relational and more declarative techniques instead of the map-based "database" and imperative-intensive approach favored by OOP proponents and languages. OOP is generally a code-centric way of thinking and is not very condusive to DPFM in my opinion. It is a fight that has to be settled one of these days.

Hierarchical approaches to managing such information have generally failed to scale. The real world and its change patterns are not really tree-shaped. Philosophers have known this for quite a while, and computer scientists keep rediscovering it the hard way.

One would be querying info instead of relying on file and code browsers so much. Some things, such as math and Boolean expressions, are still best represented as code (although they don't have to be stored that way under DPFM), but the size of such units can perhaps be reduced, similar to how code is reduced to mostly individual event snippets in event-driven UI systems. But to study event snippets, you query for them if there is no UI click-and-point approach available for a given search.

Yes, all this may take more horsepower, but better abstraction usually does take more.

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.

Re:CVS Integration

[Darth_Burrito]

Ooh - sorry for responding to myself but I thought up another. It might be nice if there was more security/workflow in a version control system.

One simple example of security might be something simple like - you do not have permission to edit this file. I bet this can already be accomplished with file system permissions and what have you.

But what would be even better would be for the environment to support basic workflow style processes. For example, if Bob is the expert on the Data Access Layer, and you make some changes and check them in, Bob should receive a notification with a note from you and perhaps and automagically generated report detailing what interfaces changed. This same kind of tactic has been employed on some wiki's to reduce vandalism. It could also be implemented as an approval process.

Moving along in that workflow direction, it also might be nice if the development environment was formally aware of the to-do list. In other words, if we bring in more version control functionality, why not add project management integration.

You might start the day by opening a task. Then you edit several files accomplishing the task. The changes you made in the version control system become associated with the task as do a record of the files that were changed. If someone else needs to see what changes you made for a particular task or bug or project, they can drill down from the top instead of trying to figure out what you did by looking at comments in version control.

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.