81–90 of 291 posts
If it's not on the keyboard, nobody is going to type it. Solutions: a) only use characters in the intersection of the top N most popular keyboard layouts b) issue programmers' keyboards with an agreed character set c) issue programmers' keypads with supplementary characters d) add on-screen supplementary keypads
Earlier quoted context omitted.
A variable named ω is no better than a list named l. Both are bad. Be explicit. Terse, but explicit.
Part of the problem here is that a variable in mathematics is a different concept from a variable in programming. Mathematicians are used to using one letter variables. Using a set of unwritten naming rules, mathematicians almost always know what concepts the variables are referring to (in a mathematical context). So, I'd say if the code is only to be maintained by mathematicians, one letter variables for mathematica…
> Using a set of unwritten naming rules
Simplest being things like using upper case Greek for certain sets and lower case Greek for its elements. Or, in Statistics, using Greek letters for parameters and English equivalents for their estimates.
So, if I were programming something to do something in that realm, I would write:
for my $ω ($Ω) {
# ...
}
Then, of course, you get people like one of my former professors who liked to invent notation on the fly and would quickly and up cycling through Greek (π, Π), Hebrew (פ), Blackboard (ℙ), and reach out for Sanskrit (?). (Symbols used here for illustration, this was a long time ago and we didn't even know if he was correct as we had no way of checking with no intarwebs back then.)
Unison’s core idea is that code is immutable and identified by its content. This lets us reimagine many aspects of how a programming language works. We simplify codebase management — Unison has no builds, no dependency conflicts, and renaming things is trivial.
Some blog posts by the author of the language describing a bit of background
https://pchiusano.github.io/2013-05-22/future-of-software.ht...
https://pchiusano.github.io/2013-09-10/type-systems-and-ux-e...
The Unison language stores code as a syntax tree and they're planning to support multiple alternative syntaxes for the language. https://www.unisonweb.org Unison’s core idea is that code is immutable and identified by its content. This lets us reimagine many aspects of how a programming language works. We simplify codebase management — Unison has no builds, no dependency conflicts, and renaming things is trivial. Som…
The Unison language stores code as a syntax tree and they're planning to support multiple alternative syntaxes for the language. https://www.unisonweb.org Unison’s core idea is that code is immutable and identified by its content. This lets us reimagine many aspects of how a programming language works. We simplify codebase management — Unison has no builds, no dependency conflicts, and renaming things is trivial. Som…
Identified by its content how?
I guess built-in things get fixed names / hashes, and the hashes of everything else follow from that.
They need a mapping from content/hashes to human-friendly names, obviously. Not sure if they gained anything here, but they seem to think so, so might be worth checking this out.
If it's not on the keyboard, nobody is going to type it. Solutions: a) only use characters in the intersection of the top N most popular keyboard layouts b) issue programmers' keyboards with an agreed character set c) issue programmers' keypads with supplementary characters d) add on-screen supplementary keypads
The best thing about using only ASCII for the main syntax is that everyone can type it with their keyboard. I think the recent fad of supporting Unicode identifiers is misguided. Of course, Unicode should be permitted in string literals, but not in the code itself. *Also I don't think Go is better than modern C++, though it might be better than C++99 which was the main standard when the article was written.
But "everyone" doesn't have the same keyboard nor does everyone speak the same language. ASCII is not a universal character set and treating it as such is nothing short of cultural imperialism: "If it's good enough for us, it's good enough for everyone". Artificial limits on language and characters sets might sound simple to you but it introduces a lot of complexity for others. Unicode code solves that problem with n…
We need to break free from the tyranny of the characters on our keyboard, and express ourselves using characters not on our keyboard.
So I hope you see why that argument keeps failing.
This will work once we have keycaps with e-ink or similar technology and this will be super cheap for everyone. Then we all will have keyboards with infinite number of characters and new chapter of typing will begin.
Earlier quoted context omitted.
Identified by its content how?
Hashing, like in Git I guess built-in things get fixed names / hashes, and the hashes of everything else follow from that. They need a mapping from content/hashes to human-friendly names, obviously. Not sure if they gained anything here, but they seem to think so, so might be worth checking this out.
Bugfixing and identity matter.