From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA31254; Wed, 7 Nov 2001 19:03:44 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA30925 for ; Wed, 7 Nov 2001 19:03:42 +0100 (MET) Received: from sus-ca3it02.rational.com (ext-20001.rational.com [130.213.2.5] (may be forged)) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id fA7I3af17154 for ; Wed, 7 Nov 2001 19:03:37 +0100 (MET) Received: from 172.19.60.36 by sus-ca3it02.rational.com (InterScan E-Mail VirusWall NT); Wed, 07 Nov 2001 10:02:33 -0800 Received: by sus-ca3it02.rational.com with Internet Mail Service (5.5.2653.19) id <4K5NVAN4>; Wed, 7 Nov 2001 10:02:33 -0800 Message-ID: From: "Bauer, Robert" To: "'Eric Newhuis'" , caml-list@pauillac.inria.fr Subject: RE: [Caml-list] Jihad Date: Wed, 7 Nov 2001 10:02:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C167B6.5FC80F60" ------_=_NextPart_001_01C167B6.5FC80F60 Content-Type: text/plain; charset="iso-8859-1" Eric, You make many sweeping statements that have either logical flaws or are without support. For example, you indicate that you've been writing trivial programs in ocaml; however, the engineering issue is one of scalability. Because something makes the trivial easy doesn't mean that it makes the complex more simple. Case in point - debugging; one advantage of the imperative paradigm is that being based on turing machines, it provides (indeed requires) explicit notions of state - this makes debugging easier - the ocaml debugger is not very modern with respect debuggers for imperative languages - even though it is leaps and bounds better than anything available for say, haskell. Everyone likes polymorphic type systems - check out "basic". You state that perl, sql, javascript, and python, and a "hoard" (better - a babel) of languages brush problems under the rug - what justification, case studies, etc., the implication is that functional languages don't have the problem of "you appear to have accomplished something good, but later you find out it stinks" - I do hope that you have a sense of how the proof goes for the church-turing thesis and that you will immediately realize the logical flaw. Lastly, most of what you write sounds like marketing hype wrapped in buzzwords - and to me that is the scariest of things. Although I am a fan of functional languages, the paradigm shift won't be in that direction - remember functional languages have been around a long, long time; I think the true paradigm shift will come when we figure out to lift the language above the: functional, imperative, logical, aspect, object-oriented, and declarative models - In graduate school I was asked to compare and contrast prolog unification with inheritance polymorphism - later, in a philosphy class I was asked, "which is harder a piece of paper or a rubber band" - in a very real sense the answers were similar. robert -----Original Message----- From: Eric Newhuis [mailto:enew@bigfoot.com] Sent: Tuesday, November 06, 2001 11:20 PM To: caml-list@pauillac.inria.fr Subject: [Caml-list] Jihad I want to send this to my engineering staff but would like someone to comment on what I claim here. I don't want to mis-represent the ocaml language or the intentions of those who harbour it. I wrote this as if I speak from authority. But in reality I am a novice. My true intentions are to help spread the good news about what I think could become a major paradigm shift. Sincerely, Eric Newhuis CTO FutureSource --begin-- This slide show is a must read because it discusses the ML language's type system which is arguably the best in the world. I've been writing trivial programs in Objective Caml, an ML dialect, and have been surprised how much it helps one craft code. So I was really excited when I came across this slide show that relates C, ML, and Perl. http://perl.plover.com/yak/typing/ So the next time you hear me praising "strongly typed languages" and attacking Perl you'll know what I'm talking about. Perl, SQL, Javascript, Python, and a hoard of other languages brush problems under the rug. You can appear to have accomplished good work only to discover later, long after the product has been deployed, that something still stinks. What aggravates me the most is the ignorance of the software development community in the USA. One of the best features of modern software development practices has simply been overlooked by our American tool vendors (up until now? See below.). I suppose there is no demand for what I'm going to describe here because most of us are ignorant of the benefits. So maybe I can help build that demand by passing on this cutting-edge information to this group. Strongly typed languages are your friend? As programming languages have evolved, attempts at type systems implemented in Pascal, C, and C++ made declarations more complex than necessary. Perl mongers have been quick to point out that it is much harder to type type-safe code. And I concur that C++'s template syntax is one of the most disgusting uses of ASCII characters. But the designers of C++ had little choice because of C++'s roots in earlier mistakes--i.e. C. Recently Java has decided to join the ranks of C++ template syntax lemmings. But Java, to the best of my knowledge, is actually going to make the problem worse than that in C++ because one will not be allowed to provide aliases for complex type descriptions. Simple, and yet strong? ML proves that type-safety can be simultaneously easier to code and yet more powerful than dynamically typed languages and inferior strongly-typed languages. Complexity arguments just don't hold up. I've heard other arguments that languages like Perl, because they allow slop engineering practices more closely map to the real world because the real world is also full of a lot of slop. This is bull. Software, because it is so pliable, should represent our exact engineering intentions and our tools should help us enforce those intentions as much as is currently possible before we deploy our systems. The true professional will understand the merits of what I am demanding. Languages like C and Perl will not stand the test of time. They will fade into obscurity as more powerful engineering tools take center stage. We should stand up and demand better engineering tools from our tool vendors. After all, our users have the right to intentionally-designed products. We ought to be able to demonstrate that the code we create will actually work without running it in every possible combination of use cases. An Early Hope? Microsoft's .NET platform may play the role of catalyst in this Jihad. For finally we may see theoretically superior research-grade languages make their way into the mainstream with a newfound ability to use a common library platform (i.e. Microsoft's platform). Once developers see the benefits of stronger type systems and higher-level polymorphism they will avoid C and Perl like our predecessors learned to avoid assembly language in favor of FORTRAN and Pascal. Microsoft R&D has pumped some money into ObjectiveCaml research. They did so in order to extend the reach of .NET's Common Language Runtime. If you learn only one "alternative language" (as Dr. Dobbs magazine put it) in your lifetime, then I urge you to study ML or Objective Caml. Use of these languages will reduce time to market and eliminate most failures of your code to, as one University of Illinois professor put it "obey the principle of least astonishment". Be Fair to Perl? To be fair I must admit that Perl has a lot of neat tricks. Being a conglomeration of a diverse toolset enables the language to perform mixed-paradigm feats that bland languages like C must delegate to platform-specific libraries. So there is still a lot one can learn from Perl. So when you want to perform tricks and you feel like a magician, go ahead and use Perl. And when you feel like an engineer, use ObjectiveCaml or some other ML dialect. But remember that magicians are only concerned with appearances. Engineers are after the loftier goal. Evidence that ObjectiveCaml Works? Check out http://dada.perl.it/shootout/ for some excellent language comparisons. If you give CPU time, lines of code per intention, and memory footprint equal weights then ObjectiveCaml reigns supreme over all other languages. If all you care about is CPU time then ObjectiveCaml sits between C and C++. Amazing? No, just proof that strongly-typed languages rule. A number of successful commercial applications have been developed in ObjectiveCaml. NBC uses it in a web site: http://shopping.nbci.com. For a better list check out http://caml.inria.fr/users_programs-eng.html and http://caml.inria.fr/hump.html. (Although cool, the ObjectiveCaml port of the DOOM game engine doesn't count because DOOM has been ported to everything.) Some of the standard ObjectiveCaml library modules include Perl-compatible regular expressions, shell interfaces, XML, XSLT, XPATH, cryptography, web servers and clients, message queuing, xml-to-unix-man-page (what!?!?!), a graphical CVS front end, an Emacs-like editor, 3D graphics, signal processing, file system synchronization, LaTeX stuff (who cares?), COM and CORBA, a web proxy, mail client, parallel computing, lots of TCP/IP stuff, generative techniques, gobs of complex data structures--not just the stupid simples ones like linked lists and sets but Splay trees, Tries, and other exotic things, Postgresql, ODBC, MySQL, Java & C++ interfaces, scientific and numerical computing, "here" docs, ZIP/Jar/GZ libraries, etc. Lastly? I didn't intend to convince you all to turn in your C++ compilers. Nor do I want to bash Perl to a pulp. I do, however, want us to keep our minds open and be ready to move if and when the paradigm shifts. I wouldn't mention this stuff if I didn't think it would help us to compete. I strongly believe that the ML family of languages can some day help us cut our development costs at least in half. See? It really is all about oil. ------_=_NextPart_001_01C167B6.5FC80F60 Content-Type: text/html; charset="iso-8859-1"
Eric,
 
