Scientists Have 'Hacked Photosynthesis' in Search of More Productive Crops - <AUTHOR> https://www.npr.org/sections/thesalt/2019/01/03/681941779/scientists-have-hacked-photosynthesis-in-search-of-more-productive-crops <comment><USER3> I wonder - once we start replacing more extensive segments that represent complex functions, not only does it become a less probable natural solution but to steal a term from ML - perhaps there is a danger of temporal "over- fitting"... The natural version maybe sub-optimal in the current climate, but that historical baggage could have evolved to that state because it allowed the continuation of that species through a more diverse range of climates, something that could be useful in the future.

There is the potential that forcing a "more efficient" solution for _now_, could be also creating a more fragile and endemic species? Perhaps not even for the distant future, if details in the original in-fact make it better able to cope with subtle climatic variations more efficiently.

<comment><USER4> Crop plants and livestock animals are already pretty much unable to survive in the wild, outside of farms. So the "overfitting" is as old as farming.

<comment><USER3> True, but this is direct, cultivation is by proxy, and does not necessarily remove unexpressed genes.

<comment><USER5> That's a confusing thing to say... surely GMO doesn't necessarily remove unexpressed genes either?

To provide a counterargument, with GMO we additionally have a decent understanding of the underlying mechanics and which genes have changed. This puts us in a better position to correct things if they do turn out to have unintended consequences.

<comment><USER3> > That's a confusing thing to say... surely GMO doesn't necessarily remove > unexpressed genes either?

You may be correct, this was speculation based on imagination on my part - <USER2> do not know if unexpressed genes were removed in this experiment, I only have a suspicion they may have been part of the "inefficient" original sequence that was replaced.

</comment></comment></comment></comment></comment><comment><USER6> >"But it has what we like to call one fatal flaw," Cavanagh continues. Unfortunately, Rubisco isn't picky enough about what it grabs from the air. It also picks up oxygen. "When it does that, it makes a toxic compound, so the plant has to detoxify it."

Can someone explain this, the article doesn't go into much detail. What is this toxic compound, and why must the plant make it?

