Earlier quoted context omitted.
What exactly do you mean by "damned" here?
I am assuming the author is using it as one would use "wicked" (with a positive conotation)?
That's right, forgot the word (not a native speaker unfortunately).
Microfeatures I'd like to see in more languages
461–470 of 539 posts
Re: Microfeatures I'd like to see in more languages
#462Earlier quoted context omitted.
D has had these for a long time.
Looks like these fall into the "structured comments" category, based on seeing /** */ and /// in a repository I found. Does it also have a story for doc tests?
Yes, tests in those comments are actually pulled out and run.
Re: Microfeatures I'd like to see in more languages
#463I really liked the postfix and prefix notation in Mathematica. These three all mean the same: f[x] f@x x // f It matches the flow of thought more naturally when hammering out a couple of one-liners.
Julia also has x |> f as a syntax sugar for f(x) and is useful for the same reason as Mathematica.
(I don't know where the pipeline operator originated, but F# certainly had it before Julia, by the way.)
Re: Microfeatures I'd like to see in more languages
#464Earlier quoted context omitted.
But is that December 8th or August 12?
>> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12 > But is that December 8th or August 12? I didn't even think YYYY-DD-MM is a possibility. Maybe I can grant 08/12/2022 is ambiguous and so is 08-12-2022 but can we please agree YYYY-MM-DD can't have variations?
The first rule of timestamps is, we agree on nothing!
Reverse-middle endian YYYY-DD-MM is used in Kazakh writing (https://en.m.wikipedia.org/wiki/Date_format_by_country )
Re: Microfeatures I'd like to see in more languages
#465Earlier quoted context omitted.
Even C these days, although they chose ' instead of _ :-(
My guess is that they did that because there are real human languages where ' is used as a thousands separator.
Swiss German for example. But space, half space and dot is also common in Europe. Just not a comma, because this is used as a decimal separator (fractions) in most countries.
Re: Microfeatures I'd like to see in more languages
#466Earlier quoted context omitted.
>> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12 > But is that December 8th or August 12? I didn't even think YYYY-DD-MM is a possibility. Maybe I can grant 08/12/2022 is ambiguous and so is 08-12-2022 but can we please agree YYYY-MM-DD can't have variations?
The first rule of timestamps is, we agree on nothing! Reverse-middle endian YYYY-DD-MM is used in Kazakh writing ( https://en.m.wikipedia.org/wiki/Date_format_by_country )
Anyone who packs multiple values into a single string hates the world and possibly themselves.
Nowhere is it written that we must use the same field separator between the ambiguous fields. We could fix this problem by using the separators as type signifiers.
We could also stop using day <= 12 in our examples, which would also help a ton.
Re: Microfeatures I'd like to see in more languages
#467Earlier quoted context omitted.
Note that some kind of string builders are necessary for efficient repeated concatenation both in languages with immutable strings and in languages with 0-terminated strings. Using strcat() repeatedly in C for example will mean that the string is being read over and over again to find the end, making an O(n) loop actually O(n²).
Right, but that's still a performance optimization and not anything like what OP is implying.
Yes yes, OP had some really strange ideas. I was just adding some extra info to GP's answer, not trying to contradict them.
Re: Microfeatures I'd like to see in more languages
#468Earlier quoted context omitted.
It shouldn't be that confusing. Ideally, a method should be defined on an object only if it needs to access the encapsulated state of that object. Otherwise, it should probably be a free function. So, in your case, depending on other modeling decisions, I could argue either for onCollide(Player, Pickup) - if Player and Pickup are both plain data, and don't need to guarantee any invariants Player.collect(Pickup) - if…
But this isn't a discussion about pickups specifically. Attacking an example is pointless if the thing you take issue with is incidental and not fundamental to the argument. I bet you could think of a case where you pick something else and OP's example meets your standards.
My point was that there is a meaningful, and I believe relatively simple, distinction to be made between free functions and methods bound to an object - a distinction which UFCS doesn't really help with. For any given example, I believe there is a reason to prefer one over the other, and I showed what reasoning I would use for the particular example raised by OP.
Re: Microfeatures I'd like to see in more languages
#469Earlier quoted context omitted.
Without UFCS, if I see obj.foo(), I know I can lookup the definition of foo() in the definition of obj's type, or in its supertypes. Even for foo(obj), there is often a canonical place where such functions are defined. With UFCS, I need to look in both of these places until I can find the right definition. And sure, the IDE/language server/other tooling can often help, but not always (e.g. if I'm browsing some code o…
In languages that have UFCS, there's no such thing as classes, so… you simply look for the procedure.
D certainly has classes, and a member function has access to private members, while a free-floating function does not. Nim indeed doesn't seem to have this distinction at all, and only seems to support encapsulation at the module level, not the class level (as far as I could tell from very brief searching - I have never programmed in it).
Re: Microfeatures I'd like to see in more languages
#470About kebab-case identifiers. What I always wanted is proper spaces! Designing syntax where identifier could have spaces (without backticks or something like that) might be tricky of course. But may be it's not impossible. All those space imitations, whether they're dashes, underscores or camels - they're just imitations. Nothing compares to real spaces. If anything, underscores are closest ones, if you ask me.
> What I always wanted is proper spaces! Designing syntax where identifier could have spaces (without backticks or something like that) might be tricky of course. But may be it's not impossible. What would this look like, though?[1] How would you solve the problem of adjacent identifiers vs a single identifier which has spaces? Maybe having identifiers, and only identifiers, starting with a uppercase letter with no u…
Well, I would imagine that it requires designing a language which ordinary does not allow adjacent identifiers.
Of course keywords must not be allowed as part of identifiers (or there should not be no keywords at all like with Lisp).
Just an example of my head that I didn't think really much about:
function print person (p: person) {
var full name = p.first name + p.last name;
if p.middle name != "" {
full name += p.middle name
}
print line(full name)
for c : p.subordinate person list {
print person(c)
}
}