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 have source for previous projects, you're seaching,
cutting and pasting, searching for dependencies and catching
bugs from various incompatibilities. That's if you try to get
the work done in reasonable time, _provided_ you _do_ have
reusable parts in your previous projects.
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.
If the only source you have is in interpreted language, like
Python, Scheme, Lisp, any other, you have to translate it into
Forth or deploy some weird construction with IPC. Thus you fight
with two languages and, optionally, IPC, wasting your time on
anything rather than the problem itself.
Designing good interface takes from one day to a week,
translating, even mechanically, may take much longer.
The last resort, roll your own solution from scratch,
for sufficiently complex library, even provided you're ten times
more productive, this may well mean wasting of monthes.
_This_ is the price you pay for not having those "5%".
--
BECHA...
CKOPO CE3OH...
|
