IEEE Software Special Issue: Development Tools - Revision history

Shelsen: /* New proposal outline */

2008-04-13T16:45:33Z

New proposal outline

← Older revision		Revision as of 18:45, 13 April 2008
Line 65:		Line 65:
	** XML as a standard can be processed in many ways (XSLT, XQuery, DOM, SAX, ...)		** XML as a standard can be processed in many ways (XSLT, XQuery, DOM, SAX, ...)

	=== New proposal outline ===

	SPH: I see DDS's point in the sense that it is probably better if we could make the article interesting by not just being historical (most of our readers will be familiar with the history of different tool landscapes). But it would be nice if we could motivate Arthur's observation that SDTs have evolved to source-driven tools and at least give a speculative explanation of why this might be (open source and distributed development). I would find that interesting to read! Similarly I would not mind an explanation why graphical and/or higher-abstraction tools (and languages) still have not made it. This would make sense because a lot of people are hyped about MDD-like environments, but reality seems to be driving to something else. The trend to quality is ok for me. In fact, that includes a lot of other kind of tools such as profilers, heap dump analysers, runtime maintenance tools (like JMX), etc. I guess this helps referring to the articles in the issue. Diomidis has a point in that we could try to focus on new challenges and trends beyond the current state-of-the-art. The biggest I can see right now is multiprocessing and distributed development. Although there we have a danger writing about programming language paradigms, not about tools. And we really should try to focus on tool challenges. As another example, there is a lot of interest in integrating tools ever better. The Eclipse/NetBeans movement is a good example. At SAP, we're moving ever more development tools on top of Eclipse, which naturally permits integration. Jazz-like environments attempt to push that limit even further: they integrate project planning (issue tracking), collaborative development (shared workspaces), continuous build infrastructures, bug tracking, team communication (integrated chatting capabilities), etc in order to have developers stick to one environment. As a side-note to this evolution: One of the great successes of SAP's R/3 system was exactly this level of (proprietary) integration, albeit in a slightly more arcane fashion (no rich clients for instance).

	So, here is a new attempt:

	1. Back to the Source

	* First, we briefly talk about source-driven tools until the mid-80s, perhaps about 1st-5th generation languages, in other words, the drive for abstraction
	* Then, we talk about CASE and MDD tools and how that did not and still does not work
	* Finally, we explain the current state of affairs, which explains "the back to the source"

	2. Support for Quality

	* In this section, we go into different tools or tool groups that focus on quality improvements (giving concrete examples if we know them). We could probably refer to most of the articles we've selected.
	* static analysis

	3. Tool Integration
	* tool integration at the source code level. (e.g. Jazz)
	* integration of simple static program analysis techniques. (e.g. find bugs and test generation)

	4. Challenges and Outlook
	Here we could describe different trends and challenges as much as we can think of. Summarizing some that have been mentioned:
	* search engines to improve development (e.g. code conjurer and other search engine tools)
	* perhaps something about multi-processor development, but as I said, this is more a paradigm topic (e.g. Erlang)
	* ...

	=== Administrative Rejection Letter ===		=== Administrative Rejection Letter ===

Shelsen: /* Proposal for an outline */

2008-04-13T16:44:58Z

Proposal for an outline

@@ Line 24: / Line 24: @@
 === Proposal for an outline ===
 * It seems that development tools spread their wings over other aspects of the software development lifecycle, but mostly do this at the source level
 * We should also point out that this is the reality today
 * We could argue how the Internet and distributed OSS development have shaped the form of development tools today
 === New proposal outline ===

Shelsen: /* Introductory Article Brainstorming */

2008-04-13T16:30:17Z

Introductory Article Brainstorming

← Older revision		Revision as of 18:30, 13 April 2008
Line 10:		Line 10:
	=== Introductory Article Brainstorming ===		=== Introductory Article Brainstorming ===
	* Dale's suggestion "Your Guest Editors' Introduction (typically 2,000 to 2,500 words) should discuss the theme topic in the context of the magazine, presenting recent results, future directions, and important trends and their implications, and getting across to the reader why this topic is important and timely. The introduction should not rehash the accompanying articles but should motivate the reader to read them. Your GEI is due June 2."		* Dale's suggestion "Your Guest Editors' Introduction (typically 2,000 to 2,500 words) should discuss the theme topic in the context of the magazine, presenting recent results, future directions, and important trends and their implications, and getting across to the reader why this topic is important and timely. The introduction should not rehash the accompanying articles but should motivate the reader to read them. Your GEI is due June 2."

