Having a bit if fun on stackoverflow

[Idan Arye]

On Thursday, 27 June 2013 at 21:56:00 UTC, H. S. Teoh wrote:
> On Thu, Jun 27, 2013 at 11:48:15PM +0200, Idan Arye wrote:
>> On Thursday, 27 June 2013 at 20:43:47 UTC, H. S. Teoh wrote:
>> >That's something I never really understood about the Windows 
>> >/ GUI
>> >world. The backend functionality is already all there, yet 
>> >for some
>> >strange reason the application refuses to have the means to 
>> >access
>> >that functionality, requiring instead for you to install 
>> >"plugins".
>> >To me, a "plugin" should *enhance* functionality by adding 
>> >what
>> >wasn't there before, but in this case, it seems to be more 
>> >about
>> >removing artificial barriers to reveal what has already been 
>> >there
>> >all along. Same thing goes with the iPhone emoji apps, and 
>> >many other
>> >such examples.
>> >
>> >As a CLI-only person, I find this really hard to grok.
>> 
>> With the popularity of XML build systems, that shouldn't be 
>> that
>> hard for an IDE to provide you with a GUI to edit the targets 
>> and
>> make complex build processes. I would have expected big IDEs 
>> like
>> Eclipse to have that feature...
>
> Yeah, what with all the fancy code-editing features, you'd 
> think having
> a built-in XML editor would be easy...
>
> XML is a pain to edit by hand, though, if your editor doesn't 
> understand
> XML. It's sorta like Java and IDEs; in theory, you *can* write 
> Java with
> nothing but pico, but in practice, it's so verbose that it's 
> only
> tolerable if you use an IDE with autocompletion.
>
>
> T

I'm not talking about an GUI XML editor here - I'm talking about 
a buildfile editor. One that is familiar with the common tasks 
and let you edit them with a GUI menu. Ofcourse, it should also 
be expandable with plugins to deal third party tasks, and have a 
way to deal generic tasks, but having a GUI for the common tasks 
is the key.

Eclipse already have an textual XML editor, and it has 
autocompletion for Ant's build.xml, but it's much easier to 
configure an Eclipse run configuration with a configuration menu 
than to edit the Ant target with a text editor, so most users 
will prefer to use the IDE's build function.

It's also important that the IDE will use this build system by 
default. When you open a new project, it should automatically 
create a buildfile, and only store in it data that needs to be 
shared between developers. If the IDE needs to store other data 
that is only relevant locally, it should be in a separate, 
unversioned file - otherwise this data will create redundant, 
hard-to-solve merge conflicts.


The IDE needs to have both features:

If the IDE does not use the proper build system by default, most 
developers will use the default build function, and when they 
reach it's limit they'll have a hard time switching to the proper 
build system - and many might choose not to switch, and will use 
bad solutions that introduce technical debt.

If the IDE does not have a GUI configuration tool people will 
simply not use the IDE. IDE users don't like having to edit the 
build configuration with a text editor - not when most IDEs have 
nice GUI for it. People who prefer the powerful edit-by-text 
build system over the crippled edit-by-GUI one usually prefer 
text editors over IDEs anyways.