caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Martin DeMello <martindemello@gmail.com>
To: Wojciech Meyer <wojciech.meyer@gmail.com>
Cc: Gerd Stolpmann <info@gerd-stolpmann.de>,
	Louis Gesbert <louis.gesbert@ocamlpro.com>,
	 "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: AW: [Caml-list] geany as an ocaml ide
Date: Wed, 13 Feb 2013 12:49:57 -0800	[thread overview]
Message-ID: <CAFrFfuFQYzYbH8dxBMmu+MKYrBs+3_gCHmNiZzXZVjPZFdsR5g@mail.gmail.com> (raw)
In-Reply-To: <wf38x0nrui.fsf@gmail.com>

I agree, they are definitely two separate options. Speaking for
myself, as an experienced user there are all sorts of things I want
out of my development environment (starting with vim keybindings and
really good autoindentation), but when I'm learning a language the top
thing I want is one-click compile and run. I don't want to figure out
the build toolchain and how to integrate it into my standard developer
environment until after I've decided whether I want to invest time in
the language itself.

martin

On Wed, Feb 13, 2013 at 7:41 AM, Wojciech Meyer
<wojciech.meyer@gmail.com> wrote:
> Hi,
>
> I think we should stick into two of these options:
>
> - provide a exhaustive framework for supporting editors, with possible
>   bindings everywhere, and let the community to write needed plugs for
>   the existing editors. It's already happened with OCaIDE. Looking at
>   projects like Slime for Common Lisp, our Typerex, it probably requires
>   to act as a client-server application. It's not necessary though,
>   Eclipse for Java is a primary example how excellent can be support
>   from the IDE without listening to a socket. However, the architecture
>   needs to be well thought and it must work across different APIs,
>   Eclipse, VIM, Emacs and other editors I don't know much about.
>   So in summary there are few things to consider:
>
> -- syntax highlighting and indentation - best if that worked across
>    lines of code. This is basic feature most people just need to have to work
>    on Caml code;
> -- navigation and refactoring - with an interactive support of the
>    editor - so refactor one bit and continue to the next or abandon last
>    change, etc;
> -- tooling integration - invocation of the compiler, integration with
>    the toplevel, navigation to auto-generated docs etc;
> -- completion mechanism and decent error recovery - that means we
>    probably can't use OCaml parser as it does not re-cover very well
>    from errors. What we need is to run exact OCaml parser and when it
>    fails fallback to approximate context parser, which will do the error
>    recovery then.
> -- debugging the code with help of IDE.
>
> - the second important idea, is to introduce people that are not (yet)
>   familiar with software engineering as such, and they it's their first
>   encounter with the programming. TryOCaml website does partial job of
>   dragging these people to OCaml world, however it solves very well
>   slightly different problem, it introduces people to OCaml regardless
>   previous exposure to writing code.  Here, I'm talking mostly here
>   about kids that want to write and see games in OCaml, students that
>   are interested in genuine programming but never happen to be
>   interested in tooling or they don't have time for it (or not required
>   because they are not developers) and people that chosen that their
>   first ever programming language would be OCaml.
>
> Now in my measures minimal cost would be to provide something like
> WinOCaml were, in terms of minimal editor that just does very well few
> things: editing and interaction with toplevel, compilation with one
> keystroke, basic syntax highlighting and clever enough indentation
> scheme that does not go on the way. Just forget about fancy features, if
> somebody wants them, then go for the "real editor" like before mentioned
> ones. Just discourage people for being efficient in such environment and
> they will seamlessly consider better environment. I also concur idea
> that we could support cloud editors which boomed these days over the
> web.
>
> So the basic editor -- should be just activation energy for people
> interested in learning OCaml, heard that's brilliant language but don't
> feel yet to get into maze of tooling.
>
> The first aspect - providing enough libraries and context for developing
> the future IDEs in OCaml is also the important one -- that's the
> community who should do it, not anybody else - even the community who
> are not directly related to OCaml -- that's it, think about Eclipse
> written in Java have some very nice C++ support in form of CDT. Think
> about Emacs written in Elisp which has a nice generic support for C++
> and Java in form of CEDET or JDE.
>
> So I understand the confusion here, but I think we should clearly draw
> the line between providing a framework for others to support editing,
> and very simple and domain specific editor for the beginners.
>
> --
> Wojciech Meyer
> http://danmey.org
>
> PS: tramp is also one of the must have features to me in Emacs.
>
> Gerd Stolpmann <info@gerd-stolpmann.de> writes:
>
>
>> Just to make an example: Personally, I'm still sticking to emacs
>> (although latest tuareg-mode is error-prone), mainly because it has one
>> killer feature: Tramp. You need to know that I'm often not building my
>> programs on the machine I'm sitting at, but I'm remotely logging in to
>> another machine (often over continents). Tramp is an emacs module to
>> edit files remotely via ssh/sftp.
> Yes, I also require tramp.
>>
>> My guess is that there are many other users who would profit from such
>> a feature. Nevertheless, it is not popping up anywhere else - strange
>> enough, since we left the "PC" era long ago where everything had to
>> happen locally on your own computer. The IDEs seem not to have left
>> this era, and in a time where everything moves to the cloud this is
>> really anachronistic.
>>
>> It is clear to me that many features of IDEs are more difficult to
>> implement with such a requirement, as the latency to open files is way
>> higher. But on my side there is nothing to discuss, as remotely editing
>> files is more important than anything else.
>>
>> Another point from the perspective of a professional: There is
>> absolutely no need to integrate build support into the IDE (like
>> OCamlEditor tries to do). We have already utilities for this, and these
>> are scriptable - which is a MUST-HAVE for all professional use (think
>> of continuous integration, for instance).
>>
>> Gerd
>>
>>
>> Am 12.02.2013 12:29:41 schrieb(en) Louis Gesbert:
>>> Hi,
>>>
>>> No offence taken :). OCamlEditor indeed looks like a very interesting
>>> project,
>>> with lots of features already present. But the scope and project
>>> goals are not
>>> the same though, so I think ocp-editor still has a place on its own ;
>>>
>>> One of our main goals is to make IDE bricks available publicly, so I
>>> think the
>>> projects can benefit to one another. I would be glad to borrow some
>>> widgets from
>>> OCamlEditor, and it could use automatic indentation or better
>>> toplevel process
>>> interaction.
>>>
>>> If the author -- Francesco Tovagliari -- is around here, I would be
>>> glad to know
>>> how he feels about this ?
>>>
>>> --
>>> Louis Gesbert, OCamlPro
>>>
>>> Le mardi 12 février 2013 00:24:36, Martin DeMello a écrit :
>>> > Hi Louis,
>>> >
>>> > That looks very interesting. Sorry if this seems like a rude
>>> question;
>>> > I truly don't mean it that way, but if your editor needs a few
>>> months
>>> > of work, why not work on a stripped-down interface for OCamlEditor
>>> > [http://ocamleditor.forge.ocamlcore.org/] instead? I remember when I
>>> > was learning web development I enjoyed using Evrsoft's "1st Page"
>>> IDE,
>>> > which had modes that would add or remove bits from the interface as
>>> > you progressed from beginner to power user, and something like that
>>> > would be very nice to have for OCaml.
>>> >
>>> > martin
>>> >
>>> > On Mon, Feb 11, 2013 at 3:40 AM, Louis Gesbert
>>> >
>>> > <louis.gesbert@ocamlpro.com> wrote:
>>> > > OCaml is definitely lacking in this area; I am at the moment
>>> working
>>> > > precisely on solving this issue, with a dedicated Gtk editor that
>>> runs
>>> > > on Linux, OSX and Windows. It is pretty basic at the moment but
>>> already
>>> > > has code edition and working toplevel interaction (no compilation
>>> or
>>> > > project yet).
>>> > >
>>> > > Release is intended in a few months from now, with sufficient
>>> features
>>> > > for beginners and students. If successful, it will then be
>>> extended to
>>> > > handle bigger projects (multi-file, build system integration,
>>> etc.).
>>> > >
>>> > > Until then, you may see the project's github page at
>>> > > https://github.com/OCamlPro/ocp-edit-simple (name temporary)
>>> > >
>>> > > --
>>> > > Louis Gesbert, OCamlPro
>>> > >
>>> > > Le Monday 11 February 2013 01:49:41, Martin DeMello a écrit :
>>> > >> I spent some time last night going through all the "what is a
>>> good
>>> > >> (beginner's) ide for ocaml?" threads I could find online, and
>>> trying
>>> > >> out the various options suggested. I ruled out the following:
>>> > >>
>>> > >> * vim, emacs and eclipse (not beginner-friendly; people who want
>>> to
>>> > >> use them will know how to do it)
>>> > >> * anything that did not provide a binary install for Windows and
>>> OSX,
>>> > >> and wasn't a simple configure/make/make install on linux
>>> > >> * anything that needed fiddling with config files just to
>>> install it
>>> > >> * anything that needed the OCaml sources to be independently
>>> present
>>> > >> and configured (!)
>>> > >> * anything that was abandoned, or didn't seem to support OCaml 4
>>> > >>
>>> > >> I was left with Geany and Komodo Edit as possibilities, and
>>> Geany won
>>> > >> out by letting me open up a test.ml file and immediately being
>>> able to
>>> > >> find and run the OCaml compiler. At least on Linux, it was a
>>> perfect
>>> > >> beginner-friendly experience.
>>> > >>
>>> > >> So what do people think about ocaml.org officially promoting
>>> Geany as
>>> > >> the answer to "I'm learning OCaml; what is a good IDE?"? I'd be
>>> happy
>>> > >> to write up a page on it and contribute it.
>>> > >>
>>> > >> martin
>>> > >
>>> > > --
>>> > > Caml-list mailing list.  Subscription management and archives:
>>> > > https://sympa.inria.fr/sympa/arc/caml-list
>>> > > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>> > > Bug reports: http://caml.inria.fr/bin/caml-bugs
>>>
>>> --
>>> Caml-list mailing list.  Subscription management and archives:
>>> https://sympa.inria.fr/sympa/arc/caml-list
>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>>
>>
>>
>>
>> --
>> ------------------------------------------------------------
>> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
>> Creator of GODI and camlcity.org.
>> Contact details:        http://www.camlcity.org/contact.html
>> Company homepage:       http://www.gerd-stolpmann.de
>> ------------------------------------------------------------

  parent reply	other threads:[~2013-02-13 20:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-11  0:49 Martin DeMello
2013-02-11  1:37 ` Ashish Agarwal
2013-02-11 11:40 ` Louis Gesbert
2013-02-11 12:14   ` Gabriel Scherer
2013-02-11 12:47     ` Fabrice Le Fessant
2013-02-11 12:58       ` Gabriel Scherer
2013-02-11 13:34         ` Fabrice Le Fessant
2013-02-11 13:12     ` Daniel Bünzli
2013-02-11 23:24   ` Martin DeMello
2013-02-12 11:29     ` Louis Gesbert
2013-02-13 14:12       ` AW: " Gerd Stolpmann
2013-02-13 15:41         ` Wojciech Meyer
2013-02-13 17:09           ` AW: " Gerd Stolpmann
2013-02-13 21:17             ` Wojciech Meyer
2013-02-13 22:06               ` Török Edwin
2013-02-13 23:30                 ` Wojciech Meyer
2013-02-13 23:44               ` Jon Harrop
2013-02-13 20:49           ` Martin DeMello [this message]
2013-02-13 16:30   ` Jon Harrop

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=CAFrFfuFQYzYbH8dxBMmu+MKYrBs+3_gCHmNiZzXZVjPZFdsR5g@mail.gmail.com \
    --to=martindemello@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=info@gerd-stolpmann.de \
    --cc=louis.gesbert@ocamlpro.com \
    --cc=wojciech.meyer@gmail.com \
    /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).