Development Tools

Please, oh please can we have some nicer development tools? So much of the time I see people bicker about this coding convention or that, and performing these transformations and refactorings on code every so often, and I think these thoughts:

We are developers. No one can develop software better than us. And yet we spend all of our time writing software for other people's work (so that we can get paid) but we don't spend any time writing software to improve our own work. Probably because no one will pay us to.
Lots of coding activities are creative. But a lot of other coding activities (notation, verifying method syntax, renaming things) are horribly dull and algorithmic; instead of burning our 150+ IQ brains on these tasks, we should just have tools that do this for us.
Whenever I hear people discuss DevelopmentTools, they almost always omit discussion of the largest and most pervasive type of tools that we use: ProgrammingLanguages. Languages aren't immutable, and it's not impossible to create them or extend them (it's just very difficult. :) But really, they're just tools, and if they contain "features" that slow us down or trip us up 90% of the time, then shouldn't we focus some energy into finding better semantics for those "features?" (Not that I have certain languages in mind, in particular not C++.)

I know that SmallTalk has nice tools available for it... maybe if someone has already written some tools for other languages (Java, for one) then I would be happier. So, I ask:

Could you post pointers to helpful tools that you have written or know of here?
Does anyone know of some good strategies for getting your manager or clients to agree to let you use some company time to create tools that support your work?
Does the concept of AutomatingFrequentTasks? have any place in ExtremeProgramming? Maybe somewhere between YouArentGonnaNeedIt and Refactoring?

-- RusHeywood

I don't recall any of the ExtremeProgramming pages explicitly calling out the fact that there is an attitude of BuildYourOwnTools? it may be buried. Both of the ExtremeProgrammingProjects I have been part of have this McGuyver? attitude of crafting the tools you need exactly when you need them. The first thing the VcapsProject did to become extreme was when we wrote our own version of the TestingFramework. If you don't know a thing well enough to create it for yourself then you will not be able to adjust it to be exactly what you need. Also, when using someone else's tools you will be subjected to a whole lot of junk your project does not need.

Think of it like this: Remember the last StarWars movie, called Return of the Jedi I think. Luke the JediKnight? in training is captured by the evil DarthVader. DarthVader has Luke's captured LightSabre? in his hands and is examining it. He says to young Luke: "I see you have constructed your own LightSabre?, your training is complete." -- DonWells

Why are we still compiling and linking programs to build applications?

Why is the Information Systems department of most companies almost completely unautomated?

Why not a new Paradigm? It's time for a change - ItsTimeToDumpCeeSyntax.

Why can't programs be built in such a way that the semantics of how they are connected together is treated equally to the mechanics. For example: today we use names to attempt to indicate the meaning, context and usage of a parameter of a subroutine or function. From the module's perspective, The names are quite arbitrary. Any other unique symbol can be substituted for any other. The program still works if the parameters are named in a way that is meaningless in its operational context or to its human readers. But what if at every level we were also required to specify the semantics of the interface as well as the mechanics? I'm sure I've never encountered computer languages which require this. What if there were? What would they be like?

What if the right size of a module were

         1 line of code or (
         1 if statement
         1 loop construct
         1 switch statement )

and if statements loops and switches had to call a module with a semantically defined interface for every "line of code". Would this drive human programmers crazy? More to the point, how would a computer program deal with programs structured this way?

What does the fact that this page went unedited for more than a year mean? -PatCallahan People were busy with something else?

From http://mozart-dev.sourceforge.net/ -

Mozart is a logical step in the evolution of development tools. Over time, development tools have improved by offering increasing abstraction, as shown in the table below roughly in historical order, and Mozart is just the next step in that direction.

[Note: this table ignores functional or declarative languages like LISP or Prolog - They are different beasts entirely.]

Technique Languages/Tools Comments --------------- ------------------- -------------------------------------------------------- No abstraction Binary switches No abstraction at all offered to the programmer. --------------- ------------------- -------------------------------------------------------- Assembly Assembler Abstract instructions encoding: ADD replaces 011001. Compilation Fortran Abstract machine dependencies: Fortran programs execute on any machine with a Fortran compiler, and the detailed machine instructions sequence need no longer be known. --------------- ------------------- -------------------------------------------------------- Structured Programming Pascal, C Abstract control flow structures (while, if-else, switch) replace use of GOTO. Abstract data structures (struct, record) replace arrays (where the programmers had to organize data themselves). --------------- ------------------- -------------------------------------------------------- Modular Programming Modula, Ada Abstract relationships between users and providers of services are described through module interfaces. The implementation can be hidden from the user. Structured error handling mechanisms (exceptions) --------------- ------------------- -------------------------------------------------------- OOP SmallTalk, C++, Objective-C, Java, Eiffel, etc. Abstract relation between code and data. The underlying data representation becomes irrelevant. In particular, polymorphism allows different types of data structure to be treated identically by the code using them. --------------- ------------------- -------------------------------------------------------- Generic Programming Ada, C++ Abstract description of algorithm and data structures that correctly specifies type relationships or algorithmic invariants without imposing any particular type or algorithm. --------------- ------------------- -------------------------------------------------------- Concept Programming Mozart, Xroma, XL Abstract description of "concepts" in application code and of operations on application code. Effective meta-programming. --------------- ------------------- --------------------------------------------------------

What about ProgrammingInWiki

See: ThinTools, AspectOrientedProgramming, ScidAndPrism, OpenCpp, BlitzPlusPlus, ConceptProgramming, GccIntrospectorProject, OpenJava, IntellijIdea, NetBeans, EclipseIde and ArgoUml.