Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Software Tools of the Future 337

Posted by michael from the keyboard-probably-the-most-important dept.
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."
This discussion has been archived. No new comments can be posted.

Software Tools of the Future More

Software Tools of the Future

Comments Filter:

  • Trend vs Financial Backing (Score:5, Insightful)

    by fembots ( 753724 ) on Sunday November 21, 2004 @02:34PM (#10882089) Homepage
    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.

    • Re:Trend vs Financial Backing (Score:2, Funny)

      by Anonymous Coward
      "To effectively affect".

  • It's already here... (Score:5, Funny)

    by dberton ( 178101 ) on Sunday November 21, 2004 @02:34PM (#10882091)
    emacs

  • Resumes... (Score:5, Funny)

    by EnronHaliburton2004 ( 815366 ) on Sunday November 21, 2004 @02:35PM (#10882096) Homepage Journal
    Gosh, these are tools of the future but I have already found several job openings asking for 5 years experience in each tool...

  • Heh (Score:5, Funny)

    by Neil Blender ( 555885 ) <neilblender@gmail.com> on Sunday November 21, 2004 @02:37PM (#10882104)
    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.

    • Re:Heh (Score:3, Insightful)

      by ScrewMaster ( 602015 )
      When I was younger, my brother and I we're responsible for shoveling show out of the driveway. We lived near Chicago at the time, and survived a couple of blizzards and other examples of Midwestern winters through the sixties and seventies. One year (1977, I think), after removing a four or five foot thick layer of drifted snow from the driveway and front walk, we asked our father if he would consider buying a snowblower. His response was, "Why? I already have two."

      We never did get that snowblower.

  • Usability in Non-MS Environments (Score:5, Interesting)

    by The Raven ( 30575 ) * on Sunday November 21, 2004 @02:38PM (#10882114) Homepage
    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
    • Have you ever worked with QNX Momentics [qnx.com]? It can be used to build programs in a variety of languages for a variety of platforms. I found it a lot more comfortable than MS Visual Studio .NET. Also, it's not restricted to just one platform. It costs quite a bit, though.
    • part of the reason for their popularity is the quality of their development tools

      And part of the reason for the quality of their development tools is that the languages are easy to parse, which in turn makes it easy for a tool to understand the code well enough to provide useful assistance. C++ is a nightmare to parse compared with C# or Java.

      Another part of the reason is the Pointy-Clicky GUI Builder, of course, but that part I most definitely would not want to see emulated elsewhere. Addiction to the P
  • Why, exactly, should I take the word of a guy who works for Rational? The people who want to SELL me the tools to do these things?

    • Re:dubious (Score:5, Interesting)

      by Dolphinzilla ( 199489 ) on Sunday November 21, 2004 @02:50PM (#10882173) Journal
      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

      • Re:dubious (Score:2, Insightful)

        by Tablizer ( 95088 )
        One group at work proudly used the Rational tools to generate some code - it was the most obscure code I had ever seen

        Somebody will probably have already said it, but generally code generation is a sign that your language or abstractions are not powerful enough. Code generation takes a more compact form of information and creates a less compact result (generated code). One should use the more compact form to tell the software how to operate, not turn it into bloated code. It is almost like turning a tab
    • I've spent the last two years in a OOD project with a team of 5 - 15 SW Engineers. I can't speak for the Rational XDE tools, or Rose RT, but Rational Rose really really sucks bad. It's the kind of tool that will make you claw your eyes out.

      Any company that can sell a tool like this and claim to be in the buisness of "improving" your software process and productivity has absolutely no credibility with me.

      Rose has Modal, non-resizable, dialog boxes that display paths. If the path doesn't fit in the box i

  • Completely lacking vision (Score:5, Insightful)

    by beelsebob ( 529313 ) on Sunday November 21, 2004 @02:40PM (#10882126)
    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

  • autotools (Score:3, Funny)

    by sik0fewl ( 561285 ) <xxdigitalhellxx&hotmail,com> on Sunday November 21, 2004 @02:41PM (#10882130) Homepage

    As long as automake and autoconf aren't software tools of the future, I'll be happy.

    I'd like to see more projects moving towards SCons or jam.

  • Eclipse! (Score:3, Informative)

    by JKR ( 198165 ) on Sunday November 21, 2004 @02:44PM (#10882141)
    I believe Eclipse [eclipse.org] will become a major part of software tools of the future, simply because the Rich Client Platform initiative brought in for Eclipse 3.0. This makes it easier to create custom Eclipse API applications, compared to version 2 which was a much less modular design.

    My employer is working on an Eclipse-based development environment for their Cascade [criticalblue.com] product, instead of developing yet another custom environment from scratch with all the incompatibility and test overhead that that entails.

    Jon.

    • Re:Eclipse! (Score:4, Informative)

      by eenglish_ca ( 662371 ) <.eenglish. .at. .gmail.com.> on Sunday November 21, 2004 @03:09PM (#10882272) Homepage
      Eclipse has a great design no doubt. Automatic code generation through the use of omondo was very helpful in the work I have done with it. However, being a program written in Java it suffers from serious lag even with Java 1.5. It just cannot keep up with Anjuta or KDevelop in terms of raw speed. This may not seem like a serious impedement but it can make working with it quite irritating. Given that using java does give it platform independence, there are solutions like gtk for windows and mac or wx windows in terms of the gui.

      Additionally, I have found it quite buggy when running it on Solaris and Redhat based systems at school where i've primarily used it. I shouldn't have to delete my workspace directory just to get it to run as I have needed to.

      These issues need to be resolved before it can be considered seriously.

      • Hmmm. We've used every milestone in the 3.0 series (except one) on Windows XP and Debian (sid) boxes, and not had problems. The Linux GTK version is even fast enough over remote X sessions to a Linux server using the cygwin X-server.

        You do know that Eclipse uses SWT, not Swing, and SWT uses native widgets (so GTK or Motif on Linux)?

        Admittedly all the extra features in Eclipse 3 have made it slower than 2 (and I almost prefer the v2 UI, it's cleaner and faster), but nothing is free...

        Jon.

        • And then there are people like me prefering emacs (or another simple editor) over the feature-bloat of these graphical development tools and debugging mostly with print-statements which get the job done and can be used in any environment (and almost any language) without reading pages and pages of manuals to understand the debugger.
  • I remember there was a type of object based visual language for programming/scripting on the Amiga, I can't remember what it was called. But I always thought that if someone could standardize that and make it more available and versatile that it would be the programming language of the future. And that it would allow everyone to make programs.

    It's also kind of like in Star Trek: TNG, the episode where Dr. Crusher has to program the computer to calculate who all those speices DNA will map out to the star

    • Re:On the Amiga (Score:2, Informative)

      by starbird ( 409793 )
      AmigaVision it was called. It came with my A500, but without a HDD and 2 megs ram it was pretty useless.

      I saw some pretty impressive presentations done with it.

  • Make it simple (Score:5, Insightful)

    by jackb_guppy ( 204733 ) on Sunday November 21, 2004 @02:49PM (#10882168)
    0. Alan is a Distinguished Engineer at IBM Rational

    translates to: Buy Rational Rose - scaratch that see 5... Rent Rational Rose

    1. Connecting business with IT: Business-driven development

    translates to: What do you mean that it will take 8 weeks to rewrite? We are already selling the service, you must change it tonight or be fired.

    2. Greater transparency in the software development process: Auditing, traceability, and accountability

    translates to: We must find some one else to blame, because we don't need to test the part, the system drew it that way.

    3. RAD using new programming models

    translate to: do not design first. build it first , then find out if it mets the need. Wait that is why the want to find someone else to blame it on.

    4. Collaboration among individuals and teams

    translates to: Talk to each other. Stop work in the castles with moats that where built between managers!

    5. "Pay-per-use" software tools: New licensing and subscription offerings

    translate to: We need more money, so we are following M$ model, charge for everything at least twice. Remember: give away the razor, sell the razor blades. Wait that is what Lexmark is doing now.
    • ``do not design first. build it first''

      Actually, that's a very good way to build software. You start with a simple program that does one thing. Then you add some features and make it more flexible. You keep doing this until it does everything you want. In the meantime, you rip out and rewrite parts that could have been done better.

      Why not design it right to begin with? Because you can't. You always encounter little details during the implementation that you didn't think of during the design. Moreover, if

      • Re:Make it simple (Score:3, Insightful)

        by Tablizer ( 95088 )
        Your viewpoint sounds like Extreme Programming (XP) philosophy. I generally disagree with it. One can design pretty close to needs if given enough time to study the problem.

        Good designers can pull it off. The problem is that fad-chasing buzzword-oriented Bozo's usually create giant messes because they are using dogma instead of brains to build software. Perhaps XP is for bad designers, but not every designer is bad.

        And, XP is expensive because it reinvents a lot of small wheels along the way that a good a
        • I generally disagree with it. One can design pretty close to needs if given enough time to study the problem.

          I have to disagree with your disagreement. The main problem is (at least in my experience) that the customer doesn't want what he told you he wants, but he won't realize that until you show him what he asked for. I'm not advocating XP (pair programming would drive me insane), but it's critical to be able to alter the design even after lots of implementation work has been done, because you *will* be
        • I don't know much about XP; What I posted are just my own views. Addressing your comments:

          ``XP is expensive because it reinvents a lot of small wheels along the way''

          You mean that you end up writing and rewriting parts of your code? Not very often, if all is well. Typically, there are components that you can re-use in your project. After they have been used in a few projects, they are good enough that they don't need to be rewritten. And sometimes you do get the design right the first time.

          ``XP also requ
      • All things in moderation. In my experience, if you concentrate too much on the design, then you end up with something that's inflexible and hard to change when (generally not if) the requirements change.

        On the other hand, I've seen a lot of complete messes that happened when programmers just leapt straight in and started coding without doing any design work at all. Talk about spaghetti.

  • O'Caml....the future today (Score:3, Interesting)

    by Tyler Eaves ( 344284 ) on Sunday November 21, 2004 @02:51PM (#10882176)
    Objective CAML is the language you really should be using.

    Features include:

    FAST

    It can be compiled to native code that is just as fast as C.

    Type inference

    In the function
    let hello foo = "Hello, " ^ foo
    , 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,
    let gimme_a_one x = 1;;
    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 [ocaml.org]

    Free online book, best place to learn the language [inria.fr]
    • I played with OCaml for a good length of time, considering whether to make it my next language for everyday use. I should also preface things by mentioning that I'm into graphics and rendering; I need fairly heavy duty numeric performance. I've also been thinking a lot about what would be my perfect language, so this has been on my mind of late - I've been reading up on Programming Language Theory papers and texts and contemplating drafting my own language spec and trying to bootstrap a compiler.

      OCaml an
      • Thanks for the interesting reply!

        I must admit I'm pretty much a rank newbie at O'Caml, but I thought I'd try to bring in a few more converts ;). I certainly don't think it's perfect, but basically, to me, it gets more right than any other language I've found.
    • i've been meaning to learn objective caml, just because i hear a lot of good things about it. it really reminds me of ruby (features wise) without the scary syntax.

      i think we need to see languages like objective caml, ruby, lisp, scheme, etc become more mainstream. these languages support extremely dynamic capabilities that languages like java, c, and c++ just can't do without a lot of trouble or huge workarounds.

  • Are tools a crutch? (Score:5, Insightful)

    by K.B.Zod ( 642226 ) on Sunday November 21, 2004 @02:51PM (#10882179)
    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? (Score:5, Insightful)

      by m50d ( 797211 ) on Sunday November 21, 2004 @03:07PM (#10882264) Homepage Journal
      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.

      • Left behind (Score:5, Insightful)

        by GCP ( 122438 ) on Sunday November 21, 2004 @04:11PM (#10882635)
        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.

        • The problem here is that car mechanics still understand the whole engine of a modern car. Developers ARE the mechanics, not the normal people, if the developers don't know what's going on (or going wrong) we have too much abstraction. We should remove some abstraction until a time where the lower abstraction levels are guarranteed to work 100% correct. Then we can start to build additional abstraction above them.

        • Re:Left behind (Score:3, Insightful)

          by iabervon ( 1971 )
          The thing is that, previously, each increase in abstraction was either done by writing in a higher-level language or by using a nicer library in the same language. IDEs, on the other hand, move from writing code in any language to carrying out an IDE-specific process which generates a chunk of code which is then part of the project without anyone having written it.

          The real solution isn't IDEs. It's adding language features that let you write the code more simply without a lot of boilerplate, and APIs which
      • Your analogy to the jump from machine code to assembly, and from assembly to higher-level languages, is spot on. As I was finishing my original post I thought of that, but kept going anyway. :)

        And so I guess the real question is what makes those tools really great? I know I couldn't do without compilers, nor could most others, and develop anything as good as I can with them. Chris Sawyer is one exception ... I think he did Roller Coaster Tycoon in straight-up assembly.

        Perhaps it is because they complete

      • Increasing abstraction is necessarily the way of things.

        Better languages give you increasing abstraction, which is a good thing. But tools don't really give you increasing abstraction, they just try to hide complexity.

        The next wave is the ides that make the repetitive coding unnecessary.

        That has also been the previous wave and the wave before that. In all those waves, people tried to get by with tools, but eventually they realized, they had to move to new languages. It's going to be the same this t

    • Exactly, tools are a crutch... (Score:5, Insightful)

      by Anonymous Coward on Sunday November 21, 2004 @03:11PM (#10882289)
      ...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... (Score:5, Interesting)

        by Beek ( 10414 ) on Sunday November 21, 2004 @04:03PM (#10882596) Homepage
        >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).
        • IDE != Automation

          Automation means Scriptability which is not possible in most IDEs I know. They let you use their integrated scripts but when you want to make a custom change no IDE-Developer thought of you are at the same point as in a simple text editor. With Emacs or make or the shell I can write small programs to make almost any change in my programs I want. That is true automation.
    • You use Emacs and Ant and think you're close to the metal? What sort of lunatic are you?

      Emacs is certainly a mature product, so it's hardly surprising that its CVS support is rock solid. But in no way, shape, or form is it less complex (unless the Eclipse SDK acquired a LISP interpreter that nobody's told me about).

      Eclipse support for CVS was patchy to start with and is pretty solid as of the 3.0 release, but that's because Eclipse is essentially a work in progress. I use it myself and adore it, but it ha
      • Eclipse has CVS problems because they write their own client and now have to keep it up to date and bug compatible with the various CVS forks (yes, Tony, I mean CVSNT!).

        CVS apparently is still not featureful enough to not have to rely on parsing the text output of various commands, and not stable enough that that text format doesn't keep changing (like we just discovered, Debian (testing) runs CVS 1.12 and Eclipse 3 only officialy supports CVS 1.11 due to some textual output change, WTF???).

        Subversion suppo

    • 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 occ

    • Re:Are tools a crutch? (Score:3, Insightful)

      by lostguy ( 35444 )

      I develop in Java, and my environment consists of Emacs and Ant, mostly (hardcore, right?).

      Not to be snotty (oh, come on, this is /., so I'll have to snot this up a bit.) but you're probably using a tiny subset of the language if you're relying on your understanding of the SDK. You're probably wasting a lot of time trying to remember if it's put() or add() or addElement(), all things your IDE should tell you, and you shouldn't need to store in your brain.

      The people I've worked with who insist on using vi

  • ...will run under emacs.

    Emacs, baby. All the way.
  • From the statement "It looks at how to improve software development efficiency through visual modeling, generating code from abstract models, and systematic reuse." in the introductory remarks, I am sure Mono foots the bill here. Go Mono! I hope those in charge of filing for patents have already done so, or are about to do so.

    Cb..

  • I've already seen one post dissing code generators (Score:4, Interesting)

    by Jack William Bell ( 84469 ) on Sunday November 21, 2004 @03:11PM (#10882283) Homepage Journal
    I've already seen one post dissing code generators [codegeneration.net], 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...
    • 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.

      The way I look at it, there's only one good kind of code generator: the kind whose output I almost never look at and never, ever tweak. Compilers, for example, are a kind of code generator that I love.

      The other kind of code generator strikes me as just half implemented. Somebody has come up with some sort of interesting abstraction, but th
      • I think you missed my point: Code generators have improved so that the cost-of-change has gone down! At one time they were really only good for getting started by spitting out piles of repetitive, uninteresting code; afterwards you might tweak the generated code or have to change it for a bug fix, so you didn't want to regenerate. This is no longer entirely the case.

        Check out some of the links here [del.icio.us]. Especially CodeWorker [codeworker.free.fr].

        Mind you I am not entirely a fan of code generators myself, having been forced to use

  • Pay-per-use - Bah! (Score:5, Insightful)

    by crimethinker ( 721591 ) on Sunday November 21, 2004 @03:20PM (#10882332)
    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

    • +1000 Insightful
    • 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.

      I'm just trying to imagine a self respecting Carpenter who rents his hammers, chisels and lathes only as he needs them...

      Nope, my imagination just doesn't stretch that far.

      Jedidiah.

  • Better Languages (Score:3, Interesting)

    by RAMMS+EIN ( 578166 ) on Sunday November 21, 2004 @03:20PM (#10882336) Homepage Journal
    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.
    • I never understood why someone would design a language with a C-like Syntax today. Okay, C has its uses but it definitely hasn't the best syntax I have ever seen. Most modern scripting languages like Ruby and Python have a relatively easy, short syntax and focus on integrating proven tools like regexp, xml-parsers,getopt... into the language to ease common tasks like string-parsing and config-file reading and writing. In Java most of these tasks still require pages of code which were spend better elsewhere

  • Fundamental problems in the items (Score:5, Insightful)

    by Todd Knarr ( 15451 ) on Sunday November 21, 2004 @03:23PM (#10882353) Homepage

    Hist first item shows a fundamental problem right off. I've dealt with projects that were driven directly off the business requirements. The problem is that they were driven directly off the business requirements. The next project was for a slightly different set of business requirements, and because they were slightly different none of the work on the first project could readily be transferred over. By contrast in other projects I managed to divorce the business requirements from the actual work, and I could step back and instead of addressing the business requirements create tools and facilities that I could then use to address the business requirements. The next project in that line, with it's slightly different requirements, required only some relatively easy extensions to the existing work and we were in business. It took a fraction of the time. Most of the problems with business-process-driven software design and development, IMHO, is that it's too focused on the end result to be good at front-loading the solving of meta-problems that can speed up later work because solving the meta-problem doesn't provide any immediate advantages for the problem immediately to hand. In mathematical terms, it looks for a local maxima at the expense of an even better global maxima that's on the other side of a minima.

    His second item about auditability also aims at the wrong point. When, for example, designing the control software for an ABS system, the goal is to have it work correctly. All else, auditability, certifications and such, are supposed to be means to insure the goal is met. That implies that you judge their usefulness not on their own but on how well they help meet that goal. He's aiming at those things as goals in themselves. ISO 9000 falls into the same trap: it concerns how well you followed a process and not how the final results turned out. This is useful if someone at the top has their eye constantly on the final result and is willing to boot the process out regardless of how thoroughly it complies with ISO 9000 if the end results aren't meeting spec, but all too often the process becomes the goal and a shield against actually being judged on the end results.

  • Radical Innovation (Score:5, Interesting)

    by LionKimbro ( 200000 ) on Sunday November 21, 2004 @03:24PM (#10882356) Homepage

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

    Here we go:

    • Refactoring Browsers [c2.com] - 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 [taoriver.net] - Is it just me, or is publish-subscribing becoming more important? That's because we're going to component systems.
    • Tuple Space(s). [c2.com] 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. [w3.org]
    • 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
    • Refactoring Browsers were a radical change 2 years ago, and improved coding immensely.

      But the claim that they "aren't commonly used" is bunk. They are in very common use today. Eclipse, IDEA, JBuilder, etc. Java IDES have made a huge leap in the last 2 years, and they rock.

      They succeeded because they weren't trying to reinvent programming. They just aim to make coding easier and better.

      Why non-Java IDEs haven't caught up, I don't know. The worst part by far of having to deal with C++ is that these d
      • Partly the problem is that C++ is a pain in the ass to parse - for example you need whitespace to stop nested templates <T<A>> from mis-parsing as the stream operator >>, and if there's a syntactical error it's harder to recover gracefully and carry on parsing. This makes building fast parse trees in memory and maintaining them as the user keeps on typing harder than, say Java (notice how generics in Java 1.5 correctly parses <? extends List<Integer>> without needing magic whit
      • By "commonly used," I mean: "just about everywhere."

        If the Java people are using it right now, then that's a good sign.

        The Internet was huge and big in 1993. In 1997, my mom used e-mail regularly.

        E-mail is now in common use.

        I'm eager for refactoring browsers to be in common use.

      • Why non-Java IDEs haven't caught up, I don't know.

        Maybe Java has a language design so bad that you need these tools more than with other languages. Java lacks a certain kind of consistency in is API that is sometimes called the Principle of least surprise. In Ruby e.g. you want to sort an array, you call arrayname.sort, in Java you call Collections.sort(arrayname) after searching the documentation where the latter is speed up by the use of an IDE but the problem wouldn't even exist if the language design w

    • Your "radical innovation" has been around for several decades; it's only that the industry mainstream is finally catching on.

      (Calling MFC a "real UI advance" is a howler.)
    • Social Help Documentation...
      That would be a nice idea however I doubt that it will be integrated into programming languages/IDEs from people who think Javadoc is a good idea even though you can't navigate Sun's own Javadoc-Collection in a useful way without using google to search it (even concerning Classes that have similar functions like the different Time and Date Datatypes).

  • MDA, Code generation, and the like (Score:3, Informative)

    by SlySpy007 ( 562294 ) on Sunday November 21, 2004 @03:37PM (#10882418)
    As systems beome more complex and the amount of code required to do it grows, we need to actively find new strategies to help us create better software faster. Development activites also need to be tailored to suit other related activites, most notably verification and validation. MDA is a good step because it allows the developer to focus on the higher level concerns of the system, and step back from some of the code level concerns. Code generators and transformational systems are an excellent counterpart -- if you have a modeling language with a formal syntax and well-defined semantics, you can easily write very powerful transformational tools to spit out anything you like -- models in a different representation, code, test cases, graphs...the list goes on. A colleague of mine has a saying "No more software engineers"; I personally think he's on to something. We as a profession spend altogether too much time worrying about code-level concerns and the like, when to make more robust, fault-tolerant, higher-performance systems we need to spend more time focusing on higher-level system concerns.

    Some links to check out on these topics:

    Semantic Designs (makers of a very powerful, generic transformational environment) http://semdesigns.com/ [semdesigns.com]

    Link to Nic Rouquettes slides from a talk on MDA at the UML 2003 conference) http://ase.arc.nasa.gov/uml03/rouquette.pdf [nasa.gov]

    Link to an article from ACM Computer magazine (last january I think) about MDS, and project at JPL which aims to incorporate some of these ideas into the design of a robust, re-usable flight software platform http://www.computer.org/computer/homepage/0104/Reg an/r1059.pdf [computer.org]

    • Funny, in my experience high-level tools make me worry about code-level-problems more than low-level ones do. High-level-tools often do something almost but not exactly the way I need them done and then I spend more time on this small difference than I would have spend on the whole manual code writing thing. I think however that domain languages and special parsers for them are useful (like lex and yacc e.g.) if you can decide yourself when NOT to use them and when they integrate nicely with manual code-wri

  • Buzzwords, psychology, and viewpoint relativity (Score:4, Interesting)

    by Tablizer ( 95088 ) on Sunday November 21, 2004 @04:07PM (#10882615) Journal
    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 (Score:5, Interesting)

      by JKR ( 198165 ) on Sunday November 21, 2004 @04:11PM (#10882640)
      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.

  • I would be interested in seeing better version control integration in development environments. In a traditional approach we have several distinct tools. There is usually a repository with a version browser, a diff viewer, and a your development environment.

    If you want to see a the previous version, you often have to switch to your repository tools. If you want to see comments submited with a version, you have to go to the repository tools. If you want to compare the previous version to the current

    • Re:CVS Integration (Score:4, Interesting)

      by Darth_Burrito ( 227272 ) on Sunday November 21, 2004 @04:33PM (#10882785)
      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.

  • I'm a developer; here's my prediction/wish list (Score:3, Interesting)

    by crazyphilman ( 609923 ) on Sunday November 21, 2004 @04:40PM (#10882835) Journal
    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!

  • People will develop software like that right after we get world peace, have completely switched to renewable energy, and everybody exercises for 1h and flosses and brushes three times a day.

  • Source DB? (Score:5, Interesting)

    by Doc Ruby ( 173196 ) on Sunday November 21, 2004 @05:32PM (#10883214) Homepage Journal
    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.

  • Tools that are simple to use are complicated to develop and enhance.

    The simpler the tools are to use, the more complex the projects are that they are used to create.

    In addition, simple tools become more complex over time as new features are added and they are used to solve more complex problems. Whole sub-systems are reduced to a tool, which makes the resulting systems simpler at the expense of more complex development tools.

    I don't see any way to avoid complexity. It just gets moved to a different level

  • Still trying to replace the programmer (Score:5, Insightful)

    by Brandybuck ( 704397 ) on Sunday November 21, 2004 @08:23PM (#10884244) Homepage Journal
    I see they're still trying to replace the programmer after thirty years. This is nothing new folks. Let me explain the situation. The people running businesses hate programmers. Maybe it's because we have real degrees instead of MBAs, or maybe it's just because we didn't join the right fraternities. But they just don't like us. So they keep trying to come up with ways to fire all the programmers.

    It all started with Cobol, the language that didn't need a degree to use. In more modern times it was Visual Basic, the language that even monkeys could use. You've got entire programming environments where all you do is drag and drop stuff around the screen. Rational [sic] salesmen claim you can generate your entire application from UML.

    For some generic "fill in the blank" type applications, they're correct. For maybe half (wild ass guess) of applications out there all you need is to wire a form into a database. But what about the other half of applications? And what about the remaining 90% of software that is NOT an application?

    At the core of Google is a Damned Big(tm) database, but does anyone in their right mind think Google could ever have gotten off the ground without real programmers writing real code in a real language? Or what about the Linux kernel? Does anyone think it could have been created with a CASE tool? Is there anything in GNOME, KDE or Mozilla that could have been automatically generated from UML? Would you feel safe driving a car which had an ignition system written in Visual Basic?

    Programmers aren't goin to go away, no matter how advanced the tools become. They'll make the programmers' jobs easier, but they won't replace them.

  • Oh, please. Buzzword overload. (Score:3, Insightful)

    by Animats ( 122034 ) on Sunday November 21, 2004 @11:22PM (#10885061) Homepage
    From the article:
    • The importance of understanding the business context for IT investment has never been more obvious than it is today. More organizations are recognizing the role of IT as a determining factor in the efficiency of their operations, and a bottleneck in their ability to innovate. I am spending a lot of time with customers who want to explore business alternatives, drive IT projects more directly from business needs with well established business goals and ROI, choreograph services to realize their business processes, and monitor those services in execution to relate operations to the needs of the business. Support for that flow (in its myriad variations) is essential. As we use the current generation of tools in this context we are seeing the emergence of new roles, usage scenarios, and support needs. The lessons from this work are leading to a complete refactoring of tooling capabilities.
    Let's try that again, in a different context.
    • The importance of understanding the business context for office furnishing investment has never been more obvious than it is today. More organizations are recognizing the role of office furnishings as a determining factor in the efficiency of their operations, and a bottleneck in their ability to innovate. I am spending a lot of time with customers who want to explore business alternatives, drive office furnishing projects more directly from business needs with well established business goals and ROI, choreograph services to realize their business processes, and monitor those services in execution to relate operations to the needs of the business. Support for that flow (in its myriad variations) is essential. As we use the current generation of tools in this context we are seeing the emergence of new roles, usage scenarios, and support needs. The lessons from this work are leading to a complete refactoring of tooling capabilities.
    See? It's a totally generic statement.

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close