Live data from Hacker News

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

gotw.ca

21–25 of 25 posts

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

#21
post #18
post #3

"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 e…

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.

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

#22
post #15

Earlier quoted context omitted.

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?

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

#23
post #21
post #18

Earlier quoted context omitted.

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.

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

#24
post #18
post #3

"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 e…

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.

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

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

#25
post #21
post #18

Earlier quoted context omitted.

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.

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

Post reply on HN