Paul Graham Keynote at PyCon • Hacker News Board

Re: Paul Graham Keynote at PyCon

#101

Post by vyrotek » Sat, Mar 10, 2012, 2:37 AM UTC

dgallagher wrote: post #79

bambax wrote: post #37

> inbox is a todo list. email is the protocol for putting stuff on it I see these categories of email 1. Email from people you know that you're likely to respond to, and which therefore lead to "conversations" 2. Reminders and "things to do" that you need to act upon; once you have acted upon it you usually update the status of the task by mailing back 3. Read-only email: email sent by corporations that you somehow n…

A replacement for email probably won't look very much like email. It'll inherit the good and drop the bad. Speech ---> messenger ---> letters ---> telegraph ---> telephone ---> fax ---> email ---> ??? What's good about email? You can send it at any time. It's standardized and supported everywhere. UTF-8/UTF-16. Cheap/free. Extremely fast. Extremely easy. What's bad about email? Spam. Conversations get broken (reply i…

There are some services out there where you spend an email specific currency in order to flag the importance of the email. I can't remember exactly how you earned them, but there were things you could do to earn these credits which then you spent by attaching them to your outgoing messages.

Cash is interesting though. I can imagine how it would technically work.. but would anyone actually pay? I think it depends on what sort of 'email problem' you have. I don't imagine someone's boss would be happy to get a notification that it costs $10 to send their employee an email ;) It seems this cash thing would work only for blind introductions to popular individuals.

Re: Paul Graham Keynote at PyCon

#102

Post by ikawe » Sat, Mar 10, 2012, 4:40 AM UTC

> it would be great if a startup could make a lot of cpus look to the developer like 1 cpu. most ambitious: do it automatically with a compiler.really hard, but is this really impossible?

>if so, prove it if not, the expected value of working on it might be really high.

parallel complexity theory: https://larc.unt.edu/ian/books/free/pct.pdf

Re: Paul Graham Keynote at PyCon

#103

Post by mcartyem » Sat, Mar 10, 2012, 5:30 AM UTC

pjscott wrote: post #76

bambax wrote: post #37

> inbox is a todo list. email is the protocol for putting stuff on it I see these categories of email 1. Email from people you know that you're likely to respond to, and which therefore lead to "conversations" 2. Reminders and "things to do" that you need to act upon; once you have acted upon it you usually update the status of the task by mailing back 3. Read-only email: email sent by corporations that you somehow n…

#3 is a doozie, and we've been working on it at Greplin. I think we can break it down into some subcategories: * Notification emails that are very time-specific in their relevance. "Reminder: Coffee with Chuck at 3:25 today" or "Thank you for your reservation for a party of 4 at Alice's Restaurant at 7:30 tonight." You care about these a lot, until you have coffee with Chuck and abruptly stop caring. * Things that ar…

Has Greplin basically solved inbox being a todo list?

Re: Paul Graham Keynote at PyCon

#104

Post by humbledrone » Sat, Mar 10, 2012, 5:33 AM UTC

pedoh wrote: post #50

bambax wrote: post #37

> inbox is a todo list. email is the protocol for putting stuff on it I see these categories of email 1. Email from people you know that you're likely to respond to, and which therefore lead to "conversations" 2. Reminders and "things to do" that you need to act upon; once you have acted upon it you usually update the status of the task by mailing back 3. Read-only email: email sent by corporations that you somehow n…

Gmail offers email+foo@gmail.com, which is sent to email@gmail.com, but then you can filter on the To: field. I don't think that completely solves #3, but it's a helpful trick. Plus, then you can see how your email addresses get passed on, as long as whoever's got your email isn't clever enough to =~ s#\+.*?@#@# regex your address...

I love this feature, but unfortunately I've found that probably 30-40% of the websites that I supply with my email address will not accept it due to the "+" character. It seems like travel-related businesses are some of the worst offenders -- the vast majority of airlines and hotels seem to balk at the "+", which is frustrating, because "+travel" is one of my favorite filters.

