dododo

i've worked on code written during a phd that eventually graduated to a product. my role was making it production ready.

code written during research is a complete mess, and necessarily so: you don't know what you're going to end up with. you try this, you try that, you hack it, you tweak it six different ways. often things only work in a few very specific situations; generalising to more useful situations can be difficult.

a phd won't motivate you. the right environment will educate you on the latest techniques though and teach you to be critical of them and improve them.

you'll also learn how to write code quickly---i find deadlines in academia more intense than my industrial experience (perhaps because the outcomes are far less predictable).

i wouldn't do a phd part-time:

1. it's intense.

2. you want it to be over as soon as possible.

i also use these guys; in the past it has helped to have a german speaker around...

irssi. <esc># instead of <alt># for window switching.

i only wish that i could annotate a kindle by pen or touch. this is super clumsy:

http://www.amazon.com/gp/help/customer/display.html?nodeId=2...

i read a lot of papers and text books: typically i want to draw pictures for intuition or write math. you can't do that with a keyboard easily.

this seems to be simply a ranking of organisations by the number of citations.

there are a number of factors missed:

1. what's the earliest publication of each organisation?

2. what's the real world impact of the publications? (citations are not real world impact.)

3. what was the significance of an organisation's contribution to a publication? for example, there might be many authors, where only one author did the actual work.

4. it should be normalized by the size of the organisation.

5. CS is multidisciplinary: plenty of people in CS publish in other domains such as biology, mathematics, statistics.

i couldn't work out if they counted self-citations or not.

often the simplest things in machine learning/data mining work best---so maybe come up with a very simple way of achieving what you want, try it out. work out what's not so good, and improve. repeat.

an important thing is to work out what maths you can just rationalise and ignore the details of, and what maths you need to know in detail. for example, you probably at this stage don't need to know how to prove the central limit theorem, but it might help you to know the intuition. it might be a good idea to know, in detail, where linear regression comes from though.

warning: in my experience, data mining books tend to provide poor explanations of the mathematical justifications of what's going on. if you can, get to a library and get some more theoretical books on machine learning or statistics. in stats, larry wasserman's all of statistics is great, in machine learning, hastie et al's the elements of statistical learning, mackay's information theory book, bishop's machine learning book, etc, etc...

with any text book, don't read them cover to cover. just get what you need and move on. if it's not obvious what you need from the book, try another one and go back. books can be expensive, but time is more precious. it's more important to do math than read math.

maths can be like programming: it can seem pointless without a purpose. too much is made of proofs and too little of intuition.

so pick a project, something you'd like to know. then apply math as, and when, needed.

what are you interested in? (other than learning math) if we know, then maybe someone can suggest a project related to something you'd care about :)

the article mentions a python implementation of CSP which is here

http://code.google.com/p/pycsp/

Invented by the same guy that brought us quicksort, CSP is actually a really nice framework for describing interacting processes. It's used a lot in formal proofs of correctness of programs, so it's nice to see real-world implementation with such clear syntax. (Of course, Go uses the same formalism, as opposed to Actors that are used by Erlang/Scala/etc.)

you're right---consistently faulty products would certainly make a bigger (negative) impression than peacocking.

but in this instance, for some time, the products were just fine.

a customer's trust is most tested when things are going wrong, not when they are going well.

unfortunately for them, i was a paying customer. sorry if my comment gave you a different impression.

after some time, they delivered me a faulty product: i wanted to return it. it turned out they were 'peacocking' their customer service team as well as their accounts team.

i don't think it's ok to 'peacock'; it's tantamount to fraud.

if your clients are concerned that you cannot cover their requirements, you should address these concerns, not lie to them as this impedes their due diligence. if you get caught, your reputation is destroyed, and i would be surprised if there were no legal recourse.

i dealt with a company that did this: after a short time it became obvious what was going on.

as customer i no longer trusted the company: they were lying to me, trying to make their business look bigger than it actually was.

if they were dishonest about this, what else were they being dishonest about?

at the first opportunity, i took my business elsewhere.

you didn't name a single tech start up. why not if there are so many?

there are many small businesses in the UK: http://www.bytestart.co.uk/content/news/statistics/small-bus... but i cannot find any statistics on the area of business.

note it depends upon cython: i suppose it's more likely it will make it into cython rather than python 3.2.

can you name these european tech start ups?

i can think of very few.

it won't give you a prompt: try typing something, and you'll see it works fine (unless centos have done something funny).

as well as "quick stuff" i'd like a peer-reviewed paper.

the first question is: why should i care about it?

the next questions are about the details.

it would be great if every language on their home page, as well as listing how to do common things such as this:

http://www.iolanguage.com/scm/io/docs/IoTutorial.html

would also give a demonstration of what makes this language unusual (beyond syntax).

for io it seems like this might be some smalltalk-inspired message passing stuff:

http://www.iolanguage.com/scm/io/docs/IoGuide.html#Objects-F...

combined with concurrency:

http://www.iolanguage.com/scm/io/docs/IoGuide.html#Concurren...

but it's hard to tell at a glance.

