<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><snipped and shortened earlier thread></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, Jan 31, 2014 at 1:00 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Fri, Jan 31, 2014 at 11:40 AM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi Joe,<br><div class="gmail_quote"><div>On Fri, Jan 31, 2014 at 8:49 AM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>On Fri, Jan 31, 2014 at 7:50 AM, Michael Turner <span dir="ltr"><<a href="mailto:michael.eugene.turner@gmail.com" target="_blank">michael.eugene.turner@gmail.com</a>></span> wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">One thing I've gotten out of this excellent thread: given what some<br>
people (but not Joe, I guess) want out of a programming environment,<br></blockquote><div><br></div></div><div><div>What I want in a programming environment would take a book to describe.</div><div><br></div><div>For starters, I would like it to be precisely documented.</div>
<div><br></div><div>It should be textual not GUI based - the reason for this is automation - I cannot</div><div>easily automate things if they are GUI based. I can automate things if they are text based.</div><div>Also It's very difficult to describe what to do in a GUI - the descriptions need pictures</div>
<div>to tell you what to do.</div><div><br></div><div><br></div></div></div></div></div></blockquote></div><div>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...</div>
</div></div></div></blockquote><div><br></div></div><div>I guess I'd like to be able to run eclipse headless (whatever that means)</div></div></div></div></blockquote><div><br></div><div>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? </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>I just want to enter things in a file using my favorite editor and then say (in the command line)</div>
<div>> do_the_stuff_in_the_file <file><br></div><div>and get a file back with stuff I can read. The stuff in the file will tell me what went wrong.<br></div><div>It's an added bonus if both the inputs and outputs are easy to parse.<br>
</div>
<div>This way I can automate everything with programs that manipulate files.</div></div></div></div></blockquote><div><br></div><div>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). </div>
<div><br></div><div>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. </div>
<div><br></div><div>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? </div>
<div><br></div><div>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. :-) </div><div><br></div><div>[*] 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.</div>
<div><br></div><div>regards,</div><div>Vlad</div><div><br></div></div></div></div>