edit: Explained in detail in this article: [https://arstechnica.com/science/2019/01/re-engineering- photo...](https://arstechnica.com/science/2019/01/re-engineering- photosynthesis-gives-plants-a-40-growth-boost/)

<comment><USER7> The semi-technical "Perspective" column

[http://science.sciencemag.org/content/363/6422/32](http://science.sciencemag.org/content/363/6422/32)

in the same issue of Science is also excellent while still being more accessible than the main technical article.

[http://science.sciencemag.org/content/363/6422/eaat9077](http://science.sciencemag.org/content/363/6422/eaat9077)

</comment></comment><comment><USER8> The article focuses on GMO food production which is great. But since this process is said to be more efficient than the natural one, could this be also used for consuming the excess carbon dioxide in our air?

<comment><USER9> A field crop planted annually that grows faster or bigger isn't likely to make much of a difference to atmospheric CO2 as it will just release it again after harvest. Perennial plants (those that don't need to be planted each year) are better at sequestering CO2 in the soil, along with other benefits. The Land Institute does work on this, including developing (through traditional plant breeding) a perennial wheat variety which is being trialed [0].

There are other agricultural practices that promote CO2 sequestration in the soil. You might have a look at Project Drawdown, it ranks solutions to climate change based on impact and has a section on food [1] which includes agricultural solutions. For example, Silvopasture [1], ranked #9 overall amongst all solutions, involves integrating trees with livestock pasture. Another one is conservation agriculture (#16) which uses annual crops but promotes soil health in selection of species and method and timing of planting [3].

[0] [https://landinstitute.org/our-work/perennial- crops/](https://landinstitute.org/our-work/perennial-crops/)

[1] [https://www.drawdown.org/solutions/food](https://www.drawdown.org/solutions/food)

[2] [https://www.drawdown.org/solutions/food/silvopasture](https://www.drawdown.org/solutions/food/silvopasture)

[3] [https://www.drawdown.org/solutions/food/conservation- agricul...](https://www.drawdown.org/solutions/food/conservation-agriculture)

<comment><USER10> Why can't you take all the leftover biomass after a harvest and sequester it? Then it wouldn't "simply relaase it". I'd image we only take a small part of the mass for food.

<comment><USER11> for which crop? most of the leftover biomass is used in typical crops.

For corn, the stalks are used as silage. For wheat, the stalks are used to make straw.

<comment><USER12> > For corn, the stalks are used as silage.

How common is this? In my area, the combines chew up the stalks and spit them out as chaff. I don't see many people collecting the chaff.

<comment><USER11> Not sure. The dairy farm I worked at used the corn stalks. They make a product called "silage" which can be used as winter feed for the cattle.

<comment><USER12> Curious. My neighbor was a dairy farmer. They did this too. No one else though.

<comment><USER13> It can depend on the price of fodder. If hay is cheap, there's not much incentive to spend time/fuel on baling stalks.

However, if they're not baled, they decompose in the field, which technically reduces fertilizer inputs.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> There's a website for a project aiming to produce a modified version of rice using these improved photosynthesis pathways[1]. Some previous HN discussion on the subject can also be found[2]. Really interesting stuff!

[1] [https://c4rice.com/](https://c4rice.com/)

[2] [https://news.ycombinator.com/item?id=8867365](https://news.ycombinator.com/item?id=8867365)

</comment><comment><USER15> I hate the writing in this. "This protein's super-important!" "Yay for Rubisco!"

<comment><USER16> Here [https://arstechnica.com/science/2019/01/re-engineering- photo...](https://arstechnica.com/science/2019/01/re-engineering- photosynthesis-gives-plants-a-40-growth-boost/)

<comment><USER6> Thanks for sharing, this article is so much better than OP's. It answers a question I posted which the NPR article was very vague on, but Ars covers in detail.

</comment></comment></comment><comment><USER17> While this is certainly interesting it doesn't have as wide an application as you might think. In tobacco the harvested product of value is in the leaves, bigger leaves means a bigger crop.

But take corn, larger leaves and a taller plant doesn't result in bigger ears of corn. A taller plant in general means that it is more likely to lodge or fall down in the fall before it's harvested. Some corn is harvested as silage meaning the entire plant is chopped and fed to cows. I've worked with farmers who experimented with varieties of corn that would be 3-4 feet taller than regular corn. The result was less feed value per acre than what they had been growing.

With soybeans, wheat or oats you can also likely get an increased amount of disease with more foliage. This development may see more application than just tobacco but it remains to be seen.

<comment><USER7> This is a modification which increases the efficiency with which the plants generate needed sugars which presumably are used everywhere in the plant, not just the leaves. Why would this only increase the size of leaves?

Indeed, if each photosynthesizing leaf becomes more efficient, wouldn't this _decrease_ the number of leaves you need to support the non-leaf consumable part of the plant, allowing foliage to _decrease_?

</comment></comment><comment><USER18> In nature there is typically no free lunch. Optimizing this may lead to other issues such as lower drought tolerance of less natural pesticide resistance. Although as the author states, photosynthesis isn't usually a rate limiting factor in nature so it could potentially be optimized.

</comment><comment> pillow-case It's neat to see this finally come to fruition (no pun intended). Someone has been anonymously posting about this research for the last few years on 4chan's science board.

</comment><comment><USER19> _" It's called Rubisco, which is short for an actual chemical name that's very long and hard to remember."_

Anybody else wish he would've let us be the judge of that?

[https://en.wikipedia.org/wiki/RuBisCO](https://en.wikipedia.org/wiki/RuBisCO)

</comment><comment><USER20> Superweeds have been talked about before, in terms of weeds that are herbicide resistant. Kind of a yawn, really, unless you're a farmer.

But a weed that grows 40% faster than anything else out there? That's some scary stuff. (Palmer amaranth, for example)

<comment><USER21> Kudzu?

Anyway, my impression is that most plants bottleneck on water or nutrients before sunlight, so this probably won't make that big of an impact if it gets out in the wild, but it would be a problem on fertilized and irrigated fields.

</comment></comment><comment><USER22> Also for better solar batteries. Direct solar to dissociated hydrogen & oxygen. Might eventually be more efficient than solar generated electricity if you read some of the university press releases.

</comment><comment><USER23> There isn't enough information to assess why this is a good thing or if it will work.

</comment><comment><USER24> What could possibly go wrong?!

<comment><USER25> A lot of things can go wrong for pretty much any significant technology.

Those technologies do require caution, and control, but I think this is still a good step forward, even if it ends up being unusable as is for whatever yet unforeseen reason.

</comment></comment><comment><USER26> One thing that concerns me about hacking crops to have higher yields is that they may consume more soil nutrients, when we're already in pretty serious danger of exhausting large patches of arable land. So then we'd need to use a lot more fertilizer, which is already an environmental disaster at its current scale with nitrogen/phosphate runoff.

There's no such thing as a free lunch, unfortunately.</comment>


GPGPU Accelerates PostgreSQL - <AUTHOR> http://www.slideshare.net/kaigai/gpgpu-accelerates-postgresql <comment><USER2> So glad to see this coming along.

If any of the project team are reading, what I'd like to see most is GPU- accelerated point-in-polygon lookups in postGIS, ST_Contains and so forth.

<comment><USER3> It's likely GPUs are slower than CPUs for spatial data structures. Getting the data to GPU and results back takes just too long. Point in polygon is also very branchy in general case. GPUs are really bad with branchy code, so it's very unlikely you could even GPU accelerate such query, if it operates on point coordinates and a set of polygon vertexes. At least it would be very hard.

Edit: right, after thinking about it, the branches can be optimized out. It could be fast if there are a set of sorted segments, just parallel compares and some boolean logic.

Which leaves the problem of getting the data to GPU. Because you can definitely stream same comparisons on the CPU much faster (memory bandwidth limited) than you can stream the data to GPU over PCIe.

So 2 CPU socket system, such as Xeon E5, I'd bet on the CPU. PCIe 4.0, 16 lanes would give 30 GB/s (not sure if PCIe 4.0 is supported anywhere), vs. aggregate CPU bandwidth of up to 150-200 GB/s. Dual socket Xeon E5 supports at least 1 TB of RAM (16x 16 GB buffered DDR4). 32 GB DDR4 memory modules exist as well, I think, and larger DIMM banks than 16 slots can be supported. It's just the number of slots on typical 2 socket mainboards.

With more realistic setting, CPU would be even more ahead. All of this is ignoring GPU latency issues, which can be anywhere from microseconds to tens of milliseconds in pathological cases.

Unless the data was on the GPU in the first place... I think currently a single GPU can have up to 12 GB of RAM. Maybe larger GPUs exist too. That's just not much RAM compared to what is typical for CPUs. Currently smallest amount of RAM a dual socket Xeon E5v3 standard server can have is 64 GB, if all memory channels have at least one DIMM.

<comment><USER4> Point in polygon actually seems like a good problem for the GPU. It can be calculated with a simple angle calculation performed in parallel against all segments. Trig functions are fairly heavy weight, and serially or with lesser degrees of threading on the cpu, creates a large computation, making it good for offloading to the GPU.

<comment><USER5> Point-in-polygon is usually done with simple vector arithmetic; not trig.

</comment></comment></comment></comment><comment><USER6> As an aside, if this is of interest you might be interested in the third run of the GPGPU course by coursera/University of Illinois starts in January. See: [https://www.coursera.org/course/hetero](https://www.coursera.org/course/hetero)

</comment><comment><USER7> It's great to see that they're using OpenCL. GPU computation desperatly needs standardization, and this could help bring OpenCL drivers on par with CUDA.

<comment><USER3> A lot is lost in the translation when it comes to OpenCL. Current nVidia and AMD GPUs are just wide SIMD machines, just like current x86 cores. GPUs are just just wider and with much less cache, slower serial execution.

<comment><USER8> "Current nVidia and AMD GPUs are just wide SIMD machines"

That's not really true; you can kind of treat it that way, depending on the algorithm (eg, matrix multiplication breaks down cleanly that way), but there are serious flexibility advantages in the "single-instruction-multiple-thread" model vs SIMD. For example, consider streaming large numbers of hash lookups - difficult to express clearly with a pure vector processing model.

<comment><USER3> Right, I should have mentioned GPUs have a ton of hardware threads. Then again, they have to, GDDR5 memory access can take a _microsecond_. Try latency like that on a generic CPU, hyperthreading or not...

So: GPUs are wide SIMD machines with a lot of hardware threads, massive branch and glacial memory latencies. When there's a branch or memory latency, HW simply switch thread. GPUs don't care about serial execution performance.

</comment></comment></comment></comment><comment><USER9> Most servers I've used don't even have a GPU. It will be interesting to see how this and other GPGPU applications for server software will shape the server parks in the future.

<comment><USER10> In the scientific computing community, servers with GPUs are pretty common, and available off-the-shelf. See for example [http://www.supermicro.com/products/nfo/gpu.cfm](http://www.supermicro.com/products/nfo/gpu.cfm)

So asking the folks that already use that stuff could give pretty accurate predictions.

</comment></comment><comment><USER11> This is very interesting, but not as a CPU saving optimization. I'm sure it does that very well, but that's not why it's Important. Rather, this seems to me like the next step toward the inevitable future of PostgreSQL as arbitrarily scalable, and as _the_ general query engine that ties together whatever physical data stores you happen to use.

It seems obvious to me that pushing the Foreign Data Wrapper layer with work like this is how we eventually break through the RDBMS scalability barrier of the individual host. In the future, I'm sure you'll see similar work where _the_ GPU won't be the GPU and the PCI bus won't be the PCI bus. Rather, they'll be _a_ host and the network. A database service (database cluster in Posgres's nomenclature) will eventually run not just on a single machine, but on a single cluster of machines. Instead of a cluster of machines for redundancy, you'll have a cluster of clusters.

Postgres is really two things in one: a physical layer of bytes in pages in files, and a logical layer of queries on tables of records. The most important piece in the future will be the logical layer. The FDW layer will naturally be extended and generalized until it is fully as powerful as the current physical layer. At that point, it can be made _THE_ api through which the logical layer accesses data. The current physical layer will then be nothing more than the default implementation of that general API.

At that point, we can move whole or partial tables to other hosts. Perhaps the autovacuum daemon will gain a sibling in the autosharding daemon. The query optimizer will need to care not just about disk IO, but network IO and will need to start considering the non-uniform performance characteristics of different tables. Some tables will be driven by Postgres's default physical storage engine. Others will be driven by other RDBMSs, or by NoSQL key/value or document stores, or other data stores. They may be on the same machine or a different one.

Postgres will transform into a query engine on top of whatever data stores best fit your workload. I expect the query engine will learn about columnar stores and be able to mix those in a single query with the row stores, key/value stores and document stores that it already understands. PostgreSQL will be a central point through which you can aggregate, analyze, and manipulate any and all of your data. It needn't be intrusive or disruptive: you can still use a normal redis client for your redis store, but you can also use Postgres to manipulate that data with SQL and to combine it with other tables, whole RDBMSs, other NoSQL stores, spreadsheets, web services, or anything else. Maybe it will even make things like Map/Reduce frameworks redundant.

I don't typically follow Postgres's internal discussions, so maybe this is already being discussed and planned. Or, maybe it's so obvious that nobody even needs to talk about it. Or, perhaps I'm just some wide-eyed idealist who doesn't understand the fundamental problems preventing such a thing from ever being practical.

</comment><comment><USER12> While I absolutely love the concept and really want to buy a graphics card just to play with this on my development box. Find it quite exciting how some applications are utilising graphics processing power.

But I can't help but wonder what the sys admin's response is going to be when I start asking for additional graphics cards being added to his perfectly built 2U database servers!

<comment><USER13> Size is nothing.

You are also asking the sysadmin to install a closed, unreliable kernel-level piece of software with that GPU.

<comment><USER14> > You are also asking the sysadmin to install a closed, unreliable kernel- > level piece of software with that GPU

Unlike all of the closed network equipment they already manage.

</comment></comment></comment><comment><USER15> This reminds me a little of the Netezza data warehouse appliance's architecture: a query planner in front of lots of little nodes with one disk, one CPU, and an FPGA. Every query is a full table scan, each node flashes the WHERE clause to the FPGA, and slurps the whole disk through the FPGA.

</comment><comment><USER16> Does anyone know if or when the GPGPU acceleration will be available in the normal Postgres install?

Is / will this acceleration be switched on by default?

<comment><USER17> Too far off in the distant future to tell.

</comment></comment><comment><USER18> This + Amazon RDS would be pretty awesome for mapping.

</comment><comment><USER19> in other breaking news grass is green and water is wet. Obviously throwing more power at the problem ends up with faster execution.

There's a limit to GPGPU acceleration though. It's the tiny amount of RAM. We need to adopt shared memory architecture like those found in games consoles. A single massive pool of RAM would further unlock potential power.

<comment><USER20> It's not that simple, when you look at those architectures like AMD's fusion platform, the differences of latencies and bandwidth play a huge role, making it a much more nuanced story. One of the papers showing this: [http://link.springer.com/article/10.1007/s00450-012-0209-1#p...](http://link.springer.com/article/10.1007/s00450-012-0209-1#page-1)

<comment><USER21> The paper's unfortunately paywalled, but it being two years old, and with AMD's fusion platform having added a few interesting features in the interim, like being able to just throw a pointer over the wall to the GPU, instead of copying the entire data structure over, makes me wonder if the paper needs to be revised to address this. GPGPU is a rapidly changing field, and just a couple years is a big difference.</comment></comment></comment>


Show HN: {{Mailstache}}, Templating for email. - <AUTHOR> http://sfdevlabs.com/mailstache/

<comment><USER2> I had an idea for a similar product a while back which would be basically the same thing for group messaging on mobile phones.

</comment><comment><USER3> This could be a great tool for those business founders that need to send a flood of emails quickly.

<comment><USER4> Yep. There's plenty of services that do it, Jeff just built this for me because I was being stubborn and didn't want to fork out the money.

<comment><USER5> It seemed like a good use for Mustache. It's for sending a few hundred emails in your normal client. Also a nice tool for learning the template language.

</comment></comment></comment><comment><USER6> well this just saved me $20. AWESOME</comment>


Why and How to Use Docker for Development - <AUTHOR> https://medium.com/@treeder/why-and-how-to-use-docker-for-development-a156c1de3b24

<comment><USER2> Seems to me that this is all working with the assumption that the development is on a Linux box. When developing on windows or mac using a vm such as boot2docker you're going to need to somehow share your codebase from your host machine to the vm and from there mount it as a volume in the docker container.

</comment><comment><USER3> Did you have to handle files created or changed by processes running inside the container being assigned the root user ?

<comment><AUTHOR> Doesn't seem to be an issue. The files created inside the container and written to the mounted volume outside the container are the same user/group as the parent directory (outside the container), not root.</comment></comment>


Brain scans show "sleeping on a problem" at work - <AUTHOR> http://www.guardian.co.uk/science/2008/jul/14/neuroscience.medicalresearch

<comment><USER2> _Some were then allowed to sleep while others were not. They repeated the same tasks the next day while having their brains scanned._

So are we talking about letting the test subjects nap or keeping the control group up all night?

</comment><comment><USER3> I heard a sample of McCartney talking about the origins of Yesterday years ago on the radio and how he just woke up and there it was.

Then a while later I was given a Naxos album following a Baroque music theme in my stuff on another continent and there's a theme from one of the songs on it that's eerily similar to yesterday except several hundred years older. Not quite Eric Carmen similar, but close to.

But that's OK - all artists derive and there is no shame in it so long as you give credit where you can and from the sounds of things he wasn't even aware of the connection.

The Naxos article is one of the very early ones and the labelling on it is terrible so I could never identify which labels applied to which CDs.

<comment><USER4> <http://www.spiderrobinson.com/melancholyelephants.html>

</comment></comment><comment><USER5> Sometimes i have a very hard time going to sleep, and i am at what i call the middle ground. Some random thoughts go through my mind while i try to sleep and sometimes i think of problems and get to something like a solution. Usually its just a subconscious hint that i understand in the morning after thinking about it. But i don't remember my dreams, so i rarely get to solutions in my sleep, just some hints in my middle ground. But who knows, maybe i get some work done and don't know it.

</comment><comment><USER6> Not sure that the "Yesterday" anecdote was appropriate; it's an example of creative thinking rather than learning.

It's also unclear as to whether the "same tasks" on subsequent days were exactly the same, or simply the same activity with different specifics. For instance, are people following the same path with a joystick, or a different path with a joystick? Are we talking about memory retention here, or learning skills?

</comment><comment><USER7> I've got to the point where I plan for this now. I stuff my head with the problem before I go to sleep, the next morning I wake up and there's the solution, I even get schedules some times :-), some times I wake up at 3 or 4 with the solution, if it's a curly one sleep can be elusive or I sort of have this twilight sleep where I'm half asleep but working on the problem as well.

</comment><comment><USER8> I'm reminded of the fascinating _Tetris Dreams_ study:

[<http://www.sciam.com/article.cfm?id=tetris-dreams>]</comment>


Libdispatch is open source - <AUTHOR> http://libdispatch.macosforge.org/

<comment><USER2> I wonder how hard it is to make libdispatch available for Leopard. I don't mind requiring Snow Leopard for development, but the resulting binary should be runnable under both Leopard and Snow Leopard, without requiring potential new developers to jump through hoops. Possible?

<comment><USER3> From the brief description on the site, it sounds possible.

Kernel support is not mandatory, as it only provides optimizations. So you're good there.

You will have to supply a build of the GCC compiler that supports blocks, and make it play nicely with Xcode (provided you're talking about end-user apps to take advantage of libdispatch). This shouldn't be too bad, but requires more Xcode-fu than the majority of Mac devs have.

The thing is, you should still use NSOperation for most multithreaded coding tasks in Snow Leopard, as it is now implemented using GCD underneath. You should only really monkey around with libdispatch calls directly if you're seeing performance problems with NSOperation (verified using profiling, of course).

I think the real benefit of this OSS project is going to be porting libdispatch to entirely different platforms (Linux, BSD, Windows, ...), and building NSOperation-like constructs in other languages/APIs to be used on many platforms (including the Mac, in the end).

<comment><USER4> _You will have to supply a build of the GCC compiler that supports blocks_

That's been available for awhile: <http://code.google.com/p/plblocks/>

</comment></comment></comment><comment><USER5> Definitely one of the most under-appreciated parts of Snow Leopard; anyone who has used BeOS can appreciate the value of making it easy for developers to "thread pervasively"...</comment>


The idea maze of personal logging (2016) - <AUTHOR> http://pcmonk.me/2016/10/13/logging-idea-maze.html <comment><USER2> This is a very interesting read, because I took the opposite approach.

I started out with the premise that manual logging is very hard to do well. It takes effort on my part (and thus hinges on my discipline), can be inconsistent, and can change depending on what my important metrics are.

I automatically collect as much information as possible. I log every time I change a window or tab and what I change it to (extending from native windows on macOS all the way through to virtual windows in gmail.com). I log the same from my iPhone. I throw all of my data in a Postgres data warehouse, and then use a BI tool to normalize it and put some KPIs in a dashboard.

This system allows me to ask anything from "what articles did I read last week?" to "what percentage of my time at work did I spend programming?" to "how much did I sleep this week?" to "who do I spend the most time messaging?".

It's also an exercise in understanding that metadata is incredibly revealing.

<comment><AUTHOR> Sounds interesting! Sounds like you've hand-rolled this, have you published anything about your system? I'm sure the details would be fascinating.

<comment><USER2> I haven't yet! I should really get around to doing that.

</comment></comment></comment><comment><USER3> I treat Google Calendar as a time-series database.

I have 14 calendars logging approx 500 events per month, and I have a UI for all of this... Google Calendar.

I also have API endpoints for all of this... Google Calendar. Which can be triggered by IFTTT for automatic stuff (i.e. did I Instagram something or Tweet?).

My email is linked to Gmail, so flights, itineraries, online shopping delivery, restaurant bookings can all flow in.

So the only thing I need to do manually are the few things it cannot automatically know, such as what film I just watched or what book I finished reading.

I only log public things, that is... data that exists in someone else's database somewhere. I do not log private things, i.e. Signal conversations or anything 100% offline that didn't involve a public database.

For me it's a simple thing... this data exists, can I make store it myself in a structure that I can do something interesting with it.

I have about a decade of this data.

Oh, and Google Calendar is really long in the tooth and is becoming both slow to use, hard to search, and clunky.

<comment><USER4> > Oh, and Google Calendar is really long in the tooth and is becoming both > slow to use, hard to search, and clunky.

In your personnal case (because of the many events) or in general ?

I feel like calendar has been forgotten by Google (no material design for instance) and could be on the list of next things they chop off.

<comment><USER3> In general.

I don't think they'll chop it because it's critical to the GSuite business side of things.

But it's probably not receiving love as whilst Ai has seen things like Photos revamped and the emergence of Google Assistance, the applicability of this to the business stuff is more difficult for compliance reasons and politics, etc. It's easier to focus on consumer when innovating.

The weirdest bit of all of the Google offerings, is the ever-diverging difference between the capabilities of the consumer Gmail accounts and the GSuite accounts. Google's tagline of "One Account, All of Google" is long dead in reality, and with it there seems to be a very different focus, innovation happens to the consumer and not to the business side, and never the twain shall meet.

Consumer accounts cannot use Google Calendar's "Find a time", and business accounts cannot fully use a list of products so long that it's boring listing them.

Google Calendar is central to how I run my life... I even logged phonecalls with links to the audio files uploaded to Google Drive, as well as scans of post received (and categorised in Google Drive but linked from Google Calendar).

But the usefulness is being reduced, silo'd, splintered from the general usefulness of Android and the Google related family of products due to the split of Google into consumer-focused vs business-focused with less overlap.

I've not bought a Pixel phone for this reason either. What's the point when so much of it's selling point is software and that software doesn't work with GSuite accounts.

<comment><USER5> > I even logged … scans of post received (and categorised in Google Drive but > linked from Google Calendar)

Oh, very nice idea. What's your workflow for doing this?

<comment><USER3> Imagine a 1990s batch flow system :)

I have a Fujitsu ScanSnap S1500, I scan through that... it auto names my post based on timestamp and drops it into a folder.

I rename it how I want to file it within my "Files" folder in Google Drive but leaving the datestamp intact, i.e. "2016-05-03T07:13:01 Finance - HMRC - P60.pdf" and I move it into another folder.

A cron comes along, looks at everything in that folder, fires a little Go util that uploads it to Google Drive (splitting " \- " into subfolders), and finishes off by adding it as a calendar ever.

This would be a lot easier on Windows or Mac as I think you have Google Drive clients that sync whereas on Linux this doesn't exist.

I thankfully don't receive a lot of post, but when I do it's only 30 seconds to scan something and a few seconds to rename and move into another folder.

</comment></comment></comment></comment></comment><comment><USER6> I made my side project ([https://socialite.ooo](https://socialite.ooo)) to do personal logging, but I had a slightly different problem. I would remember small things about people but not their names. I was going to the dog park with my girlfriend a lot and couldn't believe how often we'd remember someone's dog's name, or the walk we met them on, but we wouldn't remember them.

My solution was to correlate people to events, and events to locations. This allows you to not only remember what you were doing, but pivot off of any piece of information to better recall an event. Logging into a web app to enter information is a bit of a slog. I think making a mobile app is really crucial. That could even lead to some automation of the logging. For example, "You just called [CONTACT], would you like to create an event for this? ", or at the end of the day, "You texted [CONTACT] today, give a quick summary of what you spoke about". From there you can make the analysis smarter and smarter.

It's really strange, all these companies have so much data about us. We don't have access to our own data in a decent format though. My call history is with my telco, my location history is with Google (and probably many others), my conversations are spread out among so many different apps. What happens when I want to query the data about me though?

<comment><USER7> > Socialite is a paid application. We made this choice in order to give you > peace of mind. With no advertisers involved, you won't have to worry about > who is getting their hands on your information. Pricing will be targeted at > $10/year. Don't worry though, we won't charge you until you're making use of > the application.

> Socialite is a paid application. We made this choice in order to give you > peace of mind.

That sounds very funny. I would get much more peace of mind if you said that your client app is open source and uses strong encryption before saving data to your server. If you pay somebody, they must be trustworthy? That logic is laughable.

<comment><USER8> It it's free, you're the product, not the customer.

<comment><USER9> If it's proprietary software, it uses you.

<comment><USER10> Can you expand on that?

</comment></comment></comment></comment></comment><comment><USER11> I remember using AutoHotKey [1] (windows only) to randomly prompt me what I was up to every hour.

This was many years ago so I don't recall the details but my intention was to understand where/how I spent all those hours in the day as a student.

While there was no formal syntax that I followed that would have helped to analyze the logs programmatically, it did help me get a general understanding of my schedule and identify things I should change.

Ref : [1] [https://autohotkey.com/](https://autohotkey.com/) [2] [http://lifehacker.com/5582372/use-a-daily-log-to-keep- yourse...](http://lifehacker.com/5582372/use-a-daily-log-to-keep-yourself- focused-on-productivity)

<comment><USER12> Beeminder's TagTime does this, but according as a poisson process averaging once every N minutes.

</comment></comment><comment><USER13> In college I had to keep a life log for about a week as part of a psychology class. It was a completely manual process (i.e. pencil and paper; this was quite a while ago), and I was supposed to log in as much detail as possible what I was doing throughout the day. At the end we were supposed to create categories from the log, and add up all the time spent in each activity.

The purpose was to find out how much time was _really_ spent on each activity, rather than what we thought we did. It was an eye opening experience.

<comment><USER14> I did something similar back in university after reading about Sen. Bob Graham [0]. For a period of 6 months, I would write down every single action with place and people involved in a small notebook. At the end of the day and the week I would review it. It was really eye opening and allowed me to change some bad habits.

[0] I can't remember which article it was, but this one describes his logging activities: [http://quantifiedself.com/2009/05/politician-as-self- tracker...](http://quantifiedself.com/2009/05/politician-as-self-tracker/)

</comment></comment><comment><USER15> I've been using RescueTime ([http://www.rescuetime.com](http://www.rescuetime.com)) for around three years now, which pulls data from all of my workstations as well as my phone, but it lacks the ability to handle soft skill logging like social encounters and dietary habits with the finesse that pcmonk is working towards. Right now, I use it to track things like how much time I spend in IDEs, in StackOverflow, Hacker News, etc.

For some previously unexamined reason, I am giddy about tools that enable me to surveil my own productivity and procrastination metrics, but feel slightly uneasy about trying to capture daily intangibles.

I'm not sure if I would want to know how much time I've spent with each of my friends; the analytical side of me excises and optimizes, and I worry how that might manifest in negative ways if I start to quantify friendships and phone calls.

Anyone identify unexpected truffles and/or landmines in the exploration of your personal logs?

<comment><USER16> DayOne could help you, it can add a little popup on your device asking "what did you do today?" where you could enter little or lots of details of your encounters which are not loggable.

</comment></comment><comment><USER17> My very first (and maybe not so useful comment): I really love your approach. I was thinking something more automatic (I have some withings stuff) but you convinced me to start small and manual. Really interesting. Thank you for sharing.

</comment><comment><USER18> How about screen video capture? Rewind at 60x at the end of the day and take notes in whatever structured form you want.

It would also help to have an app that reacts to inactivity, that is you stepping away, and ask you what you did.

This works well if your day revolves around a desktop or maybe Android, but not so well with iPhone or iPad.

<comment><AUTHOR> Sounds like a fascinating idea, but I suspect a video will be unmanageably large. However, a relatively low resolution time-lapse would probably be sufficient.

<comment><USER19> You could sample say one screenshot every minute. It wouldn't take up too much space.

<comment><USER20> Those files will add up very quickly. On Linux I had screenshots for every click for months and the results were numerous enough to bring 'ls' to its knees

<comment> yjftsjthsd-h I think the idea was to analyze and cull at the end of every day

<comment><USER19> Well the goal was to make a video. The screenshots could be compressed into a single video file. At one screenshot a minute, and 24 frames per second; 24 hours of screenshots would give you a one minute video.

</comment></comment></comment></comment></comment></comment><comment><USER21> Really well thought out. Would also map well to an Alexa skill, like:

Alexa, tell plog I ate a burrito at 8am.

</comment><comment><USER22> Being able to log and analyze your data is great. It not only provides insight, but also provides motivation ("I'm logging this to improve. Let's not screw it up." etc).

I think my three big tools that have helped in this space are: my fitbit (tracking exercising), habitica for recording daily tasks and todos, and private journaling at the end of each day.

I've been terrible about routines and such, but all of this has really helped get things back on track.

Overall, I think also logging has to feed back into both organization and action, such as new goal setting. Which adds new things to log.

</comment><comment><USER23> This is great. The structure and simplicity is bomb and the data will be easy to mess around with while still being easy to clean up even if you mess around with verb usage like "scarfed" instead of "ate".

</comment><comment><USER24> There's some evidence that this kind of behavioral monitoring can be useful in a number of areas, especially weight loss, and other gradual lifestyle shifts. This seems like a particularly smart way to implement that.

</comment><comment><USER25> Most of the human-subject research done in public health, sociology, and similar domains uses data collected in a similar way. They basically ask people to take notes on specific behaviour or fill short surveys multiple times a day (they call it ecological momentary assessment), then they analyze it in the context of their research.

So yes, a tool like this has value in helping with better understanding ourselves, but also can help population research as well.

</comment><comment><USER26> GUI is not a problem, you can always tweak it or delegate it for little money. The big problem is how to force yourself to do it regularly in long term, at leat in my case.

I think that good idea is to integrate it with bot on your IM platform of choice. Messenger bot, in my case, could ask randomly what I'm doing and track it.

</comment><comment><USER27> I've used Timing.app on my Mac for a loooong time. Love it.

[http://timingapp.com/](http://timingapp.com/)

</comment><comment><USER28> ibGib's current web app used today by my girlfriend and myself for personal logging while our shower is getting remodeled: [https://www.ibgib.com/ibgib/Saturday%20II%5E818E0366E6B009CA...](https://www.ibgib.com/ibgib/Saturday%20II%5E818E0366E6B009CA0F71083DDD001EC99E5B0E708795B9F7FDBBF43C29225220) _(NB: After a temporary session "login" at the bottom of the page, you will be redirected...also, the links are long because the last part of it is a sha-256 hash that guarantees the integrity of the content of the ibGib data)._

I post this because I think personal logging is a perfect fit for ibGib's engine (and it's partly why I've written it), and it may interest you as a back end. It would allow you to basically have a graph database for a back end, while also allowing you to create and evolve your semi-structured data much like evolving an Event-Sourcing event in version control like Git (since each and every datum is versioned and maintains a complete audit history). It also is designed to be Big Data friendly, with the ibgib website's datastore acting with _completely_ Open Data.

Also, I wanted to mention that I've actually used it recently in the exact use case given by @TACIXAT where I was walking my dogs in my neighborhood and I wanted to be sure I remembered the neighbors' names down the street when I met them a month or two ago ([https://www.ibgib.com/ibgib/Walk%5EE3EE1755557357849C41C1511...](https://www.ibgib.com/ibgib/Walk%5EE3EE1755557357849C41C151117424D87EEB806D28216987B0F92F71ED1A2A39) \- just doule-click the big yellow circle). I definitely like how the socialite app looks, and it's great in that it helps you remember things _in context_. This is also what is primary about ibGib, allowing for pictures, text, links, etc., to be nested "inside" other "objects" (so each node acts as both a file with content and a folder with relationships to other nodes).

So for your personal logging, you could create a semi-structured "type" with your subject-verb-DO-etc. and then create instances of these. Then you can relate them via any named relation to any other construct (called an ibGib). So it's very much like a graph datastore that also has data hashing for all "children" nodes, which makes it a merkle graph. There's all sorts of neat properties, and like I said, I thought your use case would be a good fit for the engine. (Btw, the structure also lends itself to auto-generating dynamic and collaborative blogging from your data, e.g. [https://www.ibgib.com/ibgib/WaffleGib%20Jr%5E59B6D3828D35209...](https://www.ibgib.com/ibgib/WaffleGib%20Jr%5E59B6D3828D352091B0251F2A017511C2A681BE300E179398F4D7CB8BC56B650A) or [https://www.ibgib.com/ibgib/Grillin%20burgers%5E9E0151A452C1...](https://www.ibgib.com/ibgib/Grillin%20burgers%5E9E0151A452C17F5814602D9A119865A60E12E53E8A9819FFB41DE33C0D05CDBB))</comment>


Newsday to charge for website, online cable service - <AUTHOR> http://www.reuters.com/article/newsOne/idUSTRE51P71W20090226 <comment><USER2> Terrible idea. And not just for the usual reactionary "information wants to be free" reasons, but because paying for general news online doesn't work, it's why the washington post, nytimes and even the wall street journal have opened their archives to varying degrees.

I still like Dave Winer's idea: open up your archives completely, take away the spinning Flash ads and plaster contextual adsense strips next to each article instead.</comment>


We Should Treat Earth as Kindly as We Treat Spacecraft - <AUTHOR> http://www.wired.com/wiredscience/2013/11/chris-hadfield-wired/

<comment><USER2> Yes! Let's smash it into a nearby astronomical object when its usefulness runs out!</comment>


Blippy And Credit Card Numbers - Official Blippy Blog - <AUTHOR> http://blippy.posterous.com/blippy-and-credit-card-numbers <comment><USER2> _We take security seriously and want to assure Blippy users that this was an isolated incident from many months ago in our beta test, and doesn't affect current users.

While it looks super-scary and certainly sucks for those few people who were affected, and is embarrassing to us, it's a lot less bad than it looks._

This could have been phrased a bit better to include an actual apology. It's pretty easy to do: "Several months ago Blippy's limited beta test leaked data about four customers, including their credit card numbers. That is totally our fault. We have apologized to those four customers personally and have taken steps to make sure it cannot happen again. The site currently does not leak data, but those four customers' numbers are still visible on Google searches. We are working with Google to correct this and expect it to be resolved in a few hours.

Here are the improvements Blippy has made to deserve our customers' trust:"

[Edited to add:

The Japanese salaryman in me would suggest that the CEO sign this post. Phrasing might include "This was ultimately a failure of our internal quality controls, because it should have been caught several times before this data was exposed publicly. I take full responsibility for the lapse and have begun..."]

<comment><USER2> A quick elaboration on the CEO thing, because I didn't want to give the impression I'm grinding anybody's nose in it: Tactically I think it is a good idea because it demonstrates that the company has no higher priority than the users' security and their trust. (And if your business is publishing folks' info, that is probably true. Heck, everybody on the Internet who takes credit cards, in any capacity, has a built-in "Are they going to scam me?" objection to address.)

Culturally, in Japan, the title for the CEO (often) literally means "Person With The Highest Responsibility." (最高責任者 -- all the other CXOs are "Person with the Highest Responsibility For [Information, etc]") Within the company, I'm sure some junior engineer is going to get a royal chewout today, but to the rest of the world, the company is an impenetrable mass. When an employee screws up, the company has screwed up, and when the company screws up, the CEO (or division chief or whomever) apologizes because his job is managing the business such that it does not screw up.

 _When done well_ , I think this is one of the most emulation-worthy bits of the Japanese corporate culture. It sends a message internally that you will always back your people come what may, and externally that you're worthy of the trust your customers, shareholders, and business partners place in you.

<comment><USER3> Patrick, it's always a pleasure reading your posts. How I wish companies in the US acted like this...

</comment></comment></comment><comment><USER4> Yeah, I don't know. My lizard brain wants to see them writhing on the ground pleading for mercy, but the teeny tiny rational part of my brain wonders what I expected them to say instead of this.

If you get past your expectations about their attitude, they are being pretty forthright about what actually happened; in many more contrite disclosures, you don't get this level of detail. I appreciate the detail.

I'd like to see something other than the standard "now we're getting third- party security audits" platitudes. For instance, I'd like to know that they have a software security person _on staff_ now, since they're clearly dealing with credit card information that they don't fully understand.

</comment><comment><USER5> _sucks for those few people who were affected_

Pretty much guarantees I'll never use this site.

<comment><USER6> I have never used this service and from reading what it does, I probably never will. BUT, if were the kind of person into these type of things, I would feel pretty good about them. The explanation sounds sincere, honest and heart-felt. They have done their research and discovered what caused the problem. The credit card numbers were only in the source-code of the HTML, not actually diaplayed on the HTML page (I know it only takes 2 clicks to see the source, but how many people check out the source code of every page we see through the day ?). And they are telling us that they are well-funded to dedicate more resources on security. I feel pretty good about them.

<comment><USER7> _(I know it only takes 2 clicks to see the source, but how many people check out the source code of every page we see through the day ?)_

The same kind of people that go hunting for credit card numbers online?

<comment><USER8> I'm pretty sure there are much easier ways to get credit cards online than randomly looking at webpages. Can't you buy them in bushels from Romanian hackers? I hear the going rate is much less than a dollar a number.*

*I hear this from a person who used to work in e-commerce stopping illegitimate transactions, not from illegal activity, btw.

<comment><USER9> Credit card numbers alone can be generated, no need to steal them. Only in combination with the expiry date and cvv do they have any value, newer cards are protected with a pin code for that reason.

The whole reason the VBV program exists is to make the numbers alone worthless.

Why would you single out the Romanians?, there are people doing that sort of thing all over the world.

</comment></comment></comment></comment></comment><comment><USER10> Their anonymously-signed blog post doesn't engender much confidence in them as a company. Except that they try hard to protect their own identity.

<comment><USER6> The apology is signed by the Co-Founder. What am I missing?

"Thank you for reading. Philip Kaplan, co-founder"

<comment><USER11> Probably 2 hours of time in which they could edit the page and append a signature.

</comment></comment></comment><comment><USER12> Either you want businesses to communicate with the public like normal human beings or you can complain and nitpick their statements for not being perfectly phrased. Not both.

I'm glad they candidly told us about what went wrong. There's an important lesson to remember about how everything put on the web can be indexed and stored even if it was only up for a short time.

</comment><comment><USER13> Wow, I would have thought they would have at least made a motion to apologize. Instead they've basically said "hey, this isn't a big deal, stop complaining".

<comment><USER14> Seems like they apologized to the four users involved. I don't know that they owe the public in general an apology. They basically explained why this is less scary than the headlines (including the one here on HN) makes it look and said that they were committed to keeping this from happening again, including giving examples of steps they were going to take.

What would you have liked to see from them? Prostrating themselves before you for revealing someone else's credit card data?

<comment><USER15> Leaking 4 of thousands of credit card number IS a huge deal. It's a disservice to their users (even the ones who weren't affected) for them to downplay it.

<comment><USER16> I'm personally getting the feeling that downplaying it was more of a trip up on their part. They wake up, find they are suddenly being viewed as the devil, and for some strange reason want people to believe that things are not as bad as they look. The problem, though, is they should never have said that directly. They should have given us every reason to believe that things are not as bad as they look and have us come to that conclusion for ourselves. They should also get some PR people on pay; they probably need them more than the added security.

</comment></comment></comment></comment><comment><USER17> If the onus is soon going to be on the user having to explain why he sees a problem with his private details being shown to the whole world, there are going to be lots of problems and incidents which people are in no way ready for.

</comment><comment><USER18> I was chatting with someone about the language used in a lot of these apologies. This has come up in a lot of issues - like in the Justin.tv suicide case.

I think companies fear legal repercussions. If you use certain words, you might be taking blame onto yourself in a legal sense and might have someone use that against you in a lawsuit.

I'm not sure about this incident but I definitely sensed that was the issue with the Justin.tv apology.

</comment><comment><USER3> Sorry, but this blog post indicates that Blippy is in no way serious about security. Blippy handled sensitive data (credit card numbers) in a highly insecure fashion, and rather than treating it like a full-scale emergency, which it is, regardless of the number of people affected, we get this "hey, it's no big deal" blog post.

What other massive security mistakes are lying around in their codebase? Why does this sort of reply give me absolutely no faith that they'll deal with those problems seriously when/if they arise?

</comment><comment><USER19> Their response is totally fine and in proportion to the actual harm done.

</comment><comment><USER20> Everyone and every company makes mistakes, so it's not a matter of whether or not you screw up (because you will), but rather how will you deal with it when it happens. I think Blippy dealt with it pretty well.

Having said that: I think Blippy was a dumb idea to begin with, and this dumb mistake may have been the final nail in the $11-million-Series-A-funded coffin.

</comment><comment><USER21> now that this whole thing has blown over, i'd love to hear from someone at blippy regarding how this affected their subscriber count. i have a feeling it went up today despite the negative press.

</comment><comment><USER22> Hint for the future: if you're processing raw data that could include credit card #s, filter out 16-digit sequences as a whole.

<comment><USER23> 15 for American Express. 14-16 for various kinds of Diner's Club. 16, 18, or 19 for Solo and Switch.

It would not have occurred to me that the number might even be in the raw data. Sounds like the supplier is violating PCI. (That doesn't apply if the supplier is the card company or issuing bank--PCI is just something they require others to follow. They hold themselves to a much lower standard).

<comment><USER24> It might be a useful heuristic for companies anywhere remotely in this space to use during early alpha/beta periods though. There aren't _that_ many legitimate cases where you're going to be sending 14-to-19-digit numbers in HTML, so at least during the early phases, flag them and make sure they're not CC#s that somehow got there.

</comment></comment></comment><comment><USER25> "That's why it's okay to hand your credit card over to waiters, store clerks, and hundreds of other people who all have access to your credit card numbers."

I don't like this attitude. Anyway who cares when you have $11.2 million funding

</comment><comment><USER26> all publicity is good publicity.

</comment><comment><USER27> u guys are being too hard on them. Shit happens. Even serious shit. I feel like they are being accountable and honest.</comment>


Thoughts on OnLive - <AUTHOR> http://blog.wolfire.com/2010/06/Thoughts-on-OnLive#top <comment><USER2> What really amazes me about OnLive is the interface. It's really a thin client: your entire interface is streamed from OnLive's servers. Since the UI is a video, they jam it full of movie clips. Reminds me of the video wall from Back to the Future.

My expectations were shattered when I clicked on a game preview video, expecting a 10 second wait while it loaded and buffered. Nope! It started playing immediately. Heck, even the infinitesimal load screens they have are videos.

I clicked on all the "Brag Clip" videos and they played immediately. You can even watch people playing live. Since there's no wait penalty for moving through the interface, you find yourself clicking a lot more.

</comment><comment><USER3> This seems like it could be a perfect complement to a low-power device running something like ChromeOS. I wonder if they'll branch out from games, though? Any CPU-intensive application could be made to live in the cloud: OnLive Photoshop, OnLive AutoCAD... it would just need to be coupled with a cloud document store of some sort. (Hopefully Dropbox.)

<comment><USER4> He did mention there's a certain mouse-lag on cursor based games and Photoshop with mouse-lag would be kinda bad. I don't see how you could solve the problem either. His 14 ms ping is probably as good as it gets and even the smartest software can't circumvent physical limitations.

<comment><USER5> This is actually easy to solve -- most VNC applications already implement the solution, which is to have a local, lag-free cursor that is shown to the user, and hide the laggy cursor on the other machine.

One thing I forgot to mention in the post is that there is apparently an OnLive API that some games are using that replaces the cursor in the game with a local cursor. Not all games can use it (for example, World of Goo's cursor is blocked by walls and such which is critical to gameplay), but Unreal Tournament, and OnLive itself, use it in the UI.

Edit: of course this wouldn't solve the case where you are actually doing something in Photoshop that might require real-time feedback like the airbrush tool!

<comment><USER6> This is why I'm entirely skeptical of this whole OnLive business.

If you're having trouble with a mouse cursor, then no video game that requires interaction will be playable. QuakeWorld, IIRC, was the first real game to solve the latency problem. And they did it with prediction that lets the UI maintain responsiveness while hiding latency. That game was playable up to maybe a 200ms ping time and with a dial-up modem. That's impressive. But it was also a lot of client-side magic, which is what VNC is doing with the mouse.

In addition to that, no Wii game will be playable with this thing, no FPS, no World of Warcraft, etc. etc. I think this is why serious game companies aren't even commenting on it. It doesn't even register to them. I can really only see OnLive taking business away from the Appstore or Android handheld markets. Extreme casual gamers that don't know the difference between an Xbox controller, a Wii nunchuk, and a 1980s joystick will be the market here.

<comment><USER5> Disagree, I found FPS to be the most playable games on the service. You should definitely try it out. Also what makes you say that serious game companies aren't commenting on it? Their games are already there.

<comment><USER7> I'd love to try it out. How? It looks like their "sign up" is just a waiting list at this point. I'd also question whether they have really "launched" if at this point all they're doing is what amounts to a limited subscriber no- cost public beta.

</comment></comment></comment></comment></comment></comment><comment><USER8> I tried OnLive in beta phase. For most 3D games, it works just fine, I can jump, turn my head around and everything. But for racing game, the lagging is killing me, I cannot finish one round because the dismatch between my perception and the actually driving. Not a FPS person, have no opinion on that.

Overall, I still think that OnLive is a product born too ahead of time; we just simply don't have that hight quality Internet to support it.

<comment><USER9> It's making me imagine a box that you can install in an apartment complex where you just plug in a number of game consoles and a SAN, and it allows anyone in the apartment complex to use an onlive-like interface to play the games. This is probably doable with today's technology, although the lack of digital delivery and HD game storage to the consoles makes it a little too much of a challenge in the short term. But that would get around the network infrastructure issue.

<comment><USER8> The reason why OnLive is economical than your game console is not that one OnLive server can power several game instances. Maybe the most powerful server (expensive ones but still x86 arch) can serve 3 or 5 game instances simultaneously. However, in per dollar perspective, it is not cheaper than your game console.

The way OnLive is cheaper is that it smoothes the usage curve by allowing people in different places, different time-zones to play on the same server. Once the utilization rate up, it is a scalable business.

In your "dorm room" scenario, I fail to see any advantages in server utilization perspective.

<comment><USER10> How do multiple time zones jive with local cdns serving at 14 ms...?

</comment></comment></comment></comment><comment><USER11> An unmentioned benefit is that this stops a lot of cheating.

<comment><USER12> Until you use the free cpu to do image analysis for some cheap hacks like aiming. This might be interesting (I doubt people will do it though).

<comment><USER11> That would be possible, but other classes of cheating wouldn't be, like maphacks.

</comment></comment></comment><comment><USER13> This is a pretty remarkable service, but there is one awkward caveat mentioned in the article:

 _"Unfortunately, because of licensing restrictions, we can only offer Mass Effect 2 for play under Windows. So, if you do not have access to a PC, your only option to play it on a Mac is under Windows using Boot Camp or a similar system. We apologize for the inconvenience. OnLive has no other games in the pipeline that are Windows-only, and we do not expect to have any others."_

D'oh!

[edit: As a Canadian surfer, I run into US services and sites every week that don't allow non-US users. Netflix, Comedy Central, etc. I could imagine the licensing issues could be similarly irritating with OnLive as well]

<comment><USER14> "OnLive has no other games in the pipeline that are Windows-only, and we do not expect to have any others."

As they point out, this is the only game that's not available cross platform. It's understandable that this would happen during the beta period, while they are still trying to prove the model to game developers.

<comment><USER15> I wonder if the restriction is because EA already licensed the Mac publishing rights to someone like Aspyr?

<comment><USER16> It's more likely a Microsoft exclusive.

</comment></comment></comment></comment><comment><USER17> This is a great writeup of OnLive. I wrote one myself a few months back, [http://siculars.posterous.com/onlive-shows-us-the-way-to- vid...](http://siculars.posterous.com/onlive-shows-us-the-way-to-video-game- nirvana). Like the author, I also agree that this is the real deal and will only continue to get better as technology improves and end users get fatter pipes. I, for one, am looking forward to giving this a go.

I might even venture to say that at some point in the future as the platform matures, OnLive will be the preferred distribution platform simply due to the fact that there is no way to resell a game by the end user. Resale is a major problem for publishers who are desperately trying to eek out every last cent from their investments.

</comment><comment><USER18> I wonder if you could eventually sell cycles back to OnLive, since you aren't doing the heavy lifting on your machine ... Maybe offset the cost of the service? Or maybe OnLive could do an ElectricSheep-like screensaver for distributed processing. That could mitigate some of the latency issues as well, for those near you. Social rendering, comrade!

Edit: The more I think about this, the more it seems this is precisely (or at least _should_ be) where they're going with this.

<comment><USER19> The added complexity and lack of centralized control isn't worth the cost of cycles.

<comment><USER18> I don't know. OnLive can't scale very well as is. A liberal estimate would be four game instances per server, which means 250,000 servers for a million players. But if you're spreading that around, especially on players' machines that aren't being used at the time and may be fewer hops from the destination, it may be worth it. Plus, it'd be a good first step towards a mostly decentralized gaming infrastructure.

</comment></comment></comment><comment><USER20> This might be the killer app for next generation networks for countries that don't have it already. It'll go from "Oh well, Youtube is a little slow but I won't spend money on a better plan for _that_." to "I absolutely must have a 20Mbit connection in order to play all these _amazing_ games."

I get 700kb-1Mb/s here in Berlin on a cheapo contract - I will definitely try it out if (and that's a big one) it becomes available here.

<comment><USER21> It actually requires 700 KB/s or 5.6 Mb/s but that should still be affordable in most of Europe.

</comment></comment><comment><USER22> I saw OnLive on E3 and was greatly impressed. I wish I had this technology, working locally at work for things like RemoteDesktop/VNC (okay not fair, as the latter would probably deal better with high-frequency detail such as fonts). But for testing/developing games off line, or even in a big office (to cut down few miles a day of walking) that would be great :)

</comment><comment><USER23> How does it work with custom content? If I wanted to say play Mnerva for HL2 (assuming HL2 were offered on it in the future), is there a way?

<comment><USER5> There is none. It's like a console in that regard.</comment></comment>


How's this for domination? Apple controls 95 percent of tablet market - <AUTHOR> http://www.techvibes.com/blog/hows-this-for-domination-apple-controls-95-percent-of-tablet-market-research

<comment><USER2> Sounds right. They have been the only game in town. Now the only way for that number to go is down as 50+ android tablets flood the market.

Whether any of them will rival the iPad remains to be seen though.

<comment><USER3> when mom and pop stand at best buy and look through the options, there's definitely going to be some cheaper options than an ipad. still though, i anticipate christmas will be good for Apple.

</comment></comment><comment><USER4> Wonder how many more potential tablet users there are out there, especially at the iPad's price point.</comment>


Live broadcast of LA Hacker News Meetup - <AUTHOR> http://vokle.com/events/7201-la-hacker-news-january-meetup

<comment><USER2> Who was the guy who was speaking about selling his videos and said he had created the presentation on the bus?

I think he presented before the guy who spoke about Perftools. Thanks!

<comment><USER3> Giles (<http://gilesb.com>)

<comment><USER2> Thanks!

</comment></comment></comment><comment><USER4> Great talk by Giles. Thanks!</comment>


This is so wrong at so many places. Web App vs Native App (Infographic) - <AUTHOR> http://www.alterian.com/wcm/images/278692/mindthegAppinfo

<comment><USER2> Am I the only one getting fed up with these stupid "religious" wars in much of the IT world?

There are many valid cases where native is the better approach and others where web-app is best ! Any decent developer will do their homework and select appropriately.

BTW - many of the 'problems' high-lighted on the graph apply to both Native and Web-apps and there are some additional ones with Web-apps but I can't be bothered to spell them out. Bah !!

<comment><USER3> > Am I the only one . . .

If you have to ask this question, the answer is probably no.

</comment></comment><comment><USER4> This avoids the one major reason that I think most developers choose to develop native apps - how much easier it is to charge for it.

<comment><USER5> It also sidesteps many of the shortcomings associated with going the HTML5 route. In short, it's not an fair, objective comparison of the two.

</comment></comment><comment><USER6> Even this highly simplified view changes once you have the app installed. With a native app, you have an icon right there on the user's home screen. The web app would require more typing and clicking.

<comment><USER7> On iOS you can hit the plus button on any web page to add it to the home screen, making an icon right there on the user's home screen.

<comment><USER8> This is true in Chrome, Windows and ChromeOS as well. Android probably does too, although I don't know for a fact. The notion that a web app is "just a web page" is really starting to fade away.

</comment></comment></comment><comment><USER9> A lie by omission. They forgot to warn (following their warnings upside down):

1\. Website can be malicious, too. Phishing, clickjacking, XSRFs, browser exploits - there's a lot of nonpleasant stuff on the web.

2\. Websites can't manage memory and other resources at all. Sure, you, for example, can try to measure performance and disable UI effects, but that's another story.

3\. In a same way, users must have enough of free space where browser's application cache is kept, too. Or you'll strain network re-downloading same data over and over again. This is especially annoying for roaming and other areas with high $/MiB cost or countryside with slow GPRS connectivity.

4\. Website can fail, too. And if this is not some user-local network problems, this is more disasterous than a crash of a single copy of app on someone's device - your "webapp" works for noone at that time.

5\. And, obviously, in a same way as removing the app, users could delete the bookmark for your service.

</comment><comment><USER10> Almost all of those negative points apply to the right column as well.

<comment><USER11> Should add a few, too, like "hope wireless connection works well or that developer properly prepared manifest," or "hope the developer didn't just assume 'web app' meant 'test in Safari Mobile only,'" etc.

<comment><AUTHOR> And not just that but not all the native apps have-to-have-an-active-internet connection vs. a web based app.

<comment><USER11> Not all web apps do, either, thanks to HTML5 Manifests and the like. That said, not everything plays along well with offline web apps, sadly.

</comment></comment></comment></comment><comment><USER12> And of course, this whole thing ignores an entirely different entry point "Discover new app". It assumes you are specifically searching for the app in question. What the app store and it's ilk offer is exposure. Angry Birds has been near the top of the top 25 on the app store since launch, and that alone drives continuous sales.

If you're an incredibly well-selling web app, you STILL have to market and spend and shout to get yourself known. No matter how well you're doing, your word of mouth still probably doesn't beat Apple's Top 25 board.

<comment><USER13> The App Store offers exposure to a few hundred applications that are at the top of their category due to intentionally difficult to predict algorithms; relying on this mechanism for users discovering your app is asking for failure and makes about as much sense as making a web page and hoping that it appears on the front page of a website catalog/portal like Yahoo for the lifetime of the product. For 99.99% of the applications in the store, people are going to be finding out about it from online reviews, word of mouth, and search engines.

</comment></comment><comment><USER14> HTML5 support for things like geolocation / camera usage is inconsistent across models and generally brittle. The upside is that mobile web is really low friction and allows for instant deployment, but there's functionality and no good management system like the home screen.

I've used the Quora web app occasionally. But if I had actually had a Quora app on my home screen, I'd use it far more frequently.

<comment><USER13> Web applications can be icons on your home screen (at least on the iPhone): just click (+) and "add to home screen". If the application is setup correctly, when spawned in this manner it will also appear without any browser chrome, allowing it to be a truly full screen application.

</comment></comment><comment><USER15> This is just an excuse to drop a semi-cool design on the web using a hot topic, very typical these days.

</comment><comment><USER16> Oh man, they should really tell Instagram / Angry Birds that their software will work as a webpage and that the user experience on a mobile browser will be that much better.

<comment><USER17> Uh, Angry Birds quite obviously works as a web page (<http://chrome.angrybirds.com/?version=hd>), haven't tried it on either mobile or computer browsers though. Just wanted to point out that even high- profile games such as that are indeed becoming available as web pages.

<comment><USER18> Angry birds in the browser is 100x worse than on the iPad. It feels like a totally different game. For a game like that, web apps can't really compete with native apps right now.

<comment><USER19> the distinction should be made of mobile web apps vs web apps.. cause there are tons of flash games that outshine Angry Birds in many ways. Just pointing out for clarification.

</comment></comment></comment></comment><comment><USER20> The only valid negative point I see here is "update app", which is really the web-as-deployment-platform's killer feature from a user's perspective. I do hate having to update 20+ apps on a regular basis, it should just be on- demand.

<comment><USER21> The problem with invisible updates is sometimes you don't want to get the update at all. This is especially true if you work in a corporate environment and you need to re-certify each version of the app for use on your work- provided devices.

<comment><USER20> HTML5's Application Cache can solve that to some extent. I believe you can prompt to user to ask if they want to update (though once it's updated there's no going back, or installing previous version initially, unless the site provides mirrors of old version)

<comment><USER13> This question is only going to be relevant if the application is already open: if you close your browser windows and then re-open the application it will use the latest cache and evict the older ones. In essence, this mechanism is designed to allow an application to operate with an atomic version of the resources it requires for operation, and is not designed to allow the user to manage old versions.

</comment></comment></comment></comment><comment><USER22> Never had any of the problems on the left with my iPhone. Seems like FUD to me.

</comment><comment><USER23> WTF is this shit....was this a joke?

<comment><USER24> No, just PR material from a company with a horse in the race, targeted at people who are too poorly informed to see through it.

</comment></comment><comment><USER25> If it's so wrong, then why do you post it?

</comment><comment><USER26> Apps may contain viruses? FUD pure FUD

</comment><comment><USER27> This is useless flamebait.

</comment><comment><USER28> If you try to view the post in a mobile browser, you get:

"Article not found"

Or at least, I am, on my iPhone right now.

There's definitely a touch of irony there.

<comment><AUTHOR> This is the blog that linked to it and that's how I got to it: [http://blog.utest.com/mobile-app-or-web-for-mobile- infograph...](http://blog.utest.com/mobile-app-or-web-for-mobile- infographic/2011/07/)</comment></comment>


Curry-Howard, the Ontological Ultimate - <AUTHOR> http://psnively.github.io/blog/2014/10/14/Curry-Howard-the-Ontological-Ultimate/ <comment><USER4> This is very vague about what Curry-Howard means. Curry-Howard means that any type can be interpreted as a theorem in some logical system, and any term can be interpreted as a proof of its type.

This does _not_ mean that those theorems have anything to do with your program. Take the following function:

        swap : forall a,b. (a,b) -> (b,a)
        swap pair = (snd pair, fst pair)

The type here is forall a,b. (a,b) -> (b,a). The logical meaning of this type is (a and b) => (b and a). Note that this is a theorem in _logic_ , not a theorem _about your program_.

This is entirely different than what the types say about your program. Those properties you get from progress/preservation proofs of the type system. Now it is certainly the case that in dependently typed languages you can get the logic from Curry-Howard to express theorems about values in your program. That's the whole point of dependent typing. But it's important to to keep in mind that statements such as this:

> Look again at the OCaml Set module example above. You already get a > universally-quantified property just from using the type system to guarantee > an invariant expressed in an ADT. That's the import of the Curry-Howard > Isomorphism, minus any appeals to more expressively powerful type systems.

are nonsense. The fact that the module enforces the property

        P(n) === S1.mem n (S1.singleton n) = true
        Q(n) === forall m \in int. m /= n -> S1.mem m (S1.singleton n) = false

has nothing to do with Curry-Howard. Which proves Kell's point about the equivocation around type theory.

</comment><comment><USER5> > _You express your specification as types (theorems), and your implementation > proves those theorems. Then your code is correct by construction. This is a > true statement; it isn't open to debate, not being a matter of opinion._

That's technically correct, but a little bit divorced from reality. Let's say I want to write a function that counts the primes below one million. Since that's a function with no arguments that returns a single integer, the corresponding theorem by Curry-Howard is that "at least one integer exists". The function "return 0" is a proof of that theorem. That doesn't seem too useful!

You might argue that we should use a richer type system to express the specification. Sure! We just need to express the idea of "primes below one million" in the type system. But that's at least as difficult and bug-prone as writing the program in the first place, so I have a hard time seeing the benefit.

Most real world functions are the same way. Say you're programming a game and you need a function to fire the gun. Play the sound, add some screenshake, create a bullet object, etc. Go ahead, express that as a theorem. Don't forget to come back and tell us what you gained by doing that.

<comment><USER6> Um, maybe you missed the point about dependent types? You can express a function, that takes no arguments, that returns primes below 1,000,000 as it's type! That's kind of the point of the talk, and is supposed to be possible in languages like Agda and Idris (I don't know enough about them to give any syntax here). See jules' comment below about how curry-howard does not mean your implementation is a full proof as well.

Considering code that flies planes and shoots guns generally is written using proofs on control systems (if not required by law), your examples are a bit weak.

<comment><USER7> The constructive nature of Idris makes it hard (at least for me) to express a prime under 1,000,000 as a type. For example, it's trivial to express a composite as a GADT:

      data Composite : Nat -> Type where
        factors : (x : Nat) -> (y : Nat) -> Composite ((S (S x)) * (S (S y)))

but there is no analogous construction of a prime type. Luckily most day to day programming looks more like the composite case than the prime case.

<comment><USER8> As an example, here's how primality is defined in the Agda standard library. It is simply the negation of the property 'has a divisor and is greater than 2'.

[http://agda.github.io/agda- stdlib/html/Data.Nat.Primality.ht...](http://agda.github.io/agda- stdlib/html/Data.Nat.Primality.html)

</comment></comment></comment></comment><comment><USER9>
      Again, how he gets this from Amanda's and my presentation is beyond
      me

Yes, I don't doubt it is beyond him. Yet he is one of only two very smart people with very interesting things to say that managed to get themselves removed from my various feeds, because I just couldn't stand their idolatry of static-typing and never ending condescension of anything remotely critical of it anymore.

I haven't seen the presentation, but I don't for a second doubt they implied that:

      If somebody stays away from typed languages, it [means]
      they're stupid, or lack education, or are afraid of maths. There
      are [no] valid practical reasons for staying away [from type
      languages].

He _believes_ they were being very constructive, showing an understanding for other opinions and taking a nuanced view of static typing, with an eye for valid criticisms. I _know_ , from the online reviews, many did not experience the talk that way.

<comment><USER10> Can you recommend some even-handed reading on the opposing views here?

<comment><USER11> This comment by Matthias Felleisen's is a very polite and well-considered position from an academic on the dynamically-typed side of the spectrum: [http://existentialtype.wordpress.com/2014/04/21/bellman- conf...](http://existentialtype.wordpress.com/2014/04/21/bellman-confirms-a- suspicion/#comment-1362)

Harper himself can't be relied on to be so cordial, unfortunately.

<comment><USER9> Speaking of the culture around static typing: Bob Harper's blog, where Matthias Felleisen gets 15 downvotes per courteous, thoughtful response...

<comment><USER4> Seems like voting has now been turned off, or at least I don't see any votes any more.

</comment></comment></comment></comment></comment><comment><USER12> The talk he's defending was tiresome and dripping with condescension (I agree with Stephen Diehl: [https://twitter.com/smdiehl/status/519160854517149696](https://twitter.com/smdiehl/status/519160854517149696)). Typed-language folks don't need advocates who waste breath talking about "incompetent Ruby developers moving to Clojure" and whatnot. There's enough positive stuff to talk about! I think the folks who gave that talk need to read Gershom Bazerman's (a person who has no trouble giving talks filled with excitement about type- and category-theoretic concepts with no condescension) excellent post here: [http://comonad.com/reader/2014/letter-to-a-young- haskell-ent...](http://comonad.com/reader/2014/letter-to-a-young-haskell- enthusiast/)

</comment><comment><USER13> It seems oddly defensive for Paul Snively to interpret Stephen Kell's "Seven Sins" essay as being mostly about his (and Amanda Laucher's) Strange Loop talk – sure, their talk was mentioned as an example in passing (along with another talk about Rust), but in no way is the essay specifically about their talk. The seven sins essay addresses the entire discourse about static and dynamic typing; whether one particular talk exhibits a particular "sin" or not doesn't mean there's not a real problem.

</comment><comment><USER14> _> >In a typed language, only polymorphism which can be proved correct is admissible. In an untyped language, arbitrarily complex polymorphism is expressible.

>This misses the point, which is that "arbitrary" has proven to be unlikely to be correct. Ultimately, this argument comes down to "you should trust human programmer intuition," which I gladly admit to being an assumption I'm unwilling to make._

It's true that _"arbitrary" has proven to be unlikely to be correct_ in the general case.

However, allowing untyped types(?) has also proven to be _useful_. I think this is because there is yet to be a language that makes expressing complex types _easy_.

We work in an environment where FizzBuzz is considered a good way of filtering people who can program.

I'm generally a proponent of "strongly typed" languages. But I do worry about the cognition overhead the syntax causes, and I do wonder if there is a "better way".

<comment><USER15> > I'm generally a proponent of "strongly typed" languages. But I do worry > about the cognition overhead the syntax causes, and I do wonder if there is > a "better way".

What about dynamic language + runtime type checking + (nearly) 100% test coverage? You get the flexibility of a dynamic language and the safety of a static type language (in fact you get more, since runtime type checking is more powerful).

<comment><USER16> I still don't understand the notion that dynamic types gives you anything more than static types. Are there really usefull programs that can't be written in, say, Haskell?

<comment><USER15> Unfortunately I do not know so well Haskell to give you an answer. I was referring to this:

> I think this is because there is yet to be a language that makes expressing > complex types easy.

Since I'm obliged to use a dynamic language (JavaScript) I'm looking for a solution in it. And in JavaScript is really easy to express a complex type, say "the set of all the even integers between 2 and 14 but 10", using runtime checking to enforce the constraints. Is it simple in Haskell to define such a set in its type system?

<comment><USER17> Simple? Yes. Pleasant? Not really. I'm not a Haskell expert but I can write that type in Scala (the Haskell version probably has less boilerplate, but still some):

        sealed trait Even[N <: Nat]
        object Even {
          implicit object zero extends Even[_0]
          implicit def evenSS[N <: Nat](implicit e: Even[N]) = new Even[S[S[N]]]{}
        }
        sealed trait EvenAndBetweenTwoAndFourteenAndNotTen
        object EvenAndBetweenTwoAndFourteenAndNotTen {
          implicit def forN[N <: Nat](implicit e: Even[N], le2: Le[_2, N], le14: Le[N, _14]) =
            new EvenAndBetweenTwoAndFourteenAndNotTen[N]{}
          implicit object interfere10 extends EvenAndBetweenTwoAndFourteenAndTen[_10]
        }

Like I said, it's cumbersome, but there's nothing actually complicated about writing this, it's just boilerplate to represent it in the type system.

On the other hand, in Idris or the other languages mentioned in the article, you should be able to write that kind of constraint at the type level just as easily as you can at the value level. That's where it gets really exciting.

</comment></comment></comment></comment></comment><comment><USER18> Regarding the referenced talk at Strange Loop, I have noticed that I have yet to see a good talk ever done in that style where dual-presenters oscillate back & forth. Especially when they're trying to elicit laughter. I did manage to enjoy the talk between cringeworthy moments, at least.

There is an interesting slide at around 21:00 where they show four quadrants that represent:

What do you get when you pass a Term to a Term? (a function)

What do you get when you pass a Type to a Type? (templates, generics, type variables)

What do you get when you pass a Term to a Type? (dependent types)

What do you get when you pass a Type to a Term? (inheritance, overloading)

It was an interesting slide. It manages to make dependent types seem like an essential missing piece for the sake of symmetry. I'm not sure I understand the last one, though: how is inheritance and/or overloading the act of passing a type to a term?

Does anybody know if this idea is explained better elsewhere?

<comment><USER19> That slide was a simplification of the Lambda Cube that they showed right at the end. That's probably a good starting point for better references: [http://en.wikipedia.org/wiki/Lambda_cube](http://en.wikipedia.org/wiki/Lambda_cube) ... the wiki page isn't particularly approachable, but there's more detail if you follow the links.

</comment></comment><comment><USER20> One problem with this talk (and many other talks about static typing) is that it seems to take at faith value the common claim that static typing is a net benefit for program correctness because it prevents programs from compiling that would otherwise create runtime errors (e.g., at around the 13 minute mark and again after the 18 minute mark). [1]

This seems like it's just common sense, but common sense claims do not always hold up in science and (as with many other claims regarding software engineering benefits that presumably derive from this or that language feature), it has rarely been tested.

This is not surprising: most computer science departments don't have the infrastructure to do work that involves human test subjects (unlike, say, psychology departments). Not only is there an ethics review board that has to sign off on such tests (no matter how harmless they may seem), creating meaningful tests involving non-trivial programming tasks can be pretty involved (a talk by the author of the first paper I discuss below was that one problem with the study was that it had been very expensive).

But at least some such tests have been done, and the conclusions are not necessarily what common sense would tell us.

Consider for example, the following series of papers:

Hanenberg, S. _An Experiment About Static and Dynamic Type Systems - <USER2> About the Positive Impact of Static Type Systems on Development Time._ In Proceedings of OOPSLA/SPLASH 2010. ACM, Reno 2010. [2]

From the conclusion: "In this paper we presented results of an experiment that explores the impact of static and dynamic type systems on the development of a piece of software (a parser) with 49 subjects. We measured two different points in the development: first, the development time until a minimal scanner has been implemented, and second the quality of the resulting test cases fulfilled by the parser. In non of these measured points the use of the static type system turned out to have a significant positive impact. In the first case, the use of the statically typed programming language had a significant negative impact, in the latter one, no significant difference could be measured."

Now, that is one data point that only relates to the initial development of a piece of software, too (and as we'll see in a moment, it's not as though dynamic typing is a free lunch, once we look at maintenance tasks), but it does contradict common sense: The defect rate of the statically typed software is not actually better (at least not in a statistically significant way). Earlier studies had also shown that statically typed languages (unsurprisingly) did have benefits over languages that performed neither compile-time nor runtime type checks (such as ANSI C vs. K&R C w.r.t. function arguments).

Now, a follow-up paper:

Kleinschmager, S.; Hanenberg, S.; Robbes, R.; Tanter, É. & Stefik, A. _Do static type systems improve the maintainability of software systems? An empirical study._ IEEE 20th International Conference on Program Comprehension, ICPC 2012, Passau, Germany 2012, S. 153-162. [3]

Three conclusions from this paper on the effect of static type systems on software maintenance: (1) "Static type systems help humans use a new set of classes." (2) "Static type systems make it easier for humans to fix type errors." (3) "For fixing semantic errors, [...] no differences with respect to human development times [was observed]."

The paper also references a number of other studies with related results that may be interesting.

A second follow-up paper was the following:

Spiza, S. & Hanenberg, S. _Type Names without Static Type Checking already Improve the Usability of APIs (As Long as the Type Names are Correct) - <USER3> Empirical Study._ Proceedings of the ACM Conference on Aspect-Oriented Software Development, AOSD '14, Lugano, Swizerland 2014. [4]

From the abstract: "This paper describes an experiment with 20 participants that has been performed in order to check whether developers using an unknown API already benefit (in terms of development time) from the pure syntactical representation of type names without static type checking. The result of the study is that developers do benefit from the type names in an API's source code. But already a single wrong type name has a measurable significant negative impact on the development time in comparison to APIs without type names."

What we're seeing is that while there do seem to be measurable benefits from static typing, the actual nature of these benefits may not be what one may expect on the basis of common sense alone (it's actually even more complicated than I can convey in this brief summary).

[1] To be clear, the talk makes many other immensely sensible points, and I don't think there's even enough material to conclusively say this one is right or wrong; my point is that it's essentially unproven either way, and that there is evidence that our intuition may be wrong here.

[2] [https://courses.cs.washington.edu/courses/cse590n/10au/hanen...](https://courses.cs.washington.edu/courses/cse590n/10au/hanenberg- oopsla2010.pdf)

[3] [http://pleiad.dcc.uchile.cl/papers/2012/kleinschmagerAl- icpc...](http://pleiad.dcc.uchile.cl/papers/2012/kleinschmagerAl-icpc2012.pdf)

[4] [http://dl.acm.org/citation.cfm?id=2577098](http://dl.acm.org/citation.cfm?id=2577098)

<comment><USER21> Just took a quick look at paper #2, which is quite fascinating -- to try and isolate the effects of static / dynamic typing, they developed _two_ slightly different programming languages which varied along only this axis.

I have some sympathy with this approach, but I'm not convinced you can actually separate things in this way. The type systems I actually find _useful_ are not just a static analysis layer, but have significant impacts on the semantics of the language and the way libraries are designed. I'm not sure you could just 'turn off' the type system in Haskell and have anything even remotely sensible, for example.

I sometimes wonder if there's enough mature open-source projects in the wild now to be able to draw some statistical conclusions about the long-term effects of language choice, but that would be quite a project...

<comment><USER13> > I'm not sure you could just 'turn off' the type system in Haskell and have > anything even remotely sensible, for example.

You can actually do exactly this:

[https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime](https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime)

Of course, the type system doesn't vanish but checking types is deferred until runtime, turing Haskell into a dynamic language with an unusually elaborate tag system.

<comment><USER4> It's still not comparable to a dynamic language however. Simply constructing a list [1, "Hello"] will already produce an error. Dynamic languages usually allow this, and only signal errors when the values are used in an erroneous manner, like 1 + "Hello". It does exactly what it says on the tin: it displays type errors that were _found at compile time_ with the same type system that regular Haskell uses, but the actual displaying is deferred until run time. There is no actual tag checking going on at run-time.</comment></comment></comment></comment>