Hacker News Reader

Comment by kens | Hacker News Reader

I alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere.

On the positive side, things that were cutting-edge hard problems in the 80s are now homework assignments or fun side projects. For instance, write a ray tracer, a spreadsheet, Tetris, or an interactive GUI.

On the negative side, there seems to be a huge amount of stagnation in programming languages and environments. People are still typing the same Unix commands into 25x80 terminal windows. People are still using vi to edit programs as sequential lines of text in files using languages from the 80s (C++) or 90s (Java). If you look at programming the Eniac with patch cords, we're obviously a huge leap beyond that. But if you look at programming in Fortran, what we do now isn't much more advanced. You'd think that given the insane increases in hardware performance from Moore's law, that programming should be a lot more advanced.

Thinking of Paul Graham's essay "What you can't say", if someone came from the future I expect they would find our current programming practices ridiculous. That essay focuses on things people don't say because of conformity and moral forces. But I think just as big an issue is things people don't say because they literally can't say them - the vocabulary and ideas don't exist. That's my problem - I can see something is very wrong with programming, but I don't know how to explain it.

View on HN

I tend to think of it as evolution: new ideas that succeed and improve performance multiply, new ideas that fail disappear, and old ideas that are still efficient live on.

People still typing the same Unix commands into terminals do it because it's still the most efficient way to accomplish those things. Maybe it's always going to be the optimal solution for some tasks.

Just because an idea is old, doesn't mean it's bad or wrong.

Text as code, for instance, is just an extension of a concept which has been around in one form or another since the scribes of ancient Babylon, or thereabouts. I can imagine more complex ways of representing code but I can't really imagine anything more efficient for translating human concepts into machine language. Except maybe direct, augmented telepathy, but even then people would probably think to the computer in glyphs and symbols. Complexity doesn't always correlate with advancement.

The problem with code as text is not the visual representation but the manipulation. From the point of view of tooling for live-coding, it's incredibly painful to deal with an unstructured pile of text that at any given point may be in an invalid state (ie partially edited). Structured editing (http://en.wikipedia.org/wiki/Structure_editor) allows the tooling to deal with consistent, structured data whilst still taking advantage of the expressive power of language.

Fair enough.

It's actually not that hard to deal with text, even in partially edited states. It's just most people don't know how to build a decent incremental parser with fairly good error recovery, but some of us do.

But the hard part isn't dealing with invalid parses and error recovery. The hard part is dealing with completely valid bits of code that aren't yet finished:

    (doseq [x (range|cursor|)]
      )

You can wait until the end of time, but that won't finish ;) Whereas I probably wanted to get out (range 10) before it went off and looped forever.

Text also doesn't provide you with stable IDs. If I previously had function "foo" in a file and now that's gone, but there's a function "bar" in the same place with roughly the same code, does that mean it was renamed? Or did foo get deleted and we need to surface that anything using foo is an error? How would you know? The only thing you have to go on is position and position can change for all sorts of other reasons. I ran into this problem with trying to do functions in single editors: when the file can change in any way, reconciling that file with your previous view of the world is tremendously difficult.

I don't have a problem with this. If you accidentally encode an infinite loop, you just break it on the next code change. You can memoize your token stream in an incremental lexer to use tokens as stable IDs: you use the same symbol for bar as you did for foo because the token/tree start position never changed; only the contents of the existing token happened to changed! This is what I do in YinYang, and it works well. Of course, to get here, you have to be incremental 100% and not use existing batch tools (or adapt them first to be incremental).

I'd be happy to share these techniques sometime.

I'd enjoy reading.

Ok, I'll make an effort to really write this up sometime, maybe as an SLE paper.

Please do even if only as an informal blog post or something. :)

I agree that the problem is not error recovery, but is more generaly described by Peter Naur's "Programming as Theory Building"[1]. With that, programming is hard because creating a theory, collectively, and teaching other people about it, is hard. Making it easier is therefore solving the problem Douglas Engelbart envisioned solving: Augmenting the Human Intellect

