Interview with Dennis Ritchie, Bjarne Stroustrup, and James Gosling (2000) | Hacker News Reader

Interview with Dennis Ritchie, Bjarne Stroustrup, and James Gosling (2000)

gotw.ca

56 pointsingve22 comments

"It just feels like there's so much territory out there that's beyond the bounds of ASCII text that's just line after line, roughly 80 characters wide, mostly 7-bit ASCII, something that you could type in on a teletype. That's still where programming basically is these days, and it's proven to be a very hard thing to get anything beyond that."

Few things in programming are as stupefying and obvious as to why we all essentially still use glorified text editors to do "high-end" programming. I wonder if in a 100 years programmers will still be editing text. I'd like to think there's a paradigm shift out there but no one's found it yet.

Paradigm shift will occur, when we will deploy neuromechanisms allowing to directly interact with the brain. Pictures are more natural representation for our mind, so we probably will live in some super-unicode environment. No need to stick with ASCII, no need to encode "while" operator with those 5 latin letters, just some fun picture and that's all. Or may be block schemas will live again or modified block schemas. They are difficult to use with current input methods. Even with mouse it takes a lot of time to scroll and zoom big picture. And with neurointerface, when computer will show you exactly what you want in exactly millisecond you though about it, block schemas might be just perfect representation for imperative programming language. Classes might be represented in some kind of UML diagram or another similar approach.

That would be really fun time to program.

The futurist in me thinks the following: in a 100 years programs will program themselves. We'll just need a reliable way to tell them what to program.

Great news, The Future is here already! These reliable methods for telling computers what to compute are known as Programming Languages.

The closest paradigm to what I was trying to imply are more general purpose declarative languages. Something like sql or rich logic libraries that let the developer describe the desired result rather than the 'how.' Now advance this by 100 years, and I would hope anyone can program arbitrarily complex things by using graphical/natural-language tools to specify constraints, and then the 'program' arbitrarily generates the lower-level code.

So the future is Prolog?

It may be from the early 1970s, but compared to the mainstream programming languages of today, it still look pretty futuristic to me.

Aren't most things from the 70s? Did we get any serious new language tech since then? Tooling got nicer, runtimes faster - but the language breakthroughs?

I think you're sort of on to something with how the change will come when we have a true major paradigm shift in programmimg. We're not anywhere near that though.

Text and programming languages: It ain't pretty but it isn't broken so don't fix it.

How does this work if 2 or more people are working on the same program? I then have to understand what other people's pictures mean, so then not much has changed: you still have to learn the meaning of symbols, but those symbols are pictures rather than words.

In terms of representing structure with pictures, there is a further weakness in that many problems can't be neatly represented in a diagram because they have more than 3 dimensions to them.

I think you basic point still stands though: I'm sure we could be more effective about how we navigate around code and express ourselves to the computer.

7000 years later and we're still communicating with glorified cuneiform. Maybe the reason we're using text for programming is because text is a really, really, good way of communicating abstract thought?

I think it's great for people to experiment with different ways of expressing programs. But I don't think the fact that programming is mostly text-based is necessarily a cause for disappointment, and my guess is that any future form of programming will look more like augmented or improved text, rather than something completely different to today's programming.

The frustration, I think, is the feeling that a very powerful turing machine is being limited by 7000 years of biological and cultural idiosyncrasies.

But there is no better alternative. If there were, maybe we wouldn't use language to talk and give instructions to each other either.

Not many other programmers are looking, though: most are happy with C, C++, and Java.

I'm looking, however, and I think I'm on the right track. I'll need time. I'll believe I've succeeded when Lisp is no longer my favourite language.

The problem is with the input methods. With a standard keyboard and mouse, it's tedious to enter unicode characters or create other graphical-style representations.

All ASCII characters are easily accessible. Your suggestion is a strawman, most coding is in plain text form and is typed.

I did a quick calculation a while back. I don't want to repeat it, since I lost the source, but the conclusion was that typing speed doesn't matter for programmers, since most of the time they actually think, not type. I.e. the bottleneck is information no the input of it.

While that's true, verbose languages and crappy editors still add a tedium and frustration to programming. Perhaps it isn't deserved, and we should be fine even typing in double the amount of code, but it still feels bad. (Except for the people that love verbosity and boilerplate as it makes them feel like they're doing serious business.)

Also reading is important, and having concise, short code is a boon to understanding code. In most cases, every extra non-comment character is just a place for bugs or misunderstandings to hide.

Unless I've misunderstood you, I'm not sure that's a strawman argument. I'm not arguing against the original point! I'd like to have better representations than just plain text. The fact that our current input methods are holding us back is more a fact, rather than an argument against trying to fix the situation.

It's the friction of entering those other representations that's the problem.

The use of an interface drops off in greater proportion to the difficulty of using it - Nev's law

(IE, if a user interface is twice as difficult to use (takes twice as long to do things or takes twice as many steps for example), then it will be used by much less than half as many people.)

The editor can just replace characters as typed, e.g. render a / as ÷.

I've implemented a whole rich code editor/language around that, here is an old essay about it:

http://research.microsoft.com/en-us/projects/liveprogramming...

And a more recent version of the system:

http://research.microsoft.com/en-us/um/people/smcdirm/apx/in...

> Stroustrup: Without supporting libraries, most serous applications are unnecessarily hard in C++.

Indeed.

I also wish C++ had a large Standard library. Including <vector>, just works, you don't even have to think about it. Now imagine doing the same for <sound> or <window>.

They have that. It's called Java.

Reply on news.ycombinator.com