4 ms·

The future of computing

30 points by dgsiegel 13y ago

girvo 13y ago
I want to see image-based development (think Smalltalk, for example) that scales to large teams. Datomic-style time shifting of your code, a DVCS built directly into the environment basically, that allows for rapid experimentation, but that will work cross-user and cross-team -- we may have it as one large project, but I want to work locally and somehow merge with master, despite eschewing pure text/files. A pipe dream, yeah, but one I continue to tinker with :)
phaemon 13y ago
If you don't use capital letters at the start of sentences, it makes it much more difficult to read. People who read a lot, tend to read whole sentences at a time, so clearly marking the beginning and end of a sentence is important. I didn't bother reading through what you had to say simply because I'm a little tired and you deliberately made it more difficult for me.
- igvadaimon 13y ago
  the same happened to me.
- pflanze 13y ago
  You could save the page, paste the following into a file and run "perl file savedpage.html > fixedpage.html" and open that instead. I'm sure a Javascript programmer would come up with some better solution instead?... local $/; $_= <>; s/<(.*?)>/$id++; $t{$id}=$1; "<$id>"/sge; s/([.?!][^\w].*?)([a-zA-Z])/$1.uc($2)/sge; s/<(.*?)>/"<$t{$1}>"/sge; s/(<[pP]\b[^>]*>\s*)([a-z])/$1.uc($2)/sge; print; Edit: changed \. to [.?!] in line 4.
csmuk 13y ago
As my computer science lecturer once said to me: "there's nothing wrong with computers; humans on the other hand..." I think the future of computing is the same as the past, hopefully without as many mind-numbingly deep abstractions. I'd settle for that.
RyanZAG 13y ago
> by thinking how we can make the power computing technologies give us available to everyone. the rest will follow automatically. But that's exactly what we are doing. What do you think iPhones and iPads are? Those startups that are making it easier to book holidays? The very thing they are doing is making technology available to everyone. We've been doing all of this the whole time with the very goal of making technology available to people by creating ready made interfaces and tools that others can use. There seems to be the idea that it's possible to leapfrog all of this hard, technical stuff and let everyone do it. Obviously that's not going to happen because those little technical bits are the difficult parts that need actual intelligence to overcome. You can't sandpaper them away.
- dgsiegel 13y ago
  > But that's exactly what we are doing. What do you think iPhones and iPads are? Those startups that are making it easier to book holidays? The very thing they are doing is making technology available to everyone. so, yes, they make technology available to everyone. but in my opinion the problem is something else: we still think in representations invented for the medium of paper. we still code in text files, we still read pdfs/ebooks page by page, and your mom still can't send you that thing over the internet. with all these beautiful devices we have, it kinda makes me sad to see what potential we are missing out. you may have heard of this beautiful research project "sketchpad" by ivan sutherland (http://en.wikipedia.org/wiki/Sketchpad http://en.wikipedia.org/wiki/Sketchpad), which plays with direct manipulation of data. they even managed to plan a bridge with it. not that i am saying everyone should be able to build bridges, but you see where this is going. i very much recommend to watch both talks by bret victor: the future of programming - http://worrydream.com/dbx/ http://worrydream.com/dbx/ media for thinking the unthinkable - http://worrydream.com/MediaForThinkingTheUnthinkable/ http://worrydream.com/MediaForThinkingTheUnthinkable/ > There seems to be the idea that it's possible to leapfrog all of this hard, technical stuff and let everyone do it no, of course not. we always build on the shoulder of giants. but i hope you agree that we can do better than what we are currently doing. ryan, thanks for your comment.
- nightski 13y ago
  I'd argue they are not making technology available to everyone. Rather they are making cheap appliances. Single experience apps designed for a specific purpose with limited flexibility. It is like having a toaster and a blender. Oh you want to grind coffee? Well buy a coffee grinder! Instead of making general purpose tools accessible, we are providing accessible single purpose tools. There is a very large difference.
transfire 13y ago
Reminds of a time when my boss wanted to print out some forms that were essentially just a bunch of columns and rows with a date at the top of the page. He wanted one page for each day of the year. And for all my programming knowledge (30 or so years) this problem turned out to a pain in the ass. I imagine if I were an expert in back-end scripting MS Word, then maybe it would have been easy, but how many of those experts do you know? I don't think I've met a one. It seems like such an easy problem, the lay person would think it could be done in minutes --a few hours at most. After two days of trying to write a Ruby script using (at the time new and unfortunately buggy) Prawn postscript generator, my boss told me to stop wasting time and get back to work.
secstate 13y ago
Makes me want to go work on Self: http://selflanguage.org/ http://selflanguage.org/ Also, flow based programming is just Self without an image environment like some Smalltalk dialects. Or am I missing something?
ericHosick 13y ago
> I do think that it would be kind of a shame if in forty years we're still coding in procedures... I agree with this. Software frameworks have improved but are still unnecessarily complex. As we build out a solid body of knowledge in software engineering, we will end up with frameworks that are much easier to use than what we have today. In my opinion, such frameworks would support the composition of software, hooking up behavior, as opposed to the "coding" of software (calling procedures). Most likely this composition would take place in some kind of visual development environment though it could still be "coded".
- darkmighty 13y ago
  Let's not forget the principles though. Programming isn't magic; you still have to at least specify the intended behavior, even if without specifying the how. You could even specify approximately (or incompletely) the intended behavior of your system (and let another hypothetical system fill in the gaps), but that's not viable for every application in the future due to reliability. In the end this can't lead to something much different than saying "Sort this list" -- isn't that simply calling a sorting procedure?
- lowmagnet 13y ago
  I don't care if we're coding in procedures in the future, so long as the results are no longer stored in plain text files. The transparency is fine, but tools have to re-parse every time, and an AST allows tools to reason about the structure of the code.
  - ericHosick 13y ago
    > I don't care if we're coding in procedures in the future In my opinion, the procedure/sub-routine/method/function, and specifically these things with parameters, as an abstract concept is the reason why software engineering isn't maturing. Procedures are difficult to use. You have to prepare to call them by obtaining all the information they require to be used (what you push into them via parameters), do something with the results and deal with any un-intended outcomes of using the procedure. Procedures lead to specialization. In the world today, there are probably millions of procedures with unique signatures. Each time we create a new signature, we complicate the process by which our software framework(s) communicate. Specialization, in this case, is not good. It's makes using the frameworks more difficult. Also, the procedural signature of any given behavior will be different based on the programmer who writes it and, even more so, the framework for which it is written. There is no way to easily assure, across the industry or even within a small group, that the signature of any given behavior will be the same.
vezzy-fnord 13y ago
Basically, the future of programming is Smalltalk. At least, the way you envision it.
AndrewKemendo 13y ago
Seems like the author wants to make programming as simple as building something with Legos. As someone who struggles with software development I would love this. The problem however is that there is a translation problem between me and my computer. It doesn't understand what is in my head and I don't understand how to make it do what is in my head. So we have come up with lots of different ways to do that, with tradeoffs between rigor and usability. The problem of translation of ideas really crosses all boundaries, machine/human, human/human, human/animal etc... so if you could figure out a way to do that translation (specifically human/machine) that has basically no learning curve the world would beat a path.

30 points by dgsiegel 13y ago

girvo 13y ago

I want to see image-based development (think Smalltalk, for example) that scales to large teams. Datomic-style time shifting of your code, a DVCS built directly into the environment basically, that allows for rapid experimentation, but that will work cross-user and cross-team -- we may have it as one large project, but I want to work locally and somehow merge with master, despite eschewing pure text/files. A pipe dream, yeah, but one I continue to tinker with :)

