vii

The technique described takes a low quality sensor (a DRAM chip with an open window onto it) and uses it to produce reasonable quality grayscale images.

Interesting to look at the sourcecode of the Kuckoo program (before the widespread adoption of UTF-8!) and how it uses High Dynamic Range tricks to read off the image at different exposures.

With much faster RAM and smaller cells nowadays maybe one could do something cool with very fast photography, but of course the faster/smaller the RAM the more trouble interfacing with it and calibrating the light intake.

This methodology is flawed, because in practice the conversion rate changes over time. There are different effects that cause this temporal dependence not including the natural effect on the product of certain techniques (for example testing a very loud and painful to escape from upsell will cause some people to agree into the upsell and never see it again, and others to feel pissed off). Other causes of temporal dependence are different mix of traffic in terms of geography and demographics at different times of day and week.

Even using proper Wilson confidence intervals with good methodology with tens of millions of impressions per group, we would see day to day variations in rate outside confidence intervals of the previous day, way more frequently than one would expect (one would expect a 95% confidence interval to be exceeded once every few weeks instead of every couple of days).

The proper methodology is to estimate by bootstrapping on a good selection of dangerous variables, including time.

The cost of switching is generally very low and it's quite likely that most people with data in the UbuntuOne system that they wanted to keep were already using another service like DropBox simultaneously.

The biggest cost here is to the Ubuntu reputation. They stand on the promise of LTS releases: with the quick timeline for removal of support from what could be a critical piece of customer infrastructure they signal that they are willing to sacrifice relationships for convenience.

The disk is almost certainly not idle, but instead the iops are consumed by read traffic.

Ideally, the kernel would know the deadline by which the data should be committed, manage accordingly, and the fsync would be simply acknowledged rather than inspiring extra IO.

This is pretty hard to work towards and the clearly specified narrow syscall interface leads to a great deal of difficulty in sharing this information with the kernel IO scheduling -- the way it is shared would naturally depend on the details of the kernel implementation, which would imply a tighter link between application and kernel version than is normally desirable.

If this is what passes for an apology from Ars Technica for wrongly reporting on this story from the start, when I believe it claimed that this was free Photoshop for the masses, it is a weak apology. A news organisation should stand behind its stories with its reputation and sadly Ars believes it has little reputation.

Dependency injection subjugates readability and simplicity of data flow for a narrowly defined notion of testability. Even in languages like Java, it's possible to substitute class definitions for mocked ones without having to thread a weird sort of test monad through code that otherwise serves a purpose.

I pretty fundamentally disagree with making production code more complex to make unit tests easier to write. Make the tests more complex instead and think about the natural units for testing. Maybe the natural unit for testing isn't exactly one class.

This is counter to the conclusion of the article: it's true one shouldn't force Java idioms on Ruby but also if the Java idiom doesn't translate well, maybe it's a bad programming idiom in general.

Exactly.

Seeing all that private activity with no way to capitalize on its inherent virality has driven Google away from their natural core. From a company which started out with an quirky barebones homepage, deliberately eschewing the natural monetizability of it, this new aggressive identity grab is a big cultural transformation.

Consumer flash cards are an example of a market where the purchaser has very little information to go on. The raw user available storage number is pretty misleading as the block remapping system (or absence of one) is a key determinant of reliability.

The fact that SanDisk and other name-brand manufacturers make a practice of switching out the underlying parts without changing the part numbers make reviews pretty much useless.

The link between broadband and apps is tenuous at best.

The US has lagged in consumer broadband behind most other countries for a long time. It also lagged in adoption of text messaging and so on. This is presumably due to the weird regulations that the very powerful telecoms companies managed to place themselves under, which stifle competition. The US never led here. In Japan, for example, gigabit to the home has been available reasonably cost effectively for almost a decade.

In terms of apps, there is much freer competition. I think the biggest difference here is that in the Bay Area there is a very high proportion of iPhone users, whereas in the rest of the world Blackberry, Nokia and Android dominate. That explains the success of WhatsApp's cross platform strategy and the relative sidelining of Messages.app!

I agree that browsers should make it much clearer that clicking on a button or link which does nothing is having no effect. In my mind this violates good UI design: that whatever action the user takes, they deserve some feedback. There are many very popular sites (including Facebook, at which I am advocating for new approaches) where pages are essentially unusable until JavaScript has loaded but little indication is given to the user.

