Disqus - Latest Comments for glyph

Re: Programming changed forever -

Glyph — Fri, 16 Jan 2026 00:53:07 -0000

By calling it "anti-AI hype" antirez is trying to do the same thing that the Apes of "This Is Financial Advice" fame did by redefining "shill" from "someone who is dishonestly trying to sell something" to "someone who is attempting to interrupt OUR dishonest attempt to sell something". A rhetorical attempt to invert meaning and make conversation impossible. Thank you for seeing through it.

Re: US venmo

Glyph — Mon, 27 Jun 2022 16:13:20 -0000

Re: : Test-Driven Development

Glyph — Thu, 20 Oct 2016 20:44:02 -0000

As much as I think this study is flawed, replying to legit scientific research with an exhortation to check out a marketing / trade industry website is not going to advance the state of the art. TDD may well be awesome, but a website *dedicated to its awesomeness* is not going to present a dispassionate assessment of empirical facts.

Re: : Test-Driven Development

Glyph — Wed, 19 Oct 2016 15:02:50 -0000

You can ensure 100% coverage with automated tooling, though, ensuring that TLD and TDD would have equivalent metrics.

Re: : Test-Driven Development

Glyph — Wed, 19 Oct 2016 15:01:41 -0000

Your understanding of the study is correct, or at least, the same as mine. My view is that unit testing helps, and TDD helps more. What I was saying was that if you had a control group that did no testing at all, that group might reasonably expect to have a low defect count on this tiny of an assignment as well; at a slightly larger scale you'd start to see testing-at-all mattering, and then at an *even* larger scale you'd see TDD being better than TLD.

Re: : Test-Driven Development

Glyph — Thu, 06 Oct 2016 15:06:54 -0000

The view that I'd be reconsidering was really my level of emphasis on *other* folks doing it, not necessarily me doing it myself.

Re: : Test-Driven Development

Glyph — Thu, 06 Oct 2016 14:06:59 -0000

Glad to hear you think that this can be studied more economically. I'm not an academic, and I was sharing my concerns on this hopefully academic-leaning site in the hopes that someone else would say exactly this :-).

Please do post those longer-term studies. I have to assume based on your tone in this article that their results are the same as this one, but I'm keen to look at the specifics and see if maybe I *should* be changing my view of TDD.

Re: : Test-Driven Development

Glyph — Wed, 05 Oct 2016 23:29:01 -0000

I still have a problem with a lot of these studies.

Here's my hypothesis, based on personal experience: the benefits of TDD begin to manifest when they are applied at scale. During design and development, if a single developer can plausibly understand an entire system in their head, the benefits of TDD (and, in fact, unit testing) are negligible. However, there's a non-linear benefit as systems become larger, particularly in the diagnosis of large and complex system failures.

The problem with this hypothesis is that I cannot formulate a study or experiment that could validate it for less than a half a billion dollars or so. This strikes me as a huge problem in software engineering research generally: many (if not most) of the practices I consider beneficial for professional developers are at best pointless and at worst actively harmful when you apply them to problems that have been scaled down too far. I'm a huge TDD proponent, and I would not *expect* to see any benefit from TDD for an undergrad working on a handful of programming katas.

I suspect that some useful work in this direction might be Monte Carlo simulations of simplified models of developer psychology, but even the hypotheticals I can dream up there would mostly be for simulating the utility of regression testing on large codebases, not the benefits of TDD vs. TLD.

My question for others is: are there studies which have looked at the value of TDD longitudinally? There's a wealth of experimental evidence at this point, but all the evidence that I'm aware of is of this variety; extremely short term, extremely small projects. While I appreciate that these researchers are trying to investigate this claim, it's sort of like analyzing refined sugar's impact on obesity by giving a room of 100 subjects a teaspoon of glucose and then observing how many of them become obese in the following 10 minutes.

Re: The hardest problem in computer science

Glyph — Wed, 27 Jul 2016 05:08:35 -0000

Nitpick: “signature” is the set of arguments that it takes, and typically also the type of the return value and any exceptions that it might raise. The return value part is really important, which is why I took the time to nitpick ;).

Re: On a technicality

Glyph — Sat, 23 Jul 2016 21:09:44 -0000

> in reasonably large communities, there doesn't have to be a well-defined in-group, or fully centralized control

At that point, what you have is a platform, not a community.

> For example, some forums allow users to personally block other users' posts from showing up for them, going back to Usenet killfiles and including today's Twitter blocks and mutes

Are you seriously holding up Twitter and Usenet as paragons of effective community management? Shared blocklists only work if you have very strong identity management and creation of new pseudonyms is expensive. On Twitter they only work against the most casual trolls.