phaemon 13y ago

If you don't use capital letters at the start of sentences, it makes it much more difficult to read. People who read a lot, tend to read whole sentences at a time, so clearly marking the beginning and end of a sentence is important. I didn't bother reading through what you had to say simply because I'm a little tired and you deliberately made it more difficult for me.

igvadaimon 13y ago
the same happened to me.
pflanze 13y ago
You could save the page, paste the following into a file and run "perl file savedpage.html > fixedpage.html" and open that instead. I'm sure a Javascript programmer would come up with some better solution instead?... local $/; $_= <>; s/<(.*?)>/$id++; $t{$id}=$1; "<$id>"/sge; s/([.?!][^\w].*?)([a-zA-Z])/$1.uc($2)/sge; s/<(.*?)>/"<$t{$1}>"/sge; s/(<[pP]\b[^>]*>\s*)([a-z])/$1.uc($2)/sge; print; Edit: changed \. to [.?!] in line 4.

csmuk 13y ago

As my computer science lecturer once said to me: "there's nothing wrong with computers; humans on the other hand..." I think the future of computing is the same as the past, hopefully without as many mind-numbingly deep abstractions. I'd settle for that.

RyanZAG 13y ago

> by thinking how we can make the power computing technologies give us available to everyone. the rest will follow automatically. But that's exactly what we are doing. What do you think iPhones and iPads are? Those startups that are making it easier to book holidays? The very thing they are doing is making technology available to everyone. We've been doing all of this the whole time with the very goal of making technology available to people by creating ready made interfaces and tools that others can use. There seems to be the idea that it's possible to leapfrog all of this hard, technical stuff and let everyone do it. Obviously that's not going to happen because those little technical bits are the difficult parts that need actual intelligence to overcome. You can't sandpaper them away.