Re: Paul Graham Keynote at PyCon

#105

Post by ramanujan » Sat, Mar 10, 2012, 5:36 AM UTC

bambax wrote: post #37

> inbox is a todo list. email is the protocol for putting stuff on it I see these categories of email 1. Email from people you know that you're likely to respond to, and which therefore lead to "conversations" 2. Reminders and "things to do" that you need to act upon; once you have acted upon it you usually update the status of the task by mailing back 3. Read-only email: email sent by corporations that you somehow n…

#2: Google does have Gmail tasks, with keyboard shortcuts for using them. But because there isn't yet a tasks API it's hard to sync with other things.

Some thoughts:

1. Whatever the new email is needs to look and feel like email at the beginning, though it can morph into something else over time. It also needs to be completely keyboard driven and entirely API controllable on the client and mail server side. GMail's API is only so-so and a moving target.

2. It should be initially marketed at power users who can define sophisticated functions on emails or groups of emails. Those with 100s of emails a day feel the most pain right now.

3. On Stackoverflow, before you can submit a new question, it is intercepted and searched against the database to determine whether it has already been answered. Similarly, you could have something that directly links email to search of a corporate database. Before you hit send, it suggests alternate things you could look at: Google Docs, github, the general web. This search would be a combination of statistical NLP and deterministic rules set up by the system administrator, and would intercept many informational or TODO type queries.

4. You might do something much more interesting with auto-responders. E.g. someone asking for a meeting could be redirected to your calendar to self-serve schedule if they are on your "ok to meet" whitelist.

5. More interestingly, you might also allow API-hooks for trusted senders and receivers. For trusted senders within your own corporate network, you might allow them to put some kind of button or hook in the email to permit more structured responses than free text. For example, they could discharge the TODO directly without having to click a link and leave email. Or in the case of the CEO below, it would be "authorize payment". You might actually be able to make this work today within GMail with suitable iframing.

6. A properly configured mutt or Emacs gnus has many interesting features that could be ported to the browser.

Re: Paul Graham Keynote at PyCon

#106

Post by Ingaz » Sat, Mar 10, 2012, 5:44 AM UTC

>6. bring back the old moore’s law

I'm not an expert in this field by any means, but I think this idea is not so "frightening".

There was rumors in 2006 that AMD tried to develop "Reverse Hyperthreading". No official notes though.

Edit: Intel Anaphase: http://newsroom.intel.com/docs/DOC-1111

http://dl.acm.org/citation.cfm?id=1555754.1555813&coll=A...

Re: Paul Graham Keynote at PyCon

#107

Post by rbanffy » Sat, Mar 10, 2012, 6:26 AM UTC

sounds wrote: post #89

rbanffy wrote: post #73

Earlier quoted context omitted.

I'm curious. How did BeOS solve this problem?

