MostAwesomeDude

I have successfully avoided purchasing Apple products for a long time, and aside from a gift, haven't bought Microsoft software for a good decade. Google's not on my boycott list yet, but I won't hesitate to stop using all of their services (beyond that required for work) if I find it morally reprehensible to do otherwise.

Your laziness is not our laziness, and your apathy is not our apathy.

It doesn't necessarily take maturity. One can be extremely self-deprecating and refuse to find any good parts in their code.

Current sociological research pretty heavily points to consumer disillusion and annoyance with the behavior of studios as the reason that they decide to pirate, to not go to theaters, and to pursue alternative forms of entertainment.

Most people are just as "unreasonable" as the grandparent, which is to say that they are highly reasonable and you are the unreasonable one.

I don't know if you remember a film from about forty years ago, where the general public was exhorted to admit that they were, in fact, "mad as hell," and as result, "not gonna take it any more." People are currently mad as hell, and now we're seeing them decide (unsurprisingly) to not take it any more.

Yes. This is already how many communities are referring to it.

The other way around; Firefox nightlies let you use Python to script the DOM directly.

I politely submit that what you actually want is Python, Ruby, or Lua in the browser.

This article cherry-picks and attempts to bang on the table, probably because banging on the facts would not turn out so well.

He claims that C was designed by committee, which I can only assume is a defensive projection meant to hide that C++ was designed and is maintained by committee. He points out mplayer as an example of C code that is supposed to be good but is actually bad, which is a low blow. (mplayer's code quality has always been awful and this is well-known in the community.)

The railing against C++ object models being bad is similarly defensive, and I get the feeling that the author is deliberately trying to make people forget that pImpls ever happen.

C++ is an incredibly obtuse language, full of so many misfeatures and fancy whirligigs that it's difficult to be certain that even repeated reads through a file are giving you the correct impression of structure and flow.

You might be surprised to learn that there are languages that are agnostic in what they target.

For what it's worth, PyPy had a multimethod implementation that it used to power some of the more polymorphic builtin functions in Python. They recently started killing them off as too difficult to reason about and maintain.

Don't limit yourself to JSON. Your dislike of XML does not mean that JSON is always the right answer. Instead, write code that flexibly can render to any of a set of formats, and use content negotiation to determine which format the user agent wishes to consume. This lets you do things like let the read-only portion of your API be accessible via browser, and it will future-proof you.

There are two options for Python networking: Twisted, and things that are not Twisted. Guess which one most people pick.

What do you use to package? distutils, setuptools, distribute, distutils2, pkgutils...? How to choose?

Disagree; Python's hardest problem is packaging, followed closely by bikeshedding over networking libraries and an ever-growing dichotomy between the Python 3 and Python 2 universes of code.

You can skip all conversation about the GIL and threads neatly by simply preferring a different concurrency model. There are plenty of ways to do this (see above re: bikesheds and their colors), but being permanently tied to CPython and the threading module is increasingly uncommon for professional Python, and it isn't as unavoidable as things like networking or even which language you're going to use.

Edit: I see that the author's in this thread. Nicely written article, but a tad hyperbolic.

Sometimes, you are wrong.

Out of curiosity, do you have any documentation on reifying and reflecting continuations in pure concatenative languages? I did some preliminary work in this direction a bit ago, but found that the pure concatenative languages, like Joy, don't actually have continuations (delimited or undelimited) with the flexibility that I'd like, and Factor's continuations aren't pure. Factor cheats in order to get its stack effects to line up, with a separate continuation stack.

Additionally, if you've managed to crack this puzzle, I'd love to see some documentation accompanying FJS, because it is a major omission from the concatenative literature and nobody seems to actually have anything to read besides the shift/reset white papers.

Sucrose is exactly half-and-half fructose and glucose; it is composed of one of each, bound together. This is important because it means that it can't be immediately absorbed into the bloodstream. It has to be broken apart first, and the enzyme that does so is in the intestine. This means that its absorption rates and effect on the glycemic index are different from HFCS. Diabetics care about this.

While I can't really argue against you, partially because you're tptacek and partially because you're not wrong here, it's quite irritating to see somebody have a good conclusion and faulty premises.

Also, stop with the scare quotes.

Wait, wait, wait. Are you saying that the kid that came up with this stuff only eats it five days a week? I feel cheated.

Could you rephrase your comment without the words "Drupal" and "works" next to each other? You are unconsciously reinforcing the author's point.

You've nailed it.

I work in Seattle. Before I moved there, I lived and worked in Oregon, in the Valley. I grew up with working public transportation, with buses that were affordable and ubiquitous. The school that I went to, Oregon State University, came to an agreement with the city that it was in, and they cooperated to make all buses free within city limits. Yes, even for non-students and non-residents.

Portland's transportation is great, and Seattle's transportation is great. Every time I visit the Bay for work, I cringe, because I know exactly what to expect: Hours of trains and buses if I don't want to rent a car. It's utterly ridiculous.

asyncore is almost certainly the worst module in the standard library.

Most popular Haskell libraries use single-letter names internally for type and value variables, and then verbose, full names for Types and TypeConstructors. Don't get soured on Haskell just because of one presentation.

Huh. I didn't do any of this. Maybe there isn't a single way to do things.

His name is "Alan." I'm not sure how you managed to copy-paste that improperly.

I was an X.org hacker a few years ago. X predates me.

X is (very) roughly the size of GCC. It's massive and it's nearly entirely C, with a few modern Python scripts to generate some of the more onerous tables. There are many old libraries, and they are horrifying. Eldritch, cyclopean, etc.

As a friend of mine pointed out, PHP's problem is not that it's improving, but that bad things continue to happen. C wrappers continue to be thinner than tissue paper, error-handling routines continue to segfault, and bizarre security holes continue to be found.

"Decent object-oriented structure" doesn't help when the language still has so many primitive types. Namespaces don't help when most of the built-in and standard libraries live in the global namespace, C-style. The runtime is still creaky and inefficient.

There's not really any hate these days, just eye-rolling. You could be doing better things, but you're deliberately choosing not to, and harming nobody but yourself in the process.

Neither. Flask presumes that you know Python and that you understand how requests and responses work. This isn't impossible for a beginner, but it's certainly not likely.

Flask's main API is heavily based on decorators, and those are a perennial problem for new programmers.

Whatever you say, Mr. Lawdawg. What a great last name; I wish I could have one like that.

Dunno if the author's around, but Haskell does not descend from Lisps in the way that he thinks; it is much more closely related to the ML family.

This seems like a checklist for when to factor, not when to refactor; he appears to be describing massive mutant code that has never actually been split into manageable chunks.

I think that you should assemble your team of thirty random people on HN and get them to do that thing that you want them to do. Good luck!

But not everybody has an email address! Oh noes!

No, seriously, this is a bad link, it's got no advice, and it's not helpful.

Here's some serious advice: Put a field in your database, make it Unicode, bound it according to your DBA's advice on how much space you have to spare. A couple thousand code points should be plenty. Then give your users a single field called "Name" and have it accept up to a couple thousand Unicode points. Done.