⚫	* ~~title proposal:~~ "Where is my jetpack"
			* title proposals:
⚫	** ~~SPH: my variation to this:~~ "Back to the Source: Where is my jetpack?"
		⚫	** "Where is my jetpack?"
		⚫	** "Back to the Source: Where is my jetpack?"

	* Most of the papers we got address software quality. Maybe other aspects, like productivity, management, and software efficiency, nowadays take a back seat on quality.		* Most of the papers we got address software quality. Maybe other aspects, like productivity, management, and software efficiency, nowadays take a back seat on quality.

	** SPH: although there are 3 quality papers, the 3 other papers have not all that much to do with quality (except perhaps the refactoring one), so we have to be careful to not just focus on quality, I think.
	** AGR: Refactoring aligns with the source code and quality themes, i.e. continuously improving the code and correcting the design entropy that creeps in as software evolves.
	* Source code has become the common currency of software. Tools work, search, inspect source code, not abstract descriptions. The open source movement reflects this trend.		* Source code has become the common currency of software. Tools work, search, inspect source code, not abstract descriptions. The open source movement reflects this trend.

	** SPH: I totally agree that the Internet, and thus global collaborative development, has been instrumental in this focus on source-based tools. Also the fact that building infrastructures for higher level's of abstraction is very difficult and expensive, drove us away from the graphical modeling-based tools.
	** SPH: So, I very much support the idea that we should spend the intro article on the historical evolution of software development tools and culminate it in an explanation why modern software development has become intertwined with source-driven tools. See my notes below.
	* Twenty years agos, experts would have predicted that the level of abstraction in software would have been raised. Just as machine code gave way to assembly language, and assembly language gave way to third generation languages like Fortran, Cobol, C, etc., this trend would continue and we'd be defining systems in much higher level languages, e.g. UML and other model-based domain specific languages. This trend did not continue, and instead the innovations occurred due to network effects from the Internet. Open source communities arose where source code was the lingua franca. Tools evolved to improve the quality of source code - e.g. bug trackers, static analysis, refactoring, searching for code reuse, etc. Complex tools and IDEs come and go, but source code remains. Source code has a long life, much longer than the tools used to create it.		* Twenty years agos, experts would have predicted that the level of abstraction in software would have been raised. Just as machine code gave way to assembly language, and assembly language gave way to third generation languages like Fortran, Cobol, C, etc., this trend would continue and we'd be defining systems in much higher level languages, e.g. UML and other model-based domain specific languages. This trend did not continue, and instead the innovations occurred due to network effects from the Internet. Open source communities arose where source code was the lingua franca. Tools evolved to improve the quality of source code - e.g. bug trackers, static analysis, refactoring, searching for code reuse, etc. Complex tools and IDEs come and go, but source code remains. Source code has a long life, much longer than the tools used to create it.

	** SPH: we have to be careful about the statement that the trend to raise the abstraction does not continue. In fact, it does continue very much because lots of effort and money is being put into it as we speak. Instead, I think we should rather point out that success of ever higher (modeling) abstractions appears limited because the inherent complexity and limitations of such tools. It is most remarkable how IDEs introduce all sorts of language-specific modeling abstractions, but still base it on source code.
	* ~~AGR:~~ We should include a brief history of programming languages too. Machine Language to Assembler to Procedural (3GL) then to 4GL and 5GL, but these never became dominant. We dropped back to 3GLs, adding OO constructs. The basic elements of 3GLs (data structure, control flow) seem the right level of abstraction for specifying algorithms. We should discuss the evolution of tools in parallel with the evolution of programming languages: Unix pipes and filters, eMacs, make, CASE tools, graphical IDEs, convergence of OO methods to UML, etc, i.e. try to put the current set of tools in context		* We should include a brief history of programming languages too. Machine Language to Assembler to Procedural (3GL) then to 4GL and 5GL, but these never became dominant. We dropped back to 3GLs, adding OO constructs. The basic elements of 3GLs (data structure, control flow) seem the right level of abstraction for specifying algorithms. We should discuss the evolution of tools in parallel with the evolution of programming languages: Unix pipes and filters, eMacs, make, CASE tools, graphical IDEs, convergence of OO methods to UML, etc, i.e. try to put the current set of tools in context

	=== Proposal for an outline ===		=== Proposal for an outline ===