[1] http://catenary.wordpress.com/2011/04/19/naurs-programming-a...

I apologize for the fanboy post in advance, but Peter Naur was such a badass.

Any chance you could point me at some resources on incremental parsing? It's something I've been interested in for a while.

I wrote a workshop paper last year, but it wasn't very deep. Actually, incremental parsing, at least the way I do, doesn't really involve any special algorithms, here are the three points:

* making your lexer incremental first, memoize tokens between edits so you have something to attach trees to that will still be there after the next edit!

* Match braces (or determine indented blocks) separately before you even bother parsing. This makes incremental parsing more robust, and it is really easy to do without parsing information (unless your language overloads brace lexemes, like Java generics do! Scala didn't have this problem however). Also, autocomplete braces even if your users really hate that, because otherwise you won't have anything nice to reason about 99% of the time (indented languages are really better here for obvious reasons). Tell them to just use emacs if they don't like it.

* The last thing to do is just memoize parse trees (by attaching them to your memoized tokens) and then replay parsing on trees whenever their parses could have changed. So if their is an edit, invalidate the inner most tree, or multiple trees if the edit occurs at a boundary. If a child tree parse changes, invalidate its parents. Log your symbol table additions so you can undo them when they are no longer done on a parse (or the parse tree is deleted); trace your symbol table references if the symbol binding for the name being looked up changes, and don't worry about type checking in a separate pass, because you can just replay the parse multiple times if necessary.

The last point is quite fascinating and something I'm working on right now to turn into a more general programming paradigm. Check out:

http://research.microsoft.com/apps/pubs/default.aspx?id=2112...

Yeah, all those Structure-Editors and Node-Editors and Meta-Node-Editors and all those years and still more and more simple text-editors keep winning. My personal impression is that developers are actually moving away from those uber-tools, IDEs even and move toward vim plus shell tooling...

I once had the pleasure of asking Marvin Minsky if he thought we'd ever use something other than text to create computer programs. Without missing a beat he said, "If it's good enough for Plato and Aristotle, it's good enough for me."

Whoa now, if it's evolution, what's the fitness function? It's not fully endogenous. It's market-driven. Network effects & cooperation mean plan9 just ain't gonna see much screen time anymore.

The main problem is that Bell Labs had more success making their research mainstream than Xerox PARC did.

So here we are in 2014, with all that nice GUI live development environments (Interlisp, Smalltalk, Mesa/Cedar) lost to people that prefer a UNIX System V clone.

That doesn't sound convincing. The Xerox PARC GUI is everywhere. The results of their work are about as mainstream as they could possibly be.

Likewise, Smalltalk and Mesa were both hugely influential in everything from C, C++, Java and beyond.

Given that, it seems more likely that graphical development hasn't taken off because it isn't good enough yet. All developers have prejudices, but they typically have to yield to superior methodologies.

> The Xerox PARC GUI is everywhere

Quoting Alan Kay

<quote> Now, the abortion that happened after PARC was the misunderstanding of the user interface that we did for children, which was the overlapping window interface which we made as naive as absolutely we possibly could to the point of not having any workflow ideas in it, and that was taken over uncritically out into the outside world. </quote>

> Given that, it seems more likely that graphical development hasn't taken off because it isn't good enough yet. All developers have prejudices, but they typically have to yield to superior methodologies.

The only existing mainstream environment that can replicate some of the live coding experience of the said systems is Mathematica.

That is why for old guys like myself it is so interesting to see all the live coding discussions that happen on HN, from people that never used those systems or at least saw them being used.

> <quote> Now, the abortion that happened after PARC was the misunderstanding of the user interface that we did for children, which was the overlapping window interface which we made as naive as absolutely we possibly could to the point of not having any workflow ideas in it, and that was taken over uncritically out into the outside world. </quote>

And then tiling window managers were invented, and users rejoiced.

Mathematica may have pioneered the notebook[X], but there are imitations[1] which are arguably just as good (or better given the seeming ad-hoc nature of the Mathematica language).

[X] I don't presume to know -- it's just the first system I came into contact with which has this concept.

[1] http://ipython.org/

(edit: apparently there's some magic markup I don't yet understand.)

> I don't presume to know -- it's just the first system I came into contact with which has this concept.

It was already present on the Xerox PARC systems.

You can see a little bit of it here about Symbiotics, http://www.loper-os.org/?p=932 at minute at minute 30.

Or here for Smalltalk-80, https://www.youtube.com/watch?v=JLPiMl8XUKU

> Now, the abortion that happened after PARC was the misunderstanding of the user interface that we did for children, which was the overlapping window interface which we made as naive as absolutely we possibly could to the point of not having any workflow ideas in it, and that was taken over uncritically out into the outside world.

He also goes on to praise NLS, which failed precisely because of its steep learning curve and unsuitability for large swaths of the personal computing market.

Incidentally, that's why a GUI with overlapping windows succeeded : because it was familiar, intuitive and simple.

IMO, it's rather telling that none of the major DE's or WM's involve automatic tiling. This, despite the fact that there are a myriad of solutions available [1]. It's not about "better" or "worse", but suitability for a given market.

[1] If anyone's interested, I highly recommend i3. As powerful as xmonad with a fraction of the configuration hassle.

That's pretty much the thesis of Bret Victor's "The Future of Programming" talk. It's here, for all who have missed it: http://worrydream.com/dbx/

Good talk.

I had all this stuff in the first chapter(the history) of my HCI-course at University. So, luckily, the younger programmers learn about stuff that already has been there, back in the days.

But I was baffled by what bad stuff must have happened to the world, that we ended up where we are now and not where we should have been.

> But I was baffled by what bad stuff must have happened to the world, that we ended up where we are now and not where we should have been.

UNIX spread into the enterprise world.

What is so bad ab out Unix and what would be an alternative?

A world of command line interfaces and TTY text editors, instead of the powerful interactive GUI world Xerox PARC systems had.

The shell is worlds more powerful than the GUI (or CUI), because things in the shell trivially compose.

Except Xerox PARC systems also had a shell in the form of REPL and live coding.

The UNIX shell is quite primitive by comparison.

That's all stuff we have now.

"The UNIX shell is quite primitive by comparison."

I don't believe that's still the case (and hasn't been for some while). If you believe it is, rather than just making assertions please explain what you think is missing from bash in screen in urxvt.

- bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems

- bash is not a REPL with support for live coding.

- as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures

Writing data to /proc to alter the OS behavior, is pretty basic compared with changing OS behaviour with a "doit" message on a expression block.

EDIT: For better understanding, imagine using something like Mathematica as an OS shell.

You're being argumentative instead of informative or useful.

"bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems"

Bash is one example of a modern UNIX shell. It is not the only example - there are some that are more advanced in some ways, and some that are less advanced in some ways. I wasn't saying "BASH IS ALL UNIX", I was picking a specific setup as a point of comparison.

"bash is not a REPL with support for live coding."

What are attributes of a REPL which you see bash as lacking? Clearly, it Reads, Evaluates, and Prints. If you just object to the particular language, fine, there are certainly things to object to there - though I think it's pretty great as UI. It's certainly atrocious when you try building anything large out of it.

"as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures"

That's mostly false, which you touch on immediately following.

'Writing data to /proc to alter the OS behavior, is pretty basic'

It can get arbitrarily sophisticated, but...

'compared with changing OS behaviour with a "doit" message on a expression block.'

I don't know what this means, please elaborate.

"For better understanding, imagine using something like Mathematica as an OS shell."

There's too many things that can mean for it to aid my understanding much. Do you mostly refer to the ability to embed graphics in the interactive session while retaining a scrolling log? or are there other relevant attributes I'm not following?

In Interlisp, Smalltalk and Mesa environments the shell interacts with the operating system.

All those demos you see from Bret Victor are based on the experience to do live coding originally developed in these environments.

The operating system and applications are blended.

UNIX shell is based on the principle you write little programs in whatever language you feel like and you just have pipes, command line arguments and exit codes as communication mechanisms.

In Xerox PARC environments, you have a REPL experience where you can make use of any function or object in the whole OS and applications. You can change them dynamically (Interlisp, Smalltalk) or via module reload (Mesa).

Since the language of the REPL is the one of the system, you can do tasks, like select something with the mouse and then apply a REPL script to the currently selected graphical objects.

Just a few dummy examples, do a map over all selected windows to change their size for automatic tiling.

Or go over the paragraphs on the text editor and right align them.

The shell blends application macros, operating system scripts and live coding all in the same way.

For graphical editing in the shell you can pretty print data structures so that when you type a variable that represents a graphical structure, it gets drawn graphically in the command line.

You get to change running applications state from the shell, without requiring some kind of network protocol or shared memory API that they need to implement. Any public function or object can be directly accessed and manipulated.

Think of the whole experience as something like DrRacket or Mathematica being the complete OS.

Much more informative - thanks!

That said, little of this is really dependent on another model. It seems your complaints boil down to 1) applications may do a poor job defining interfaces (which is either also true in the PARC setup, or they ignore the need to define interfaces in which case things are unlikely to be stable), 2) everything is too stringly typed (which I mostly agree with, though there are advantages to it), and 3) these (plus cultural attitudes) lead to insufficient/inappropriate infrastructure (which I also agree with - "the application" is typically harmful in the UNIX model).

