Aleksej Saushev <asau@[EMAIL PROTECTED]
> writes:
> Bruce McFarling <agila61@[EMAIL PROTECTED]
> writes:
>
>> On May 2, 2:20 pm, Marc Olschok <nob...@[EMAIL PROTECTED]
> wrote:
>>> Aleksej Saushev <a...@[EMAIL PROTECTED]
> wrote:
>>
>>> > > On Apr 30, 5:14 pm, Richard Owlett <rowl...@[EMAIL PROTECTED]
> wrote:
>>
>>> > > Then add on top the lack of a de facto library management
standard,
>>> > > and on top of that the fact that for those who only need to do a
>>> > > specific, people with a distinct set of concrete string tasks can
>>> > > solve it from scratch with tools like those in TOOL2002. If that
is
>>> > > auxiliary to their main task, then once its solved, they may
rarely
>>> > > need to revisit it. So instead of investing the time and effort
into
>>> > > learning and importing a general purpose string handling toolkit
and
>>> > > than using 5% of it, they build a much simpler special purpose
string
>>> > > handling toolkit and use 100% of it.
>>
>>> > And thus reinventing the same wheel 100 times, instead of reusing
>>> > the library written once years ago.
>>
>> Yes, I agree with you here that this *may well be an advantage* ...
>> instead of staying with the same compromises, same mistakes, and
>> oftentimes a quite obsolete set of assumptions, in, as you put
>> it so eloquently "a library written once years ago", this approach
>> means that the small portion that is actually needed can be
>> written precisely in tune with the needs of the moment.
>>
>> It is, as you imply, often a useful thing to keep working
>> at reinventing the wheel until you get it right.
>
> Low rate of code reuse reduces any utility of this to ashes:
> each new developer is forced to start from ground level and
> repeat mistakes of previous generations over and over again.
>
> I think, the the whole Forth community would benefit much from
> simple project: overview of that famous Taygeta archive.
> It will cut Forth proponents down to size, and probably force
> them to think about the high quality of software, they're so
> much proud of.
>
>> And further, as Marc notes:
>>> Well, what if it is another wheel each time?
>>
>> ... which is that 5% that is used out of the library may not be
>> the same 5% each time, and rather than having a Swiss Army knife
>> toolkit that does so many different things to a certain extent
>> that it does nothing very well, this does offer the opportunity
>> to craft the tool to the precise needs of the moment.
>>
>> However, even if I follow the strong implication of your statement,
>> Aleksej, that it is often desirable to write the code from scratch,
>> I still must insist that having that library would be handy for RAD.
>
> The rapid development is another frequent point of Forth proponents,
> let's see: string processing, list processing (if you sacrifice
> performance to speed of development, if not, add balanced trees
> and/or other more complex structures), networking, database
> connection (even simple one, Berkeley-style). Pretty many of
> usual things, you have to deal with _from_scratch_. And this is
> all basic stuff, you don't need to take care of, if you have
> ready libraries. In Forth communities I've seen only one way
> to close the gap: through FFI to C-written libraries.
>
> (Right, there's ColdForth, so what? How can I run it?
> Just to check, that it works. Any simulator?
> I am not satisfied with UDP-only approach of colorForth either.
> Besides that, colorForth presents many other impediments to its
> usage, i.e. complete absense of interoperability.)
>
> You tell me about 5% of usage, my estimation is higher, 10% at least,
> if you exclude analogues of strcat/strcpy crap (right, I live in
> the post-"rm -rf /" world). Anyway, I take your estimation, let
> it be 5%.
>
> What do these "5%" include? Memory consumption, right?
>
> Memory is cheap these days, and when it isn't, you can go and
> remove unused definitions by hands, if you don't have tools for
> this purpose (C, C++, FORTRAN have them, and I don't even know,
> how precisely they're invoked, "it just works"). Anton doesn't
> bother dealing with memory leaks, and I guess, he doesn't
> most of the time.
>
> What else? Nothing significant, I'm afraid.
>
> Now what the _lack_ of these "5%" include.
....
> If you don't have the source, you're searching for appropriate
> library in C, C++, FORTRAN, any other compiled language, trying
> to design reasonable interface in Forth and fighting bugs and
> deficiencies in FFI. Provided --- again!--- you want to get the
> work done in reasonable time, even wasting time on FFI and
> interface design.
I've forgottent to note.
With C, C++, FORTRAN, you don't even think about those 95% of
wasted space because:
1. You have a linker, which "just sits there and _works_",
removing unreferenced parts of the code.
2. You have shared libraries, which you run _anyway_, since they
are part of the system or common used components, like desktop
environment, or networking services.
And you don't think about FFI, since you have plenty of the code
in native language and tools to interface to the other ones,
which follow the _standard_ platform ABI (C, C++), or the
_common_ one (FORTRAN). That you have to design FFI yourself,
thus including it in the number of missing facilities, is simply
yet another incarnation of the same problem.
> _This_ is the price you pay for not having those "5%".
--
BECHA...
CKOPO CE3OH...
|
