Re: YAGNI, feature avalanche, 4NT compatibility, following RC, KM or... LG
- From: "Klaus Meinhard" <K_Meinhard@xxxxxxxxxxx>
- Date: Thu, 2 Oct 2008 00:44:32 +0200
FoxWolfie,
I would tend to agree with you. if this whole discussion took place upon
a background of statistical significance.
I tend to agree with this. Adding the ISO 8601 functions was nice, and
likely used by a fair number of users, as it is a standard.
I was asked for by me, seconded by Steve. 2 people. There is a standard
for Julian date too, though not from ISO.
It seems to
have triggered requests for all sorts of other date-related features
though.
Please try to be precise. It has triggered exactly one request by me for
Julian date related vars and functions, seconded again by Steve. 2
people again. BTW, it was started by a remark from Lucho.
I think anyone who frequently works with time data has already made
suitable adjustments to accommodate their own time zone offset, so
there
would be little benefit in adding that sort of thing into 4DOS itself.
I already had batch solutions for ISO weekdate etc. as I have for Julian
date (though not with the complexity Steve and Lucho discuss). Much of
4DOS' and TCC's evolution since version 4 or 5 consists of vars and
functions the user could write himself with means existing in version 4.
People
might want to think before asking for new features - is it purely for
their
own use or amusement, or will it actually benefit others.
Julian date is, as I see it, a very small but useful addition to 4DOS -
it is in general use in astronomy. Some things Lucho wrote to make 4DOS
keep up with 4NT/TCC are probably much more exotic for a command
processor - see @LCS. Have you even heard of that before? Or do we need
3 different hash functions? Who's advocating "feature avalanche" (see
Re.)?
Only because of compatibility. I'd like most batch files for 4NT to
work
also in 4DOS. What more natural than retaining the compatibility
between
two products that once had even a common codebase, not only feature
set?
Compatibility between both CPs is an illusion. I think I have a lot of
experience writing complex btms, and receiving and editing btms I
received from others. Nearly no complex 4DOS btms work without a rewrite
in 4NT/TCC. The difference in pipe handling alone makes sure of that,
and there are a few other hitches. And the other way is hopeless.
4NT/TCC now has so many features outside the scope of 4DOS that any
nontrivial batch is bound to fail. Note that I'm Talking nontrivial
btms.
I agree. retaining compatibility is a good idea. I use 4DOS on my DOS
and
Win98se machines. I use TCC/LE on NT-based machines. I like to use the
appropriate shell for whichever OS I'm using. I like knowing that
batch
files written on one machine are likely to run on the other with
little or
no modification. I think it's safe to say that abandoning
compatibility
would result in far fewer downloads of 4DOS, as many users would
simply not
upgrade to newer versions. Right now, it remains very compatible, and
I'm
happy with that. The few differences are in areas I can easily avoid
so
far.
You could do that just the same if 4DOS had more added features that
aren't present in 4NT. Just avoid them. You have to do the same if you
write a btm in 4NT and want to run it in 4DOS, too.
I have no problem with added features, as long as they don't break any
existing compatibility, they would be commonly used by many people,
and
they don't make 4DOS slower, less stable, or significantly larger. The
ISO
8601 routines seem to fit in with these preferences.
Each addition makes 4DOS larger and slower. 4NT/TCC are by now so much
larger (and slower in some respects), that one questions if Rex is doing
the right thing adding new features...
Some of the more
recent requests would not.
IYHO, pray.
Generally, if only one or two people want
something, they can define their own functions.
And they have done. See above. That doesn't preclude asking for an
enhancement of 4DOS.
If a lot of people want
something, then it should be weighed against any impact on the
program's
size, speed, stability and compatibility before being added. You've
been
doing a great job so far.
This statement ignores that there are not "a lot of people" in this
newsgroup. There are probably not a lot of 4DOS users left. You should
take a look at the actual fígures: I count about 15 different posters
for the last 4-6 weeks, about 6-8 being regulars (including yours
truly). 2 of these asked for the feature, making up 25 - 33 % of the
regulars. You are airing your own feelings, not an actual represention
of verifiable numbers.
Don't forget that the existence of a certain feature in 4DOS may put a
certain pressure on JP Software to implement that feature in TCC too.
E.G. I don't think it's likely that Rex, if he ever implements ISO
weekdate, will stray too much from what Lucho has done. A feature
implemented in 4DOS may actually hasten its implementation in TCC.
--
Mit freundlichem Gruß,
Klaus Meinhard
.
- Follow-Ups:
- Re: Feature snowball, argument avalanche, 4NT compatibility, size restrictions
- From: Luchezar Georgiev
- Re: Feature snowball, argument avalanche, 4NT compatibility, size restrictions
- References:
- Re: YAGNI, feature avalanche, 4NT compatibility, following RC, KM or... LG
- From: FoxWolfie Galen
- Re: YAGNI, feature avalanche, 4NT compatibility, following RC, KM or... LG
- Prev by Date: Re: tzset() implementation in MSC and Open Watcom
- Next by Date: Re: Feature snowball, argument avalanche, 4NT compatibility, size restrictions
- Previous by thread: Re: YAGNI, feature avalanche, 4NT compatibility
- Next by thread: Re: Feature snowball, argument avalanche, 4NT compatibility, size restrictions
- Index(es):
Relevant Pages
|
Loading