Contribution 60 - Revision history

Egarson at 00:09, 14 July 2008

Egarson — Mon, 14 Jul 2008 00:09:17 GMT

←Older revision		Revision as of 00:09, 14 July 2008
Line 15:		Line 15:
	While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].		While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].

-	Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities: embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.	+	Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities; embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.

Egarson at 23:13, 2 July 2008

Egarson — Wed, 02 Jul 2008 23:13:42 GMT

←Older revision		Revision as of 23:13, 2 July 2008
Line 7:		Line 7:
	So what changes took place to fuel this renewed interest in polyglot programming?		So what changes took place to fuel this renewed interest in polyglot programming?

-	The change was that technical standards together with ever-increasing bandwidth and computing resources conspired to make text-based protocols viable: gone are the days of arcane binary protocols as a pre-requisite to efficient distributed systems. Text-based interoperability largely began with XML/SOAP-based web services and continues ~~today~~ with RESTful architecture implementations and other 'smaller' protocols such as Atom and XMPP.	+	The change was that technical standards together with ever-increasing bandwidth and computing resources conspired to make text-based protocols viable: gone are the days of arcane binary protocols as a pre-requisite to efficient distributed systems. Text-based interoperability largely began with XML/SOAP-based web services and continues to evolve with RESTful architecture implementations and other 'smaller' (but no less important) protocols such as Atom and XMPP.

-	This new breed of ~~interoperability~~ technologies ~~affords~~ far broader opportunities for heterogeneous development than ever before, simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible~~; the impact of this is largely underestimated~~.	+	This new breed of technologies creates far broader opportunities for heterogeneous development than ever before, simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible.

-	Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. The effects of this change manifests as a combinatorial increase in the architectural topology of modern software systems; this is not just a reflection of their inherent diversity, but a testament to new possibilities.	+	Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. The effects of this change has begun, and manifests itself as a combinatorial increase in the architectural topology of modern software systems; this is not just a reflection of their inherent diversity, but a testament to new possibilities.

	While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].		While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].

Egarson at 22:45, 2 July 2008

Egarson — Wed, 02 Jul 2008 22:45:59 GMT

←Older revision		Revision as of 22:45, 2 July 2008
Line 25:		Line 25:
	== Footnotes ==		== Footnotes ==

-	[1] - The ~~incumbent~~ multicore era may well prove to be the most significant problem yet faced by the software development community.<br/>	+	[1] - The impending multicore era may well prove to be the most significant problem yet faced by the software development community.<br/>
	[2] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm<br/>		[2] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm<br/>


	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Egarson at 22:45, 2 July 2008

Egarson — Wed, 02 Jul 2008 22:45:45 GMT

←Older revision		Revision as of 22:45, 2 July 2008
Line 25:		Line 25:
	== Footnotes ==		== Footnotes ==

-	[1] - The incumbent multicore era ~~will~~ prove to be the most significant problem yet faced by the software development community.<br/>	+	[1] - The incumbent multicore era may well prove to be the most significant problem yet faced by the software development community.<br/>
	[2] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm<br/>		[2] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm<br/>


	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Egarson at 22:44, 2 July 2008

Egarson — Wed, 02 Jul 2008 22:44:55 GMT

←Older revision		Revision as of 22:44, 2 July 2008
Line 3:		Line 3:
	The natural evolution of computer technology has brought about important changes with respect to the tools that architects are able to employ in the provision of software systems. These changes have brought about a resurgence of interest in ''polyglot programming'', which refers to the use of more than one core language in the provision of a software system.		The natural evolution of computer technology has brought about important changes with respect to the tools that architects are able to employ in the provision of software systems. These changes have brought about a resurgence of interest in ''polyglot programming'', which refers to the use of more than one core language in the provision of a software system.

-	Polyglot programming is not a new concept: one prominent example from ~~recent history~~ is Visual Basic clients talking to COM objects authored in C++. Fundamentally speaking, this architecture leveraged what those languages were good at in their heyday.	+	Polyglot programming is not a new concept: one prominent example from the past is Visual Basic clients talking to COM objects authored in C++. Fundamentally speaking, this architecture leveraged what those languages were good at in their heyday.

-	So what ~~change has taken~~ place ~~that fuels the~~ renewed interest in polyglot programming?	+	So what changes took place to fuel this renewed interest in polyglot programming?