Ryman: /* Proposal for an outline */

2008-04-13T16:08:23Z

Proposal for an outline

← Older revision		Revision as of 18:08, 13 April 2008
Line 34:		Line 34:
	** In the case of CASE tools, there was a desire to bidirectionally tie graphical models to code, which has limited use because it does not really bridge an abstraction and causes a lot of work		** In the case of CASE tools, there was a desire to bidirectionally tie graphical models to code, which has limited use because it does not really bridge an abstraction and causes a lot of work
	** In the case of MDD tools, the main problem seems to be that not everything can be modeled graphically and the proposed solutions to this problem are problematic in themselves: specking graphical tools with textual languages is complex to build and therefore difficult to standardize and exchange. The alternative, complementing generated code with user-code is a lifecycle nightmare and expensive in practice. Moreover, modern software development is unthinkable without debugging, which is generally difficult or almost impossible with this approach		** In the case of MDD tools, the main problem seems to be that not everything can be modeled graphically and the proposed solutions to this problem are problematic in themselves: specking graphical tools with textual languages is complex to build and therefore difficult to standardize and exchange. The alternative, complementing generated code with user-code is a lifecycle nightmare and expensive in practice. Moreover, modern software development is unthinkable without debugging, which is generally difficult or almost impossible with this approach
	** AGR: There is a parallel with office tools as well. The initial computer-based document processing tools were textual. They added markup to ascii text files. Examples are troff on Unix, then GML, and finally SGML. Then personal computers came along and drove the development of GUI applications and the underlying OO languages and class libraries and frameworks. These lead to GUIs that hide the underlying file format and gave rise to binary formats, first for word processors then PC based text editors and associated office applications. Then the Internet happened and file interchange became much more of an issue, not just between different platforms but between different versions of the same application, e.g. multiple versions of MS Word where it became impossible to use very old Word documents on new versions of the application. The need for interchange across time and space led to the rise of the text based HTML and then XML. These were the children of SGML and the textual markup languages. This advance decoupled the document from the application that created it. Now there were many HTML editors and Web browsers, but they could all handle HTML, and later XML. Then the government of Massachusetts passed a law requiring open text based, XML, formats for documents. Open Office proposed ODF then Microsoft countered with OpenXML. Binary textual document formats are now obsolete. Cross-platform, open, text-based formats dominate. This preserves the intellectual capital invested in authoring the documents and decouples then from the applications, which themselves are tied to operating systems, undergo rapid evolution, and become obsolete, yet the documents live on. So in both the programming world and the office world, text based, open standards, dominate, and allow a decoupling of document from application. In the software development world, the only stable formats are really the programming language files and we now see an explosion of tools that are centered are programming language source. We would then hypothesize that only when higher level programming abstractions because widely accepted, and standardized, will be see a wealth of tools. And of course, whatever the format, we predict it will be text based, probably XML based for model artifacts.		** AGR: There is a parallel with office tools as well. The initial computer-based document processing tools were textual. They added markup to ascii text files. Examples are troff on Unix, then GML, and finally SGML. Then personal computers came along and drove the development of GUI applications and the underlying OO languages and class libraries and frameworks. These lead to GUIs that hide the underlying file format and gave rise to binary formats, first for word processors then PC based text editors and associated office applications. Then the Internet happened and file interchange became much more of an issue, not just between different platforms but between different versions of the same application, e.g. multiple versions of MS Word where it became impossible to use very old Word documents on new versions of the application. The need for interchange across time and space led to the rise of the text based HTML and then XML. These were the children of SGML and the textual markup languages. This advance decoupled the document from the application that created it. Now there were many HTML editors and Web browsers, but they could all handle HTML, and later XML. Then the government of Massachusetts passed a law requiring open text based, XML, formats for documents. Open Office proposed ODF then Microsoft countered with OpenXML. Binary textual document formats are now obsolete. Cross-platform, open, text-based formats dominate. This preserves the intellectual capital invested in authoring the documents and decouples then from the applications, which themselves are tied to operating systems, undergo rapid evolution, and become obsolete, yet the documents live on. So in both the programming world and the office world, text based, open standards, dominate, and allow a decoupling of document from application. In the software development world, the only stable formats are really the programming language files and we now see an explosion of tools that are centered are programming language source. We would then hypothesize that only when higher level programming abstractions because widely accepted, and standardized, will be see a wealth of tools. And of course, whatever the format, we predict it will be text based, probably XML based for model artifacts. For example, the Web service standards for WSDL and BPEL are XML based.
	** AGR: As Simon and I discussed, there is also an analogy between a) byte-codes and b) PDF! These are generated from source but are designed for interchange. Both are less flexible than source code but are useful for a) execution and b) presentation.		** AGR: As Simon and I discussed, there is also an analogy between a) byte-codes and b) PDF! These are generated from source but are designed for interchange. Both are less flexible than source code but are useful for a) execution and b) presentation.