You make many sweeping statements that have either logical flaws or are without support.  For example, you indicate that you've been writing trivial programs in ocaml; however, the engineering issue is one of scalability.  Because something makes the trivial easy doesn't mean that it makes the complex more simple.  Case in point - debugging; one advantage of the imperative paradigm is that being based on turing machines, it provides (indeed requires) explicit notions of state - this makes debugging easier - the ocaml debugger is not very modern with respect debuggers for imperative languages  - even though it is leaps and bounds better than anything available for say, haskell.
 
Everyone likes polymorphic type systems - check out "basic".
 
You state that perl, sql, javascript, and python, and a "hoard" (better - a babel) of languages brush problems under the rug - what justification, case studies, etc., the implication is that functional languages don't have the problem of "you appear to have accomplished something good, but later
you find out it stinks" - I do hope that you have a sense of how the proof goes for the church-turing thesis and that you will immediately realize the logical flaw.
 
Lastly, most of what you write sounds like marketing hype wrapped in buzzwords - and to me that is the scariest of things.
 
Although I am a fan of functional languages, the paradigm shift won't be in that direction - remember functional languages have been around a long, long time; I think the true paradigm shift will come when we figure out to lift the language above the: functional, imperative, logical, aspect, object-oriented, and declarative models - In graduate school I was asked to compare and contrast prolog unification with inheritance polymorphism - later, in a philosphy class I was asked, "which is harder a piece of paper or a rubber band" - in a very real sense the answers were similar.
 
