glyph

"Meritocracy" is not a real concept of how to run a community, but rather a satirical term used to lampoon the idea that "merit" is a 1-dimensional concept which can be measured linearly and used to judge people and rank them. The term was invented as satire.

https://en.wikipedia.org/wiki/The_Rise_of_the_Meritocracy

Thinking that it's a good idea is like what happened with "waterfall" development. Someone described all the problems with what big companies were doing, and then someone else picked up that description of all the problems and said "ooh! all the big companies are doing this! this must be a great way to do things!" and then everyone perpetuated that disaster for the next two decades.

The fact that "hacker" culture has uncritically picked up on "meritocracy" and doesn't realize it's a snarky joke about unfairness says a lot about the unbelievably sheltered and privileged position that most people reading this site enjoy, and our collective lack of social skills. By "social skills" I don't just mean, like, how to behave at parties, but also how to manage groups and how to be aware of the perspectives of other people.

Not to mention the fact that if your open source community isn't measuring merit on an objective, defined-in-advance, linear scale, with measures in place, then you are not even practicing the (unfair, broken) system of "meritocracy", you're just doing "rule by cognitive bias" ("biasocracy"? surely nobody is going to take that term and think it's a worthy goal to aspire to).

You can trust me, because my community _does_ practice objective, quantitative meritocracy, and therefore I am provably the best and most deserving person in this conversation: https://twistedmatrix.com/highscores/

I don't think you read the article very carefully. Specifically, what I am claiming about (shared-state) threaded code which is not true of "any re-entrant code" is the fact that you cannot tell whether threaded code is re-entrant or not without a comprehensive, combinatorial whole-program analysis. It's not feasible to know what you might be re-entrant with, because you might be re-entrant with anything. With preemptive threads you really just can't do it at all, but with green threads you have to follow every call stack all the way to the bottom, because nothing else about it the bottom of the stack tells you whether you're going to context switch or not. When you get back a Deferred (or a Promise or a Future or a thunk or whatever), then the stack-inspection can be shallow; O(1) on the depth of your stack instead of O((stack_depth) * (function_length)).

You might be able to write the drivers without running afoul of the law. If it's a signature check, breaking it could be construed as a DMCA violation (in the US, probably some other law in friendly countries). Neither one's great, but there is a difference.

Python outperforms C in many cases. http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-a...

Twisted has a benchmark suite and release-to-release tracking of performance information, so that we can be sure optimizations have a positive impact. http://speed.twistedmatrix.com/timeline/

Twisted's event loop is faster than gevent and tornado. http://cyclone.io/

I can definitely relate; I was somewhat discouraged that it wasn't open source, and was somewhat resistant at first. It would have more value to me that way. I paid my $60 and I would easily pay another $60 if he'd open it up :).

So I understand that its proprietary nature is a cost and a risk, but it's important to keep that cost and risk in context.

For me, there are two mitigating factors.

