| 1 |
On Wed, Aug 26, 2020 at 10:26:59PM -0600, Grant Taylor wrote: |
| 2 |
> I'm sure there are those that will disagree with me. But I don't think it's |
| 3 |
> as important how professional things look as long as they are sound ideas. |
| 4 |
> Lest it be an ad hominem attack. Which, as previously indicated is not a |
| 5 |
> good thing. |
| 6 |
> |
| 7 |
> Good ideas should be able to stand on their own. If Caveman's idea turns |
| 8 |
> out to be deemed better on it's technical merits, then the text vs HTML vs |
| 9 |
> TeX/LaTeX formatting shouldn't matter. |
| 10 |
|
| 11 |
Well said; thanks for the correction. Mathematical notation can be seen as a |
| 12 |
tightly coupled analogue to this sort of typesetting: the same book that |
| 13 |
introduced Algebraic expressions (Cossike numbers) and the equals sign ('=') |
| 14 |
into the English-speaking world also suggested the use of the word |
| 15 |
"zenzizenizenike" to represent `x^8` [1]. Solid ideas will stick due to, as you |
| 16 |
said, their own merits; the form of the representation is generally redundant. |
| 17 |
|
| 18 |
Nevertheless, as xkcd so brilliantly explains, TeX inspires a level of blind |
| 19 |
trust in the content of a document [2]. As long as you avoid proposing standards |
| 20 |
in the form of an animated GIF, you're probably going to be OK. ;-) |
| 21 |
|
| 22 |
> I would probably argue that using a mid to higher level language or even a |
| 23 |
> pseudo code for documentation / explanation might be advisable. I think |
| 24 |
> that it's more important to get the idea out, in a way that it's easily |
| 25 |
> understandable and re-implementable by others. |
| 26 |
|
| 27 |
I concur, but this was about the reference implementation. |
| 28 |
|
| 29 |
> Is it better to have the first implementation be crem de la crem and the |
| 30 |
> overall idea not be adopted? Or would it be better for the original |
| 31 |
> implementation to fade into history while the concept takes over and |
| 32 |
> surpasses current email solutions? |
| 33 |
|
| 34 |
It would be impossible to make the initial implementation the crème de la crème |
| 35 |
of all implementations, unless the protocol was never intended to expand. We do |
| 36 |
see some reference implementations being used as the de facto choice for |
| 37 |
supporting many standards, such as Apache Tomcat as the ref. imp. for Java |
| 38 |
Servlets, but as the name would suggest, reference implementations are only |
| 39 |
intended to be used as a reference to developers of future implementations. |
| 40 |
|
| 41 |
> I think trying to restrict things will do more harm to the idea than the |
| 42 |
> idea itself would do good. It's likely to cause people to reject it out of |
| 43 |
> hand as why would they want to choose something that fights them? |
| 44 |
|
| 45 |
Moreover, these ridiculous restrictions only encourage various implementations |
| 46 |
to deviate from the standard, adding their own non-standard extensions like |
| 47 |
"HillaryMail HTML support". Implementation developers are always going to add |
| 48 |
stupid things to their software (just look at the GNU `typeof` introspection |
| 49 |
mess), but the standard text itself should certainly not encourage such |
| 50 |
behaviour. |
| 51 |
|
| 52 |
Ashley. |
| 53 |
|
| 54 |
[1] https://en.wikipedia.org/wiki/Zenzizenzizenzic |
| 55 |
(My favourite thing about this mad notation is the words used to describe it in |
| 56 |
the original manuscript: "represent the square of squares squaredly".) |
| 57 |
|
| 58 |
[2] https://xkcd.com/1301/ |
| 59 |
|
| 60 |
-- |
| 61 |
|
| 62 |
Ashley Dixon |
| 63 |
suugaku.co.uk |
| 64 |
|
| 65 |
2A9A 4117 |
| 66 |
DA96 D18A |
| 67 |
8A7B B0D2 |
| 68 |
A30E BF25 |
| 69 |
F290 A8AA |
Archives