Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] RFC: IDE GUI, alternative development workflow

Eric, I read about it (still am). I can't figure out: is it only for
Java? Yes I want something like this but to be portable (web-based)
and not language specific. Not only to do DB logic or MVC logic or
simple function level logic (as Microsoft Robotics VPL
http://msdn.microsoft.com/en-us/library/bb483088.aspx ) but all of it.

Boris, it does not discourage me. I've recieved a lot of negative
feedback but I'm also talking to people like Jonathan Edwards from MIT
who is developing Subtext (http://www.subtextual.org/) The problem of
complex wiring (the case where wires are everywhere and you can't
clearly follow it) is that there is no context and there's a lot
visible at one time which makes an untidy workspace. A mapping of
relevant tasks can help the computer to hide irrelevant things when
you are at certain point.

Also this interface is not close to final. I guess that if a designer
(not software engineer) works on this problem eventually there will be
a good solution. All the ergonomics and HCI point that visual work
environment is the best scenario.

By GitHub do you mean my own repository or to become contributor to a
specific eclipse related account?

All the best,
Anton Stoychev,
Internet Engineer



On 14 February 2011 21:52, Boris Bokowski <Boris_Bokowski@xxxxxxxxxx> wrote:
> Hi Anton,
>
> Thank you for your email, I appreciate the effort you put into it. I hope
> you don't mind when I respond in a very frank way. Don't let my feedback
> discourage you, if you don't like it feel free to file it under "an old
> smalltalk dude's irrelevant opinion".
>
>> Main benefits of this approach are:
>> - you are not writing code
>
> Here in our office in Ottawa, a common saying is "Just write the code!" [1].
> What we mean by this is that you are kidding yourself if you think you can
> avoid writing "the code" by introducing one more layer of abstraction, or
> going meta. In the end, to have the computer do what you want it to do, "the
> code" has to be there in some form. So if you add abstractions or
> indirections, these will be there in addition to "the code". In many cases,
> just writing "the code", and not more, results in the simplest solution.
> Easy to write, easy to understand, and easy to change.
>
>> Main developer interaction is by dragging and dropping which can
>> create links/wires (see http://neyric.github.com/wireit/ for
>> reference). The screen real estate (the workspace) is managed by
>> panning and similar approach as Code bubbles
>> (http://www.cs.brown.edu/people/acb/codebubbles_site.htm). Method and
>> function parameters become slots where you can drop data.
>
> These are interesting approaches. However, I am highly skeptical, because
> from my experience, 2D wiring of components often results in configurations
> that are hard to grasp visually even though they could be expressed
> succinctly in textual form.
>
> Rather than targeting the e4 project, have you thought about creating a new
> project on http://eclipselabs.org or on GitHub? To "sell" your idea to the
> existing e4 committers, it might be useful to be able to point to something
> that is in a demoable state.
>
> Good luck!
> Boris
>
> [1] I've first heard this from Steve Northover, but I am not sure if the
> quote is his own.
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>


Back to the top