sashahart

If it is like the interrogation I have gotten from developed countries outside the US, they are asking questions about what you do and what brings you to their country, and the questioning can be somewhat adversarial. Which nobody likes.

If you travel frequently across borders, you will often be taken aside and asked questions. It is mind-numbingly common, it has happened to me in Schiphol (EU) several times. Very annoying, but not at all the same as people being beaten and censored and put into gulags for mild civil forms of political dissent.

Let's not trivialize real totalitarianism in our haste to condemn stupid airport security theatre.

I agree that Django vs. Flask is not a matter of what sucks or is broken.

If I think a hammer looks nice but someone informed explains that it is designed in such a way that the head will tend to fly off, I find that very instructive. The many broken spatulas on github are also instructive.

If you want a pre-built admin, Django provides for a different need, yeah... but if the needed stuff is in the large overlap between Django and Flask, you can't just say "different needs" because you are considering competition to satisfy the same needs. (For example, Flask is promoted for HTTP APIs, but Django also has some good packages for putting together HTTP APIs, so that it is hardly clear that Flask would always be the better choice for APIs).

Most of the argument (here as in emacs vs. vim) is in matters of taste or philosophy - or a dead heat between valid technical concerns. tastypie or Flask? I submit that it matters more what makes you happy and productive, so that it is entirely valid to choose Flask, or Django, or both. After all, it is your life you are spending on all this, you should be happy. If you hate emacs, there are alternatives.

To be fair to the author of the presentation: if there is a problem, it isn't features and reuse. It's tight coupling, boilerplate and overhead. (Although it is funnier to say that the problem is features and reuse, like it is more provocative to say that Django sucks).

I won't slam Django, Django is good. Its most salient traits are its mindshare, liberality with features, big plugin ecosystem. And these traits were not all present from the beginning, when it was the Django developers who were reinventing wheels and going without features. Django's top traits are historically contingent. So in an alternate history, we might be talking about CherryPy having basically the same problems, because of the inherent pain of taking on so many features so quickly, then maintaining backward compatibility, etc.

Good framework or library code takes significantly longer to develop than similar functionality inside an app. When you add goals like trying to reduce boilerplate and coupling, it gets much harder and slower. It is totally valid to question why not just charge ahead with something easier to develop and get done more quickly. There is a real issue to think about here, it's not so clear cut.

It isn't as simple as saying "Flask is only nice because it has no features, anything with features is necessarily ugly." Both features and clean design take time and if you want both, even more time. But design is hard while features earn mindshare and dollars... if they work reliably, then who is complaining?

Now, at this point, Flask actually has a significant mindshare and plugin ecosystem of its own, so it is really inaccurate to say it has no features. And actually Flask does have a number of dependencies as well, with much of its implementation tucked away in Werkzeug (which is hardly a simple library).

I completely agree with you about needlessly provocative titles.

On the other hand, in the world of frameworks, it's not entirely common for the use cases to be (as) disjoint as they are for hammers vs. spatulas. More often, frameworks overlap in functionality and differ on matters of style and ideology. And this is what feeds the flame wars.

For starters, you have a choice between MyKitchen and spatula. MyKitchen has everything you need to make a reasonable pasta meal for up to 8 guests. The pasta practically serves itself... even when you are making steaks. spatula is totally dedicated to scraping things out of pots, and obviously you could just use MyKitchen.SpatulaFactory(_ctx) instead (you did read the equipment manifest, didn't you?) Plus MyKitchen has a plugin which will make pork buns that practically serve themselves... why waste time with low-level stuff like spatulas?

Some guy graduated from spaghetti to pizzas and he can only scoff at spatula, which is not necessary at all, since you can cook pizzas directly on the rack.

Another guy made this incredible pocket-sized leatherman which includes compact versions of all the kitchen tools including a camp stove.

It is true that most frameworks are better suited to some tasks than others, but for a given task one might be just plain technically inferior, or only different in some stylistic way.

Not that style doesn't matter, if it makes you feel happier doing your job. Otherwise, why bother with Ruby or Python when there is already Java EE or COBOL?

You can, but that doesn't mean you should. It's brittle. If your app or library breaks because a minor update to a dependency changed those internals completely, you can't say you weren't warned.

Would you mind saying a little about what kind of thing you are looking for? I am curious.

There is no dichotomous distinction between coding and using vim to automate tasks. The latter is part of the former - no different from using q or @ or .

As I recall, vimpager doesn't edit files, it just uses vim to view the file instead of using a different program to view the file.

Here's a gist comparing the Moka front page example to a slightly more typical Python way of doing things:

https://gist.github.com/1380898

EDIT: using the timeit module on these, the Moka version is about 18 times slower on my machine... not that this matters much if it's a much nicer way of expressing the program

It's totally legitimate for you to write this according to your own taste and use it. I don't think it's bad for Python, or anything like that. You are not an idiot and I am sure you can write interesting and useful programs in Python.

But I do agree that it is not 'Pythonic' - except maybe in the trivial sense that it's written in Python.

I would be happy to go into more detail if you really want it.

vimrc affects startup time, but like any program it isn't the lines but the work done which will make it slow or fast. How slowly does your computer read a 1000-line text file? vim is fast, setting some parameters in vimrc doesn't change that. Avoiding configuration that will make your life easier out of fears about performance is premature optimization.

If you have a ton of autocmds for frequent events, things can slow down. I also find that things can get slow when LOTS of calls are made to a language other than Vimscript.

But fundamentally, run Eclipse and Netbeans and gedit and emacs - vim should compare favorably even with a ton of config.

If you want to actually profile your startup time, try this on a recent version of vim: vim --startuptime=vim.log

Using Python and other runtimes is often kind of slow - it's not a huge deal but if you have a lot of this stuff in your config, then vim might start up only like 8 times faster than Eclipse.

The other thing is that the Vim API you use in these other languages is pretty much Vimscript anyway.

For me, Vimscript is basically a normal imperative language in the general neighborhood of perl and shell... I agree it is more awkward to write than Python, particularly with escaping. But it's a decent DSL for configuring text editors, and Python isn't as much.

I also have a huge vim configuration: https://github.com/sashahart/.vim

I highly recommend putting your vim configuration on github or similar, you don't have to worry about losing your config and it gets easier for everyone to learn the new tricks