Ryman: /* Proposal for an outline */

2008-04-13T16:00:48Z

Proposal for an outline

← Older revision		Revision as of 18:00, 13 April 2008
Line 34:		Line 34:
	** In the case of CASE tools, there was a desire to bidirectionally tie graphical models to code, which has limited use because it does not really bridge an abstraction and causes a lot of work		** In the case of CASE tools, there was a desire to bidirectionally tie graphical models to code, which has limited use because it does not really bridge an abstraction and causes a lot of work
	** In the case of MDD tools, the main problem seems to be that not everything can be modeled graphically and the proposed solutions to this problem are problematic in themselves: specking graphical tools with textual languages is complex to build and therefore difficult to standardize and exchange. The alternative, complementing generated code with user-code is a lifecycle nightmare and expensive in practice. Moreover, modern software development is unthinkable without debugging, which is generally difficult or almost impossible with this approach		** In the case of MDD tools, the main problem seems to be that not everything can be modeled graphically and the proposed solutions to this problem are problematic in themselves: specking graphical tools with textual languages is complex to build and therefore difficult to standardize and exchange. The alternative, complementing generated code with user-code is a lifecycle nightmare and expensive in practice. Moreover, modern software development is unthinkable without debugging, which is generally difficult or almost impossible with this approach
	** AGR: There is a parallel with office tools as well. The initial computer-based document processing tools were textual. They added markup to ascii text files. Examples are troff on Unix, then GML, and finally SGML. Then personal computers came along and drove the development of GUI applications and the underlying OO languages and class libraries and frameworks. These lead to GUIs that hide the underlying file format and gave rise to binary formats, first for word processors then PC based text editors and associated office applications. Then the Internet happened and file interchange became much more of an issue, not just between different platforms but between different versions of the same application, e.g. multiple versions of MS Word where it became impossible to use very old Word documents on new versions of the application. The need for interchange across time and space led to the rise of the text based HTML and then XML. These were the children of SGML and the textual markup languages. This advance decoupled the document from the application that created it. Now there were many HTML editors and Web browsers, but they could all handle HTML, and later XML. Then the government of ~~Massechusetts~~ passed a law requiring open text based, XML, formats for documents. Open Office proposed ODF then Microsoft countered with OpenXML. Binary textual document formats are now obsolete. Cross-platform, open, text-based formats dominate. This preserves the intellectual capital invested in authoring the documents and decouples then from the applications, which themselves are tied to operating systems, undergo rapid evolution, and become obsolete, yet the documents live on. So in both the programming world and the office world, text based, open standards, dominate, and allow a decoupling of document from application. In the software development world, the only stable formats are really the programming language files and we now see an explosion of tools that are centered are programming language source. We would then hypothesize that only when higher level programming abstractions because widely accepted, and standardized, will be see a wealth of tools. And of course, whatever the format, we predict it will be text based, probably XML based for model artifacts.		** AGR: There is a parallel with office tools as well. The initial computer-based document processing tools were textual. They added markup to ascii text files. Examples are troff on Unix, then GML, and finally SGML. Then personal computers came along and drove the development of GUI applications and the underlying OO languages and class libraries and frameworks. These lead to GUIs that hide the underlying file format and gave rise to binary formats, first for word processors then PC based text editors and associated office applications. Then the Internet happened and file interchange became much more of an issue, not just between different platforms but between different versions of the same application, e.g. multiple versions of MS Word where it became impossible to use very old Word documents on new versions of the application. The need for interchange across time and space led to the rise of the text based HTML and then XML. These were the children of SGML and the textual markup languages. This advance decoupled the document from the application that created it. Now there were many HTML editors and Web browsers, but they could all handle HTML, and later XML. Then the government of Massachusetts passed a law requiring open text based, XML, formats for documents. Open Office proposed ODF then Microsoft countered with OpenXML. Binary textual document formats are now obsolete. Cross-platform, open, text-based formats dominate. This preserves the intellectual capital invested in authoring the documents and decouples then from the applications, which themselves are tied to operating systems, undergo rapid evolution, and become obsolete, yet the documents live on. So in both the programming world and the office world, text based, open standards, dominate, and allow a decoupling of document from application. In the software development world, the only stable formats are really the programming language files and we now see an explosion of tools that are centered are programming language source. We would then hypothesize that only when higher level programming abstractions because widely accepted, and standardized, will be see a wealth of tools. And of course, whatever the format, we predict it will be text based, probably XML based for model artifacts.
			** AGR: As Simon and I discussed, there is also an analogy between a) byte-codes and b) PDF! These are generated from source but are designed for interchange. Both are less flexible than source code but are useful for a) execution and b) presentation.

	3. Integration at the source		3. Integration at the source

