caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] New Ocaml Plug-in for NetBeans
Date: Sat, 26 Jul 2008 12:40:10 +0100	[thread overview]
Message-ID: <200807261240.10757.jon@ffconsultancy.com> (raw)
In-Reply-To: <20080726200312.7cfde7ef.mle+ocaml@mega-nerd.com>

On Saturday 26 July 2008 11:03:12 Erik de Castro Lopo wrote:
> The same can be said for the Unix IDE, but the UNIX IDE is 100
> times more flexible and more capable than any other IDE in
> existance.

Yet we cannot even get basic documentation about potential completions from 
any Unix development environment for OCaml.

> I know Make well enough to whip up a complex make file in minutes.

Yet Make is not expressive enough so we have OMake, OCamlBuild...

> I am also intimately familair with the automake/ 
> autoconf/libtool set. Since these tools are so flexible they
> adapt to my requirements and never force me to work the way they
> are designed.

That's great but it is the writing of OCaml code that is unnecessarily 
cumbersome, not the building of it.

> > In fact mastering
> > emacs, vi, etc. with all those "modes" also requires a lot of
> > work.
>
> I don't like emacs and vi. My editor of choice for the last 13
> years has been nedit (Nirvana Editor) which has syntax highlighting
> for dozens of languages (and it easy to add new ones or modify
> existing ones), regex search/replace and macros. Its configurable
> so over the years I have bent it into the shape I  want. The same
> goes for my Unix shell.

I assume nedit does not even have basic type throwback, let alone 
documentation throwback?

> I suspect that a lot of the people who think Ocaml needs an IDE
> are people whose primay development platform is windows.

Diversifying to Windows has certainly shown me just how far behind Unix is in 
terms of usability, productivity and modern computing environments like GUIs.

Here is an example: programming the GUI Sudoku solvers in OCaml and F# for the 
OCaml and F#.NET Journal articles. I had years of experience with OCaml but 
little experience of LablGTK2 (I did not know its API at all). I had little 
experience with F# and none with Windows Forms. Yet I wrote the F# 
implementation 10x faster because the Visual Studio mode makes it trivial to 
explore unfamiliar APIs with complete graphical throwback of documentation. 
In contrast, developing the OCaml required me to use "grep" to search the 
LablGTK2 source code distribution from the command line and ocamlbrowser to 
find definitions (but there is no way to jump to related definitions and no 
way to jump back to previous definitions). That is unbelievably tedious in 
comparison.

Provided you only want to write programs that manipulate text and maybe do 
some custom OpenGL, OCaml is awesome. But if you want to write even the most 
mundane GUI application, OCaml is a world of pain compared to the 
alternatives. This could be solved by a decent graphical development 
environment.

Mathematica has by far the best GUI I have ever seen. I think it would be 
fantastic to have such an interface available for OCaml but, as I say, the 
front-end requires tight bindings to the compiler and top-level which is not 
easy with OCaml.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e


  reply	other threads:[~2008-07-26 11:39 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-26  9:02 hmf
2008-07-26  9:19 ` Richard Jones
2008-07-28  9:58   ` Florian Hars
2008-07-26 10:03 ` Erik de Castro Lopo
2008-07-26 11:40   ` Jon Harrop [this message]
2008-07-26 12:07     ` Erik de Castro Lopo
2008-07-26 15:22       ` Jon Harrop
2008-07-29 14:16         ` Damien Doligez
2008-07-29 14:30           ` Lukasz Stafiniak
2008-07-29 18:01             ` Jean-Christophe Filliâtre
2008-07-26 12:17     ` [off-topic] was " Richard Jones
2008-07-26 15:51       ` Jon Harrop
2008-09-07 21:39     ` Nathaniel Gray
2008-07-26 11:42 ` Jon Harrop
  -- strict thread matches above, loose matches on Subject: below --
2008-07-26 12:44 hmf
2008-07-26 12:01 hmf
2008-07-26 12:25 ` Erik de Castro Lopo
2008-07-26 15:37   ` Jon Harrop
2008-07-26  9:18 hmf
2008-07-26  9:22 ` Richard Jones
2008-07-26  8:46 hmf
2008-08-20  6:29 ` Maxence Guesdon
2008-08-20 14:38   ` Richard Jones
2008-08-22  6:34     ` Maxence Guesdon
2008-08-20 16:32   ` Jon Harrop
2008-08-22  6:41     ` Maxence Guesdon
2008-09-07 23:31     ` Nathaniel Gray
2008-09-08  1:10       ` Jon Harrop
2008-09-09  5:31         ` Nathaniel Gray
2008-09-09  7:43           ` Jon Harrop
2008-09-09  7:50             ` Nathaniel Gray
2008-08-27 20:24   ` kirillkh
2008-09-02  6:49     ` Maxence Guesdon
2008-07-22 11:14 adonis28850
2008-07-23  8:42 ` hmf
2008-07-23  8:50   ` adonis28850
2008-07-25 23:56     ` Jon Harrop
2008-07-26  0:24       ` Erik de Castro Lopo
2008-07-26  2:57         ` Jon Harrop
2008-07-26 12:25           ` Romain Beauxis
2008-07-26  9:09       ` Richard Jones
2008-07-28 17:25         ` Pal-Kristian Engstad
2008-07-28 19:25           ` Jon Harrop
2008-07-26 18:12 ` adonis28850

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200807261240.10757.jon@ffconsultancy.com \
    --to=jon@ffconsultancy.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).