> might be capable of sustaining functional, reasonably-sized communities. Might. Dunno.

Given that every attempt to do this has failed dramatically, the null hypothesis is "no". The reason I spoke derisively about attempting to do so is that generally attempts to do this simply ignore or shout down explanations of the endemic failures that previous attempts have experienced.

Similarly, automated moderation often just reflects the biases of the moderators, but without the capacity to learn. This is true even in gravely important areas of life - http://www.npr.org/2016/03/... - so it's very unlikely that forum-moderation machine-learning will be responsibly architected to the degree where it can really be trusted.

> As one possibility, imagine that after pressing submit on a post, you got an auto-nag along the lines of "my neural network thinks this post is inflammatory; unless you're sure it's wrong, why not read the rules and tone it down?"

However, this does strike me as a really good idea. It strikes a good balance between remaining aware of the technical problems with providing good tools to help people be more responsible. In other words: computer-driven moderation no, computer-assisted moderation yes.

Re: On a technicality

Glyph — Sat, 23 Jul 2016 16:37:35 -0000

Thanks for your feedback, I wasn't really aware of that; I somewhat ethnocentrically assumed the british version of this had been globalized. Do you have any other mechanisms for selecting jurors or judges from other societies you think are a good idea to put forth?

Re: On a technicality

Glyph — Sat, 23 Jul 2016 16:28:56 -0000

This idea is incoherent, technologically speaking. If you have a "forum", that is, an indexed list of posts, someone has write access to the index, and therefore, control over what participants see. If _nobody_ has control over that, and anyone can write anything at any time, then nobody can exert any kind of control over their own computers (if you can't choose which index to go to, then your screen will just be displaying a random jumble of garbage from every corner of the internet simultaneously).

You can store your posts on a content-addressable network and you can do all kinds of crypto or blockchain shenanigans to make it _possible_ to access content securely and privately if you _want_ to, but when it comes down to it, communities are constructs that involve distinguishing between an in-group and an out-group, between which things are posted and which aren't.

In terms of using machine learning to build curated indexes that resolve in coherent communities and eliminating people from the moderation loop, my criticism is much more straightforward:

Ha. Ha ha. Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha.

Re: On a technicality

Glyph — Sat, 23 Jul 2016 06:12:26 -0000

I think you've actually gotten a lot closer to an answer than you realize: the answer here is *adjudication*.

For a small community, dictatorial adjudication can be fine. If you don't like it, you can go somewhere else. However, as you have noticed and outlined here, this solution doesn't scale. You can't have arbitrary dictatorial decisions banning political speech in a public forum, for example; your personal blog comments are niche enough that you can just do what you like, but giant culture-wide systems like Twitter really do start to bump up against real issues of freedom of expression.

For a larger community, what you need is to copy what you've observed works in civil society: a jury system.

You want subjective human judgement, so people need to be involved. You want the judgement to be impartial, so the selection of the human jurors has to be effectively random, or at least, done without consideration of the specific case at hand, beyond people recusing themselves for conflicts of interest. You also need the jurors to be representative.

In the legal system you get into the juror pool by being a citizen. Everybody has to participate, it's mandatory; if you don't want to, you have to demonstrate hardship. Forum systems could have something similar: you get entered into the pool by having an account in good standing, and get selected for "jury duty", and participate in good faith, or lose access to your account or that "good standing", whatever it means.

This doesn't mean you need to make decisions democratically. The jurors might get more sensitive information than you'd wish to make public.

Ultimately I think this is where CoC enforcement, for example, needs to go. Right now the system is so horribly imbalanced that we can almost always believe the accusing party. But when the gross violations get more subtle and the abusers learn to (A) hide and (B) abuse CoC processes to get their way, we'll have increasingly subtle and unclear cases to consider.

Many people deride these ideas by saying they don't want to play "internet police", and that this is a lot of effort to maintain "just" a discussion list or whatever. But the point is that as these discussion media become universal and replace other mechanisms to have political discourse, online community participation has become the agora and needs to self-regulate in a grown-up way.

The alternative is real, actual cops getting trained on how to deal with the Internet, and real, actual juries judging these issues. I think that would be terrible (although, seriously, cops could stand to know a thing or two more about the Internet generally) because it would be an incredibly ham-fisted solution to a very subtle problem. But if communities don't police themselves, they eventually get policed from outside.

Re: : Polymorphism in Python

Glyph — Mon, 13 Jun 2016 17:36:32 -0000

Apologies if this is covered in the paper itself, but: what does it mean by "programs" here? Is this a study of python modules, or are they doing whole-program analysis? From the introduction, it says "polymorphism is used in all programs", so these percentage numbers are a little misleading; even if monomorphism is the rule. Also, these traces appear to be run-specific so platform-dependent polymorphism doesn't seem to be covered?

Re: The Best Noise-Cancelling Headphones

Glyph — Mon, 09 May 2016 02:19:03 -0000

Even after reading the review, I ended up going with the Plantronics BackBeat PRO. They've been on sale at Amazon for roughly 1/3 the price of the Level Over, not to mention their product specs make them seem considerably lighter. I'm not sure what article this would fit into, but personally I'm looking for an all-purpose utility headphone that has acceptable sound quality, is comfortable enough for long wear, but that strikes a balance between features, sound quality, and weight, and based on Amazon reviews – regardless of the acknowledgement above! – it seems that, at least at its currently vastly-reduced price, the BackBeat is the way to go for that balance.

Re: fundingoss.com

Glyph — Mon, 25 Jan 2016 15:22:12 -0000

It's worth noting that Twisted does have a fiscal sponsor, in the form of the Software Freedom Conservancy, and an attendant sponsorship program; so there's a donation form right on the front page of twistedmatrix.com if anyone would like to do something about our funding problem immediately :-).

