Slashdot Mirror
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."
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.
.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.
A lot of developers poo-poo
Raven
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
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
Features include:
FAST
It can be compiled to native code that is just as fast as C.
Type inference
In the function , it knotws that the paramter foo is a string, and it won't even compile code that tries to pass something besides a string, ever. However, it also supports polymorphic functions. For instance, can take anything what so ever as x, since it isn't used in a way that requires a specific type
Garbage collected
No malloc() or free(). Ever. Oh, and it's efficient, and can handle things like circular references just fine.
Technique agnostic
While fundamentally a functional language like lisp or haskell, it has superb support for imperitive and object-oriented programming, including multiple inheritence and all the usual goodies.
Good standard library
Things like printf, regexs, hash tables, etc, are already implemented, and always available.
It really is a great language, and you should investigate it.
A few helpful links
Offical Site
Free online book, best place to learn the language
TODO: Something witty here...
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...
- -
Are you an SF Fan? Are you a Tru-Fan?
You have hit the nail upon its head. At work, I use Vim/ctags/bash/gdb. I am highly effective with them because I have taken the time to learn how to use them. Other developers in my company whine about how hard they are to use, and petition management for some super expensive supertool that will release them from the burden of learning how their tools work. If they are successful in getting management to buy these tools for them, I predict that I will still be more effective than they are and that they will still come to me for help finding obscure bugs that they can't find themselves because they don't want to learn how anything works.
I think that we will see a movement to better languages than the currently ubiquitous C-like and Java-like ones (heck, even VB.NET is Java-like these days). These languages lack flexibility and get in the way of rapid application development and adapting to changing requirements. I think the world will move to more dynamic languages.
Also, with multiprocessor systems, clusters, and other forms of parallel systems becoming more and more common, I think we will see an increased usage of languages and paradigms better suited to that than the current imperative ones.
The tools of the future, then, will obviously be the tools that we write to support these new languages and paradigms. Dynamic languages can be optimized by figuring out which parts are static and leaving out the dynamic checks for those. Or programs can be optimized at runtime, by seeing which execution paths are most frequently taken and speeding up those.
Please correct me if I got my facts wrong.
Here's my set of software predictions. Some more detail to fill in for that other guy's blog entry.
Here we go:
Don't think of them as crutches, think of them as enablers. If the environment is well designed, the benefits of a technology that enables more people to do a particular task will almost always outweigh the costs.
For example, if the environment is generating weird problems when interfacing with cvs and it's hard to figure out what's wrong, then there are two problems. First, the environment is apparently difficult to integrate with cvs (this was my experience with eclipse). Second, when a problem occurs, the environment is not giving the user the requisite information to solve the problem.
Shrug, even with these kinds of design problems, the benefits will still outweigh the costs for many people... and the technology will only get better.
>However you have to be a master of the tool, rather than its slave unsure of how it does its magical stuff.
;-) 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).
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
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.
.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.
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
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.
Table-ized A.I.
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.
This is a combination prediction/wish list:
Microsoft will continue to integrate third-party tools into their Visual Studio suite, demolishing the companies that manufacture them. This will suck for third-party tool builders, but it'll be pretty cool for us developers. Here's what I see them putting in:
* Expansion of their project templates to include a comprehensive set of patterns for just about anything you might want to do in an enterprise. Got a project coming up? Click an icon and you'll be given a complete set of skeleton code for you to modify. Useful, but dangerous: more productive developers = fewer developers.
* expansion of modelling tools as the VB guys get more comfortable with object oriented programming. Integration of UML tools with Visual Studio.
* Expansion of tools that allow managers to directly code business rules using prebuilt code blocks. This is going to be a big deal; everyone's already scrambling to build it.
* Integration of unit test tools with Visual Studio as Microsoft catches on to the whole test-driven development thing. Right now, you've got to hand-build your tests. Not for long...
In the JAVA world, I've got a wish list, but I think it's pretty realistic:
* Sun, under pressure from Microsoft's ease of use, will create a new GUI layer that is simpler than Swing and AWT, works more quickly, and provides 90% of the functionality programmers use the most. Swing and AWT will still be available, of course, but we'll have this easier option and it'll get integrated into IDEs as a project type, making everyone's life easier.
* Java IDEs will continue to embrace visual development, making life easier on everyone.
* One thing I think would be nice would be for IDEs to incorporate patterns as templates that you can drop into a project. So, say, if my main GUI is MVC, I can drop an MVC template into my project, and other templates in for specific parts of the backend... Sort of a quickstart, right?
* And, since Microsoft is going to do it, some of the Java IDEs will too: prebuilt project skeletons for common business needs, and tools to easily build business rules so Managers can handle all the client-meeting shit.
I know, my predictions are boring as always. I'm not a revolutionary, I'm a code monkey!
Farewell! It's been a fine buncha years!
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.
--
make install -not war
Um, what is "graph programming"?
If you hear that all the time, aren't you kind of curious what all these people are talking about??
.. the framework he wrote is open source.
Here's a site I use to manage big important projects, written entirely in Ruby by ONE PROGRAMMER in about a month: http://www.basecamphq.com/
The whole site is something like 4000 lines of code. I've seen XML configs for Java ORM layers longer than that!
Here's the programmer's blog: http://www.loudthinking.com/
Search around for the comments from many Java programmers who have taken a look and realized they've been wasting their life.
Numbers don't really mean anything. If I can work more effectively in a programming language that nobody else uses, I will. It doesn't hurt that Ruby is very easy to read and learn and is becoming more popular by the day (I believe Gentoo.org is dropping AxKit in favor of a 100-line Ruby program to render their web site's XML).
But "numbers" aren't a valid argument. PHP is extremely popular, but only because so many *inexperienced programmers* use it. It's a rotten language.
I would say 50% of my work is in Ruby, the rest in more boring languages. If the client doesn't care, I use Ruby and I finish most things in a few *days*. I don't know what "important" means, but I have Ruby code running that medium-sized business *depend* on. I bet in 5 years, you'll see Ruby in the big companies too. Amazon.com has asked some Rubyists to come over and give presentations, for instance.
Again, if you have to use a code generator rather than just writing everything in one language, you're doing more work, and more *complex* work than I am. You like doing less work, right?
Do yourself a favor, learn a little about these other languages and decide for yourself.