Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Fw: [Caml-list] Jihad
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Eric Newhuis <enew@b...>
Subject: Fw: [Caml-list] Jihad

  You make many sweeping statements that have either logical flaws or are without support. 
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. 

I'm not really in favor of functional languages, but strongly-typed ones that have deductive 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 = 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.

Eric Newhuis