Having said that, there doesn't seem a theoretical difference in capabilities except for the choice of a more sophisticated terminal (which is something I'd like fixed on modern systems).

As an amusing aside, "Just a few dummy examples, do a map over all selected windows to change their size for automatic tiling." I did literally this just the other day with bash + ratpoison.

There's no doubt Bret Victor has many interesting ideas, but I thought this post[1] had some interesting counterpoints to his general thrust.

[1] http://www.evanmiller.org/dont-kill-math.html

> People are still typing the same Unix commands into 25x80 terminal windows. People are still using vi to edit programs as sequential lines of text in files using languages from the 80s (C++) or 90s (Java).

This seems like an almost willful misunderstanding of what programming is. The power of programs does NOT come from their syntactic structure. The power of programs comes from the non-linearity of programming language semantics -- I can trivially write a program that (theoretically) calculates a number too large to represent in the number of atoms in the universe.

The command line amplifies (non-linearly) what you can conventionally do with simple UIs. As a trivial example:

    $ mkdir -p src/{main,test}/{scala,java,resources}
    $ touch src/{main,test}/{scala,java,resources}/.keep

I've just created 2*3 directories and files with two commands which were very quick to type out. I haven't done actual tests, but I'd argue that that was pretty quick compared to doing it in a GUI (for instance).

