Re: [all] Modern Development

On 2007-04-17 23:11:36, Xiong Changnian <please@xxxxxxxxxx> wrote:

In article ,
Kenneth 'Bessarion' Boyd wrote:

Your proposal got cut off because
it was (unintentionally) flamey.

No, it was intentionally terse and direct. I'd like to think that at a
certain age, .... and no, I won't take offense.

If I thought your proposal was theoretically untenable, I wouldn't comment.

I won't address the implicit
assumption of top-down design...

Why not? I disavow the label, though.

It was a best extrapolation, and one that was somewhat questionable in context.

The API needs to be thrashed out before any serious module work can be
done. Otherwise, well-written modules blow up when the API changes.

There will be a cycle, early on, of demo modules and API revisions --
the API specs must serve the modules. Every developer needs to bring his
needs to the table and see them addressed. Eventually, though, the API
must settle -- before serious module writing can proceed.

May I assume you are aware of XP and/or Agile programming?

In those paradigms (concrete versions of the evolutionary software lifecycle),
the API cannot be thrashed out except in conjunction with serious module work.
They also reduce the number of programmers you need compared to more normal
techniques...it would be worth considering adapting at least parts of.

...I want to improve the V API to
something transparent.

Well, then, you'd think we'd be on the same page. But I think you are
still in the incremental improvement camp. I want to start over.

I'm more comfortable with radical refactoring, yes. But I see no intrinsic
conflict with putting time into both approaches.

....

...Total change of implementation language...

Yep. Even more radically, I envision a multiple-language development. So
long as the stuff compiles and presents the appropriate features to the
API, I don't care what the source looks like.

This last point, I think, got lost in the shuffle. Traditionally, we
assemble modules, then compile. I want to compile each module
standalone, then integrate them with a metamodule.

Or with a linker ;)

The obvious argument against this is that it's woefully inefficient. I
say modern hardware is powerful enough to overcome the penalty.

That is so *inobvious*; in principle, there should be no efficiency loss from
linking across different languages within the same compiler vendor. And there
is no efficiency loss for both Microsoft and GNU compiler suites.

Considering the examples of Java/Jython and the intended example of Parrot, I
think "in principle" will also apply to bytecode-compiled languages
.

Relevant Pages

  • Re: Some questions; SHMenuBar, multilingual prog
    ... It's possible that any given API is specific to a given device or class ... > and the VCE language reference. ... one for German and one for English. ... I compile and get German, then enter a symbol for the resource ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Lebans Calendar Problem - Doesnt work on some computers
    ... "UserCreateBackendBackup" code which I use to backup my Back Ends. ... bit that calls the Windows File Save Dialog is ignored on that ... I'm thinking it may be a problem with the Windows API calls but I'm ... first try to compile the code (Debug - Compile from the VB edit ...
    (microsoft.public.access.formscoding)
  • Re: [PATCH] Re: [PATCH 4/4 v2] [RFC] UIO: generic platform driver
    ... This is part of a generic API defined ... platform dependencies. ... Unfortunately, I tested on x86_64, and it doesn't compile. ... Only that the kernels Kconfig is turning into a real complicated mess ...
    (Linux-Kernel)
  • Tcl Dll problem
    ... information system developed in TCL. ... In Windows I can compile the APi without an error, ... program starts(the same thing is in linux version). ...
    (comp.lang.tcl)