fwiw, the haskell page does a great job of this: following the "why use haskell?" gives the classic quicksort example.

you should try. all -T does is not allocate a tty: most shells will still work. bash/zsh/rc do for sure.

hah! the dsp trick actually works surprisingly well IF you combine it with lame (iirc).

want to log in without appearing in lastlog(8)/w(1)/who(1)?

ssh -T host

(of course syslog still sees you).

if available, ssh-copy-id(1) is an easier way of setting up passwordless ssh(1).

note also that openssh supports on-demand proxying via SOCKS4/5: check out ssh -D. this makes it easy to pipe all web traffic (for example) over ssh.

Monads are a special case of Arrows.

You can think of Arrows as generalised functions: the type of a function is X -> Y, whilst the type of an arrow is A X Y, where A takes the place of the infix type ->. So another way you can write the type of a function is (->) X Y, from this (+ technicalities) we see that functions are Arrows.

Monads are a special case of arrows where A X Y becomes X -> M Y or (without the infix syntactic sugar) (->) X (M Y); Monads can take control of the outputs from operations, whilst Arrows can take control of both the input and output to operations.

I found Monads made a lot more sense after I learnt about Arrows because Arrows are what I wanted Monads to be.

btw, the "killer app" for monads, imho, is parsec: http://legacy.cs.uu.nl/daan/parsec.html

whilst the "killer app" for arrows is probably FRP: http://www.haskell.org/haskellwiki/Functional_Reactive_Progr...

there are two gnu utilites that are useful for writing: gnu style and gnu diction. http://www.gnu.org/software/diction/diction.html

diction finds common mistakes. style gives some metrics (may or may not be useful, YMMV).

they have a similar theme as this article.

1. the point of doing statistics properly is to try to remove your bias about what you think the results are: every developer who has worked hard enough on a problem, probably thinks they made an improvement. it's a good idea to test this, statistically, as you might be surprised.

2. the article didn't repeat anything, at all. it's not even on average (at least, as it's reported). as far as i can tell, he ran a test once and reported the result.

3. the point is that judging from one sample or a mean on a small sample does not answer any reasonable question because the (unrepresented) uncertainty in the answer could actually mean the result goes either way in general.

btw, what i'm suggesting isn't some deep, complicated statistics! i'm suggesting the most basic, elementary statistics. this is super, super basic stuff. high school kids here know about the mean and standard deviation here.

if you want to be more principled about things kind of thing, you could either do some kind of hypothesis test (e.g., a two-sample t-test adjusting for variance would be appropriate here) or use a Bayes factor to compare the two hypothese (better, not better).

you only know the mean is good enough if you examine the spread and/or use a robust estimator.

spikes happen in performance (for better and for worse) all the time. one spike is enough to totally distort the mean, no matter how often you repeat.

it might be a microbenchmark but to paraphrase: if it's not done well, it's not worth doing. the complete opposite of what the microbenchmark purports to show could be true most of the time.

why are so many benchmarks done so badly statistically?

the benchmark was run once: we have no idea if this was a fluke or not. hopefully the author didn't repeat and pick the best.

at best the numbers reported can be considered some mean. the mean is not a robust estimator: http://en.wikipedia.org/wiki/Robust_statistics#Examples_of_r...

one sample is enough to distort the mean. furthmore we've no idea how typical this run was: there should be some measure of spread.

if you just look at age demographics of facebook users:

http://www.istrategylabs.com/2009/01/2009-facebook-demograph...

40% of facebook users are 18--24.

now compare to people with iphones in 2009 (different to people who queued, admittedly, got stats on this? but still earlyish adopters since 2009 data)

http://gorumors.com/crunchies/age-demographics-of-iphone-use...

whilst for the iphone, very few are in the 18--24 range: just 13%. most people are 35-54.

it seems from this 2009 users of the iphone tend to be older than users of facebook. perhaps because the iphone is an expensive device.

hardware is currently disposable because this is how manufacturers have decided to make money. not so long ago, it seemed common to upgrade your PC: swap in one component, put in another. you're arguing to just buy a new device completely.

why do you think throwing away, rather than improving, something that so much energy, material and other resources went into creating, is a good idea?

please don't assume everyone is as imprudent, lavish and wasteful as some stereotype you seem to have.

i replace devices when they are no longer of use to me, or if something significantly more useful comes along. actually useful not hype.

i got my current phone in 2005: i only have one phone, and this phone works well. i've repaired this phone: a year ago it fell in water and stopped working so i stripped it down, cleaned it up, checked for obviously blown circuits, replaced bits until it worked again.

this is the source of the article: http://www.mydroidworld.com/forums/droid-x-discussion/3330-h...

from the source, the things checked before blowing the fuse are: "the firmware information (what we call ROMS), the kernel information, and the bootloader version"

it seems like if you get any kind of corruption, in any part of the above components, for any amount of time, your phone becomes a brick.

corruption happens: my previous phone was a motorola. i stopped using it because it would randomly redirect phone calls to other numbers in the phone book (but it was usable for a long period despite this).

motorola phones' get corruption (which keep essential functions working), but now any temporary, minor problem results in permanent, intentional bricking.