One of my favorite CS professors back in the 80s used to joke that we had gone from cave paintings to written language, and now we wanted to back with our computers. (my paraphrase of whatever he actually said back then)

Pictographs work for the illiterate, but that doesn't make them the most efficient interchange mechanism.

A professor I knew had a good way to put it: "With the shell, you have a language. With pointy-clicky, you're reduced to pointing at things and grunting."

While I enjoy the shallow dig, I think this is a pretty great metaphor generally, in a deep (and less condescending) way.

If you drop me in France, and I don't speak French, I'll probably do a lot of communication with pointing and grunting, and I'll probably be able to accomplish simple tasks (particularly with an ideographic picture book on hand). Expressing more complicated things that way is pretty intractable, however. Learning to speak French is the solution, but it's a lot of work.

Moreover, there are certainly contexts where pointing makes more sense ("I'll take that one, that one, and that one" versus trying to pick out differentiating features or count).

Most technical academic textbooks are full of pictures, diagrams, and graphs.

Memory is linear and so is execution( at a basic level ) yet our programming and ideas are not. Imagine programming as a needle with one continues thread stringing boxed functions and values together, sometimes threading something that has been threaded before, and ultimately creating a crisscross of wire that's hard to understand. We cannot organize something that is linear with a non-linear representation. We try to make the crossed wire simpler to understand with programming languages but it is inherently unsolvable as a problem. There will never be a authoritative programming language.