Ryman: /* Proposal for an outline */

2008-04-13T15:31:46Z

Proposal for an outline

← Older revision		Revision as of 17:31, 13 April 2008
Line 42:		Line 42:
	* We could argue how the Internet and distributed OSS development have shaped the form of development tools today		* We could argue how the Internet and distributed OSS development have shaped the form of development tools today
	* This would be the section to point to our special issue articles, where applicable:		* This would be the section to point to our special issue articles, where applicable:
	** Code Development: ever more powerful and integrating development environments, which improve productivity: source outliners, code completion (we can point to a large amount of commercial and open source IDEs such as Eclipse, NetBeans, JBuilder, Visual Studio, XEmacs, IntelliJ, etc.)		** Code Development: ever more powerful and integrating development environments, which improve productivity: source outliners, code completion (we can point to a large amount of commercial and open source IDEs such as Eclipse, NetBeans, JBuilder, Visual Studio, XEmacs, IntelliJ, XCode, etc.)
	** Life-cycle Management: version control systems have become a necessity in distributed development and they integrate at the source level		** Life-cycle Management: version control systems have become a necessity in distributed development and they integrate at the source level
	** Project Management: mostly bug and issue trackers, which refer or tie themselves to source code		** Project Management: mostly bug and issue trackers, which refer or tie themselves to source code

Ryman: /* Proposal for an outline */

2008-04-13T15:24:16Z

Proposal for an outline

