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 TAA32569; Wed, 7 Nov 2001 19:43:24 +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 TAA32342 for ; Wed, 7 Nov 2001 19:43:22 +0100 (MET) Received: from c0mailgw11.prontomail.com ([216.163.180.10]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fA7IhLf18262 for ; Wed, 7 Nov 2001 19:43:21 +0100 (MET) Received: by c0mailgw11.prontomail.com (NPlex 5.5.029) id 3BD60E520027E5B2 for caml-list@pauillac.inria.fr; Wed, 7 Nov 2001 10:36:31 -0800 Received: from 207.1.194.208 by SmtpServer for ; Wed, 07 Nov 2001 18:36:30 +0000 X-Sender: 29538.starband.net Message-ID: <002d01c167bb$fc8b2fd0$d0c201cf@XENO> Reply-To: "Eric Newhuis" From: "Eric Newhuis" To: "Caml" Subject: Fw: [Caml-list] Jihad Date: Wed, 7 Nov 2001 12:42:42 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C16789.B188D640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002A_01C16789.B188D640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric, You make many sweeping statements that have either logical flaws or = are without support.=20 Yes I know. This was the whole point of why I posted this asking for = help to clear the cobwebs from my thinking. 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. Of course. 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. Sure. But doesn't Caml weed out many of the errors one needs an = imperative-language-friendly debugger for? Lately I've been programming = in K, a proprietary language derived from APL. K does not have a strong = type system. Yet the power of its interactive functional human = interface provides me with debugging tools that are more appropriate for = functional langauge debugging...I guess. I'm new to a lot of this = stuff. 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. There may be a better way for me to describe the very specific issue I = have that I've experienced with languages like C and even weakly typed = functional languages like K. Here is a conrete example: 1. I write some code that I expect to do X. 2. It initailly appears to do X. 3. Later on, when someone enters slightly different input the code does = Y instead of X. This usually occurs a few milliseconds before I put my = foot in my mouth over a claim that my system is ready to ship. Lets say X is an operation on a character vector. Lets say Y is a type = error due to the fact that someone entered something other than a = character vector in some input module. Lastly, most of what you write sounds like marketing hype wrapped in = buzzwords - and to me that is the scariest of things. Sorry. I am probably overly optimistic that some of those buzzwords = actually have some muscle behind them. This is fueled by my limited = knowledge of what Microsoft's Intentional Programming might some day = accomplish. 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.=20 I'm not really in favor of functional languages, but strongly-typed ones = that have deductive powers...like OCaml. But yeah; I also have a personal argument AGAINST strongly typed = languages. People WANT to be sloppy. There are times when one DOESN'T = know the perfect solution. There are holes in thinking that are filled = in over time as a system evolves. Slop languages are good for those, I = suppose. One thing that surprized me about ML and OCaml was that strongly typed = languages, those even stronger than C++, could actually express things = in a much simpler and cleaner syntax. I've been doing C++ for years = since the original cfront compiler and was very happy to use templates. = Recent thougths on C++ template meta-programming led me to believe, for = a while, that I had reached nirvana. I was really shaken when I = discovered that OCaml could do a lot of the things that one can do with = template meta-programming in C++ without the code density. If I had to give a quick rundown of why I think some functional = languages have "failed" in the past I would just say: No mainstream = integration support on the majority of platforms =3D Microsoft Windows. = Allegro CL captured my imagination for a while because they seemed to = have a very nice native Windows environment. So now that Microsoft declares a "common language runtime" can you = understand how I've become so excited? Won't it usher in a functional = language Renaissance? Like I said earlier, maybe I'm being overly = optimistic or naiive. Nevertheless one way to predict the future is to help build it. Sincerely, Eric Newhuis ------=_NextPart_000_002A_01C16789.B188D640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Eric,
 
You=20 make many sweeping statements that have either logical flaws or are = without=20 support. 
Yes I know.  This was the whole point of = why I=20 posted this asking for help to clear the cobwebs from my=20 thinking.
For=20 example, you indicate that you've been writing trivial programs in = ocaml;=20 however, the engineering issue is one of scalability.  Because = something=20 makes the trivial easy doesn't mean that it makes the complex more=20 simple.
Of course.
Case=20 in point - debugging; one advantage of the imperative paradigm is that = being=20 based on turing machines, it provides (indeed requires) explicit = notions of=20 state - this makes debugging easier - the ocaml debugger is not very = modern=20 with respect debuggers for imperative languages  - even though it = is=20 leaps and bounds better than anything available for say,=20 haskell.
Sure.  But doesn't Caml weed out many of = the=20 errors one needs an imperative-language-friendly debugger for?  = Lately I've=20 been programming in K, a proprietary language derived from APL.  K = does not=20 have a strong type system.  Yet the power of its interactive = functional=20 human interface provides me with debugging tools that are more = appropriate for=20 functional langauge debugging...I guess.  I'm new to a lot of this=20 stuff.
Everyone likes polymorphic type systems - = check out=20 "basic".
 
You=20 state that perl, sql, javascript, and python, and a "hoard" (better - = a babel)=20 of languages brush problems under the rug - what justification, case = studies,=20 etc., the implication is that functional languages don't have the = problem of=20 "you appear to have accomplished something good, but = later
you=20 find out it stinks" - I do hope that you have a sense of how the proof = goes=20 for the church-turing thesis and that you will immediately realize the = logical=20 flaw.
There may be a better way for me to describe = the very=20 specific issue I have that I've experienced with languages like C and = even=20 weakly typed functional languages like K.  Here is a conrete=20 example:
 
1. I write some code that I expect to do=20 X.
2. It initailly appears to do = X.
3. Later on, when someone enters slightly = different=20 input the code does Y instead of X.  This usually occurs a few = milliseconds=20 before I put my foot in my mouth over a claim that my system is ready to = ship.
 
Lets say X is an operation on a character = vector. =20 Lets say Y is a type error due to the fact that someone entered = something other=20 than a character vector in some input module.
Lastly, most of what you write sounds like = marketing=20 hype wrapped in buzzwords - and to me that is the scariest of=20 things.
Sorry.  I am probably overly optimistic = that some=20 of those buzzwords actually have some muscle behind them.  This is = fueled=20 by my limited knowledge of what Microsoft's Intentional Programming = might some=20 day accomplish.
Although I am a fan of functional = languages, the=20 paradigm shift won't be in that direction - remember functional = languages have=20 been around a long, long time; I think the true paradigm shift will = come when=20 we figure out to lift the language above the: functional, imperative, = logical,=20 aspect, object-oriented, and declarative models - In graduate school I = was=20 asked to compare and contrast prolog unification with inheritance = polymorphism - later, in a philosphy class I was asked, "which is = harder a=20 piece of paper or a rubber band" - in a very real sense the answers = were=20 similar.
 
I'm not really in favor of functional = languages, but=20 strongly-typed ones that have deductive powers...like = OCaml.
 
But yeah; I also have a personal = argument AGAINST=20 strongly typed languages.  People WANT to be sloppy.  There = are times=20 when one DOESN'T know the perfect solution.  There are holes in = thinking=20 that are filled in over time as a system evolves.  Slop languages = are good=20 for those, I suppose.
 
One thing that surprized me about ML and = OCaml was that=20 strongly typed languages, those even stronger than C++, could actually = express=20 things in a much simpler and cleaner syntax.  I've been doing C++ = for years=20 since the original cfront compiler and was very happy to use = templates. =20 Recent thougths on C++ template meta-programming led me to believe, for = a while,=20 that I had reached nirvana.  I was really shaken when I discovered = that=20 OCaml could do a lot of the things that one can do with template=20 meta-programming in C++ without the code density.
 
If I had to give a quick rundown of why I = think some=20 functional languages have "failed" in the past I would just = say:  No=20 mainstream integration support on the majority of platforms =3D = Microsoft=20 Windows.  Allegro CL captured my imagination for a while because = they=20 seemed to have a very nice native Windows = environment.
 
So now that Microsoft declares a "common = language=20 runtime" can you understand how I've become so excited?  Won't it = usher in=20 a functional language Renaissance?  Like I said earlier, maybe I'm = being=20 overly optimistic or naiive.
 
Nevertheless one way to predict the future is = to help=20 build it.
 
Sincerely,
Eric Newhuis
 
 
 
 
------=_NextPart_000_002A_01C16789.B188D640-- ------------------- 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