The other point that the Internet is slow and high latency in foreign countries: true, but in the SF Bay Area it's slow and high latency on mobile devices and this should be a common experience shared by Hacker News readers.

Hashtables are great until they grow to a significant fraction of available memory. Then there is no way to avoid the cost of rehashing or giving up constant time access - and if your program isn't using most of memory then you can run it on a smaller computer!

In practice, if we were going to talk about that -- variations which perform statistically significantly better one day may perform worse the next. For example, because happy people like to click on one variation versus another which is preferred by stressed people.

Keep A-B tests running even after you've decided the best variation to make sure that the uplift you've observed is real! See http://john.freml.in/ab-testing-significance

This article doesn't go into the reasons for which Steve Jobs was given up for adoption. His biological father reportedly said, "I honestly do not know, to this day, if Steve is aware of the fact that had it been my choice, I would have loved to keep him." Steve Jobs is claimed by Syrians as his own, and there are suggestions that the father of his mother forced him to be adopted out of Islamophobia or anti-Semitism.

It is not sensible to hire people who will become rapidly frustrated at the function they are delegated to perform unless you have another position to promote them into. Often you need someone to perform a dull role.

There are plenty of people, even knowledge workers, who are satisfied with a steady paycheck and a low level of workplace stimulation. Should one force them to improve? If you do, then they often move on (in my experience). That is why the distinction brought up between innovators and knowledge workers is important.

It is natural to feel challenged and threatened by obviously more intelligent co-workers and subordinates. Most people probably don't want to work with someone who thinks they are a superstar, and would prefer just to go home at a regular time. Those of us who wish to work in an intellectually challenging environment are probably a minority.

It is unfortunate that the article uses the term 'clever' to make a slightly unclear differentiation from 'knowledge worker.' Maybe if the term 'innovator' were selected then the article would be clearer. It would also help to explain why frequent feedback may be disadvantageous. Managing or harnessing innovative people is extremely difficult and it is an important subject to discuss and study.

I've this laptop. I quite like it, the screen can go very bright so you can use it outdoors.

The downsides: super sharp edges make it uncomfortable to rest on oneself, the power socket is flimsy and the charger easily damaged, awful drivers for the Broadcom WiFi chip.

I tend to give laptops a rough treatment lugging them around (my ThinkPad was continually damaged and had bits shattered off it on a regular basis). My last laptop was a Toughbook which bravely survived years though a few screws came out of it. The Samsung has done very well and the only damage is to the charger and the screen getting bright patches from being squashed in transit.

The SSD is very fast, maybe faster than the Intel X25M I had before, and I'm generally pleased with it. I use Ubuntu without major issues.

Seems to me that this would be a huge opportunity for some well co-ordinated use of social media by the MET: many people have seen looters return to their home with their swag and would probably be delighted to report it anonymously - along with all photos taken by people of the actual looting. The refugees seem to have no clear contact number let alone website to go to on their smartphones. These people surely are motivated to inform on the rioters and quite probably have useful knowledge.

And finally, phone location records - even without call history and text messages - could be data-mined to give leads on the rioters - when they go home to sleep pick them up with the loot, and you have an easier case than two weeks later with it all squirrelled away.

Well a three element array does solve that but there are better ways still.

http://www.starling-software.com/blogimg/tsac/1011/fremlin-t...

In my opinion the idea that there is a division between functional and non-functional programming at all comes because of a disagreement or misunderstanding with the principles of SICP: C is a perfectly functional programming language if you say that each statement is a function from machine state to machine state. . .

SICP is a great book. Its abandonment is a sad reflexion of the gradual descent of programming teaching from principled discipline into an introduction to the process of trial and error. While most developers probably spend the majority of their time experimentally cobbling together applications from blackbox components, this they can and probably must learn on the job. What SICP tries to teach they cannot -- the most fundamental idea in programming: The evaluator, which determines the meaning of expressions in a programming language, is just another program.

We are starting to embrace again more featureful languages and regrettably accepting that the majority of programmers will use multiple languages regularly. Therefore SICP seems more appropriate than ever!

