Conversation
Notices
-
if len(domains) == 0: # pylint: disable=len-as-condition
soydevs aren't real
-
@Zerglingman
>pylint wants you to do if files: or if not files:
Python has 'strong' typing btw, as opposed to 'weak' typing. I feel like this instance where an implicit function implicitly converts any object into a boolean and you're encouraged to use that so that you could hypothetically have some 'falsy' data with non-zero length, is a good time to remind you that Python is definitely on the 'strong' side of the imaginary strong/weak axis of typing.
-
@apropos >you could hypothetically have some 'falsy' data with non-zero length
That's impossible with all the builtin types that have lengths, but yeah, worth being careful with classes you haven't written.
tbh if I wrote this code I probably would have just done if not domains. It's declared as a set earlier so it's safe.
>>> if {False}: print(1)
...
1
-
@Zerglingman still I'd prefer people used Ruby and wrote 'if domains.empty?'
Ruby has problems as well, including some modern Perl-tier problems where dumb features are added in one version and then stripped in the next so you can run into code that depends on a precise version of the language. And its historical problem was managing to be slower than even Python for a bit too long. But at least it had nice predicate? methods
-
@apropos Ruby, as far as I can tell, is an esolang masquerading as a real language.
-
@Zerglingman if Ruby looks weird today that's entirely
a. the fault of Java refugees dogpiling the language and the bringing their culture with them
b. because you think the same thing about Perl
Ruby's just a Japanese dude implementing Perl 6 in the 90s when OOP was still cool.
-
@apropos I don't think I've ever looked at perl.
-
@Zerglingman @apropos Today I learned that I am primarily a esoteric sorcerer masquerading as a dev.
-
@Zerglingman Perl's a creature of its era and a genuinely bad language today, and so obviously and subtly repulsive that Python won out despite being enormously slower, not having any kind of package system, not having anything like Perl's wealth of libraries, etc. People picked the objectively inferior technology just to get away from Perl's crazy and unsettling features. Larry Wall then tried to resolve this situation by creating a successor language that was completely assembled out of crazy and unsettling features-but new ones! He got rid of some of the more obviously bad stuff!
For example, what do you think the output of this program is?
#! /usr/bin/env perl
use strict;
use warnings;
sub oops {
my ($s) = @_;
return reverse $s;
}
my $reversed = oops("hello");
print $reversed, " ... ", oops("hello"), "\n";
Did you guess "olleh ... hello"?
-
@apropos @Zerglingman I guessed olleh ... olleh and I was wrong. Is the oops("hello") only really "properly" evaluated when it is assigned to a variable such as $reversed?
-
@dieulast @Zerglingman nah, oops("hello") is evaluated in both cases. It really runs. "hello" is really the result of the second invocation of it.
What's going on there is 'scalar context' vs. 'list context'. The assignment to a scalar $reversed causes oops() to run in scalar context, which causes the returned reverse() to run in scalar context, which means that reverse() reverses the string.
The second oops() is run in list context, where reverse() reverses the list of arguments that it's given -- the one-item list containing the string "hello", the reverse of which is a one-item list containing the string "hello"
Context sensitivity is a feature that's useful... never. And in the core language, all it does is overload a few functions like reverse() so that you can both reverse lists and strings with it. But if you become good at Perl and write and maintain Perl programs then every few years you'll have some dumb bug caused by you accidentally relying on context in the wrong way. This is the subtle repulsiveness of Perl that you get from several other features. The obvious repulsiveness is just how it looks, especially how OOP looks.