[erlang-questions] The quest for the perfect programming language for massive concurrency.

[Vlad Dumitrescu]

<snipped and shortened earlier thread>

On Fri, Jan 31, 2014 at 1:00 PM, Joe Armstrong <erlang@REDACTED> wrote:

> On Fri, Jan 31, 2014 at 11:40 AM, Vlad Dumitrescu <vladdu55@REDACTED>wrote:
>
>> Hi Joe,
>> On Fri, Jan 31, 2014 at 8:49 AM, Joe Armstrong <erlang@REDACTED> wrote:
>>
>>> On Fri, Jan 31, 2014 at 7:50 AM, Michael Turner <
>>> michael.eugene.turner@REDACTED> wrote:
>>>
>>>> One thing I've gotten out of this excellent thread: given what some
>>>> people (but not Joe, I guess) want out of a programming environment,
>>>>
>>>
>>> What I want in a programming environment would take a book to describe.
>>>
>>> For starters, I would like it to be precisely documented.
>>>
>>> It should be textual not GUI based - the reason for this is automation -
>>> I cannot
>>> easily automate things if they are GUI based. I can automate things if
>>> they are text based.
>>> Also It's very difficult to describe what to do in a GUI - the
>>> descriptions need pictures
>>> to tell you what to do.
>>>
>>>
>>> Why does automating something have anything to do with that thing being
>> textual or graphical? vim runs in a console, but also as gVim (graphical).
>> The same can be said about emacs and XEmacs. Eclipse can be run in headless
>> mode (but I admit that there are rather few tools that work in that mode).
>> To me, a tool can be automatable at two levels: it can be run from the
>> command line and it might return meaningful data that some other tool can
>> process further. I don't see what this has anything to do with the tool
>> being textual or graphical. These parts are just the presentation layer...
>>
>
> I guess I'd like to be able to run eclipse headless (whatever that means)
>

It  means that there is no GUI. "eclipse -application myapp" gives stdout
data, or creates files or whatever. Of course, there are few tools that are
available like that, but my point was that it is possible. I suppose there
isn't enough pressure from the users?


> I just want to enter things in a file using my favorite editor and then
> say (in the command line)
> > do_the_stuff_in_the_file <file>
> and get a file back with stuff I can read. The stuff in the file will tell
> me what went wrong.
> It's an added bonus if both the inputs and outputs are easy to parse.
>  This way I can automate everything with programs that manipulate files.
>

This is kind of what my "IDE-as-a-set-of-core-tools" vision aims at too.
Point the tool at a project and let it build a (conceptual) database over
the whole code (all files, libraries, documentation, etc). Then have a
bunch of utilities that can refine and process this data, resulting in
diagrams and reports (xref, code outlines, process dependencies), local
information for editors (autocompletion, code pattern suggestions, relevant
docs), new code (refactorings), and more. At a higher level, the tools
could try to understand what the code does and so provide runtime support
(runtime process/thread/object dependencies and interactions, debugging).

Some of these tools exist already as separate entities, but there's a lot
of duplication of work and no synergy[*]. An IDE can make use of the common
things that all these tools need so that the tool makers can focus on
writing new and better tools instead of writing yet another parser or such.
I'm in the camp that rather buys a wheel from a wheel-maker than building
one myself from scratch even if I could, I think it's a better use of the
effort.

You mention pen-and-paper diagrams. These are perfect when designing, I use
that a lot too, but they only show what one wants to implement. How can one
be sure that the result follows that diagram? Wouldn't it be useful to be
able to let tools draw a diagram of what it really looks like and compare
it with the original one?

Just because IDEs don't do that today, it doesn't necessarily mean that
IDEs are evil. They just need work and input from users. :-)

[*] This word has lost a lot of the hype from 10 or 15 years ago, so I
think it's safe to use once again.

regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140131/8c547293/attachment.htm>