robert
 
 
-----Original Message-----
From: Eric Newhuis [mailto:enew@bigfoot.com]
Sent: Tuesday, November 06, 2001 11:20 PM
To: caml-list@pauillac.inria.fr
Subject: [Caml-list] Jihad

I want to send this to my engineering staff but would like someone to comment on what I claim here.  I don't want to mis-represent the ocaml language or the intentions of those who harbour it.  I wrote this as if I speak from authority.  But in reality I am a novice.  My true intentions are to help spread the good news about what I think could become a major paradigm shift.

 

Sincerely,

Eric Newhuis

CTO

FutureSource

 

 

--begin--

 

This slide show is a must read because it discusses the ML language's type system which is arguably the best in the world.  I've been writing trivial programs in Objective Caml, an ML dialect, and have been surprised how much it helps one craft code.  So I was really excited when I came across this slide show that relates C, ML, and Perl.

 

http://perl.plover.com/yak/typing/

 

So the next time you hear me praising "strongly typed languages" and attacking Perl you'll know what I'm talking about.

 

Perl, SQL, Javascript, Python, and a hoard of other languages brush problems under the rug.  You can appear to have accomplished good work only to discover later, long after the product has been deployed, that something still stinks.

 

What aggravates me the most is the ignorance of the software development community in the USA.  One of the best features of modern software development practices has simply been overlooked by our American tool vendors (up until now?  See below.).  I suppose there is no demand for what I'm going to describe here because most of us are ignorant of the benefits.  So maybe I can help build that demand by passing on this cutting-edge information to this group.

 

 

Strongly typed languages are your friend?

 

As programming languages have evolved, attempts at type systems implemented in Pascal, C, and C++ made declarations more complex than necessary.  Perl mongers have been quick to point out that it is much harder to type type-safe code.  And I concur that C++'s template syntax is one of the most disgusting uses of ASCII characters.  But the designers of C++ had little choice because of C++'s roots in earlier mistakes--i.e. C.

 

Recently Java has decided to join the ranks of C++ template syntax lemmings.  But Java, to the best of my knowledge, is actually going to make the problem worse than that in C++ because one will not be allowed to provide aliases for complex type descriptions.

 

 

Simple, and yet strong?

 

ML proves that type-safety can be simultaneously easier to code and yet more powerful than dynamically typed languages and inferior strongly-typed languages.  Complexity arguments just don't hold up.

 

