caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Wojciech Meyer <wojciech.meyer@gmail.com>
To: "Török Edwin" <edwin+ml-ocaml@etorok.net>
Cc: caml-list@inria.fr
Subject: Re: AW: AW: [Caml-list] geany as an ocaml ide
Date: Wed, 13 Feb 2013 23:30:30 +0000	[thread overview]
Message-ID: <wfbobnkd0p.fsf@gmail.com> (raw)
In-Reply-To: <511C0E73.3040808@etorok.net> (=?utf-8?B?IlTDtnLDtms=?= Edwin"'s message of "Thu, 14 Feb 2013 00:06:43 +0200")

Török Edwin <edwin+ml-ocaml@etorok.net> writes:

> Don't forget that the preferred "GUI" is sometimes just a console application.
> I'm using vim to edit files in remote ssh sessions (unless latency makes it impractical), and even
> on the desktop I much prefer the console version: mostly because its
> so easy to put it into the background, do some other tasks (building /
> debugging), then bring back the editor to fix things, and so
> on. For some reason I also find it easier to switch between console tabs in Konsole than between multiple windows.

My pattern is to avoid console as much as possible, and open a buffer if
I need to. So my Emacs is usually a single monolithic session captured
in a tiling window manager, where I edit the code, send e-mails, sometimes
spawn jobs , run top-level, talk on jabber or irc and refine my patches
with magit.

Gnome-terminal is open on a different screen, just in case I find it
more comfortable to use it. (which usually happens at random times at
random days), but must say it that spawning job in terminal is much more
convenient than in Emacs. I also believe that can't live without
terminal on SSH - even though I edit my files exclusively using Tramp.

Probably your workflow is ideally orthogonal to mine, but that proves
the requirement - that such framework should be generic and scalable as
possible to cover many weird cases that tend to happen when people that
use Unix tools. Interesting idea: providing an OCaml plugin to Visual
Studio might bring up whole bunch of F# individuals that wanted to compile to
native code. There is strong move of MS to get towards the native code
instead of .net.

Also, we have some excellent UI console windowing libraries like
lambda-term or zed so maybe perhaps that is the way to go?

At least console encourages to use terminal, and it just works. There
are some famous console UI applications like Midnight Commander used by
many people.

> I agree that the focus should be on functionality, if I see an IDE with features I like my first thought would be:
>  "thats nice, now how do I make that work in Vim?".
> If an OCaml library, or even just a command-line tool is provided that implements feature X independently of the full editor,
> then its a matter of writing some editor-specific scripts to hook it up.
>
> On the other hand care should be taken when advertising the editor for beginners:
>  - if editor lacks feature X, then a beginner might generalize that to
>  "Ocaml is the language without X"

Sadly my response that it often was pointed out in the past - "OCaml is
rubbish does not have a package manager - look at my ruby gems; it just
works.". Well, yes, features and environment just takes equal time and
effort to developing a language itself, and how many years it took to
bring up OCaml to such a state? Look at, how many IDEs are for such
language like C++, and mostly they cut, and that contributes that some
people will think that C++ will be the language of their choice - they
will be scared to run Emacs, but will just approve MS Eula online to
install Visual Studio Express.

>  - will the editor be maintained with new ocaml releases?

OCaml these days  changed rapidly. Therefore having a maintaince
headache with Camlp4 I can imagine it might be an issue.

>  - once the beginner is ready to move to more advanced features, are
> they required to abandon the editor, or will it be customizable with
> plugins?

That's why the basic editor should be very limited, it took 40 years to
bring up Emacs to the current state - surely we don't want to spend another
40 years to come up with new great Emacs for OCaml (only??).

>  - once the beginner is ready to move on to using <his favourite
>  editor>, how can the features of the ocaml editor be accomplished
>  there?

The answer is: if the OCaml is popular enough and the editor of the his
choice is also popular, then might be that we will have a set
intersection, and actually some of these people will write a nice plugin
for they favourite editors. However to do this we'd first need to make
OCaml popular. The real bugs are in people that learn programming, they
tend to be not hampered by the industry and still some their dreams
about the tool they'd like to use in they daily routines. I think it's a
fair chunk of work.

>
> Also are we talking about complete beginners to programming, or
> beginners to OCaml that know other languages already?

We need to distinguish them; Usually the first needs more support, the
second one needs proper evangelising and brain washing + some impressive
project to convince them to switch over.

> I think that having an ocaml-specific editor with all the features people typically want from the IDE
> would not necessarily be bad though, in the sense that it shows whats
> *possible* for an OCaml editor. And it'd be something people can
> easily try out.
> For example Java has an IDE written in Java that people (at least
> those that I know) like a lot, unfortunately its not the open source
> one: IntelliJ Idea.

Yes, I've heard and wanted to mention. The commercial setting is
different I can't see such thing happening in OCaml community, Java
Enterprise is a strong industry and if any language needs strong support
from the IDE than IMHO Java would be placed in the first league.

> If something that has similar features and ease of use could be
> implemented in OCaml that'd be a good advertisement for the language
> itself too.
> On the other hand integrating the new features with existing editors
> *first* would IMHO probably be better.

I agree.

>
> From what I've seen at beginners in other languages they used: (on Linux) Kate,
> Emacs (using the menus, not the shortcuts), mcedit, Code::Blocks, Eclipse/Netbeans; Dev-C++ and the various
> Visual* stuff on Win32.

I didn't know Kate is still alive. Bloodshed Dev-C++ has been around
since day one I tried using C++ on windows.

> Out of those Kate seems to be the easiest to just start using, as it has a terminal too (and it supports plugins/extensions),
> but I don't know if / how well it'd work on Win32.
> Unfortunately it is the first time I've heard of Geany, haven't seen anyone use it.
>
> Best regards,
> --Edwin

--
Wojciech Meyer
http://danmey.org

  reply	other threads:[~2013-02-13 23:30 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 [this message]
2013-02-13 23:44               ` Jon Harrop
2013-02-13 20:49           ` Martin DeMello
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=wfbobnkd0p.fsf@gmail.com \
    --to=wojciech.meyer@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=edwin+ml-ocaml@etorok.net \
    /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).