← Older revision		Revision as of 17:24, 13 April 2008
Line 34:		Line 34:
	** In the case of CASE tools, there was a desire to bidirectionally tie graphical models to code, which has limited use because it does not really bridge an abstraction and causes a lot of work		** In the case of CASE tools, there was a desire to bidirectionally tie graphical models to code, which has limited use because it does not really bridge an abstraction and causes a lot of work
	** In the case of MDD tools, the main problem seems to be that not everything can be modeled graphically and the proposed solutions to this problem are problematic in themselves: specking graphical tools with textual languages is complex to build and therefore difficult to standardize and exchange. The alternative, complementing generated code with user-code is a lifecycle nightmare and expensive in practice. Moreover, modern software development is unthinkable without debugging, which is generally difficult or almost impossible with this approach		** In the case of MDD tools, the main problem seems to be that not everything can be modeled graphically and the proposed solutions to this problem are problematic in themselves: specking graphical tools with textual languages is complex to build and therefore difficult to standardize and exchange. The alternative, complementing generated code with user-code is a lifecycle nightmare and expensive in practice. Moreover, modern software development is unthinkable without debugging, which is generally difficult or almost impossible with this approach
			** AGR: There is a parallel with office tools as well. The initial computer-based document processing tools were textual. They added markup to ascii text files. Examples are troff on Unix, then GML, and finally SGML. Then personal computers came along and drove the development of GUI applications and the underlying OO languages and class libraries and frameworks. These lead to GUIs that hide the underlying file format and gave rise to binary formats, first for word processors then PC based text editors and associated office applications. Then the Internet happened and file interchange became much more of an issue, not just between different platforms but between different versions of the same application, e.g. multiple versions of MS Word where it became impossible to use very old Word documents on new versions of the application. The need for interchange across time and space led to the rise of the text based HTML and then XML. These were the children of SGML and the textual markup languages. This advance decoupled the document from the application that created it. Now there were many HTML editors and Web browsers, but they could all handle HTML, and later XML. Then the government of Massechusetts passed a law requiring open text based, XML, formats for documents. Open Office proposed ODF then Microsoft countered with OpenXML. Binary textual document formats are now obsolete. Cross-platform, open, text-based formats dominate. This preserves the intellectual capital invested in authoring the documents and decouples then from the applications, which themselves are tied to operating systems, undergo rapid evolution, and become obsolete, yet the documents live on. So in both the programming world and the office world, text based, open standards, dominate, and allow a decoupling of document from application. In the software development world, the only stable formats are really the programming language files and we now see an explosion of tools that are centered are programming language source. We would then hypothesize that only when higher level programming abstractions because widely accepted, and standardized, will be see a wealth of tools. And of course, whatever the format, we predict it will be text based, probably XML based for model artifacts.

	3. Integration at the source		3. Integration at the source

Ryman: /* Proposal for an outline */

2008-04-13T15:08:56Z

Proposal for an outline

