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

Trend vs Financial Backing

[fembots]

To affectively effect the future of software tools, the obvious support must come from the developers, but the obvious support for developers are their sponsors.

At least three of the five points are almost directly targeting at the sponsors, i.e. PHB and friends.

They don't see(care) if a particular system/software/whatever is most powerful, flexible or easy to use, they're looking at things from the business point of view, e.g. which one brings more profit in the next xx years, and which tool they can easily pretend to understand.

So a tool that's business-"sense"-driven, transparent and offers lower TCO is likely to be more favorable.

It's already here...

[dberton]

emacs

Resumes...

[EnronHaliburton2004]

Gosh, these are tools of the future but I have already found several job openings asking for 5 years experience in each tool...

Heh

[Neil Blender]

Good code generators. Yeah, and AI that works too. And flying cars. Utopia is always around the corner. Oh, wait. We have code generators - in India.

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

Completely lacking vision

[beelsebob]

This article, is simply looking at the obvious research efforts on currently used techniques... It has no vision about what might be done entirely differently. It doesn't even consider the potential of things like using different programming paradigms like functional programming or graph programming.

Bob

Are tools a crutch?

[K.B.Zod]

I worry about the increasing power and complexity of IDEs in particular. While they do so much more for developers and have all sorts of whiz-bang features, I bet much of the time the developers themselves don't understand what is going on. They become tied to the IDE, and need it to do all these things because they don't know how to do it "themselves", i.e., without hand-holding.

I develop in Java, and my environment consists of Emacs and Ant, mostly (hardcore, right?). I work with people who use NetBeans and Eclipse, and they keep running into weird problems interfacing them with CVS, or with mysterious classloading "features" that they have, or other obscure problems. Invariably, they don't know how to fix the problems, and I can't help because I never run into them.

I would like tools of the future to be as transparent as possible, to prevent this sort of situation. If tools are so magical that their users don't know the real theory and practice behind them, they end up relying on them to do any work. Their flexibility is very limited, and the tools end up compounding or obfuscating the "real" issues facing them.

Re:Are tools a crutch?

[m50d]

Increasing abstraction is necessarily the way of things. When assembly language was invented, some said it was a crutch for people who couldn't write machine code properly. Ditto for fortran and assembly, ditto for garbage collection, ditto for any feature that makes coding easier.

The next wave is the ides that make the repetitive coding unnecessary. Sure, it makes things slower, but it makes *developing* them faster, and machines are getting faster but developers aren't. I don't think there's anything to be afraid of.

Exactly, tools are a crutch...

[Anonymous Coward]

...and being a developer is a (mentally) tricky job, and all the crutches you can lay your hands on are useful to have if they improve your quality and/or productivity.

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

I've never really got why the die-hards hate any sort of automation in their environments. Why? I understand you want the direct grip on the code... which is exactly what you get in something like Eclipse (well, you have to tell it your source dirs and your classpath, otherwise you can use it as just a text editor with syntax colouring, if that's what you really want).

There are days as a Java dev when a good tool is absolutely worth its weight in gold. 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? Ctrl+Alt+H in Eclipse will tell you. A text editor which doesn't actually understand the structure of your code would require you to do a lot of fumbling around and regexp searching and cross fingers you're not missing anything.

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

Pay-per-use - Bah!

[crimethinker]

I can't quite understand why all the salesweasels think we'll jump at pay-per-use licensing. Here's a thought: I'd like to BUY my tools and OWN them, not be treated like a criminal by a vendor.

Pay-per-use implies a secure authentication mechanism, which then opens the door for abuse of one sort or another. If you are developing a product which will compete against something Microsoft already does (or plans to do), and MS gets wind of it, will there be "technical problems" in contacting the authorization server the next time you start up VC++? What about the SCO v. IBM debacle? SCO claimed they could terminate IBM's license for AIX, and if pay-per-use had been in place, SCO could have flipped a switch on all IBM's customers. Do you think that would have affected IBM's willingness to settle? Yes, they could have got a court order to turn it back on, but how many customers would have been down for a day or two, and said, "Screw this, I'm buying my unix from the people who OWN it!"

Pay-per-use is NOT the wave of the future so long as I have any say in it. When my boss asks me for tool evaluations, I'll always favour the least-encumbered tool. And yes, that means even if it's sub-optimal. We can always make changes to F/OSS stuff to meet our needs, and the freedom to do so, IMHO, more than makes up for the extra work involved.

-paul

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

Left behind

[GCP]

I agree. Anyone who doesn't understand the importance of abstractions is likely to get left behind.

There was a time when you planned to work for your company until retirement, your company had ONE computer, and you used a small set of tools plus technology-neutral algorithmic and domain knowledge to write software.

These days the diversity of technologies that matter is mind boggling. If you don't use something at your employer this month, you'll need it at your next employer next month.

Getting the XML right, getting the HTTP protocol right, etc., etc., involves using tools that automate a lot of things for you. (Libraries are included in what I'm calling "tools".) You just don't have the time or the mental bandwidth to use all of these things quickly and well if you insist on doing everything manually.

IDEs that organize the protocols, handshaking, and plumbing between technologies, that fill in the blanks for you with valid information, that bring the right documentation to you at the moment you need it, that give you one-click builds and deployment, that give you debugging views in every increasing variety, etc., are only going to increase in importance.

I'm with the grandfather poster when it comes to my desire to have tools so simple that you know what's happening when things go wrong. When I can, I use them. But, more and more, it's becoming impossible to do so.

It's just like my father, who mourns the loss of cars with engines so simple and transparent in function that normal people could repair them. For cars, that time has past, and software is going that way, too.