1 |
On 8/27/20 11:55 AM, Ashley Dixon wrote: |
2 |
> Well said; thanks for the correction. |
3 |
|
4 |
Of course. My intention is to positively contribute to and learn from |
5 |
the community. |
6 |
|
7 |
> Mathematical notation can be seen as a tightly coupled analogue |
8 |
> to this sort of typesetting: the same book that introduced |
9 |
> Algebraic expressions (Cossike numbers) and the equals sign ('=') |
10 |
> into the English-speaking world also suggested the use of |
11 |
> the word "zenzizenizenike" to represent `x^8` [1]. Solid ideas |
12 |
> will stick due to, as you said, their own merits; the form of the |
13 |
> representation is generally redundant. |
14 |
> |
15 |
> Nevertheless, as xkcd so brilliantly explains, TeX inspires a level |
16 |
> of blind trust in the content of a document [2]. As long as you avoid |
17 |
> proposing standards in the form of an animated GIF, you're probably |
18 |
> going to be OK. ;-) |
19 |
|
20 |
I wonder if this is a side effect of the fact that TeX / LaTeX is a |
21 |
difficult markup language to work in and takes considerably more time |
22 |
and effort than simple text. As such, there is a good chance that the |
23 |
idea that someone takes the time to express in (La)TeX is probably more |
24 |
completely thought out than simple text. After all, why would someone |
25 |
spend the time and exert the effort to finely polish a half baked idea |
26 |
in (La)TeX? |
27 |
|
28 |
Disclaimer: I'm speaking in general and do not mean to imply anything |
29 |
towards Caveman's efforts. It takes gumption to go against the status quo. |
30 |
|
31 |
> I concur, but this was about the reference implementation. |
32 |
|
33 |
Do you mean reference as opposed to initial. Meaning that the reference |
34 |
implementation has had some time to grow and evolve and be optimized. |
35 |
|
36 |
Fair enough. |
37 |
|
38 |
> It would be impossible to make the initial implementation the crème |
39 |
> de la crème of all implementations, unless the protocol was never |
40 |
> intended to expand. |
41 |
|
42 |
With what little I know about statistics, I think that there is a very |
43 |
small but still greater than zero percent chance of it happening. It's |
44 |
just *EXTREMELY* unlikely. ;-) |
45 |
|
46 |
> We do see some reference implementations being used as the de |
47 |
> facto choice for supporting many standards, such as Apache Tomcat |
48 |
> as the ref. imp. for Java Servlets, but as the name would |
49 |
> suggest, reference implementations are only intended to be used |
50 |
> as a reference to developers of future implementations. |
51 |
|
52 |
I don't think anything precludes the use of the reference implementation. |
53 |
|
54 |
Given that things grow and evolve, I think it means that the reference |
55 |
implementation needs to be used /somewhere/ for the people maintaining |
56 |
it to gain experience and knowledge germane to said reference |
57 |
implementation. Granted, this can be a small subset and does not need |
58 |
to be on the front lines. |
59 |
|
60 |
> Moreover, these ridiculous restrictions only encourage various |
61 |
> implementations to deviate from the standard, adding their |
62 |
> own non-standard extensions like "HillaryMail HTML support". |
63 |
> Implementation developers are always going to add stupid things to |
64 |
> their software (just look at the GNU `typeof` introspection mess), |
65 |
> but the standard text itself should certainly not encourage |
66 |
> such behaviour. |
67 |
|
68 |
Indeed. |
69 |
|
70 |
I also think that it's important to keep in mind that sometimes there |
71 |
are external limitations that dictate what can and can not be done. |
72 |
Like the fact that communications circuits were not guaranteed to be |
73 |
8-bit clean when email (RFC 822 and what predates it) and SMTP (RFC 821 |
74 |
and what predates it). It's not any more fair to blame the authors of |
75 |
RFC 821 for not supporting 8-bit than it is to blame Sir Tim Burners-Lee |
76 |
for not including encryption when he developed HTML and HTTP. |
77 |
|
78 |
|
79 |
|
80 |
-- |
81 |
Grant. . . . |
82 |
unix || die |