(1): It's actually really, really good. It is hard to overstate this. As I am writing this I realize that I am shilling pretty hard for this product, so I should say I have no financial interest in helping the author succeed :). I am giving you this sales pitch as someone interested in the well-being of my fellow developers. If you spend your days staring and typing into a text editor, you owe it to yourself to give Sublime a serious shot. After two decades of Emacs, Vim, and Eclipse, the level of quality and polish in Sublime, even in the "beta", is almost shocking. It's not perfect, but there are aspects of it which will make you wonder why you ever put up with the obviously broken behaviors and terrible performance of (your favorite editor here). In particular, I should note that you can really get exactly the key-mappings you want on every platform, so you don't have to change your habits too significantly; it doesn't have any strange reserved keys that are hard-coded to behave differently on different platforms (I'm looking at you, Eclipse). After a few months of using Sublime, Emacs's weird, chunky, jerky scrolling, slow plugin-loading at startup, and constant pauses for GC seem like pointless self-punishment. Eclipse's patina of UI widget detritus looks distracting and confusing. And Vim's slavish adherence to the character grid and grating scriptability limitations (no way to perform timed or background tasks, random segfaults when changing buffers from certain contexts) will look dated and pathetic.

(2): Perhaps more importantly in terms of the amount of energy you might need to invest: although Sublime itself is proprietary, the API is actually reasonably narrow, and there is a ton of open-source Python that has grown up around it. So, if the Sublime Text core were to implode tomorrow, and you had a significant investment in a ton of plugins, you could bring the interesting bits over from your Sublime setup to Vim (via its Python bindings) or Emacs (via Pymacs) or Eclipse (via PyDev for Eclipse's Jython scripting bridge). Perhaps someone could even write a compatibility API that provided Sublime's Python API on those editors. In fact, I had made a conscious decision a couple of years ago to stop writing ELisp and VimScript and start doing as much of my personal editor customization in Python, and that really paid off when I moved over to Sublime; my custom habits and automation were mostly there already. Had I been going from Sublime rather than to it, wrapping the underlying API to do something sensible in Emacs or Vim would be a lot easier than trying to turn my ad-hoc eval()'d turds of elisp and vimscript into something same.

I was pretty surprised that I like Sublime so much. I am pretty finicky about my editor; I spend tons of time customizing it and adding on to it and scripting it and automating things. Since my initial burst of making Sublime behave like the parts of Emacs I care about, though, I've had to tweak it far less than any of my previous experiments, and I really got to know all the editors I've used in the past pretty deeply.

My suggestion would be to get it, use it, love it, and just send the author a friendly note saying that, as a paying customer (rather than a random Internet troll), you'd love it even more if the source were available under a friendly license.

But that's the whole point of the article: the whole value of the CrunchFund (and its ilk) is that Arrington (and his ilk) will be a douche on your behalf. If it were just the money, it wouldn't be worth it for the companies they invest in: the amounts are too small. It's an alternative compensation scheme for a PR flack who masquerades as a journalist. There's no ethical way to run the fund, because it would be worthless if it were ethical.

Thanks for the thorough critique! Obviously doing all of this is a ton of work, so it's not going to get done right away, but none of this is inconsistent with our existing long-term plans for Twisted's documentation. I hope that if you do get forced to work with Twisted again we will have made the learning experience considerably smoother :-).

There's plenty not to like about JavaScript, but the biggest mess is this:

js> x = 1 1 js> z = x.y js> // WTF??

In other words: it's not an error to access an attribute of an object which isn't there. It's dicey enough that you can have attributes in Python and Ruby that can be misspelled, and mismatch their declarations, without an immediate compiler error. But, that is reasonable to deal with as long as you have pretty good unit test coverage: after all, if you run the code that is actually accessing the attribute, you'll quickly see that there's a run-time error and fix it:

irb(main):001:0> x = 1 => 1 irb(main):002:0> z = x.y NoMethodError: undefined method `y' for 1:Fixnum from (irb):2

~or~

>>> x = 1 >>> z = x.y Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'int' object has no attribute 'y'

... and you need unit test coverage anyway, because the compiler can't save you from a huge variety of other violations, so it's not like this is really making much extra work for you.

In JavaScript, by the time you actually encounter an error, it's too late to figure out where the heck the erroneous object is getting generated. So, if you have some code like 'this.observers.push(object.somefunc);', every test case which adds an observer must also verify what happens when the observer gets called: and it has to be the same test so you have some idea where the observer came from, whereas you can easily make those things different tests in Python.

Then, in order to get reasonable error-reporting behavior from quick things which aren't tested, you have to have tons of manual type-checks anywhere that objects are put into a persistent container, because by the time you have some random 'undefined' in your list of observers, it's far too late to figure out how it got there.

This type of paranoid defensive programming is a bad idea in Python and Ruby, because you can just let the language runtime do its job and inform you if there's an error, and your stacktraces will give you a good idea where it is.

The fact that sometimes unknown things are 'undefined' and sometimes they're 'null' and sometimes they're '"undefined"' and sometimes they're the empty string and sometimes they're 0 really compounds this problem. Python has None, Ruby has nil, and nobody uses random ad-hoc sentinel values because why would you do that?

The thing that just blows my mind is that the designers of JavaScript must have _known_ that this was a terrible idea, because:

js> undefined.undefined typein:1: TypeError: undefined has no properties js> null.nothing typein:2: TypeError: null has no properties

so when you are two steps out from the misspelling that caused your error, you can figure out that something has in fact gone wrong. And:

js> blub typein:3: ReferenceError: blub is not defined

since the assumption that everything you really care about in JavaScript is going to be a global variable, and prototype attributes are kind of an afterthought. After all, why would you store data in organized structures when you can just stuff it all into an undifferentiated bag of crap in the global namespace! It's all going to go away when you reload the page, right?

Except then Node comes along and changes the equation so you actually have to live with your persistent data structures and you probably want to know when things go wrong in your long-running servers. Oops.

Here I really have to agree with Ted: despite the fact that there are advantages to be had from keeping your client and your server in the same language and leveraging your investment in utility libraries in both places, JavaScript really is bad enough language that it's worth the effort to use something different when you can.

Actually, PyPy is already a drop-in replacement for many uses, and is getting closer to being a complete drop-in replacement all the time. For example, they have a source-compatible implementation of the CPython C API: http://morepypy.blogspot.com/2010/04/using-cpython-extension...