The Ciao Approach to the Dynamic vs. Static Language Dilemma (Position/System/Demo Paper 1 ) M. V. Hermenegildo 1,2 F. Bueno 1 M. Carro 1 P. L´ opez-Garc´ ıa 2,4 E. Mera 3 J. F. Morales 2 G. Puebla 1 1 Universidad Polit´ ecnica de Madrid (UPM) {bueno,mcarro,german,herme}@fi.upm.es 2 Madrid Institute of Advanced Studies in SW Development Technology (IMDEA Software Institute) {manuel.hermenegildo,pedro.lopez,jose.morales}@imdea.org 3 Universidad Complutense de Madrid (UCM) edison@fdi.ucm.es 4 Scientific Research Council (CSIC) Dynamic vs. Static Languages The environment in which much software needs to be developed nowadays (de- coupled software development, use of components and services, increased inter- operability constraints, need for dynamic update or self-reconfiguration, mash-up development, etc.) is posing requirements which align with the classical argu- ments for dynamic languages and which in fact go beyond them. Examples of often required dynamic features include making it possible to (partially) test and verify applications which are partially developed and which will never be “com- plete” or “final,” or which evolve over time in an asynchronous, decentralized fashion (e.g., software service-based systems). These requirements, coupled with the intrinsic agility in development of dynamic programming languages such as Python, Ruby, Lua, JavaScript, Perl, PHP, etc. (with Scheme or Prolog also in this class) have made such languages a very attractive option for a number of purposes that go well beyond simple scripting. Parts written in these languages often become essential components (or even the whole implementation) of full, mainstream applications. At the same time, detecting errors at compile-time and inferring many prop- erties required in order to optimize programs are still important issues in real- world applications. Thus, strong arguments are still also made in favor of static languages. For example, many modern logic and functional languages (such as, e.g., Mercury [24] or Haskell [12]) impose strong type-related requirements such as that all types (and, when relevant, modes) have to be defined explicitly or 1 In addition to the other references, this recent tutorial overview of Ciao [11] covering more fully the points made in this position paper can be downloaded from: http://clip.dia.fi.upm.es/papers/hermenegildo10:ciao-design-tplp-tr.pdf