Re: Report from the LuxAsm mailing list for Betov

Frank Kotler <fbkotler@xxxxxxxxxxx> écrivait news:426E3AB9.67214302
@comcast.net:

> As far as the "ASCII chart" (or "unicode chart" or any other
> module) bringing the whole shebang down... Ideally, we'll be
> "decoupled" enough so that this doesn't happen, but
> "coupled" tightly enough to enjoy the advantages of being a
> "fully integrated" environment. Beth thinks we can have
> "both". I suspect we'll end up in a situation where certain
> modules crashing *will* bring the whole mess down, but we
> can arrange it so that not "much" work is lost, even in the
> "worst case".

First, there is no such problem as "lost work", with an
integrated Environement. This is delirium, because,

1) The Programmers do not write for 2 hours without a
Compilation.

2) There are much better and way more ensured way for a
programmer to loose his work than because of a fault of
the Environnement. The best enemy is the Programmer himself,
who can, as well, delete his Files without having branched
his brain in the morning, and making the Trash Empty. A very
efficient method. Also, when typing too long, the Programmer
can simply loose track on what he is doing, and completely
pervert his Source, in such a way that, best is, for him,
to close all, and to restart from scratch.

Second, maybe it is possible to have "both", but, with this,
it goes the same way as with acoustic physic science, that
is, if you have one violin with a given volume, and that
you want twice more volume, you need _ten_ violins! Not two.

Same is it with complexity. One Complexity is one Problem.
Two complexities are ten problems.

So, considering that writting such a MONSTER, as an Assembly
Developement Environement, for writing real life Applications,
is around 10 years of work, if you come with a working LuxAsm
in one Century, i am afraid you will be a bit... late.

You CANNOT plan all the features that you will implement.
In a Brick & Brock Thingie, each implementation that will
envolve several "Decoupled Component" will be a true hell,
whereas, in a really Integrated thingies, like RosAsm,
implementing something that had never be planed, and that
envolves different components is very easy. Recently,
Ludwig (the Maintainer of the Debugger), told me that he
was in need of the Equates Values, for resolving some
Memory addresses. Example, at Debug-Time, if the User's
Mouse is over:

mov eax D§Symbol+EQUATE

There is a ToolTip supposed to show the Value, in Memory,
like it is done on any other source Instructions like this.

Well, to provide him with the wished access, it was 15
minutes of work, for me, _because of the Integration_.
In a Brick & Brock thingie, good luck for doing something
like this in 15 Minutes.


Betov.

< http://rosasm.org >


.

Relevant Pages

  • Re: Report from the LuxAsm mailing list for Betov
    ... One Complexity is one Problem. ... > Developement Environement, for writing real life Applications, ... > In a Brick & Brock Thingie, ... > minutes of work, for me, _because of the Integration_. ...
    (alt.lang.asm)
  • Re: WInForms to VCL converter
    ... to the programmer as exercise;-) ... work is integration of the GUI to "real code" and it might have ... Brain Endeavor LLC ...
    (borland.public.delphi.non-technical)