Re: Exceptions - The Dark Side of the Force

Glyph — Fri, 15 Jan 2016 16:09:28 -0000

Thank you for pushing back on the nonsense term "pythonic". I think there's a lot to discuss around the use of exceptions but I could not agree more with your point in "ingroup, outgroup thinking".

Re: Acknowledging Priveldge

Glyph — Fri, 13 Nov 2015 21:18:46 -0000

"privilege deserves to be acknowledgement"

^ I think you mean "acknowledged"

Re: This is what you get for reporting child abuse in PlayStation 4 Communities

Glyph — Mon, 19 Oct 2015 13:16:03 -0000

That is *messed up*. As you described it, this is straight-up CP, and not in any kind of gray area, which means it is definitely *not* Sony's moderation team's call as to whether this is OK or not, it's just a criminal offense. Could you either report it to the police, or pass it along to someone with the time and energy to go through that process?

Re: Why Obama Should Create Incentives for Private Companies to Assist the War on Terror

Glyph — Mon, 09 Mar 2015 16:49:08 -0000

"No"

Re: Optimizing Python in the Real World: NumPy, Numba, and the NUFFT

Glyph — Wed, 25 Feb 2015 00:08:18 -0000

I am not all that interested in the accuracy of your prediction – prediction is famously hard, especially about the future – but I do think that your perceptions about this situation are very interesting. Some of the things you're saying strike me as misconceptions about the PyPy ecosystem and the benefits of switching, but some things I think are because I don't have a great grasp on what the ecosystem really looks like.

Would you consider writing another post detailing what this long tail ecosystem really looks like, and what work would be required to get the scientific community onto PyPy? I'd like to better understand this situation, because making PyPy the default Python would really improve Python's reputation in the area of back-end performance; if it's untenable to do that for scientific computing, which is a very performance-sensitive area, I'd really like to understand why, and see if there are things that might motivate the potential audience here to do the things necessary to make the ecosystem more amenable to porting.

Re: Optimizing Python in the Real World: NumPy, Numba, and the NUFFT

Glyph — Tue, 24 Feb 2015 23:35:34 -0000

The way to convince the maintainers is three-fold:

First, I would try not to convince the maintainers, and simply give money to PyPy to try to make this happen - people should be compensated and not over-stretched for performing valuable services like this :).

Second, I'd say that it's probably a lot easier than it looks. Performance is so much better for so many things in PyPy that a lot of the API might just be possible to implement parts of it in Python with a little bit of profiling or looking at jitviewer.

Finally, I'd say that PyPy gives you mostly-pretty-good performance of all application code for free, which vastly widens the applicability of Python as a language for scientific applications.

Mostly though, what confuses me is that if it's such an untenable burden to port the C-API code to a newer, better C API while leaving the Python applications using it intact, how is it less work to re-write all of that in Julia instead?

Re: Optimizing Python in the Real World: NumPy, Numba, and the NUFFT

Glyph — Tue, 24 Feb 2015 22:02:48 -0000

Perhaps that is what you meant by "fast non-vectorized code"

Re: Optimizing Python in the Real World: NumPy, Numba, and the NUFFT

Glyph — Tue, 24 Feb 2015 22:02:21 -0000

As I understand it, it is also somewhat more JIT friendly and also therefore higher performance?

Re: Optimizing Python in the Real World: NumPy, Numba, and the NUFFT

Glyph — Tue, 24 Feb 2015 22:01:47 -0000

CFFI works very well against CPython; if they were to adopt it it would not require maintaining parallel versions. (pyOpenSSL, for example, is used mostly on CPython, but dropped its CPython C-API version a couple of years ago.)