Walkman

I don't know how to say it without you taking it as a personal attack, but I think it's important to say so you can take the opportunity and learn or at least think about it; If you say things like that I quoted, you are incompetent and you have to learn a lot. I feel I have to say this because you send the wrong message to a wider audience which I really hate.

Also I skimmed your library httplib2 and it's at least terrible to read.

Again, you can take this as a personal attack, flag this comment also, be mad or whatever, or buy Clean Code and start reading, also start learning more about Python idioms from people who are really good at it, e.g. Raymond Hettinger, Armin Ronacher

I always wondered why is this and I think it's just a habit and somebody do it because everybody else is doing it.

> there's no acceptable way to pass a function body to another in Python.

There are sentences which are telling a huge incompetence about the person using these.

This sounds the same story to me as "We used tech X, but X is shit/can't do something so we switched to Y, and Y is awesome and fast." Where the person switching was just incompetent with X but it would have been perfectly solvable and they just do a totally different thing with Y.

In the specific "passing a function" case, yes, it's impossible to pass only a function body, but I think it's impossible to do in JavaScript also? (correct me if I'm wrong), because you pass in function. You can do the same in Python by defining a function in the same scope and passing that in. If you don't like that, it's just one opinion, not necessarily good or bad. For example, I find it ugly and difficult to handle nesting this multiple times (defining another anonymous function inside an anonymous function) which is called "callback hell" if I understand right, but that's just my opinion also, because people seem to able to accept this hell. :)

I have one comment for the article: LOL.

Seriously, the author probably never worked in teams with different sizes [1, 2], considered another workflows [3, 4] and skill levels of the developers (yes, that's a variable you have to consider also!)

Also if you use Git in the same manner as CVS, you should do it because it's much faster, more reliable and more flexible...

Edit: Ok, the author is saying things which I agree with, I was commenting on the click-bait title and the first paragraphs mostly, but still, there is more to the story.

[1]: https://m.signalvnoise.com/the-majestic-monolith-29166d02222...

[2]: https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

[3]: https://trunkbaseddevelopment.com/

[4]: http://nvie.com/posts/a-successful-git-branching-model/

> One strategy to increase your salary 1.5X or even 2X across the next few years is to switch companies every two years.

I did exactly that and my salary is more than double in less then 4 years. I started working after 1 year of experience, I have 5 years now.

With your logic, you should pay for every new release. E.g. You bought the product at 1.0.5, you will pay for 1.0.6, 1.0.7, etc... IT IS am ongoing service. Development doesn't stop there. 1Password does this model; you have to pay for every major version of their product.

For God's sake, DON'T TEACH IF YOU DON'T UNDERSTAND YOURSELF what's happening.

"Commit C's revision number has changed." - NO IT DID NOT. The original commit (f4ba6b) is still there, it still points to B, but a totally new commit has been created with a different content. To avoid confusion, it's better to name it C'. C is now a dangling commit (has no branch or tag pointing to it, and will eventually be garbage collected).

The last part is definitely not true at all. I skipped the coding part of the interview process for my current job because I had good code on GitHub. Also got job offers out of the blue because I contributed to multiple projects. I feel there are companies looking at only GitHub (for a good reason IMO) nowadays for candidates.

We use it at the company I work for and it's not.

I was really optimistic about GitLab's vision and really liked how they shipped a ton of really good features, but they reached feature creep and I'm pretty sure they will never get "usably fast" because maintaining all these is a huge burden.

Also if you have tons of features like these, I think it's impossible to get all of them right and at the end, you have a lot of mediocre/poor features and few good ones.

The other thing is user experience. Who will know all these features, especially when setting some of them is already hard and need experts...

If you want to be everything for everyone, it's mostly impossible or you get a very complicated, unusable and/or slow thing.

I'm curious for counterarguments to these points.

Because it's the fastest, low-memory, full of features Python release yet. As Raymond Hettinger would say "Python 3.6 is the best Python version."

not tools, however these are the best: your brain, your mouth and some things you can write with. Maybe a computer.

The productivity level is nowhere near to Python's yet. You should try Go for a couple of weeks and see that still soooo much missing from Go compared to Python.

Mostly requirements.txt, yes. It's a standard and it has been a really long time I used a package where I didn't find one.

What you mean by no reproducible builds?

> Python has/had a terrible packaging story though. As you said, dependencies weren't really documented.

I wonder where have you lived? I rarely found (if ever) an undocumented dependency list for any serious Python project in the last couple of years.

Mike Bayer wrote a really interesting article about this topic 5 years ago: http://techspot.zzzeek.org/category/mako/

These techniques are easier with the Pyramid framework.

I tried it with SSH chat:

    ssh chat.shazow.net | nc seashells.io 1337
    serving at https://seashells.io/v/FYh2Dt7t

It is really real time! much wow!

In that particular article, there were a lot of "alternative facts" (basically a lot of things that were simply not True), written in a subjective, aggressive manner. That's why it was bashed not because "somebody did not like him".

Did not find whole words on the same page. Not there yet.

About testing: it's not actually True. Flask is easy to test. Also, Flask makes everything explicit which is less surprising than hidden thread locals.

Also, putting things into thread locals somewhere makes explicit request objects totally pointless, because you still depend on threads and can't use Django in an async manner. So it's not a valid good technical argument either. You might like that better, but that's just a subjective opinion.

what about the ORM? https://github.com/django/django/blob/master/django/db/utils...

Neither will help if you employ bad people or the company has a bad culture. You should trust every developer.

Once I tried to implement soccer team balancer. We made skill points to each player (so everybody had a final score) and I wanted to write a small Django application which balances the teams the most fair way. It turned out it is a really hard mathematical problem. My stupid brute-force solution ran for minutes for 10 players :D Wish this library has been existed back then!

I use a Linode instance for a personal OpenVPN server and the bandwith for me is at lest 2-3x bigger. This is a huge deal for me for the same price.

I'm curious about the tech stack you are using for this service.

The Architecture of Open Source applications: http://aosabook.org/en/index.html

These are very detailed, very well written articles from well-acknowledged developers about their OSS project.

Python is far more than glue code.

Using simple things as much as possible is always a good idea until you need a more complex thing.

I don't understand why should you delete any piece of your work. Disk is so cheap you can keep it forewer.