I always wonder if the world would be a better or worse place if all salaries where forced to be made public by law.

Lots of pros and cons, but it would be very interesting.

I believe several countries do that. For examples:

"Norway, the country where you can see everyone's tax returns" - https://www.theguardian.com/money/blog/2016/apr/11/when-it-c... .

What We Can Learn From Sweden's Public Records of Salaries" - https://theculturetrip.com/europe/sweden/articles/what-we-ca...

Many government and academic institutions do in fact publicly publish all salaries, so the question of what the effect would be is not entirely theoretical.

Here's one place that aggregates this data: https://www.openthebooks.com/ https://www.openthebooks.com/virginia-state-employees/

Governments and most education institutions are not part of the free market. Their income also does not depend on their efficiency or value they create so its not the same comparison.

yup. my salary and everyone else at my organization is published every year by the local newspaper. We aren't required to publish it ourselves, but if anyone asks, we are required to reveal it, so the local paper files a request every year and publishes it.

- Use FF + lots of blocker addons

- Use Linux

- Encrypt files

- Use signals

- Use Android without a google account or a play store

- Use google products as little as possible

- No whatsapp, no Insta, no FB

- Use pcloud encrypted solution for online storage

But even with all that, I'm pretty sure the impact is limited, real privacy would require a lot more. Not to mention banking, power companies and so on are going to sell your data no matter what.

Besides, most people would not even do 10% of this. Not even switch to FF.

And if they are transparent and knows you, they give a lot of data on you anyway.

It's a battle we are loosing.

Had to deepl "自主可控、纯中文国内社区" to understand that your comment meant it translated to "pure Chinese domestic community", which implies if we are not part of the gang, we can't enjoy the project.

Well, we've been doing this implicitly with English for a long time, so I guess Karma is a bitch.

On the other hand, I wrote a French technical blog for years, and it was way harder to reach a lot of people, so if I had to do it again, it would be in English.

They don't have this problem, since 1B people are Chinese.

> Well, we've been doing this implicitly with English for a long time, so I guess Karma is a bitch.

Or it's their loss. 7B people don't speak a word of Mandarin, and even more can't read and write it.

~7B of those would not pick up a new fringe language either way.

Nor will ~1B of the rest.

This doesn't seem like an appropriate conclusion. There's a massive semantic difference between "China #1" and "Sorry, I only know English." Karma doesn't come into play here.

Statistically, yeah.

Because the most watched youtube videos are music videos, and people listen to the same music regularly.

Also because some videos have been popular enough that people wanted to show that to their friends, and regular users don't know how to use the history, so they want to find it in their home page again.

I assume the algo just doesn't know the difference between videos that are rewatchable and ones that are not, and does that on some statistical metrics that don't make sense in a lot of contexts.

When you think something is stupid, the answer is usually there is something we don't know about it.

An algo that does not know what the user wants but tries to do something anyway, based on "some [..] metrics that don’t make sense [..]" is by definition "stupid".

you have to be wrong as Google is the leading developer of AI technology globally </irony>

It's all because of me. I've been watching the same music videos for the last 15 years. Sorry guys.

maybe they need a "watch again" tab?

There does exist a History section that offers just that.

YouTube truncates the History to last 2000 items, however. I need to be able to see my full, uncut history for audit and word-of-mouth purposes.

I'm sure that many of old videos has been removed. And the more I use the Internets the more I consider to save as much of stuff as possible (webpages, videos, everything) maybe on another machine with a really giant disk.

They probably looked at tik tok, and realized most people consumed recent content like bots.

They then calculated the cost of sorting, and realized that it would save them more money than upsetting the users that like the function would cost.

Then, A/B testing confirmed it for a few months.

Then, tada, good bye features.

Google: "we have determined that drivers only use their brakes 5% of the time versus the accelerator 60% of the time and therefore have decided to remove brakes from the car"

>They then calculated

I mean they have sort by time, so you would just reverse the order.

This stinks like GNOME mentality, giant ego designer needs something easy to do to justify it's salary so finds some button/option to remove,

So if most people supposedly don't use the feature it probably doesn't cost that much to have it. Also now people who actually want to view videos starting from oldest will use a magnitude or two more resources just by needlessly scrolling for 5 minutes.

Seems to me that it's more likely that google just has too many employees who just do idiotic/random changes to show that they are actually doing "actual" work...

The first amazing result would not be for you to program with this, but for somebody with a phone to be able to automate a few small tasks with just the voice.

Exactly.

Copilot is getting better everyday, because it's learning from the way we are using it.

GitHubNext here! We appreciate your support.

Before copilot, we were far from it.

But now, given how magical this thing is, it opens many doors to what's possible with no code.

I never really believe in anything no code before apart from Excel and RAD.

But basic tasks are going to get accessible to a lot of people sooner than I expected

I'm almost certain a trained professional is still going to do a far better job than an amateur.

That part is unlikely to change much, if it all.

