The only way I can think of to pay for this, is for the more productive people to pay, in the form of a citizen's wage. We have the first inkling of this in Britain, in the form of the proposed universal credit.
But it should be borne in mind that stuff is getting cheaper, thanks to automation. The proportion of income spent on food has fallen from 33% to 15% in fifty years.
In any case, I think we have little option. It's possible that current employment problems are a blip, but annual hours worked per person have fallen by around 25% since 1950. And halved since the 19th century. It looks like a trend to me.
they themselves will have to produce value - they will just be producing those value not as part of employment, but for themselves (e.g., subsistance living? cottage industry?).
But you are going to find people in the Python world telling you to abide by PEP8. And saying that you should be using virtualenv. And saying that you should not use (module-level) globals. And saying that you should be using various checking tools. And the checking tools may say annoying things (some of which will be good points about your code).
And I'm kind of one of those people, as well; not saying that there aren't reasons to break a rule, or that it instantly makes your code crap if you do, but I understand these arguments.
And a vocal number of those on Python IRC channels tend to be dicks to newbies or people with unusual ideas.
So I guess I would question whether Python is going to give you what you want. I can't speak much to Ruby's culture.
Use the tools you like which make your life better, and if it makes your life better then ignore other people's unsolicited opinions on the internet and just do your thing.
>>Python is much better positioned here, since the default is to be sane.
As opposed to Perl? Are you trolling or can you list a few insane things in e.g. the Perl Best Practices book?
Edit: page 470 of Perl Best Practices (also pg 429 and 431) -- recommends using strict and warnings. It is hardly controversial or insane, it catches bugs.
if there are 469 pages of best practices more important than "use strict", I think "insane" is a fair description of the language.
I'm not making the point it's impossible to write good Perl, because I know it's possible, I'm saying it's easy to write bad Perl - much easier than in most other languages I've seen.
I have to add "my" to a variable to get reasonably-sane scoping, the default is that everything's global.
Perl's defaults tend more to the insane side of the spectrum, especially in comparison with Python (who's entire design philosophy is a reaction to Perl). Not that there's anything wrong with that, and if you've done mostly perl I'm sure it seems natural, but compared to conventions across every other mainstream language it seems crazy.
People writing tools to learn, or because the existing ones didn't suit their needs or tastes, occurs in every language and is very different from Perl-style "more than one way to do it".
It's ridiculous to act like the mere existence of multiple independent projects for one task is some kind of searing indictment of the "one obvious way" principle in language and API design.
I've never actually noticed "one obvious way". There are a couple ways to do almost everything in Python; loops or map, Twisted or threads, unittest2 or nose, and so on. I like Python, but human nature pushes everything towards "there are many ways to do it", and humans have influenced the direction of Python.
I prefer Perl's approach of embracing more than one way to do things. I don't really want there to be 8 ways to do one thing, but it's just a more realistic outlook. You go into Perl knowing that you are going to have to try a bunch of different things to see what fits your mental model, instead of being told what to do. (I used Python at a Bank where they wrote their own style guide, completely different from the standard Python style guide. WTF? Humans have a way of ruining everything.)
Ironically, many things in Perl have converged into "One Obvious Way"; PSGI/Plack for web frameworks, Test::Builder for unit tests, and so on.
> There are a couple ways to do almost everything in Python; loops or map, Twisted or threads, unittest2 or nose, and so on
There are always more than 1 ways to do something, but Python tries to be directive towards the recommended way for the core.
For the given snippet, using reduce for loops is frowned upon; nothing is stopping you from doing it, but the general opinion is you shouldn't do it. I think that counts as there being an obvious way.
def pipe(val, fns):
return reduce(lambda val, fn: fn(val), fns, val)
def pipe2(val, fns):
for fn in fns:
val = fn(val)
return val
fns = [lambda x: x + 1, lambda x: x * x]
print pipe(5, fns)
print pipe2(5, fns)
As far as maps and list comprehension go, that isn't clear-cut but people incline towards comprehensions.
<nitpick>
Twisted(reactors) and threads implement two different things which serve different purposes, and unittest2 is a lib while nose is a test runner.
</nitpick>
That said, there is always going to be many ways to do something, but it helps if the core tries to stick with a uniform way to do things.
Django has such numeric superiority that there is not a lot of point splitting hairs on whether it is "default." While it isn't in the stdlib and there are other good choices, Django might as well be the default, just as Rails might as well be the default in Ruby.
You sure about that? It is my understanding that Zope/Plone has a fairly sizable community. They're just not as loud on the web as other framework fans. No one will know for sure until they are all counted though.
I'm heuristically pretty sure. From my personal experience talking to people, and from some surveys or other I have casually looked at over the years, what is mentioned most in job ads and mailing lists, heuristic stuff like that. The same kind of stuff which leads people to say that Rails is much more popular than other Ruby frameworks.
I would love to see a scientifically exact census but I don't think it can be done. Maybe PyPI could roughly tell the story? But you won't get a real unique-users count unless your logging identifies unique users, who wants that?
Please understand: I am not a big Django promoter, I disagree with many of its design principles, and I don't think that other things are "dead". I know that there are reasonable numbers of people out there using Zope/Plone, Flask, Pyramid, and other things. Just because Django is huge doesn't mean they are nothing or not worth looking at.
I believe Rails is significantly bigger than Django, but that doesn't mean I'm switching to Rails.
There is no Pope of Python to tell you "you can't write new code to do xyz, because someone else is already working on that."
How would that be enforced? Would someone's Python privileges be taken away?
What if the person working on xyz was inactive for a while? What if their xyz had a problem and they didn't want to fix it?
The "obvious way to do it" does not and was never, ever intended to bind anyone's hands from writing a library or app similar to something someone else wrote. It is a principle of language design, that it should give SOME consideration to readability and learnability rather than giving 100% of everything to nifty obscure features that help you write awesomely clever executable line noise.
I'm very amused that someone else has observed this about PyPy, I began to think I was the only one. It does not seem to be the orthodox view.
I like CPython's fast startups and low memory overhead, bad scores in Pfannkuch benchmarks notwithstanding. If PyPy runs my everyday stuff better to casual inspection I will get a different impression, but as things stand I see it as a kind of Java-ization whose superiority is often unclear or qualified.
Is a JIT always better? Is reference counting always worse? Is it a total no-brainer to want Software Transactional Memory? I don't think so. But I think there are some arguments, and perhaps as importantly I think there are many newer Python folks who want to make a name for themselves.
What would be the point of filing bugs against PyPy stating that it is slower or more resource-hungry on programs XYZ, when this is ultimately due to PyPy's core design decisions which are a point of pride and never going to be abandoned?
Expecting some positive outcome from that seems incredibly unrealistic to me. I believe it is a waste of time. It isn't my responsibility to provide reasons to PyPy why I'm not using it. Let PyPy - a project receiving no small amount of promotion - show that it is better for my purposes, before I invest big in switching over projects.
What you COULD say is that it doesn't make sense that in practice, people are treated like idiots and flamed if they publicly mention that they don't find in practice that PyPy is always or even generally better than CPython.
Or you could say that they should both work for most purposes, and that the choice is nuanced (measure the difference yourself), and in just a few respects PyPy is not as mature (not surprising given the lengths of the projects' histories). And PyPy is a work in progress and you expect it to get better if it isn't better than CPython now, for some specific purpose.
I don't expect you to say either of those things, because it seems important to the PyPy project to promote it over CPython and if that means selectively mentioning only the cases which are in PyPy's favor, or softly suppressing dissent, then so be it. That is how it seems to me, and I don't understand why it has to be that way.
I think your point about "should work for most purposes" express my view as well. Choice is tricky and especially programs violently optimized for CPython might find PyPy's characteristics strangely different. I don't see any particular design decisions that would prevent PyPy outperforming CPython on everything in the long run, but this is certainly not the case right now.
Maybe our PR got too strong or something, but I think "measure yourself and report if it's too slow" was always our motto. In fact we're definitely more interested about hearing when people find their programs slow, rather than fast because it gives us more optimization opportunities. It's however entirely pointless without a way for me to reproduce it, since I have entirely no clue.
In short - I think we violently agree and if PyPy's PR is not up to the standard and fairness you would expect, I apologize.
I've seen the promotional materials on PyPy's performance (I find them particularly persuasive on odd synthetic benchmarks) but thank you for the link.
I think you are a nice guy doing very useful work. You deserve to be proud of your work. But I do think you should be aware that an aggressive social orthodoxy has formed around the performance of PyPy. (It isn't unusual that I was downvoted here for suggesting PyPy isn't always faster, for example; it's the same thing in other fora and offline).
I think the PyPy's approach for generating Python interpreters is a great, clever idea. I think the project is more exciting than Shedskin was, etc. I'm impressed at the progress that has been made in expanding functionality and library support. I am looking forward (although with a little skepticism) to the day when it's really better at everything and is on my phone and everywhere. Sounds good.
But I am concerned about a cultural shift in Python, and unnecessary increases in complexity which come along with it. Many of the things which drew me to Python years ago come from its roots in the Unix/C world. I only recently began to hear dogmatic arguments that JIT is always faster than ASM, and memory is cheap so it makes no difference to use 2-4x as much, and being able to hook up to C isn't so important, and everyone should be writing incomprehensible, heavily-threaded programs using the world's biggest gc and synchronization mechanisms which require a lot of close supervision by people with pompous job titles. And you end up managing concerns of this type more than you spend writing domain code. And you do it all not because it is the cleanest and most direct way to get a good result, but because it's what is understood to be the right thing.
So I think a lot depends on whether PyPy drinks too much of its own kool-aid. It could second-system Python to death. It could succumb entirely to Enterprisitis. I don't need CPython, but I hope PyPy will smell like it. If the culture and the working environment continue to Java-ize, I will probably jump ship to Go or Ruby or whatever has a good library and most of the virtues I currently get from Python. I don't think that going more complicated is the best way to make software faster or better and it is important to my quality of life that I feel good about the code I am writing.
Creativity doesn't need to come in the form of doing some boring task in a contorted or intentionally complex or showy way, though. You can be creative in choosing tasks and in choosing good novel approaches to tasks. Often the conventional way is bad enough that there is novelty in doing a straightforward and clean implementation.
Besides that, getting it done in a way that you can reasonably verify as correct and you don't have to rewrite (read: a maintainable way) means you get to free up resources for whatever you are ultimately trying to do with that code. 'Boring' code plays a huge enabling role for creative code and creative projects.
Finally, creativity may be something but it isn't everything; in the rare event that writing code in a way that gets things done or helps people does not provide enough scope for creativity, your activity is more in the vein of pure recreation or performance art, and you shouldn't worry at all about maintainability. Just know what you are doing.
If you are just writing for yourself, and you don't need tests, etc. then who cares what you do. Follow your bliss and more power to you. But if there is some chance I will have to fix or figure out your code - please DO try to make it maintainable. Useful code is useful even if it's dirty, but it's just polite to consider your audience. Surely this is not controversial?
Maybe the issue here is some disagreement about what "maintainable" means and in particular, in how and where it conflicts with "clever."
If "clever" means intentionally obfuscated, or doing something in a complex or unorthodox way just to show off, I don't think there is much controversy that this is unhelpful and not good unless you are just pleasing yourself. If "clever" means extreme conciseness beyond the point where it makes it very hard to read and understand, I would tend to look at that as more of the same.
Cleverness is often instituted to make code more maintainable, as in many cases of "Don't Repeat Yourself" using introspection. I tend to think that gratuitously huge amounts of mandatory boilerplate are very not-clever and actually decrease maintainability.
For example, I have seen dependency injection being heavily touted for 'maintainability', but making a religion out of this can lead to all kinds of tortured and unclear code (just like what you see from many people who have recently become infatuated with "patterns"). Code which is overly complex for the task, and hard to read, isn't that maintainable in my book.
Cleverness can also be done behind the scenes of an API, hidden behind a screen, to make life easier for the API's end users. Sometimes this is good, sometimes bad. Often it is worthwhile to get a clean implementation, just hard to do.
I don't think there is any clear definition of "code monkey" but I think such derogatory terms should be reserved for people who are really incompetent all around, not just people who do clean workmanlike jobs and worry about how their code reads and extends and so on. Those are good things to worry about; there are other things to worry about, but those are good things to worry about.