"People are still typing the same Unix commands into 25x80 terminal windows."

Well, I for one am typing the same Unix commands and some new Unix commands into 58x170 terminal windows (on my laptop - bigger at work), and at work my builds run in 10s of seconds if I run tests. In many ways a much better experience, and one that it's easier to build still more great stuff into/atop without breaking the basic model.

The problem isn't in my opinion that people still use languages and environments from the 1980's. It's that the modern languages and environments aren't really any better. If anything, they're worse.

Well yes, there are always people who stick to the older methods, or sometimes the situation calls for programming through a terminal window, but there have been big advancements since those methods, like the great environment of Visual Studio and such. Why do you say programming has gone nowhere because there are people who don't use the newer advancements?

That's kind of the thing... that there are other ways of programming (IDE instead of text editor), but for interesting languages, there's no clear cut proof that IDEs are actually better.

For languages specifically such as Java, which have very verbose syntax, and huge amounts of boilerplate for large projects, then sure, an IDE is an improvement.

But even IDEs, really, haven't much changed. And the fact that we even still can have the discussion, sort of proves that it's not that much of an improvement.

The core of his argument was the sequential text in 20+ year-old languages.

A radical change would be similar to how 3d materials & render chains have improved in the last 20 years. From editing Renderman text files, to the nodes system: https://www.google.co.uk/search?q=blender+render+nodes That's a radical shift.

How are you defining an "interesting" language? Just your opinion? I'd say C# is a pretty interesting and powerful language that's extremely well-complemented by VS.

There's a lot more to an IDE than code generation and autocomplete (even if those are very useful and save me a ton of time). Finding all references to a variable or function (simple text searching does not do this nearly as well - the IDE actually analyzes the language and knows what points to what). Immediately letting you know if the syntax is wrong. Very visual and intuitive debugging (it goes to the line # and lets you hover over a variable to see its contents). Jumping to a variable's definition.

There have been experiments with non-textual programming, such as Scratch, but it hasn't really proven to be very useful. If there's going to be some radical shift, it might come from AI and brain scanners maybe?

Furthermore Visual Studio let's you define custom debug visualisation quite easily:

http://www.codeproject.com/Articles/13127/Create-a-Debugger-...

http://visualstudiogallery.msdn.microsoft.com/eedc48e7-5169-...

(but of course one has to think outside of the "evil MS" box)

What I was meaning was 'very different from was done 20/30 years ago, but is actually practical, as powerful as languages from 20/30 years ago, and not just a tech demo...'.

Yes, IDEs help a lot with some of those tasks. But we're really still improving programming in a very evolutionary way - which isn't bad. For sure c# is more powerful and interesting than 1990 era c++. But ultimately, it's not that different, really.

To me, that's the interesting thing about lightroom, and all that stuff. We're able to explore some of the concepts of programming from the old smalltalk systems in a modern way. And maybe, we'll find ways of programming which do actually look different from the old ways. Maybe not.

Visualising functions as things which we can glue together, transform, pass data through, etc. I'm very interested to see where it all goes.

is that really better though ?

not today, but in 5, 10, 20 years from now.

Recent experiences have shown me that flowchart systems are really really specialized tools that require a lot of training to be able to use with a modicum of success.

There are very few problem domains where I believe they provide a more accessible and expressive solution than plaintext.

> Why do you say programming has gone nowhere because there are people who don't use the newer advancements?

Speaking for myself, its because Visual Studio and its ilk don't feel like advancements. They feel like bandaids. They do their damnedest to reduce the pain of programming by automatically producing boilerplate, auto completing words, providing documentation, and providing dozens of ways to jump around text files.

Personally, I don't feel that the bandaid does enough to justify using it (granted, my main language doesn't work well with Visual Studio, so there's that too).