I've heard other arguments that languages like Perl, because they allow slop engineering practices more closely map to the real world because the real world is also full of a lot of slop.

 

This is bull.

 

Software, because it is so pliable, should represent our exact engineering intentions and our tools should help us enforce those intentions as much as is currently possible before we deploy our systems.

 

The true professional will understand the merits of what I am demanding.  Languages like C and Perl will not stand the test of time.  They will fade into obscurity as more powerful engineering tools take center stage.

 

We should stand up and demand better engineering tools from our tool vendors.  After all, our users have the right to intentionally-designed products.  We ought to be able to demonstrate that the code we create will actually work without running it in every possible combination of use cases.

 

 

An Early Hope?

 

Microsoft's .NET platform may play the role of catalyst in this Jihad.  For finally we may see theoretically superior research-grade languages make their way into the mainstream with a newfound ability to use a common library platform (i.e. Microsoft's platform).  Once developers see the benefits of stronger type systems and higher-level polymorphism they will avoid C and Perl like our predecessors learned to avoid assembly language in favor of FORTRAN and Pascal.

 

Microsoft R&D has pumped some money into ObjectiveCaml research.  They did so in order to extend the reach of .NET's Common Language Runtime.

 

If you learn only one "alternative language" (as Dr. Dobbs magazine put it) in your lifetime, then I urge you to study ML or Objective Caml.  Use of these languages will reduce time to market and eliminate most failures of your code to, as one University of Illinois professor put it

 

      "obey the principle of least astonishment".

 

 

Be Fair to Perl?

 

To be fair I must admit that Perl has a lot of neat tricks.  Being a conglomeration of a diverse toolset enables the language to perform mixed-paradigm feats that bland languages like C must delegate to platform-specific libraries.  So there is still a lot one can learn from Perl.

 

So when you want to perform tricks and you feel like a magician, go ahead and use Perl.  And when you feel like an engineer, use ObjectiveCaml or some other ML dialect.  But remember that magicians are only concerned with appearances.  Engineers are after the loftier goal.

 

 

Evidence that ObjectiveCaml Works?

 

Check out http://dada.perl.it/shootout/ for some excellent language comparisons.  If you give CPU time, lines of code per intention, and memory footprint equal weights then ObjectiveCaml reigns supreme over all other languages.  If all you care about is CPU time then ObjectiveCaml sits between C and C++.  Amazing?  No, just proof that strongly-typed languages rule.

 

A number of successful commercial applications have been developed in ObjectiveCaml.  NBC uses it in a web site:  http://shopping.nbci.com.  For a better list check out http://caml.inria.fr/users_programs-eng.html and http://caml.inria.fr/hump.html.  (Although cool, the ObjectiveCaml port of the DOOM game engine doesn't count because DOOM has been ported to everything.)

 

Some of the standard ObjectiveCaml library modules include Perl-compatible regular expressions, shell interfaces, XML, XSLT, XPATH, cryptography, web servers and clients, message queuing, xml-to-unix-man-page (what!?!?!), a graphical CVS front end, an Emacs-like editor, 3D graphics, signal processing, file system synchronization, LaTeX stuff (who cares?), COM and CORBA, a web proxy, mail client, parallel computing, lots of TCP/IP stuff, generative techniques, gobs of complex data structures--not just the stupid simples ones like linked lists and sets but Splay trees, Tries, and other exotic things, Postgresql, ODBC, MySQL, Java & C++ interfaces, scientific and numerical computing, "here" docs, ZIP/Jar/GZ libraries, etc.

 

 

Lastly?

 

I didn't intend to convince you all to turn in your C++ compilers.  Nor do I want to bash Perl to a pulp.  I do, however, want us to keep our minds open and be ready to move if and when the paradigm shifts.  I wouldn't mention this stuff if I didn't think it would help us to compete.  I strongly believe that the ML family of languages can some day help us cut our development costs at least in half.  See?  It really is all about oil.

------_=_NextPart_001_01C167B6.5FC80F60-- --------------InterScan_NT_MIME_Boundary-- ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr