9 ms·
I alternate between thinking that programming has improved tremendously in the past 30 years, and thinking that programming has gone nowhere. On the positive s
by kens 13y ago
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.
- jimmaswell 13y ago> 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). 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?
- deckiedan 13y agoThat'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 https://www.google.co.uk/search?q=blender+render+nodes That's a radical shift.
- jimmaswell 13y agoHow 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?
- _random_ 13y agoFurthermore Visual Studio let's you define custom debug visualisation quite easily: http://www.codeproject.com/Articles/13127/Create-a-Debugger-Visualizer-in-Lines-of-Code http://www.codeproject.com/Articles/13127/Create-a-Debugger-... http://visualstudiogallery.msdn.microsoft.com/eedc48e7-5169-40d3-b602-ad451990a420 http://visualstudiogallery.msdn.microsoft.com/eedc48e7-5169-... (but of course one has to think outside of the "evil MS" box)
- deckiedan 13y agoWhat 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.
- 13y ago
- falcolas 13y ago> 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.
- fragmede 13y ago> ...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.
- maccard 13y ago> People still do that? Yeah, we do. Somebody has to manage all that memory that you throw around in your ruby/python scripts.
- doesnt_know 13y agoOf 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.
- Zak 13y agoGiven 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.
- wvenable 13y agoI 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.
- krapp 13y agoText 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.
- jamii 13y agoThe 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 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.
- krapp 13y agoFair enough.
- seanmcdirmid 13y agoIt'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.
- rayiner 13y agoThe 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.
- jowiar 13y agoThat'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/ http://worrydream.com/dbx/
- k__ 13y agoGood 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.
- pjmlp 13y ago> 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.
- nubbee 13y agoMemory 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.
- pjmlp 13y agoThe 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.
- doktrin 13y agoThat 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.
- pjmlp 13y ago> 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.
- mercurial 13y ago> <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.
- dllthomas 13y ago"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.
- lomnakkus 13y ago> 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).
- Roboprog 13y agoOne 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.
- dllthomas 13y agoA 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).
- 13y ago
- jimktrains2 13y ago> People are still typing the same Unix commands into 25x80 terminal windows. I'm using 120x40, thank you very much
- z3phyr 13y agoI 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.
- michaelfeathers 13y ago> 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/criteria.pdf 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.