-	The change is that ever-increasing bandwidth and computing resources ~~have~~ conspired to ~~enable~~ text-based protocols ~~to become a reality~~: gone are the days ~~when~~ arcane binary protocols ~~were~~ a pre-requisite to efficient distributed systems. Text-based interoperability largely began with XML/SOAP-based web services and continues today with RESTful architecture implementations and other 'smaller' protocols~~, including~~ Atom and XMPP ~~(for example)~~.	+	The change was that technical standards together with ever-increasing bandwidth and computing resources conspired to make text-based protocols viable: gone are the days of arcane binary protocols as a pre-requisite to efficient distributed systems. Text-based interoperability largely began with XML/SOAP-based web services and continues today with RESTful architecture implementations and other 'smaller' protocols such as Atom and XMPP.

-	This new breed of interoperability technologies affords far broader opportunities for heterogeneous development than ever before, simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible, the impact of ~~which~~ is largely underestimated.	+	This new breed of interoperability technologies affords far broader opportunities for heterogeneous development than ever before, simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible; the impact of this is largely underestimated.

-	Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. The effects of this change manifests as a combinatorial increase in the architectural topology of modern software systems; this is not just a reflection of their diversity, but a testament to new possibilities.	+	Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. The effects of this change manifests as a combinatorial increase in the architectural topology of modern software systems; this is not just a reflection of their inherent diversity, but a testament to new possibilities.

	While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].		While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].

-	Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities: embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.	+	Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities: embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.
-		+

	By [[Edward Garson]]		By [[Edward Garson]]

Egarson at 22:26, 2 July 2008

Egarson — Wed, 02 Jul 2008 22:26:29 GMT

←Older revision		Revision as of 22:26, 2 July 2008
Line 3:		Line 3:
	The natural evolution of computer technology has brought about important changes with respect to the tools that architects are able to employ in the provision of software systems. These changes have brought about a resurgence of interest in ''polyglot programming'', which refers to the use of more than one core language in the provision of a software system.		The natural evolution of computer technology has brought about important changes with respect to the tools that architects are able to employ in the provision of software systems. These changes have brought about a resurgence of interest in ''polyglot programming'', which refers to the use of more than one core language in the provision of a software system.

-	Polyglot programming is not a new concept: one prominent example from ~~the past~~ is Visual Basic clients talking to COM objects authored in C++. Fundamentally speaking, this architecture leveraged what those languages were good at in their heyday.	+	Polyglot programming is not a new concept: one prominent example from recent history is Visual Basic clients talking to COM objects authored in C++. Fundamentally speaking, this architecture leveraged what those languages were good at in their heyday.

	So what change has taken place that fuels the renewed interest in polyglot programming?		So what change has taken place that fuels the renewed interest in polyglot programming?
Line 11:		Line 11:
	This new breed of interoperability technologies affords far broader opportunities for heterogeneous development than ever before, simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible, the impact of which is largely underestimated.		This new breed of interoperability technologies affords far broader opportunities for heterogeneous development than ever before, simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible, the impact of which is largely underestimated.

-	Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. The effects of this change ~~is manifested~~ as a combinatorial increase in the architectural topology of modern software systems~~. This~~ is not just a reflection of their diversity, but a testament to new possibilities.	+	Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. The effects of this change manifests as a combinatorial increase in the architectural topology of modern software systems; this is not just a reflection of their diversity, but a testament to new possibilities.

	While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].		While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].

-	Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities: embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.	+	Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities: embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.

Egarson at 22:23, 2 July 2008

Egarson — Wed, 02 Jul 2008 22:23:02 GMT

←Older revision		Revision as of 22:23, 2 July 2008
Line 1:		Line 1:
	== Heterogeneity Wins ==		== Heterogeneity Wins ==

-	~~''[Still~~ a ~~couple~~ of ~~rough spots, but mostly complete]~~''	+	The natural evolution of computer technology has brought about important changes with respect to the tools that architects are able to employ in the provision of software systems. These changes have brought about a resurgence of interest in ''polyglot programming'', which refers to the use of more than one core language in the provision of a software system.

-	~~There has recently been~~ a ~~surge of interest around ''polyglot programming'', which refers~~ to ~~the use of more than one core language~~ in ~~the provision of a software system~~.	+	Polyglot programming is not a new concept: one prominent example from the past is Visual Basic clients talking to COM objects authored in C++. Fundamentally speaking, this architecture leveraged what those languages were good at in their heyday.

