

Frankly, it sounds like neither of the two should lead the FSF


Frankly, it sounds like neither of the two should lead the FSF


Well, maybe you’d better wait 10min instead of one, to make sure the led lightbulb heats enough, but still…
I tested this with a 5W IKEA LED light-bulb, since I was just doom scrolling, anyway:
This means that the solution either breaks down entirely, or is unreliable, since you are not (reliably) able to tell the first two buttons apart


Loop labels are rare, but they lead to much simpler/clearer code when you need them. Consider how you would implement this kind of loop in a language without loop variables:
'outer: while (...) {
'inner: while (...) {
if (...) {
// this breaks out of the outer loop, not just the inner loop
break 'outer;
}
}
// some code here
}
In C/C++ you’d need to do something like
bool condition = false;
while (...) {
while (...) {
if (...) {
condition = true;
break;
}
}
if (condition) {
break;
}
// some code here
}
Personally, I wouldn’t call it ugly, either, but that’s mostly a matter of taste


C++ is even worse, due to templates and the so-called most vexing parse. Initializing with {} mitigated the latter somewhat, but came with its own set of woes


In practice, type inference in Rust is not a problem since the language is so strongly typed. In fact, it is more strongly typed than both C and C++, and will force you to cast values explicitly in cases where C and C++ will happily mess up your variables without warning. The absence of type inference would also be a major pain, since nested types such as iterators can get quite complex and very verbose. If you’ve programmed using older C++ standards, then you know this pain


I believe that it is useful in a few places. cppreference.com mentions templates as one case:
Trailing return type, useful if the return type depends on argument names, such as
template<class T, class U> auto add(T t, U u) -> decltype(t + u);or is complicated, such as inauto fpif(int)->int(*)(int)
The syntax also matches that of lambdas, though I’m not sure that adding another way of specifying regular functions actually makes the language more consistent, since most code still uses the old style.
Additionally, the scope of the return type matches the function meaning that you can do
auto my_class::my_function() -> iterator { /* code */ }
instead of
my_class::iterator my_class::my_function() { /* code */ }
which is kinda nice


With Rust you safe 1 char, and gain needing to skip a whole line to see what type something is.
Honestly, the Rust way of doing things feels much more natural to me.
You can read it as
getoffmylawn,Lawn argument named lawn,boolWhereas the C function is read as
bool? Could be a variable, could be a function, could be a forward declaration of a function,getoffmylawn,(, so all options are still on the table,Lawn argument named lawn, that returns a bool

Amusingly, modern C++ allows you to copy the rust signature nearly 1:1:
auto getofmylawn(Lawn lawn) -> Option<Teenager> {
return lawn.remove();
}
At this point the people complaining about Rust at every opportunity have become more annoying than the “rewrite it in Rust” people ever were


How the fuck can it not recover the files?
Undeleting files typically requires low-level access to the drive containing the deleted files.
Do you really want to give an AI, the same one that just wiped your files, that kind of access to your data?


That’s not quite true: Yes, your $99 license is a life-time license, but that license only includes 3 years worth of updates. After that you have to pay $80, if you want another 3 years worth of updates. Of course, the alternative is just putting up with the occasional nag, which is why I still haven’t gotten around to renewing my license


I’ve started converting my ‘master’ branches to ‘main’, due to the fact that my muscle-memory has decided that ‘main’ is the standard name. And I don’t have strong feelings either was
No gods, no masters


A single underscore is just a naming convention, but double underscores triggers automatic name-mangling of the variable in question:
$ cat test.py
class foo:
def __init__(self, x):
self.__x = x
f = foo(1)
f.__x
$ python3 test.py
Traceback (most recent call last):
File "/mnt/d/test.py", line 6, in <module>
f.__x
AttributeError: 'foo' object has no attribute '__x'
However, much like private/protected variables in java, this is pretty trivial to circumvent if you want.
But I don’t believe that you can argue that access modifiers are required for OO not to be shoehorned into a language, not when influential OO languages like Smalltalk didn’t have this feature either. Java just happens to be closer to C++, where public/private/protected is much more rigidly enforced than either Java or Python


In what way does OOP feel shoehorned in with Python? I ask since that is not my own impression of the language.
Would you also be willing to share what language(s) you feel do(es) OOP without it being shoehorned in?


Unix shell scripts are one of the few holdouts.
I don’t know if this applies to other shells, but bash will not only execute your script line-by-line, it will also read it line-by-line. Which means that you can modify the behavior of a running script by editing lines that have not yet been executed*. It’s absolutely bonkers, and I’m sure that it has caused more than one system failure, during upgrades.
* For example, if you run the following script
echo "hello"
sleep 5
echo "goodbye"
and then edit the third line before the 5 second sleep has elapsed, then the modified line will be executed.


It is normal usage. Though personally I’d probably make another “main” function, to avoid declaring a bunch of global variables
He has made a large number of questionable comments, including the argument that the solution to human trafficking includes legalizing child prostitution:
https://www.stallman.org/archives/2015-mar-jun.html#27_April_2015_(Human_Traffickting_Act)