dgsiegel 13y ago
> But that's exactly what we are doing. What do you think iPhones and iPads are? Those startups that are making it easier to book holidays? The very thing they are doing is making technology available to everyone. so, yes, they make technology available to everyone. but in my opinion the problem is something else: we still think in representations invented for the medium of paper. we still code in text files, we still read pdfs/ebooks page by page, and your mom still can't send you that thing over the internet. with all these beautiful devices we have, it kinda makes me sad to see what potential we are missing out. you may have heard of this beautiful research project "sketchpad" by ivan sutherland (http://en.wikipedia.org/wiki/Sketchpad http://en.wikipedia.org/wiki/Sketchpad), which plays with direct manipulation of data. they even managed to plan a bridge with it. not that i am saying everyone should be able to build bridges, but you see where this is going. i very much recommend to watch both talks by bret victor: the future of programming - http://worrydream.com/dbx/ http://worrydream.com/dbx/ media for thinking the unthinkable - http://worrydream.com/MediaForThinkingTheUnthinkable/ http://worrydream.com/MediaForThinkingTheUnthinkable/ > There seems to be the idea that it's possible to leapfrog all of this hard, technical stuff and let everyone do it no, of course not. we always build on the shoulder of giants. but i hope you agree that we can do better than what we are currently doing. ryan, thanks for your comment.
nightski 13y ago
I'd argue they are not making technology available to everyone. Rather they are making cheap appliances. Single experience apps designed for a specific purpose with limited flexibility. It is like having a toaster and a blender. Oh you want to grind coffee? Well buy a coffee grinder! Instead of making general purpose tools accessible, we are providing accessible single purpose tools. There is a very large difference.

transfire 13y ago

Reminds of a time when my boss wanted to print out some forms that were essentially just a bunch of columns and rows with a date at the top of the page. He wanted one page for each day of the year. And for all my programming knowledge (30 or so years) this problem turned out to a pain in the ass. I imagine if I were an expert in back-end scripting MS Word, then maybe it would have been easy, but how many of those experts do you know? I don't think I've met a one. It seems like such an easy problem, the lay person would think it could be done in minutes --a few hours at most. After two days of trying to write a Ruby script using (at the time new and unfortunately buggy) Prawn postscript generator, my boss told me to stop wasting time and get back to work.

secstate 13y ago

Makes me want to go work on Self: http://selflanguage.org/ http://selflanguage.org/ Also, flow based programming is just Self without an image environment like some Smalltalk dialects. Or am I missing something?

ericHosick 13y ago

> I do think that it would be kind of a shame if in forty years we're still coding in procedures... I agree with this. Software frameworks have improved but are still unnecessarily complex. As we build out a solid body of knowledge in software engineering, we will end up with frameworks that are much easier to use than what we have today. In my opinion, such frameworks would support the composition of software, hooking up behavior, as opposed to the "coding" of software (calling procedures). Most likely this composition would take place in some kind of visual development environment though it could still be "coded".

darkmighty 13y ago
Let's not forget the principles though. Programming isn't magic; you still have to at least specify the intended behavior, even if without specifying the how. You could even specify approximately (or incompletely) the intended behavior of your system (and let another hypothetical system fill in the gaps), but that's not viable for every application in the future due to reliability. In the end this can't lead to something much different than saying "Sort this list" -- isn't that simply calling a sorting procedure?
lowmagnet 13y ago
I don't care if we're coding in procedures in the future, so long as the results are no longer stored in plain text files. The transparency is fine, but tools have to re-parse every time, and an AST allows tools to reason about the structure of the code.
- ericHosick 13y ago
  > I don't care if we're coding in procedures in the future In my opinion, the procedure/sub-routine/method/function, and specifically these things with parameters, as an abstract concept is the reason why software engineering isn't maturing. Procedures are difficult to use. You have to prepare to call them by obtaining all the information they require to be used (what you push into them via parameters), do something with the results and deal with any un-intended outcomes of using the procedure. Procedures lead to specialization. In the world today, there are probably millions of procedures with unique signatures. Each time we create a new signature, we complicate the process by which our software framework(s) communicate. Specialization, in this case, is not good. It's makes using the frameworks more difficult. Also, the procedural signature of any given behavior will be different based on the programmer who writes it and, even more so, the framework for which it is written. There is no way to easily assure, across the industry or even within a small group, that the signature of any given behavior will be the same.

vezzy-fnord 13y ago

Basically, the future of programming is Smalltalk. At least, the way you envision it.

AndrewKemendo 13y ago

Seems like the author wants to make programming as simple as building something with Legos. As someone who struggles with software development I would love this. The problem however is that there is a translation problem between me and my computer. It doesn't understand what is in my head and I don't understand how to make it do what is in my head. So we have come up with lots of different ways to do that, with tradeoffs between rigor and usability. The problem of translation of ideas really crosses all boundaries, machine/human, human/human, human/animal etc... so if you could figure out a way to do that translation (specifically human/machine) that has basically no learning curve the world would beat a path.