Re: Project systems (again)

[Daniel Colascione]

On 04/18/2014 12:50 AM, Eli Zaretskii wrote:
>> Date: Fri, 18 Apr 2014 00:07:20 -0700
>> From: Daniel Colascione <address@hidden>
>> CC: address@hidden
>>
>>> FWIW, I'd prefer that you work with EDE developers to improve and
>>> extend what they have;
>>
>> If EIEIO can't be preloaded (or, equivalent morally, autoloaded on
>> find-file), there's no point in pursuing EDE improvements. An EIEIO-less
>> EDE would be an EDE rewrite anyway.
> 
> I don't know enough about this: why couldn't EIEIO be autoloaded?

Stefan was against it the last time this issue came up. There are
namespace cleanliness issues as well as deeper issues of functional
appropriateness.

>> Plus, I don't think the problem space really warrants a complex
>> object system: conventional elisp idioms are adequate.
> 
> Since EDE is already there, I think this is a moot point.  (I believe
> Eric explained why this design was chosen a while ago.)

It's there, but it hasn't seen wide use. The existence of non-EDE
projects like Projectile should tell us that EDE, as it stands today,
isn't well-suited to being a default project system.

>>> starting from scratch (or almost from scratch)
>>> sounds like waste of effort, especially since some of the EDE is
>>> already in Emacs. 
>>
>> I really don't want to start from scratch, but I think it's the best
>> option. A project system is one of those systems for which the hard part
>> isn't the coding, but agreeing on having a single interface to the code.
>> I think we need something much simpler than what exists.
> 
> Then how about asking the EDE developers to provide an "easy-ede"
> layer which would conceal the complexity for those situations where
> the corresponding power is not needed?

That's what I'm proposing, except that I imagine EDE can sit on top of
that layer, not that that layer could sit on top of EDE.

>> I find the abstractions in EDE to be much more confusing than they are
>> useful. For something that, at its core, ought to be very simple, there
>> are too many concepts --- target, project, sub-project, config, project
>> placeholder, too much shared state, and too few opportunities for ad-hoc
>> customization. The system feels specialized for a project based on
>> nested autoconf files that build C and C++, and the documentation
>> reflects that. I understand that EDE started simple and grew
>> functionality, but this functionality belongs in separate layers, not
>> mingled into the core.
> 
> I see your point.  However, EDE was added to Emacs with the intent
> that it serves as basis for developing features such as what you have
> in mind.  If there's a reasonably practical way of basing your project
> on EDE, I think we should explore that possibility first, even if it
> requires more work on the EDE infrastructure side, because not doing
> so would waste the effort of integrating EDE into Emacs.

I was afraid of an argument of this form --- it's just the sunken costs
fallacy, isn't it? The fact that effort has been put into EDE shouldn't
influence our evaluations of present alternatives. I don't think using
EDE as a base would reduce the amount of needed work. I actually think
it would increase it.

signature.asc
Description: OpenPGP digital signature