Trained professionals will always outperform the latest fellow dragged off the street.

That doesn't matter much.

You free part of the industry from needing professionals for some simple tasks, which is enough to empower users with a lot of possibilities, and focus pros on where they are really needed.

"Hey phone, next time mum send me a text about voting, you can send back a 'ok boomer'?" or "hey phone, can you setup a webpage that list my tiktok videos up to last year?"

Most people are not going to hire a pro for that, but we could end up with a AI general enough to be able to do that for users. It's ok if the result is not extensible, maintainable or modular.

It's a good learning exercise.

Of course, don't use your own hand crafted version in Python, since one is provided with the language and it is better than the one you will likely come up with.

Still, it's interesting because it's simple. So starting from the intro of this article, if you want to go further, try to do the following to match up __builtins__.zip:

- make it lazy (yield would work)

- make it work with any iterable (iter() + StopIteration would work)

- put some type int and a docstring (so that help() gives you informations)

- accept any number of iterables (variadic parameters would work)

- make a second version that accepts a fill value (like itertools.zip_longest)

This will sharpen your python skills, and also will make you appreciate even better how much you get for free with the stdlib (not to mention __builtins__.zip is in C, so it's fast).

It's worth noting that `map` is variadic and acts as an nary `zipWith`. I didn't realize that for a while.

    >>> from operator import `add`
    >>> list(map(add, range(5), range(10, 15)))
    [10, 12, 14, 16, 18]
    >>> add3 = lambda x,y,z: x+y+z
    >>> list(map(add3, range(5), range(10, 15), range(100, 105)))
    [110, 113, 116, 119, 122]

> will make you appreciate even better how much you get for free

This is unironically the reason I come back to Python again and again. The language itself is not my favorite: it 'should' be different. But my productivity with it is frankly unmatched.

The "zip" example is an excellent case study. The actual "zip" is by default lazy, it accepts arbitrary iterators, etc. It's the "correct" solution, unlike the one presented in the article, and I have it at my fingertips, in the standard library.

> This is unironically the reason

Can I ask an off topic question? Where did this sudden popular use of “unironically” come from? I don’t get it. Why would it be ironic?

It reminds me of the sudden rise of “literally” a decade or so ago.

"Unironically" here means "seriously", "literally", "actually", etc. It's basically a marker that the speaker is speaking straightly and plainly, without trying to make a joke.

Yes, it's not really antonymous to "ironically" (in the narrower sense of this word) in this context.

I think it's fairly literal, there's a whole brand of humor around pretending to like things that you actually like. "I like C because of all the undefined behavior".

But this is also how word meanings shift over time. Someone will see someone else using that word and not know what it means, but then start using it, etc.

In reality most of these are really simple, the big question is how to handle end of iteration across iterators e.g. given zip(a, b) where a is shorter than b, on the last iteration will b get updated or not?

In Python an iterator is simply an object that implements the __next__ method, and raises StopIteration to signal the end of the iteration.

It's not hard to implement just about any protocol on top of that abstraction, e.g. you have itertools.zip_longest()

I know what an iterator is. I think you missed the point.

Would you like to explain that further?

Progressing an iterator is a side-effect (a mutation).

Depending how the last iteration is handled, zip(a, b) and zip(b, a) with iterators of different sizes can have different behaviours: if a is shorter than b, a naïve implementation would update b in the zip(b, a) case, but not in the zip(a, b) case.

There is no unique solution to that problem since sometime you want consumption, and sometimes not, for one or more of the parameters.

__builtins__.zip chose to consume iterators in the order they are passed as a parameter, and therefor end up with an assymetric consumption.

That's why itertools.tee exists, so that we can chose case by case.

That reminds me of a lovely paper "How to Add Laziness to a Strict Language Without Even Being Odd" by Wadler and MacQuenn. They use "map" as their running example, but the problem is basically the same.

zip is generally implemented as a functional concept, where the iterators take values from the backing iterable structure "by const &". You can implement a custom mutating zip operation on top of the iterator protocol.

I believe masklinn is talking about whether `zip` consumes an extra element from the longer iterator on the last iteration, when the shorter iterator raises StopIteration. And the behavior might vary depending on the order of the arguments.

    def a():
      yield "a1"

    def b():
      yield "b1"
      yield "b2"

    x,y = a(),b()
    zip(x,y) # => [("a1","b1")]
    next(x) # => raise StopIteration
    next(y) # => "b2"

    x,y = a(),b()
    zip(y,x) # => [("b1","a1")]
    next(x) # => raise StopIteration
    next(y) # => raise StopIteration

This is the problem with python's conflation of iterable and iterator, and maybe why so many programmers don't understand the difference when they pick up Java.

> This is the problem with python's conflation of iterable and iterator

It really is not. It’s just a natural outcome of imperative langages. If operations can have side-effects, then combinator behaviour will affect those side-effects.

You could do the same with iterables with side-effecting iterations.

It’s also perfectly logical to be able to iterate an iterator.