Quants in banks are generally not working high-frequency trading which this website seems to focus on, and which generally requires very limited modelling. Therefore HFT is often the province of IT teams, though quants may have some input. The role of quants tends to involve hedging, calibrating models, and sensitivities -- http://www.risk.net/type/technical-paper

As a rule of thumb: it is quanty iff the word convex is employed. Interestingly, this can be abused by the uninitiated -- "Have you considered the convexity of the underlying?" etc. -- to pretend to a deeper, quantier knowledge than that possessed.

Depending on the asset class there are more specific books but "Options, Futures, and Other Derivatives" by Hull is a good starting point.

How about tpd2? If you're comfortable rewriting everything from scratch, at least you'll be working from a high performance foundation -- http://github.com/vii/teepeedee2/tree/master

Weblocks is a very good concept if you're willing to get your head round it, and work within its worldview (which is about displaying widgets rather than manually generating HTML).

Everybody uses parenscript, which is a great concept.

I've used F# at work.

It does have a sort-of REPL, you don't have to put one line functions inside a dummy class, and the async monad and queues are pretty handy.

It doesn't benefit from adding yet another set of collection types to the .NET API (which already has two semi-competing sets) but that is unfortunately beneficial, partly due to the next point.

The balkanisation between the .NET typesystem (class at a time, overloading ok) and the ML typesystem (sequential and no overloading) is a constant source of irritation. How to make a short name alias to the System.Console.WriteLine variadic function?

It's REPL unfortunately doesn't tie into the otherwise impressive VS intellisense and is a pain to attach the debugger to.

It hasn't proper closures (you cannot mutate variables you close over).

It's not a coherent platform, but a mishmash.

Siqi hadn't agreed to share his entire life with his YC cofounders and pretending otherwise is very childish. The fact that PG is being upvoted for this simply because he is PG is damaging to reasonable debate.

It was easily measurable if you ran the instructions in a loop and looked at the power draw. I can't remember the numbers now but it was definitely significant (maybe 30% on a wide vector instruction?).

I don't know where you got the idea about the flip-flops from.

Adders for example are implemented so that they grow exponentially in the number of bits in size, so that they use a time proportional to the log2 of the number of bits. Note that this means the number of bit transitions in a simple add can be much larger than the number of bits going in, meaning more power draw.

Of course we didn't worry about the instructions inputs in practice.

I think it was cheaper to store 1bits than 0bits ironically.

edit: explain more clearly that larger circuit size means more power drawn

There are many interesting points here, but "programmers will not be able to afford to be ignorant about the energy cost of the programs they write" struck me especially.

I worked in the embedded space and we had rough notions of the (power) cost of using various instructions and hardware blocks -- more or less related to the number of bits flipped (for example adding 0 does less work that adding 0xfffffff).

It would be grand if this filtered down to the mainstream. If a program runs on a million machines, making it more power efficient would be a big win economically, but the programmer probably has no incentive.

Working out big O assumptions for power use on your platform is an interesting exercise!

James Clark Maxwell came up with an ingenious (if perhaps impractical) workaround to colourblindness. If you cannot distinguish between red and green (common case), then use glasses with one green tinted lens and one red tinted lens. By obscuring alternate eyes, you will be able to differentiate the colours.

edit: note that it is a little impractical to wear silly glasses

Seems to me this discussion is missing one of the main points of the original post: a massive plug for an unfairly under-appreciated book:

  > "Let Over Lambda" 
  > (which is really quite scary to read - I can't say that I understand 
  > 100% of it - maybe 60% and I am very happy with that level of 
  > comprehension) -- you end up with an enormously powerful set of 
  > programming tools unlike anything else out there.

I really like this book too and recommend it.

http://letoverlambda.com/index.cl/toc

I've been feeling quite despondent about the general language/framework fanboyism on Hacker News. This comment is a breath of fresh air. Thank you.

I've worked on heavily used programs in several languages (including Lisp) and frankly in my experience the quality of the programmer is way more important than the framework they start from.

Can you provide a source for the 30% figure?

shinh is being incredibly sporting about the whole thing, so it's good to go.

This completely misses the point. The reason JGit cannot compete with Git is not that it is using an extra cycle or two to make function calls. The problem is that Java cripples you in the sort of data-representations you can use -- no mmap, no value types -- forcing lots of extra copying. There's no reason a language can't provide these features, and I don't know that they require significant extra programmer effort. C# does it, etc.