reuser

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?

Evolution is systematic change in allele frequencies.

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.

If Pinterest's business model is based on copyright violation, I don't expect them to do anything except dry up and blow away.

It's not like I am obligated to recognize Pinterest's right to exist. Some companies are based on questionable or illegal practices, period.

I applaud your effort. Regex is a valuable skill (really, language) which you will use across languages and programs as it gives you access to an efficient and pretty general method for scanning and extracting things from text. And if you study fundamentals of computer science (like the Chomsky hierarchy) you will also find that regular expressions are important there too.

vim or pydev

The specific reason not to switch to Jinja2 was that Django's templating language was originally intended not to be that powerful, so that you could feel reasonably safe handing it to non-technical "designers" or "writers" rather than fearing that they would generate a great variety of new tracebacks for you to look at.

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

You are right. It isn't your job to learn on old versions of Python just so that Django does not have to release a port yet. Many projects have been waiting on other projects to port, thankfully the progress in library porting has picked up speed and the available library for Python 3 is very usable.

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

If you leapt directly from $50 to $900, how should I know that there aren't sweet spots between those two points?

I have never had a $900 chair and I have managed to avoid injury, but perhaps I am just especially robust?

My impression is that Wayland planned to support X as a compatibility option. The difference is that X isn't the low level mediator of all input/graphics by default. As I understand.

http://wayland.freedesktop.org/faq.html

Pleasantries aren't part of this kind of "good taste".

Freedom from drudgery sounds great, but who will pay for those people to eat and do more fulfilling things?

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.

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.

OK, so I love Python.

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.

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.

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.

"Arguably" every API ever written is a domain-specific language.

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.

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.

Please share your data showing that Coffeescript is faster than CPython

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.

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.

Ease of learning is often decoupled from ease of efficient use, sometimes even inversely related. 'Usable' is not one thing for everybody.

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.

I like the part about ego because too much of the programming (sorry, "engineering," no wait I mean "architecting") world is focused on a kind of dick-size comparison which is somewhat poisonous and skews things toward self-promotion and away from doing useful things and enjoying yourself.

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.

This excellent solution does assume one is using an editor which supports it, which many people do not (causing endless frustration to them)

If license costs are so big that they become this important a factor in deciding how you will scale, they have become an operational problem of some size. Probably not a size which is imminently threatening to Stack Exchange. But it is not nothing, or it would not figure so prominently in this shop talk about how to upgrade.

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'm not angry that Canonical has not dedicated a staff member to Lubuntu or Xubuntu, why should I rage over Canonical not having a staff member dedicated to Kubuntu? The community is doing a fine job.

I have no problem with Unity and if I did, I have no problem installing Xfce either.

That was written by Jonathan Riddell, who worked on Kubuntu. I am fairly certain he is not trash-talking KDE and I am also fairly certain that Ubuntu is not using him as a mouthpiece to trash SUSE.

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.

After all of their evangelism about Windows servers, it is rich to see this: "but it’s so cheap compared to say a single SQL Server license that it seems silly not to do it."

Yes, that is the problem isn't it?