-	~~Polyglot programming~~ has been around for some time. An often-cited (but somewhat misguided) example of polyglot programming is the mix of SQL and programming-language code. This does not constitute ''true'' polyglot programming, as SQL is really a domain-specific language for persistence as opposed to being a direct contributor to the core, functional requirements of a system. The key differentiator is that ~~SQL is not Turing-complete; perhaps then, the better definition of~~ the ~~''modern'' sense of~~ polyglot programming ~~is where more than one Turing-complete language contributes to core functionality.~~	+	So what change has taken place that fuels the renewed interest in polyglot programming?

-	~~But alas, even 'Turing-complete' polyglot programming~~ is ~~not new: consider (for one) the old Microsoft architecture of Visual Basic front~~-~~ends talking~~ to ~~C++ COM objects on~~ the ~~back~~-~~end~~. So, ~~what change has taken place that fuels the interest in polyglot programming?~~	+	The change is that ever-increasing bandwidth and computing resources have conspired to enable text-based protocols to become a reality: gone are the days when arcane binary protocols were a pre-requisite to efficient distributed systems. Text-based interoperability largely began with XML/SOAP-based web services and continues today with RESTful architecture implementations and other 'smaller' protocols, including Atom and XMPP (for example).

-	~~The change was that~~ ever~~-increasing bandwidth~~ and ~~computing resources conspired to enable~~ text-based ~~protocols to become a reality: gone are~~ the days when arcane binary protocols were a pre-requisite to efficient distributed systems. Text-based interoperability began with XML/SOAP-based web services and continues with RESTful architecture implementations[1] and other, ~~'smaller' protocols including Atom and XMPP (for example)~~.	+	This new breed of interoperability technologies affords far broader opportunities for heterogeneous development than ever before, simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible, the impact of which is largely underestimated.

-	~~This new breed of interoperability technologies affords far broader opportunities for heterogeneous development simply because the payload is formatted text~~, ~~which is universally generated and consumed. Heterogeneous development affords using~~ the right ~~tool for~~ the ~~job, and at no time~~ in the ~~past has this been more possible than the present~~. ~~Text-based interop has blown the doors off what was previously possible~~, ~~the impact of which is largely underestimated~~.	+	Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. The effects of this change is manifested as a combinatorial increase in the architectural topology of modern software systems. This is not just a reflection of their diversity, but a testament to new possibilities.

-	~~Architects can now combine specific~~, ~~powerful tools~~ in the ~~provision~~ of software ~~that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''~~. As an industry we are ~~just beginning to see this effects of this; there has been a combinatorial increase in~~ the ~~technology topologies of modern systems. This is~~ not ~~just a reflection of their diversity, but is a testament~~ to ~~new possibilities~~.	+	While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].

-	While choice is not always a good thing[2], it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[3] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[4].	+	Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities: embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.
-		+
-	Your job as architect has become even more challenging, because technology silos are crumbling in the face of ~~the~~ new ~~interoperability;~~ embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.	+

	By [[Edward Garson]]		By [[Edward Garson]]

	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]		This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+

	== Footnotes ==		== Footnotes ==

-	[1] - Many architects prefer the RESTful architectural style over SOA, because most SOA implementations degenerate into the architectural equivalents of old-style RPC, the only difference being XML as the payload format as opposed to some binary protocol.<br/>	+	[1] - The incumbent multicore era will prove to be the most significant problem yet faced by the software development community.<br/>
-	~~[2] - _The Paradox of Choice - Why More Is Less_, Barry Schwartz<br/>~~	+	[2] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm<br/>
-	[3] - The incumbent multicore era will prove to be the most significant problem yet faced by the software development community.<br/>	+
-	[4] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm<br/>	+

	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Egarson at 14:43, 29 June 2008

Egarson — Sun, 29 Jun 2008 14:43:35 GMT

←Older revision		Revision as of 14:43, 29 June 2008
Line 1:		Line 1:
	== Heterogeneity Wins ==		== Heterogeneity Wins ==
		+
		+	''[Still a couple of rough spots, but mostly complete]''

	There has recently been a surge of interest around ''polyglot programming'', which refers to the use of more than one core language in the provision of a software system.		There has recently been a surge of interest around ''polyglot programming'', which refers to the use of more than one core language in the provision of a software system.