BeOS did several things, I'll throw out the obvious one: Separate the UI thread from main() (the thread doing the core app logic). Yes, many OS's suggest spinning up a worker thread, but by default an app is single-threaded. The default in BeOS is 2 threads. To the original poster, I'd like to point out that BeOS didn't (and Haiku doesn't) use a different compiler. What pg was saying was that we need a better compile…

> Yes, many OS's suggest spinning up a worker thread, but by default an app is single-threaded. The default in BeOS is 2 threads.

It's an interesting idea. It would be trivial to write boilerplate like this so that when you create a new .c file, it will start with a basic multi-threaded application.

I remember seeing some parallel FORTRAN code in the late 80's with things like loops explicitly marked for parallel execution and other tricks. The downside is that debugging mutable state across multiple threads is a bitch. It's not something I would wish to my worst enemy.

> Look at Verilog/VHDL for an example of a fully parallelized language.

I have been playing with the idea of using Verilog or VHDL to express computer programs... Did nothing, but it would be an interesting thing to test.

Re: Paul Graham Keynote at PyCon

#108

Post by allenbrunson » Sat, Mar 10, 2012, 6:58 AM UTC

lr wrote: post #63

6. bring back the old moore’s law I'll have to dig up my BeOS Bible this weekend, but I though the BeOS solved this problem over 15 years ago. I have been floored for years that chip makers keep telling developers to write code to work with multiple CPUs. If those developers are OS developers, then fine. But application developers? No way. This is the job of the OS!

I actually worked at Be. BeOS did a lot to make multi-threading more accessible, but it certainly did not "solve the problem!" BeOS app programmers still had to pay a whole lot of attention to threading issues, same as now.

Re: Paul Graham Keynote at PyCon

#109

Post by indspenceable » Sat, Mar 10, 2012, 8:05 AM UTC

sidww2 wrote: post #53

pnathan wrote: post #40

Earlier quoted context omitted.

> In fact, the technical people I've met on average have been smarter than liberal arts people. That's a standard technical person bias. I'm betting that its not true on average, that a good philosopher, businessperson, or history student is equally smart, but it's not as discernible due to the falsifiable nature of technical work.

> That's a standard technical person bias. First of all - I wouldn't count being a businessperson as liberal arts. One way you can look at it is how many people drop out of technical subjects because they find them too hard to move to humanities and liberal arts vs. the opposite. Anecdotally, for me the former number has been much larger. The latter number has been 0. Similarly, I've had many technical friends who to…

To me, this sounds very anecdotal; it doesn't match up with my experience (also anecdotal).

Remember, not all courses are made equal. I went to a tech school, and transferred after my first year to a high tier liberal arts school. I had a much harder time with a 050 level into liberal arts course my second year, than I did with a 400 level course on Poetry (of which I didn't have any sort of background in). I found the liberal arts courses at the tech school were aimed towards tech students - meaning, in that specific case, many of them felt somewhat watered down.

I would be willing to guess that, as a frequenter of Hacker News, you're more likely to be more active in a tech oriented circle. Growing up, and at college, I was more active among humanities oriented folk; my experience was that the tech folk were good at one thing (whatever they studied) and otherwise just played lots of video games, while the humanities students did every thing + 1.

So, all in all - my point is that anecdotal evidence is just that. Technical people can have a broad understanding, but it doesn't mean they do. Same goes for Liberal Arts.

Re: Paul Graham Keynote at PyCon

#110

Post by bambax » Sat, Mar 10, 2012, 8:11 AM UTC

pjscott wrote: post #76

bambax wrote: post #37

> inbox is a todo list. email is the protocol for putting stuff on it I see these categories of email 1. Email from people you know that you're likely to respond to, and which therefore lead to "conversations" 2. Reminders and "things to do" that you need to act upon; once you have acted upon it you usually update the status of the task by mailing back 3. Read-only email: email sent by corporations that you somehow n…

#3 is a doozie, and we've been working on it at Greplin. I think we can break it down into some subcategories: * Notification emails that are very time-specific in their relevance. "Reminder: Coffee with Chuck at 3:25 today" or "Thank you for your reservation for a party of 4 at Alice's Restaurant at 7:30 tonight." You care about these a lot, until you have coffee with Chuck and abruptly stop caring. * Things that ar…

For me, "coffee with Chuck" is #2 rather than #3 and yes, I want it in my inbox (maybe simply stay there until it happens, then archive it automatically).

Your other examples are clearly #3... and I don't need to read any of those emails.

Amazon confirmation emails are completely useless since Amazon always ships on time; in the exceptional case where a package doesn't arrive, I can go fetch the tracking number somewhere to investigate; but reading these for every package is a waste of time.

Mailing lists should go to a special folder labelled "things to read on a rainy day".

And finally "crap" is spam, no?

- - -

What about a service that would let you give a special email address for Amazon confirmation emails, for example, that would receive these emails and index and categorize them. When a package doesn't arrive you go there to look for the tracking number, but only then.

Of course you can do that with tags in Gmail.

What you can't do in Gmail is to generate a single PDF of all proforma received from a given provider, for example.