Not necessarily advocating for unidiomatic python/code, but you could use a decorator to automatically wrap the function call with a try-catch and package the return value appropriately. Lot less mangling of function bodies that way, just return and raise exceptions like normal. You *could* specify the expected Exception type, but considering the rest of the ecosystem probably won’t be following along with documenting expected exceptions, I assume it wouldn’t be worth it and would be more straightforward that all the exception types in the signatures be the plain vanilla Exception. Would also be super inefficient pre-3.11 but ¯\_(ツ)_/¯
The fact that kebab-case support is a rarity constantly boggles my mind, nevermind that it isn't the de facto default for any language created after *sh/lisp. Readability, ease-of-typing, parallel with the way it's used in (Romantic) natural language. If I were writing a new language I intended to popularize this would be one of the features I would emphasize.
Spicy semi-snarky aside: if your counterpoint is that kebab-case prevents crushing your arithmetic operators together, I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself).
Make your language syntax require whitespace around arithmetic operators, and then we can finally live in a glorious paradise of kebab-case and `foo/bar` for namespaces.
Everybody forgets about shell scripts! Bash allows dashes in executable names (how it couldn't) and in function names, but not in variable names, at least not without a lot of effort.
I actually have a toy language that uses emojis for keywords, allows me to reduce tokenizing to basically "split by whitespace, split into runs of characters of the same class (every character is its own class except for [A-Za-z0-9_-] which make up a single class), then post-process tokens for finer distinctions". Strings are somewhat more painful, but using \q instead of \" to escape the double quotes helps.
I mean, not even a bad idea. I would honestly prefer operators to be more explicit like a-variableanother-varsomething-else. (EDIT: HN removed my emojis, but imagine a plus/minus emoji inbetween ids :( )
With a good font it would basically look similar to what a good IDE with syntax highlighting already does (different color for operators).
I think this would be a bad idea because emoji are hard to type.
This might be a bit old school but I prefer things limited to plain ASCII. There's only so many keys on a keyboard and want to be able to touch type everything without thinking or looking at a special emoji bar.
That I absolutely agree with, but I think it is about time we let go of “programs as plain text” axiom. With good tooling/IDE — which are already sort of visual editors only converting to and from to plain text on save — you could enter a ‘+’ and get autocomplete show the “emoji +” as an option for example. Because the actually important question to ask here in my opinion is “what is the easiest way to read/comprehend programs”, and we seem to have implicitly agreed that syntax highlighting is already a must (which works on even not yet valid program text!). Slightly more reliance on tooling doesn’t seem too bad to me.
I think you're maybe just a little confused, or I'm missing something. Kebab case is in general not viable to implement unless you have very a special/quirky syntax, because there is no way differentiate to `a-b` from `Id("a-b")` and `Subtract(Id("a"), Id("b"))` from syntax alone. Now, there are of course options that introduce trade-offs.
First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with.
Another option is to require a space between operators. E.g. you are not allowed to write "a+b" to mean "add a to b". You have to write "a + b". This is used in Agda programming language. This is very useful because then you can have identifiers like "a+b", or even identifiers like "a+[b+c-d]" etc... As long as any char doesn't have a special meaning (e.g. in Agda "(", ";", "," etc have special meanings) you can use it in an identifier. The trade-off is that, well now you're not allowed to condense arithmetic operations. This may or may not be a problem, depending on the programming language designer. When you said:
> I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself).
I'm guessing your opinion is that you're ok with this trade-off. Fact of the matter is that this a very fringe syntax for any programming language to have. As an Agda programmer, I like it, and it is useful, but I'm not convinced something like this would find mass appeal.
The last option I'm aware is to have semantic differentiation. When you find a statement like "c = a-b" you need to ask two things. One, are there identifiers "a", "b" and "a-b". If "a-b" exist and "a" or "b" doesn't exist, you're all set. If all three exist, second question is, are "a" and "b" subtractible? If the answer is yes then programming language designer can choose to prioritize "a - b" over identifier "a-b". Alternatively, you can always choose to prioritize identifier "a-b" as long as it exists. I'm personally not aware of any language that implements something like this, however I have implemented toy languages that go through this, it's pretty easy. It's a matter of making the decision to introduce this type of complexity into your language.
All in all, although I love kebab case, in order to have it in your language you need to make pretty significant trade-offs. Given this, I'm not surprised any mainstream non-lisp-like language doesn't have it.
(Hot damn, that was a super thorough/thoughtful reply in a short amount of time.)
You're spot on about the quirky syntax, but I don't think it's as serious a trade-off or addition in complexity (or even a change), given that:
- (IIRC) many style-guides/formatters already enforce spaces between binary operators and their operands (but especially identifiers) and in my super-subjectively-opinionated opinion you should already be doing that even without a formatter
- I don't feel particularly strongly one way or another about any other special characters like "+", so really in this case I'm only considering the dash
- Requiring the dash be between alpha/alphanumerics makes it play nice with unary operators
- The language would be terrible for code-golfing, but that's a relatively niche application I'd definitely consider worth spurning
> First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with.
This is a gross error. In your sense, Lisp does not even have operators, only identifiers. The reason there is no confusion between "(- a b)" and "(-ab)" is the spacing that separates the three identifiers in the first case.[1]
Your comment is especially weird because you go on to discuss Lisp's approach as being "an alternative option to what Lisp does".
[1] However, Lisp does have a potential problem with identifiers that begin with a hyphen, due to the need to support literal numeric values like -3. Thus the Common Lisp decrement function is named "1-" despite not returning the value (1 - operand).
> Your comment is especially weird because you go on to discuss Lisp's approach as being "an alternative option to what Lisp does".
I assume you're talking about GP's third paragraph here. Assuming that's true, I think you've misinterpreted it: GP was talking about using infix operator notation, which is most certainly not what Lisp does.
Lisp will treat (a - b) as 5 tokens, just the same way it will treat (- a b) as 5 tokens. Infix operators are completely unrelated to this problem. What lisp is doing is determining tokens by reference to spacing (the parentheses don't need to be spaced; I believe they are reader macros but in any event they are special-cased) and then acting on the tokens. What C is doing is not that; the concept is that you eliminate all spacing before you decide what the tokens are.
So in C, there is no such thing as "a - b", only "a-b", and that's why "a-b" cannot be used as an identifier.
If you want to write your lisp in infix notation, you can, but it will remain true that (a - b) is a list with 3 elements and (a-b) is a list with 1 element, which is what matters here.
> First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with.
> Another option is to require a space between operators. E.g. you are not allowed to write "a+b" to mean "add a to b". You have to write "a + b". This is used in Agda programming language.
is kinda not good, Lisp allows "-" in names the same reason as Agda: it tokenize by spaces (correct me if I'm wrong). This may seem as a gross error for one, and an only implied who cares error which is even true if taken word-by-word, for an other.
> As long as any char doesn't have a special meaning (e.g. in Agda "(", ";", "," etc have special meanings) you can use it in an identifier. The trade-off is that
I would say the trade off is variable names like “a+b” themselves. I fail to see any reason why would I want something like that, like even in Math where the grammar is very hand-wavy to accommodate human parsing you would be insane to write that (though to be fair, math does have their own share of problem with identifiers, enumerating all the letters in different alphabets is not a sustainable solution)
Why not just give it some temporary name, like ‘t’, supposedly it is only used in a very tight scope. Haskell and similar languages often do these things with `let in ..` or `.. with t=a+b`.
Not really better at all, but I feel this is a bit contrived example. If it really is just numeric addition that just let the compiler do its job, otherwise I’m sure there are better names for whatever you actually try to do. And, random helper variables are a thing even in math, you don’t name the thing the way you calculate that thing because then you don’t spare any character.
One could also not have subtraction but simply negation, so instead of a-b being subtraction, one could have a+-b. It probably already works in most languages. Doubt it would be embraced.
Infix has nothing to do with it. We can already parse expressions of the form "x - 20". The change would be to stop interpreting "x-20" as being the same set of three tokens as "x - 20".
That is the point, though? Is "x- 20" the same as "x - 20" the same as "x -20" In the vast majority of modern programming languages, that is a yes. If you allowed dashes in the names, not so much.
Now, I grant the point that it is doable. But the point is it complicate things. Now, fair, we have some of these complications already by virtue of the fact that we allow numbers in variable names. "foo3" is already allowed in many languages, and that clearly gets altered as you add space between the characters.
> Is "x- 20" the same as "x - 20" the same as "x -20"[?] In the vast majority of modern programming languages, that is a yes.
Is that really true? I wouldn't exactly feel comfortable with "x -20", though I suspect you're right about at least a large number of languages determining the meaning of the hyphen through local syntactic context ("I just saw an identifier; that must be a non-unary hyphen").
Now I'm interested in whether the corpus of existing code shows any bias between "y = -x" (perfectly allowed, I think) and "y = -1 * x".
Distinguishing unary minus from binary minus is not done by spacing in parsers. Most modern language parsers ignore whitespace except where it would cause the concatenation of two identifiers (or in the case of languages like python or nim, where it is at the beginning of a line).
I know this for a fact since I've studied their grammars.
Infix notation and - are really the reasons why nobody does this, some people like to use spacing to indicate precedence too (writing code such as "a - 1*g") so it would break some workflows and realistically having a language which is whitespace agnostic except for identifiers AND the minus operator just seems too irregular for people to commit to it.
That's why I said most. Obviously there exist languages, such as elm, where this is not the case, but in the case of those languages, the teaching literature (as is the case with elm) explains these things. Most languages don't do this precisely because their designers made the judgement call that the additional parsing complexity (both for the actual parser and the human) outweighed the benefits of allowing you to have minuses in identifiers.
If anything is gonna happen it's more likely The Powers That Be would limit use and/or distribution instead of mandating a change to code itself. Half of them probably don't know how to connect to their home Wifi network, nevermind authoring and mandating a commit.
I don't plan on having kids of my own, but if life finds a way (or I end up with custody of a relative's children) I figured I would similarly put together some kind of loose "curriculum" to guide them along if they took an interest in computing. Never actually planned it out - is a pretty large domain of knowledge to cover for something I don't currently plan on using, but I wouldn't be surprised if there are already pre-existing FOSS resources along those lines.
As far as ergonomics go, a controller-like form-factor is almost definitely the current ideal for a portable, carry-able, holdable keyboard. Obviously just slapping QWERTY on it wholesale may not be the best idea, and doing the R&D for a more appropriate layout or entirely different approach to input could be costly. carriers for phones or other devices could also complicate it. Might be the reason there aren't more on the market?
Is there anything like it out there now? I searched around for something like this a while back, wasn't really satisfied with my findings, and haven't been able to stop thinking about it since.
Would be neat to take a lot of the submitted sounds of old machines (computers or otherwise) and write a background process that manipulates and plays them while performing certain tasks, like loading from an external drive, or using the more ambient sounds for 'idling'. Lord knows if I could make my machine sound like Nostromo's Mother, I'd do it in a heartbeat.
Not exactly what you're talking about, but I've seen a few RaspberryPi + iPad + External Keyboard setups where they either use the iPad as an external display or VNC into the Pi from the iPad. IIRC you can power the Pi via USB C -> PoE on iPads with sensible ports on them, so you don't need an external battery or UPS.
Again, not what you actually want (I share your pain/longing), but damn if it isn't starting to get close.
