The future of computing | Hacker News Reader

The future of computing

dgsiegel.net

30 pointsdgsiegel16 comments

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.

the same happened to me.

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.

> 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.

> 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), 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/ media for thinking the unthinkable - 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.

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.

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.

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 :)

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.

> 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".

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?

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.

> 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.

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.

Makes me want to go work on Self:

http://selflanguage.org/

Also, flow based programming is just Self without an image environment like some Smalltalk dialects. Or am I missing something?

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

Reply on news.ycombinator.com