431–440 of 539 posts
Earlier quoted context omitted.
perl have $d[$#d] represent the index of last element.
Yeah, but $#list is better used for writing loops: foreach my $i (0..$#list) { say "$i: $list[$i]"; } For getting the last element from a list you can just use -1 (and of course further negative numbers work like you would expect, -2 is second to last and so on): my @last_three = @items[-1, -2, -3];
Earlier quoted context omitted.
Wouldn't endianness interfere with this notation and the preceding one?
Of course it does - endianness interferes with any sort of numeric literal. Doesn't matter if it's hex, decimal, underscored, whatever.
(Given they have been listed separately rather than as a single number).
Earlier quoted context omitted.
String builders originated in languages with immutable strings making code using something like "foo += bar" in a loop very expensive due to the need to allocate a new string on every iteration. A string builder is basically a mutable string that can be built in-place efficiently and converted to a proper immutable string at the end. It is purely a performance thing, and there are no Unicode issues when concatenating…
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²).
Earlier quoted context omitted.
Lots of languages will implicitly return the final expression— I feel like that's a decent compromise. Not quite as magical as an actual named variable that just exists, but not as clunky as needing as explicit `return` every time.
Honestly, I don't like that style for languages which allow multiple side-effects as well. For example, (progn (print "something") 0) Is honestly pretty ugly from my point of view.
Earlier quoted context omitted.
I'm not a Haskell user, but my experience with this in the Nix language is a bit mixed. It definitely works sometimes , but then you get a pileup of parenthesis nesting anyway, because the default is greedy and you have to control which functions get which arguments.
Don't $ signs work in Nix the way the work in Haskell? E.g. https://mmhaskell.com/blog/2021/7/5/function-application-usi...
Earlier 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.
TL;DR is that it's because C++ uses quote. The reason C++ uses quote (they considered underscore) is because of a very obscure feature of C++ called custom literal suffixes which I'd never even heard of, but numbers can be suffixed with a custom identifier, and since single underscore is a valid identifier you can't use that. (https://en.cppreference.com/w/cpp/language/user_literal)
Earlier quoted context omitted.
Except I find the concept of state "doing something with" other state unhelpful. Why is bar working with baz and not baz working with bar? I struggle with this in Unity: Player.collect(PickUp) // this? PickUp.boost(Player) // ...or this? Instead, the code should describe the interaction between the two units of state: onCollide(Player, Pickup) If we structure our code like in the last example, it makes sense to weake…
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…
Earlier quoted context omitted.
Of course it does - endianness interferes with any sort of numeric literal. Doesn't matter if it's hex, decimal, underscored, whatever.
I think you are missing the point - there is no endianness in normal written text, (or code), but there is endianness when that is translated to an actual number - what order are those bytes intended to be used in? (Given they have been listed separately rather than as a single number).
> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12 Frink? Frink ? This Visual Basic erasure can not stand. The #-delimited date literal syntax has been found all over the VB family: Visual Basic, VBA, VBScript, and it persists to this day in Visual Basic .NET. Of course, being a VB syntax, it's completely cursed. You can put # 01/05/2023 # in a VB file, and what date…
A VB date literal is and always has been locale-independent. Originally, they did make the mistake of making it always US-style, M/D/Y. VB.NET added more sane formats such as YYYY-MM-DD. Now if you tried to convert a Date value to String at runtime, yeah, that would use the current locale. That was a constant source of bugs in VB6 apps running on non-US locales (including, famously, at least one Microsoft installer).
Earlier quoted context omitted.
A VB date literal is and always has been locale-independent. Originally, they did make the mistake of making it always US-style, M/D/Y. VB.NET added more sane formats such as YYYY-MM-DD. Now if you tried to convert a Date value to String at runtime, yeah, that would use the current locale. That was a constant source of bugs in VB6 apps running on non-US locales (including, famously, at least one Microsoft installer).
Are you sure? Maybe for Visual Basic proper, but I thought the VBA date literal basically followed Excel date parsing rules, so was localized depending on your office inatall.
Still, this violates the principle of least surprise for non-american developers, at least, so seems pretty on brand for VB.