Re: From the LuxAsm list.

From: T.M. Sommers (tms_at_nj.net)
Date: 08/16/04 

Date: Mon, 16 Aug 2004 19:54:54 GMT

Beth wrote:
> T.M. Sommers wrote:
>
>>If it were my project (and obviously it is not), I would not even
>>create an IDE, but would create a LuxAsm mode for emacs. I do
>>not want to waste time and effort building an editor when one
>>already exists much better than anything I could build, or
>>building a make tool, or a versioning system.
>
> But what if the editor _IS_ better?

Is that likely? Will your editor be able to do everything emacs
does (all its editing-related functionality, that is), or even
everything vi does? Will it be as programmable as emacs? Sure,
it will probably be better than notepad (what isn't?), or the
default CDE editor, but *real* editors do a lot more than those.

> The one proposed has "feedback" incorporated...it eradicates "assemble time
> / speed" by adopting a different style of approach to the problem...things
> that other editors simply do NOT typically provide...

Take a look emacs's lisp interaction mode.

> No, you've missed the point with LuxAsm...the method of "integration" is
> not as you belive...each of the tools is a quite _separate_ model that does
> one thing and attempts to do it as well as possible...the "integration" is
> only a user interface thing...

Fair enough.

> If you like, it's a "visual shell script" with multiple "command-lines"
> hidden behind the press of a toolbar button...in the sense that the IDE
> provides buttons which perform the operation of calling all these tools in
> the required sequence to complete a more complex task...the actual toolset
> itself is a series of separate "modules" that simply "link" into the main
> IDE interface...

Then you ought to be able to use existing tools as your 'modules'.

> Indeed, is GCC violating this "UNIX philosophy"? Because it automatically
> calls tools like "ld" or "ar" or whatever to perform its work of compiling
> the C / C++ (or one of the other supported languages) source code into a
> working executable (though you can ask only for compiling but no linking
> and so forth too)...

Not it isn't, because it uses those pre-existing tools, which are
not necessarily the ones that came with gcc.

> Although, what's a touch hilarious is condemning these ideas and then
> proposing it be made into a "mode" for "emacs"? The beast of a thousand
> faces that "emacs" is...yeah, right...

First, I am not condemning anything. Second, it seems to me to
be plain common sense to use what is already available instead of
always building your own. Third, yes, emacs does contain a lot
of extras that are not really necessary (okay, totally useless),
but the fact that these 'features' exist is an indication of how
flexible emacs is. Almost certainly flexible enough to do what
you want.

> Plus, you did not logically back up this bizarre assertion that
> "re-invention" somehow means it'll be "twice the cost" and "twice the
> effort"?

You left out "half the functionality".

> Ummm, surely, if one is entirely duplicating what already exists
> bit for bit then the cost is the _same_ as the thing duplicated and the
> effort is the _same_ as the thing duplicated? You're just copying what they
> did before...hence, it'll be the _same_ cost and effort, roughly speaking,
> as was originally taken

The thing is, will you be duplicating everything in the
originals? Probably not; hence the reduced functionality. And
regardless of how brilliant you are, you are probably not an
expert in every field needed to create the whole integrated
shebang. Even if you know twice as much about assemblers as the
people who wrote and maintain gas, you probably do not know as
much about editors as the emacs crew, or about linkers as the ld
crew, and so forth. So it will take you longer and cost more, in
addition to doing less. And before you get your knickers in a
twist, this applies to everyone, not you particularly. 

-- 
Thomas M. Sommers -- tms@nj.net -- AB2SB