Line 9:		Line 11:
	The change was that ever-increasing bandwidth and computing resources conspired to enable text-based protocols to become a reality: gone are the days when arcane binary protocols were a pre-requisite to efficient distributed systems. Text-based interoperability began with XML/SOAP-based web services and continues with RESTful architecture implementations[1] and other, 'smaller' protocols including Atom and XMPP (for example).		The change was that ever-increasing bandwidth and computing resources conspired to enable text-based protocols to become a reality: gone are the days when arcane binary protocols were a pre-requisite to efficient distributed systems. Text-based interoperability began with XML/SOAP-based web services and continues with RESTful architecture implementations[1] and other, 'smaller' protocols including Atom and XMPP (for example).

-	This new breed of interoperability technologies affords far broader opportunities for ~~the~~ development ~~of heterogeneous applications~~ simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and at no time in the past has this been more possible than the present. Text-based interop has blown the doors off what was previously possible, the impact of which is largely underestimated.	+	This new breed of interoperability technologies affords far broader opportunities for heterogeneous development simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and at no time in the past has this been more possible than the present. Text-based interop has blown the doors off what was previously possible, the impact of which is largely underestimated.

	Architects can now combine specific, powerful tools in the provision of software that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. As an industry we are just beginning to see this effects of this; there has been a combinatorial increase in the technology topologies of modern systems. This is not just a reflection of their diversity, but is a testament to new possibilities.		Architects can now combine specific, powerful tools in the provision of software that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. As an industry we are just beginning to see this effects of this; there has been a combinatorial increase in the technology topologies of modern systems. This is not just a reflection of their diversity, but is a testament to new possibilities.

Egarson at 14:38, 29 June 2008

Egarson — Sun, 29 Jun 2008 14:38:33 GMT

←Older revision		Revision as of 14:38, 29 June 2008
Line 13:		Line 13:
	Architects can now combine specific, powerful tools in the provision of software that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. As an industry we are just beginning to see this effects of this; there has been a combinatorial increase in the technology topologies of modern systems. This is not just a reflection of their diversity, but is a testament to new possibilities.		Architects can now combine specific, powerful tools in the provision of software that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. As an industry we are just beginning to see this effects of this; there has been a combinatorial increase in the technology topologies of modern systems. This is not just a reflection of their diversity, but is a testament to new possibilities.

-	While choice is not always a good thing[2], it is 'less worse' than the alternative in the context of ~~architecting~~ modern software ~~systems~~. As an industry, we are faced with very serious problems[3], and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[4].	+	While choice is not always a good thing[2], it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[3] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[4].

	Your job as architect has become even more challenging, because technology silos are crumbling in the face of the new interoperability; embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.		Your job as architect has become even more challenging, because technology silos are crumbling in the face of the new interoperability; embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.

Egarson at 14:33, 29 June 2008

Egarson — Sun, 29 Jun 2008 14:33:26 GMT

←Older revision		Revision as of 14:33, 29 June 2008
Line 23:		Line 23:
	== Footnotes ==		== Footnotes ==

-	[1] - Many architects prefer the RESTful architectural style over SOA, because most SOA implementations ~~ended up being~~ the architectural equivalents of old-style RPC, the only difference being XML as the payload format as opposed to some binary protocol. The tooling around SOAP will be its ultimate undoing; the ''stubs and skeletons'' creates code smells that hearken back to an RPC-centric view of distributed systems. Thus, many architects and designers were led into the trap of designing systems as they were used to. Design best-practices such as document-oriented SOA was not adopted, understood or applied on a wide scale.<br/>	+	[1] - Many architects prefer the RESTful architectural style over SOA, because most SOA implementations degenerate into the architectural equivalents of old-style RPC, the only difference being XML as the payload format as opposed to some binary protocol.<br/>
	[2] - _The Paradox of Choice - Why More Is Less_, Barry Schwartz<br/>		[2] - _The Paradox of Choice - Why More Is Less_, Barry Schwartz<br/>
	[3] - The incumbent multicore era will prove to be the most significant problem yet faced by the software development community.<br/>		[3] - The incumbent multicore era will prove to be the most significant problem yet faced by the software development community.<br/>