The main source of the pain is, to me, is that we're still working strictly with textual representations of non-textual concepts and logic, no matter how those concepts might better be rendered. We're still writing `if` and `while` and `for` and `int` and `char` while discussing pointers and garbage collection and optimizing heap allocation... Instead of solving the problem, we're stuck down describing actions and formulas to the machinery. No IDE does anything to actually address that problem.

Sorry, rant, but this problem certainly resonates with me.

> ...while discussing pointers and garbage collection and optimizing heap allocation

People still do that?

We still use 'if' and 'then', but higher level languages like Ruby and Python have eliminated pointers and their ilk from day-to-day discussion, relegating heap allocation discussion to the halls of specialized conferences, while many programmers go about their day-to-day activities skipping over the pain of garbage collection.

They may not win language shootout speed tests, but they remove a lot of programmer pain and help with how long it takes to write code.

> People still do that? Yeah, we do. Somebody has to manage all that memory that you throw around in your ruby/python scripts.

Of course, but I don't see how that "problem" will ever be solved. As long as a process has been abstracted, there will always be someone who has to look after that abstraction.

Somebody has to design and engineer the hardware and every level of abstraction between that hardware and whatever abstraction layer the "average" developer uses.

>The main source of the pain is, to me, is that we're still working strictly with textual representations of non-textual concepts and logic, no matter how those concepts might better be rendered.

I can't see any issue with representing logic abstractly with symbols. It's the same for calculus. Of course the ideas we're representing aren't actually the things we use to represent them, the same as written communication.

Non-textual programming has been explored to some degree, such as Scratch, but it's not seen as much of a useful thing.

>Instead of solving the problem, we're stuck down describing actions and formulas to the machinery. No IDE does anything to actually address that problem.

Describing actions and formulas to a machine in order to make it do something useful is pretty much the definition of programming. IDEs make it a more convenient process.

Unless you want to directly transplant the ideas out of your neural paths into the computer, maybe some AI computer in the future based on a human brain, this is how it's going to be.

> I can't see any issue with representing logic abstractly with symbols.

That's the problem: text isn't abstract enough. So we put some of the text into little blobs that have names (other methods), and use those names instead, and we call that "abstraction," but black-box abstraction doesn't help us see. The symbols in calculus, by contrast, are symbols that help you see. The OA is calling for abstractions over operating a computer that help us see.

Agree. There is must be more abstract way to present ideas than text. In this way, programs are easier to understand and modification, and have less errors and bugs.

I am suspicious. I think it would certainly be easier in some ways for rank beginners- it would make spelling errors and certain classes of syntax errors impossible- but those aren't really the bugs that cause experienced programmers grief. It's generally subtly bad logic, which is more about how people are terrible. Plus, we already know how to create computer languages that largely avoid those problems.

Written language is wonderful in many respects, and I sometimes thing people discount these things out of familiarity. Keyboards too- you can do things very quickly and very precisely with keyboards. Those things matter for your sense of productivity and satisfaction.

Our ancestors used symbols to convey messages and logic. Then came the Phoenicians. Its their fault!

Given that Chris Granger was a program manager on the Visual Studio team, it seems likely he is aware of what it provides and does not consider it an adequate solution. It may not even be a step on the path to an adequate solution.

> I alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere.

Anyone who thinks it hasn't improved should take a look at the description of the program used as an example in David Parnas's classic 1972 paper 'On the Criteria to be Used in Decomposing Systems into Modules' ( https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit... )

It's a KWIC (keyword in context) program and he says a competent programmer should be able to code it in a week. These days it's about 5-10 minutes in Ruby or Perl.

I don't say this to counter your views, but I think there is a threshold limit in everyday life.

Think about boiling water. You boil it till 100 Celsius scale. You keep heating it, but it won't attain more temperature, without turning it into steam. Now think about it, we do not need steam but we need liquid water for survival.

> People are still typing the same Unix commands into 25x80 terminal windows.

I'm using 120x40, thank you very much

Reply on news.ycombinator.com