568 reputation
514
bio website naught101.org
location Australia
age
visits member for 3 years, 3 months
seen May 18 at 2:47

Contact:

Skype: naught101

XMPP/Googletalk: naught101@jabber.org

[my username] at gmail.com


May
18
comment Does syntax really matter in a programming language?
I've never used Lisp, but I find all of the examples I've seen just as easy or easier to read than C++ (I'm not a C++ user either).
Feb
5
awarded  Excavator
Feb
5
revised Why is jQuery released under MIT and not LGPL?
clarify LGPL
Feb
5
comment Why is jQuery released under MIT and not LGPL?
Also, the GPL doesn't "force freedom on people" any more than a bill of free speech forces people to say what's on their mind. You can always write your own code that does the same thing and release it under any license you choose.
Feb
5
suggested approved edit on Why is jQuery released under MIT and not LGPL?
Feb
5
comment Why is jQuery released under MIT and not LGPL?
The first sentence is not clear. With LGPL software, if you "use it" as in modify and redistribute it, then yes, you have to license your modifications under the LGPL. If you "use it" as in include an unmodified LGPL library in your code, you do not have to license your code LGPL, but you do have to clearly state that it contains LGPL code. With the GPL you do have to use the GPL license, in both cases.
Jan
8
comment Objective Metrics for Software Quality
Seems like S.Lott is arguing with a strawman standing next to Thomas Owens. 1. Make decisions based on expert knowledge and experience, and good judgement. 2. Don't use objective metrics to make decisions. 3. Use objective metrics as indicators for where code might be able to be improved. 4. Make improvements, iff they are required, but not with regard to metrics. 5. Repeat, ignoring metrics if they don't tell you anything new... That any decision making process can be gamed is true, but that fact is independent of the usefulness of objective metrics (I'm not arguing that they are useful).
Jan
6
comment What's so difficult about SVN merges?
@MasonWheeler: like this? :P. SVN branching and merging does the same thing - the metaphor is already broken. I don't really see how something like this is that hard to understand, especially if it includes some sensible commit comments..
Jan
6
comment What's so difficult about SVN merges?
@MasonWheeler: It clearly doesn't induce headaches in many others though. You haven't actually provided any rationale for why "they're doing it wrong". Simply stating that doesn't make it true. I can't think of a reason why re-merging branches is generally wrong, though I can think of cases where it would get annoying, as well as cases where it'd be very useful, and not at all problematic.
Dec
10
comment Why do some big projects, like Git and Debian, only use a mailing list and not an issue tracker?
Greg Kroah-Hartman has a take on this as it relates to the Linux Kernel as part of this discussion. In particular: "There is NO way the github/gerrit/gitorious model would work at all for the kernel. The scale at which we work is a totally different level than could be handled by those tools. ... There really is no other known way to handle 10000 patches every 2 months, in a stable release, with peer review, with over 3000 developers, other than what we do today."
Sep
24
awarded  Autobiographer
Sep
1
comment What's wrong with comments that explain complex code?
One useful place for comments: in scientific code, you can often have computations that are quite complex, involving lots of variables. For the sanity of the programmer, it makes sense to keep variable names really short, so you can look at the maths, rather than the names. But that makes it really hard to understand for the reader. So a short description of what is going on (or better, a reference to the equation in a journal article or similar), can be really helpful.
Sep
1
comment What's wrong with comments that explain complex code?
@mattnz: below median. A lot more than half are below average.
Feb
22
comment Learning to program in C (coming from Python)
I'm to late to add an answer, but there's this online C for Python Programs booklet. Also, the makers of "Learn programming the hard way" are making a book called "Learn C the Hard Way", which is aimed at people who already know a bit of python or similar.
Feb
10
awarded  Yearling
Feb
9
awarded  Good Question
Sep
12
comment Herding your users to your bugtracker
This answer isn't entirely true. As discussed at programmers.stackexchange.com/questions/191961/…, at least in the context of open source development, a bug tracker can be quite beneficial for users: it acts as a support knowledge database of known issues, and can provide workarounds, if they exist. It lets the user assess how quickly their issue is being addressed, helping them decide whether to move to a different solution. It also helps potential contributors how the team operates and where help is needed.
Mar
30
comment Why do some big projects, like Git and Debian, only use a mailing list and not an issue tracker?
@gnat: A major part of that linked answer being so great is the "if it's easy for you, you can enter that sort of thing right there" part. That is key to many open source projects, as there is no funding for phone support. A mailing list is a turn-off for me as a bug-reporting user, as I don't want to have to sign up for responses. With a bug tracker, I can see that the issue I have is in the system, and can come back and search for it later, and see if it's been updated. This is difficult with a mailing list, unless there is a really good web-based list tracker, which often isn't the case.
Mar
30
comment Why do some big projects, like Git and Debian, only use a mailing list and not an issue tracker?
@RossPatterson I was thinking that. But it seems unlikely that it's older than the web, considering it contains a bunch of URLs...
Mar
30
comment Why do some big projects, like Git and Debian, only use a mailing list and not an issue tracker?
@CedricMartin: I know, I agree. Mailing list bug tracking clearly works adequately for some teams, but it still seems less easy than a bug tracker, to me. I've been thinking though, that for the core project developers, the difference may seem very small: they follow nearly everything that's going on anyway. But for new-comers, a mailing list is nearly impossible to grok, so no simple overview of project fitness can be had. A bug tracker lets new users/devs quickly figure out how a project is moving, and get an idea of which kind of improvements are considered important by the core team.