| >> inbox is a todo list.
>No, it isn't. It's a method of asynchronous communication and file transfer. If you're using it as a TODO list, you're doing it wrong. I don't think pg is asking for help with his email - for MANY people it IS a todo list. He's outlining opportunities for future startups - email IS an opportunity precisely because people are "doing it wrong" - you snarking like you disagree with him but it seems like you actually agree. He's saying there needs to be a better todo list system for EVERYONE email can still fill the role of asycn comms and file transfer. >>gmail is slow
>it isnt slow for me Maybe I'm wrong but I assumed he was meaning this to be it takes a lot of time not it has poor performance - again seems like your are just trying to negative. >> 5. a new apple >Apple is still on top of the consumer market. Solve problems that need solving in the way you feel is best. Don't work hard to be something else. Apple didn't. He's talking long term - he's talking about apple when they were in a garage - he's not saying they are dead - he's saying with Jobs no longer at the helm there is less likely to be next generation vision - so again there is an OPPORTUNITY - someone will be the next visionary - maybe it could be you. >> 6. bring back the old moore’s law
>>...it would be great if a startup could make a lot of cpus look to the developer like 1 cpu. >As an analogy, why don't we make Ruby look like 8086 programming? Parallel computing is different- you can't solve problems with the same mentality. I don't understand your logic here. PG is talking about abstracting the problem away from the developer - you think the future of CS is that we will no longer make things abstract?! I think PG mentions it because it would be HUGE if this could be done - it certainly is difficult - he's not advocating any kind of mentality - he's just saying there's an opportunity here. |
I interpreted him as implying that writing code for parallel processing should happen in such a way that we don't have to think of it. But that is the whole problem. Developers are ignoring the complexity and opportunity that exists in understanding parallel computing. Development languages should evolve to embrace the opportunity that exists within understanding what is going on, not hide it. We didn't keep programming in BASIC since we were kids as our primary language, nor did we continue to use assembly. Things evolve, and, as developers, our thinking needs to evolve to support multiple CPUs and parallel computing; we don't need someone's help to wash over the fact that things have gotten more complex. We need to understand that complexity before attempting to abstract it.