- 6 Posts
- 22 Comments
Some functions also don’t have any parentheses, like field access or infix operators.
You call things the way they were defined. Problem solved.
I’m kinda confused, because this is the second time now where your attempt at making a counter argument is actively supporting my point. Is this intentional at your part?
We could follow this line of thinking further …
No we don’t. If your point relies on Turing-tarpitting the whole discussion … then you have no point.
Thankfully, registration fees do not differ by length of the domain. (As it should be.)
It cost a larger 3 digit amount of currency to buy it, though. (Which was fine for me.)
Packages are usually provided by distribution packagers, not by the developers of the code itself.
This submission reminded me that I also had some articles on this topic that people may find interesting.
That’s still a workaround to try and keep a completely artificial distinction alive.
Even if I didn’t need
[]for types, I still wouldn’t want “some functions use(), some functions use[]” as a language rule.
2·6 days agoOh, good idea … any preference on the first? :-)
I have some articles on naming specific areas of program code that people might find helpful:
Wasting a perfectly good pair of brackets on some random function call and then suffering for it in many other places sounds more like syntactic salt.
What’s a form of access but a function from some index type to some element type?
If you read more than just the headings, you’d find out that your objections have been addressed in the article. ;-)
Sure, there are some worse/more limited predecessors – my design was partially motivated by a desire to improve upon these.
For instance, that ML-derivative you are using for your examples
- very likely still has
if then elsein the language, thus making it not unified - desperately tries to emulate functionality with guards that simply comes out of the box with my approach
- relies on the ultimate hack of “match on unit”, because
matchis very limited in which coding patterns it can express
Also, none of the examples are “more clear” or “have less magic”:
Maybe they are more “familiar” to you personally, but that’s about it.Too me they just look clunky, full of accidental complexity and trying to work around a poor/limited language design.
- very likely still has
deleted by creator
deleted by creator
deleted by creator
That –at best– gives you the same performance.
EDIT: Ok, I misunderstood – you meant the performance of “case insensitive in kernel” vs. “case insensitive in userspace”. I get your point now.
No, I’m not going to waste further time on trying to make you understand things you are not capable or interested in understanding.
The author of that paper hung around in the lang design forum were I originally presented this.
Case insensitive FSs aren’t a new thing.
More precisely, they came up in a time where Unicode was not a thing.
Yes, you need to attach the locale to the filename. No, I have no idea off the top of my head of how different file systems encode or store that.
They don’t. None of them.
Or, if it is, then let’s go back to eight characters from the English alphabet in all caps. 8.3 filenames. Why not? […] Why are spaces, cyrillic, special characters and long names worth doing but case insensitivity isn’t?
Because you cannot have both.
It is either “spaces, cyrillic, special characters and long names” or case insensitivity.
I think the article suffers a bit from not being up to date in regard to the work Java has done with virtual threads.
There quite a few assumptions being made in the article that would not have been questioned a few years ago, but now these assumptions feel quite unfounded and all the conclusions based on them stand on shaky ground.