← Older revision		Revision as of 17:08, 13 April 2008
Line 28:		Line 28:
	* in this section, we briefly describe the setting of the available development tools until about the late 80s (correct me if I have the timings wrong, I'm not old enough for that ;-)). We're talking about the early editors (line-based interpreters and dumb mainframe terminals), VI-style unix tools, command-line compilers, command-line profilers, command-line debuggers, and perhaps the advent of the first IDEs (Smalltalk, Turbo Pascal, and similar tools)		* in this section, we briefly describe the setting of the available development tools until about the late 80s (correct me if I have the timings wrong, I'm not old enough for that ;-)). We're talking about the early editors (line-based interpreters and dumb mainframe terminals), VI-style unix tools, command-line compilers, command-line profilers, command-line debuggers, and perhaps the advent of the first IDEs (Smalltalk, Turbo Pascal, and similar tools)
	* I must admit that I only have limited knowledge of what was available to industrial level software developers at the time. Arthur, maybe you know more about this?		* I must admit that I only have limited knowledge of what was available to industrial level software developers at the time. Arthur, maybe you know more about this?
			** AGR: I volunteer to put together a timeline that shows the evolution of programming languages and methodologies and the corresponding tools. Being ancient (56) I actually lived through a lot of this, but I am sure I can mine information from Wikipedia, the Web, etc.

	2. The CASE dream and the MDD struggle		2. The CASE dream and the MDD struggle

Ryman: /* Introductory Article Brainstorming */

2008-04-13T15:05:48Z

Introductory Article Brainstorming

← Older revision		Revision as of 17:05, 13 April 2008
Line 20:		Line 20:
	* Twenty years agos, experts would have predicted that the level of abstraction in software would have been raised. Just as machine code gave way to assembly language, and assembly language gave way to third generation languages like Fortran, Cobol, C, etc., this trend would continue and we'd be defining systems in much higher level languages, e.g. UML and other model-based domain specific languages. This trend did not continue, and instead the innovations occurred due to network effects from the Internet. Open source communities arose where source code was the lingua franca. Tools evolved to improve the quality of source code - e.g. bug trackers, static analysis, refactoring, searching for code reuse, etc. Complex tools and IDEs come and go, but source code remains. Source code has a long life, much longer than the tools used to create it.		* Twenty years agos, experts would have predicted that the level of abstraction in software would have been raised. Just as machine code gave way to assembly language, and assembly language gave way to third generation languages like Fortran, Cobol, C, etc., this trend would continue and we'd be defining systems in much higher level languages, e.g. UML and other model-based domain specific languages. This trend did not continue, and instead the innovations occurred due to network effects from the Internet. Open source communities arose where source code was the lingua franca. Tools evolved to improve the quality of source code - e.g. bug trackers, static analysis, refactoring, searching for code reuse, etc. Complex tools and IDEs come and go, but source code remains. Source code has a long life, much longer than the tools used to create it.
	** SPH: we have to be careful about the statement that the trend to raise the abstraction does not continue. In fact, it does continue very much because lots of effort and money is being put into it as we speak. Instead, I think we should rather point out that success of ever higher (modeling) abstractions appears limited because the inherent complexity and limitations of such tools. It is most remarkable how IDEs introduce all sorts of language-specific modeling abstractions, but still base it on source code.		** SPH: we have to be careful about the statement that the trend to raise the abstraction does not continue. In fact, it does continue very much because lots of effort and money is being put into it as we speak. Instead, I think we should rather point out that success of ever higher (modeling) abstractions appears limited because the inherent complexity and limitations of such tools. It is most remarkable how IDEs introduce all sorts of language-specific modeling abstractions, but still base it on source code.
	* AGR: We should include a brief history of programming languages too. Machine Language to Assembler to Procedural (3GL) then to 4GL and 5GL, but ~~then~~ never became dominant. We dropped back to 3GLs, adding OO constructs. The basic elements of 3GLs (data structure, control flow) seem the right level of abstraction for specifying algorithms. We should discuss the evolution of tools in parallel with the evolution of programming languages: Unix pipes and filters, eMacs, make, CASE tools, graphical IDEs, convergence of OO methods to UML, etc, i.e. try to put the current set of tools in context		* AGR: We should include a brief history of programming languages too. Machine Language to Assembler to Procedural (3GL) then to 4GL and 5GL, but these never became dominant. We dropped back to 3GLs, adding OO constructs. The basic elements of 3GLs (data structure, control flow) seem the right level of abstraction for specifying algorithms. We should discuss the evolution of tools in parallel with the evolution of programming languages: Unix pipes and filters, eMacs, make, CASE tools, graphical IDEs, convergence of OO methods to UML, etc, i.e. try to put the current set of tools in context

	=== Proposal for an outline ===		=== Proposal for an outline ===

Dds: /* New proposal outline */ Changes following discussion with Simon

2008-03-30T16:19:29Z

New proposal outline: Changes following discussion with Simon

← Older revision		Revision as of 18:19, 30 March 2008
Line 74:		Line 74:

	* In this section, we go into different tools or tool groups that focus on quality improvements (giving concrete examples if we know them). We could probably refer to most of the articles we've selected.		* In this section, we go into different tools or tool groups that focus on quality improvements (giving concrete examples if we know them). We could probably refer to most of the articles we've selected.
			* static analysis

			3. Tool Integration
	3. Trends and Challenges

⚫	Here we could describe different trends and challenges as much as we can think of. Summarizing some that have been mentioned:
	* tool integration at the source code level. (e.g. Jazz)		* tool integration at the source code level. (e.g. Jazz)
	* integration of simple static program analysis techniques. (e.g. find bugs and test generation)		* integration of simple static program analysis techniques. (e.g. find bugs and test generation)

			4. Challenges and Outlook
		⚫	Here we could describe different trends and challenges as much as we can think of. Summarizing some that have been mentioned:
	* search engines to improve development (e.g. code conjurer and other search engine tools)		* search engines to improve development (e.g. code conjurer and other search engine tools)
	* perhaps something about multi-processor development, but as I said, this is more a paradigm topic (e.g. Erlang)		* perhaps something about multi-processor development, but as I said, this is more a paradigm topic (e.g. Erlang)