3. polyglot
Many Languages
From Ancient Greek πολύγλωττος
(poluglōttos), “‘'many-tongued, polyglot'’”), from
πολύς (polus), “‘many’”) + γλῶττα (glōtta),
“‘'tongue, language'’”)
4. Polyglot Programming
We are entering a new era of software development.
For most of our (short) history, we've primarily written
code in a single language...but I'm beginning to see a
time where even the core language...will cease its
monoculture...applications of the future will take
advantage of the polyglot nature of the language
world...it's all about choosing the right tool for the job
and leveraging it correctly...the times of writing an
application in a single general purpose language is
over.
- Excerpts from: Neal Ford, “Polyglot Programming”
http://memeagora.blogspot.com/2006/12/polyglot-
programming.html
28. Polyglot Drivers
Concurrency/Multi-core Hardware
Framework Availability
Special purpose language constructs/libraries
Essence over Ceremony
Testing
The JVM Itself
30. OSGi Architecture
Application/Bundles
Services
Security
OSGi Platform
Service Registry
Lifecycle
Modules
Java Virtual Machine
Java Platform
Operating System
Hardware
Inspired by Modular Java (Craig Walls), page 16
31. SOA in a JVM!
OSGi
Service
Registry
Dis
ice
c
erv
ov
sS
ers
ter
Se
gis
rvi
Re
ce
Service Consumes Service Consumer
Bundle Bundle
Inspired by Modular Java (Craig Walls), page 17
58. PaxExam
Testing toolkit for OSGi
Facilitates in-container integration testing of bundles
Flow:
Starts OSGi container of choice
59. PaxExam
Testing toolkit for OSGi
Facilitates in-container integration testing of bundles
Flow:
Starts OSGi container of choice
Provisions and starts selected bundles
60. PaxExam
Testing toolkit for OSGi
Facilitates in-container integration testing of bundles
Flow:
Starts OSGi container of choice
Provisions and starts selected bundles
Injects OSGi BundleContext to your JUnit test
61. PaxExam
Testing toolkit for OSGi
Facilitates in-container integration testing of bundles
Flow:
Starts OSGi container of choice
Provisions and starts selected bundles
Injects OSGi BundleContext to your JUnit test
Executes a test method
62. PaxExam
Testing toolkit for OSGi
Facilitates in-container integration testing of bundles
Flow:
Starts OSGi container of choice
Provisions and starts selected bundles
Injects OSGi BundleContext to your JUnit test
Executes a test method
Rinse and repeat until done!
64. Why Polyglot OSGi?
Java Java Service
Java Client
Service Implementation
Client Module Server Module
65. Why Polyglot OSGi?
Java Java Service
Java Client
Service Implementation
Client Module Server Module
66. Why Polyglot OSGi?
Java Java Service
Java Client
Service Implementation
Client Module Server Module
67. Why Polyglot OSGi?
Java Java Service
Java Client
Service Implementation
Client Module Server Module
68. Why Polyglot OSGi?
Java Groovy Service
Java Service
Java Client
Service Implementation
Client Module Server Module
69. Why Polyglot OSGi?
Java GroovyService
Scala Service
Java Service
Java Client
Service Implementation
Client Module Server Module
70. Why Polyglot OSGi?
Java GroovyService
Clojure Service
Scala Service
Java
Java Client
Service Implementation
Client Module Server Module
71. Why Polyglot OSGi?
Java GroovyService
Clojure Service
JRubyService
Scala Service
Java
Java Client
Service Implementation
Client Module Server Module
82. Polyglot OSGi Cons
Constant Java translation at boundary
Less idiomatic code
Language / OSGi mismatch
Not a silver bullet for large teams with few polyglots
84. PGOVM Specification
Valid Actions:
NICKLE, DIME, QUARTER, DOLLAR - insert money
COIN RETURN - returns all inserted money
SERVICE - a service person opens the machine and
sets the available change and items
GET-A, GET-B, GET-C - select item A ($.65), B ($1),
or C ($1.50)
85. PGOVM Specification
Valid Responses:
NICKLE, DIME, QUARTER - return coin
A, B, C - vend item A, B, or C
Track state:
available items (count, price, selector)
available change (# of nickles, dimes, quarters, dollars
available)
currently inserted money
86. PGOVM Specification
Example Traces:
Buy B with exact change:
Q, Q, Q, Q, GET-B
-> B
Add change, hit coin return:
Q, Q, COIN-RETURN
-> Q, Q
Buy A without exact change (return $.35)
DOLLAR, GET-A
-> A, Q, D
89. Why this spec?
Simple to understand, yet...
...demonstrates reasonable complexity one might find
in a real application
90. Why this spec?
Simple to understand, yet...
...demonstrates reasonable complexity one might find
in a real application
Algorithms suitable for showcasing language features
91. Goals
Implement a Java interface contract for the spec
Test-drive a Java implementation
Use tests as a contract to implement in:
Groovy
Scala
Clojure
Build a Spring MVC application to exercise different vending
machines
106. Scala Gotchas
Scala in Maven Central is NOT an OSGi Bundle!
Can download from http://scala-lang.org.
107. Scala Gotchas
Scala in Maven Central is NOT an OSGi Bundle!
Can download from http://scala-lang.org.
Swap it out manually...
108. Scala Gotchas
Scala in Maven Central is NOT an OSGi Bundle!
Can download from http://scala-lang.org.
Swap it out manually...
...however...
109. Scala Gotchas
Scala in Maven Central is NOT an OSGi Bundle!
Can download from http://scala-lang.org.
Swap it out manually...
...however...
won’t work with Maven anymore!
110. Scala Gotchas
Scala in Maven Central is NOT an OSGi Bundle!
Can download from http://scala-lang.org.
Swap it out manually...
...however...
won’t work with Maven anymore!
Use Groovy script to swap out Scala jars.
117. Clojure Gotchas
Clojure also not available as an OSGi bundle!
Use Pax Construct to embed in bundle for Clojure
implementation.
118. Clojure Gotchas
Clojure also not available as an OSGi bundle!
Use Pax Construct to embed in bundle for Clojure
implementation.
Mixed experiences out there with trying to share a
common Clojure bundle.
119. Clojure Gotchas
Clojure also not available as an OSGi bundle!
Use Pax Construct to embed in bundle for Clojure
implementation.
Mixed experiences out there with trying to share a
common Clojure bundle.
OGEE Project (Roman Roelofsen)
http://ogeesource.org
122. Clojure Gotchas
Not OSGi related, but...
Maven Clojure Plugin won’t seem to compile Clojure
first, so if your Java code depends on Clojure code...
123. Clojure Gotchas
Not OSGi related, but...
Maven Clojure Plugin won’t seem to compile Clojure
first, so if your Java code depends on Clojure code...
Must run “mvn clojure:compile” first
Today I’d like to talk to you briefly about why within the next decade you’ll no longer refer to yourself as a Java developer, at least not in terms of the language that you use on a day to day basis. And at the end of my lighting talk I’ll have a prize for the first person that can identify both the artist and title of the sketch that I have here in my slides.
The word polyglot is used in various contexts to indicate that many languages are in use. It can be used as an adjective to describe a work containing several languages, such as a polyglot Bible. We can also use it to describe a region comprising various linguistic groups - a notable example is India which recognizes 22 official languages and can number over a thousand individual “mother tongues.” We can also describe a person who masters and speaks several languages as a polyglot.
The term “polyglot programming” is generally recognized to have been coined by Neal Ford in late 2006. I’ve pulled together here an excerpt of the major points that Neil raises in his blog. Quoting now, “We are entering a new era of software development. For most of our (short) history, we’ve primarily written code in a single language...but I’m beginning to see a time when even the core language...will cease its monoculture...application of the future will take advantage of the polyglot nature of the language world...it’s all about choosing the right tool for the job and leveraging it correctly...the times of writing an application in a single general purpose language is over.” Of course one of the primary undercurrents here is that we’re trying to avoid one of the most common anti-patterns in software development today, that of...
THE GOLDEN HAMMER. The golden hammer is nothing more than continually attempting to use the same tool, product, or technique to solve every problem. And I would assert to you that one of the most heavily abused tools in the software development world today is, you guessed it, JAVA. We’ve even gone so far as to categorize our development shops as “Java shops” - meaning that anything that we deliver, regardless of the business domain or problem, will be implemented using Java.
Now I’d like to break down the psychological barriers here a bit by asserting that...
...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL <transition> to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript <transition> to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an <transition> XML document? Written a web page? Used <transition> HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used <transition> Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that...
...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL <transition> to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript <transition> to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an <transition> XML document? Written a web page? Used <transition> HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used <transition> Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that...
...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL <transition> to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript <transition> to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an <transition> XML document? Written a web page? Used <transition> HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used <transition> Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that...
...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL <transition> to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript <transition> to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an <transition> XML document? Written a web page? Used <transition> HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used <transition> Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that...
...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL <transition> to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript <transition> to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an <transition> XML document? Written a web page? Used <transition> HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used <transition> Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that...
..the adoption of these additional languages, just like the adoption of Java, C++ before it, and C before that, is driven by critical mass being reached in an area of business or technical demand. Let&#x2019;s examine each of the languages that we just discussed and understand what drove their adoption...
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world.
JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us.
XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML.
HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age.
Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows.
The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language.
So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass?
So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass?
So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass?
So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass?
So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass?
