>I'm starting this comment with the letter I. I don't know who decided that we needed a symbol for that particularly combination of sounds, or why they decided it would sometimes look like a vertical line with optional top and bottom bars and other times look like a shorter vertical line with a dot over it. That all seems incredibly arbitrary. In fact, every symbol I'm using to express this idea is incredibly arbitrary.
We simply differ extremely on this, and it’s fine. Let me explain, though.
On the symbolic level, "my mind" will be eager to know where the symbols come from, what are the proposed histories of their formation through time. It’s a great way to gain completely unrelated knowledge. That is, unrelated in a discipline domain driven manner. Sometime it does come with some additional insights on the domain itself, or at least goes back to some references to the domain itself. For example the equal symbol (=) was selected because "nothing is more equal than two parallels lines".
On the representational level, the term "I" can be a very misleading one. Striving to supersede it completely in all utterances is an interesting challenge, one that can open original perspective compared to the most mundane ones. Seeking to put apart the "current conscious attention", which can detach itself from all the illusions that that often entangled in the term "I", is a rich and profound experience. For casual chitchat, it’s still nice to use "I", which can be a quick efficient way to make others aware that there are some emotions and personal engagement put at play in the exchange.
> I would much rather write "A⇒B" than "A implies B" 100 times on a page.
Wouldn’t it be even much better to do none of this? In Ruby `100.times do puts 'cause implies consequence' end` is valid code that will do that without any painful effort to make the aimed page.
If it’s too painful to produce the specimen that is aimed, the way it’s produced is to be reconsidered more importantly than the usability of the aimed specimen.
>using a symbol reinforces that we're referring to a strict mathematical interpretation and not the vagaries of ambiguous English
Using terse scriptural symbols per se doesn’t prevent to go into esoteric non-sense. And anything that can be expressed in graphical symbols can just as well and as clearly expressed in any spontaneous language if given the same careful attention.
It’s not like having the option to use terse scriptural symbols is always necessarily bad. It’s fine to have options and be aware of tradeoffs we are using one or the other. Going back to the previous Ruby snippet, `puts "cause implies consequence\n" * 100` works just as well, and might be more convenient to type in an interactive console, while the previous version might be a wiser selection to integrate in a large code base which strive to keep maintainability at its highest level.
> Wouldn’t it be even much better to do none of this? In Ruby `100.times do puts 'cause implies consequence' end` is valid code that will do that without any painful effort to make the aimed page.
Presumably it won’t be the only content on the page, the statements are going to be inside various other statements. Also I’m not sure how you’d execute Ruby code on a Blackboard.
> Using terse scriptural symbols per se doesn’t prevent to go into esoteric non-sense.
Who said you’d have to “go into esoteric non-sense”, whatever that means?
> And anything that can be expressed in graphical symbols can just as well and as clearly expressed in any spontaneous language if given the same careful attention.
Okay, but why woutd you want to use a word if a simple symbol does the trick? You have to define what it means either way and symbols have the advantage that you don’t need to translate them between languages.
We simply differ extremely on this, and it’s fine. Let me explain, though.
On the symbolic level, "my mind" will be eager to know where the symbols come from, what are the proposed histories of their formation through time. It’s a great way to gain completely unrelated knowledge. That is, unrelated in a discipline domain driven manner. Sometime it does come with some additional insights on the domain itself, or at least goes back to some references to the domain itself. For example the equal symbol (=) was selected because "nothing is more equal than two parallels lines".
On the representational level, the term "I" can be a very misleading one. Striving to supersede it completely in all utterances is an interesting challenge, one that can open original perspective compared to the most mundane ones. Seeking to put apart the "current conscious attention", which can detach itself from all the illusions that that often entangled in the term "I", is a rich and profound experience. For casual chitchat, it’s still nice to use "I", which can be a quick efficient way to make others aware that there are some emotions and personal engagement put at play in the exchange.
> I would much rather write "A⇒B" than "A implies B" 100 times on a page.
Wouldn’t it be even much better to do none of this? In Ruby `100.times do puts 'cause implies consequence' end` is valid code that will do that without any painful effort to make the aimed page.
If it’s too painful to produce the specimen that is aimed, the way it’s produced is to be reconsidered more importantly than the usability of the aimed specimen.
>using a symbol reinforces that we're referring to a strict mathematical interpretation and not the vagaries of ambiguous English
Using terse scriptural symbols per se doesn’t prevent to go into esoteric non-sense. And anything that can be expressed in graphical symbols can just as well and as clearly expressed in any spontaneous language if given the same careful attention.
It’s not like having the option to use terse scriptural symbols is always necessarily bad. It’s fine to have options and be aware of tradeoffs we are using one or the other. Going back to the previous Ruby snippet, `puts "cause implies consequence\n" * 100` works just as well, and might be more convenient to type in an interactive console, while the previous version might be a wiser selection to integrate in a large code base which strive to keep maintainability at its highest level.