Python already has tools for this. IF I were interested in my working environment becoming more like a Ruby working environment, why wouldn't I just use Ruby?
51 karma · joined November 10, 2011
The combination of natural selection and sexual reproduction tends to produce organisms which "fit to" their environments (hence "fitness"). It does so reliably enough that it might as well be the goal.
"AI systems" are not like people and they don't need people to be around to work, they do not function on the basis of ongoing intelligence from people. If the people die and there is nobody around to care, the same mechanisms do what they always did according to the natural law of the universe. They are just mechanisms which get things done. And so is evolution. And it is irrelevant that no person designed evolution to be that way.
It's not like I am obligated to recognize Pinterest's right to exist. Some companies are based on questionable or illegal practices, period.
If you have to ask why Django would not switch to (or even make any effort to allow the use of) any externally developed tool in place of its own, you might not have noticed that almost everything in Django is self-developed and that the officially given reason is that they are "perfectionists. with deadlines."
The reason why not is the Django project's philosophy
And Python 3 actually is a reasonable decision for a beginner. It is more consistent and does a better job of exposing the 'right' way to do many things.
Python 2 is reaching the end of its life and has little purpose except to support legacy libraries and apps and ease the transition.
It is not the users of Python 3, but people insisting on using Python 2 to the EXCLUSION of Python 3, who are fragmenting Python
I have never had a $900 chair and I have managed to avoid injury, but perhaps I am just especially robust?
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.
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.
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.
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.
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.
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 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.
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.
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.
So: a skeuomorph is obviously not a problem if it does not cause gratuitous errors or slowdowns, and it obviously is if it does.
And in any case design also concerns matters of taste, on which opinions will naturally differ.
Programming is a joy when I can just let the task take care of itself as I watch. I can do this in amateur or "hacker" settings but I see less and less of those these days.
It makes me unhappy when programming is a prop or setting for selfish and self-conscious and mean social behavior, as it seem to be more among people who take it as a profession more than a passion.
It's certainly a factor worth weighing when you consider what technology you'll build on top of.
In no place have I "argued against what they've done" or implied that the company is a failure. Yet money IS a part of scaling, and managing expenses IS a part of business. I'm happy to take your word that Stack Exchange makes so much money that it cannot ever matter how much their licenses cost. But in the context of evangelism for others to make the same decision, I have to observe that the kind of reasoning casually mentioned in the article implies something that would be negative for many other businesses.
If you are offended by that sort of discussion of reality then you have too thin a skin (or a conflict of interests)
I have no problem with Unity and if I did, I have no problem installing Xfce either.
So it isn't necessary to get very hot toward Ubuntu on account of it. Maybe Riddell misspoke. I seriously doubt anyone is trying to be mean to SUSE, let alone all of Ubuntu doing so through people who were working on Kubuntu.
I think it's just gratuitous to blame "mindless Ubuntu fanboyism and intolerance of alternatives" for this sort of illusory perceived slight. I like your posts, but I don't see why you would get this angry. Ubuntu is also an alternative, so clearly is SUSE, if you think Jonathan Riddell is picking on SUSE you can just ignore him.
Yes, that is the problem isn't it?