11 ms·

There is certainly room for IDEs to improve. But there's no way we can ever have the level of automation and abstraction that photographers, video editors and o

There is certainly room for IDEs to improve. But there's no way we can ever have the level of automation and abstraction that photographers, video editors and other creatives enjoy. Take the photo clone tool mentioned. Why does that work? Because human vision is lossy and forgiving - the difference between 95% correct and 100% correct is around 5%, depending on how closely the person is looking at it. Programming on the other hand... code is either 0% correct or 100% correct. Anything less than 100% correct is broken. Media is also far less complex. How do I know if my video is correct? I simply play it. If there any errors, they are all possible to detect in the minutes it takes to play the video. There will never be an equivalent for code. You can't visualize an arbitrary algorithm over all its inputs - that's undecidable. It's hard enough to see what a function in three variables does, let alone quicksort. The best we can do is have editors for specific tasks. GUI editors, markup editors, etc. For everything else, code is the only option. We can patch the awkwardness with better languages and better IDEs, but it will never, ever, go away.

charlief 16y ago
I agree with most of what you are saying, but never, ever is a long time. If I can be optimistic for a moment, I think 100 years or more from now, successive languages and IDEs won't simply be patches to awkwardness, they will probably help with many real programming problems significantly. Ask yourself how many times have you re-invented something over and over again, or the fragmentation of documentation and usage overhead of frameworks. These are just some. Computer science and software engineering are young disciplines. Comparing different IDEs is often a matter of style and personal choice right now, but if there is ever a big milestone, many will know it and many will adopt it, but until that point I don't think being complacent is the answer. Who knows what black swans lie in the future.
sofuture 16y ago
I don't think I really agree with any of that. The binary aspect of software workingness doesn't really matter... Code is just bits of information that gets massaged around, there's no reason why the tools to do so can't improve. Sure the specific example of visualizing an arbitrary algorithm over all inputs might be a little unrealistic, but the point of the post wasn't that we need that specific thing. I'm not denying it's a complex problem (grokking what the code does is hard already, nevermind grokking what it should do), but complex problems aren't fundamentally impossible, they're just... complex!
- alextgordon 16y ago
  Sure the specific example of visualizing an arbitrary algorithm over all inputs might be a little unrealistic, but the point of the post wasn't that we need that specific thing. On the contrary, this is exactly what we need. Easy visualization is the reason why word processors, photo editors, video editors, music notation and audio software, DTP packages, and 3D programs are so much more powerful than IDEs. WYSIWYG gives the user a view of the entire state of the document they're working on. Users can see what's wrong or what needs doing, then fix it. It's certainly possible to create this in an IDE in a small number of specific cases, but it's totally impossible in general (and I mean this in the truest sense of the word "impossible"). I agree with you and the author of the post that we should definitely work on getting IDEs smarter, and there's a lot of scope for improving them. It's just that computer science places a hard limit on how far we can go.
  - sofuture 16y ago
    I entirely disagree that visualization is a/the missing panacea. Code is not a visual thing nor does it even represent a visual thing -- making it visual accomplishes nothing (except for making it visual). Pictures, formatted document text, 3d models and videos are visual things. Music notes are a specific type of visual language, audio is time-linear-spatial (or something less gibberishy like that) and can be represented visually. These things are all extremely different from software.
    - jacabado 16y ago
      Surely it will be really hard to get better ways of visualizing code, it's an abstract thing and so it's hard to represent. But what we are really missing is execution visualization. Applications aren't code, applications are execution systems and it's a shame to test execution/debug like we do today. As someone has said, it's almost impossible to test all inputs for an algorithm, it's impossible to prove the correctness of an application without testing it. Without testing we're nothing, most of us can surely say in which conditions our applications will break, but how sure are we to say in which conditions will it work? Much harder. I would love to work in IDE improvement as I believe there is really a lot of things to improve.
ohyes 16y ago
"Programming on the other hand... code is either 0% correct or 100% correct. Anything less than 100% correct is broken." I don't think that's true. Anything less than 100% correct is incorrect, it isn't necessarily broken. How do I know my program is not broken? I run it. If it produces the answers I want, I can generally assume it is not broken (with a dose of skepticism). If it is actually incorrect, it could still compile, run and/or produce useful answers (it would depend on the input). Almost all of my code has subtle bugs that I have had to iron out at one point or another. I know, I know; What about space shuttle control systems or critical airplane frobnobdicators? Fine. Those aren't lossy and forgiving, but systems like that are few and far between. There is a large subset of programs that are also lossy and forgiving. (Which I assume the majority of us work on). Were it really a binary reality, we would have much less software.
- alextgordon 16y ago
  I was talking in terms of transformations, such as the clone tool. Clone takes a set of pixels, applies some math, and gives you a new set of pixels that look a bit like what you want. After you've applied clone, you're done (although you might need to apply some finishing touches). There is just no room for such tools in programming. You can't have a tool that applies some transformation to the code but leaves half of it in a broken state. That would be worse than useless. No, a tool has to be 100% correct or introduce errors that are caught by the compiler, otherwise it'll take longer to find and fix its mistakes than it would to apply the transformation manually. And it turns out that making such perfect tools is incredibly hard. How do I know my program is not broken? I run it. If it produces the answers I want, I can generally assume it is not broken (with a dose of skepticism). But notice how much effort is put into making sure code is correct. We have unit testing, integration testing, fuzz testing, static analysis, formal verification, ... Games studios pay scores of people to sit around playing games all day. This is not seen in any other creative art.
  - mnemonicsloth 16y ago
    Vim and Emacs are 20+ years old and still popular. They're still around precisely because they're really good tools for transforming source code.
Tamerlin 16y ago
"Programming on the other hand... code is either 0% correct or 100% correct. Anything less than 100% correct is broken." I don't think that's even remotely close to accurate. Spend a day looking at the Daily WTF, and consider that the Daily WTF is a LOT more representative of the IT world than HN is. There are raftloads of garbage code out there, and the people writing it can get away with it because it kind of works, even if most coders write 2000 lines to do what a competent coder would have done with 200. In visual effects, the viewer is far LESS forgiving. Why do computer-generated water effects, even with multi-million dollar budgets, still look CG? It's because we are so familiar with what water looks like that we subconsciously pick up on miniscule flaws that are exceedingly difficult to groom out, because the computer-generated water requires so much computational power. The IT industry as a whole is stark proof that code is far too forgiving. Look at the host of rants about corporate IT -- the vast majority of IT, and the reason that "enterprise" carries the connotations of certain 4-letter words. And look at films that are heavy with visual effects, and see how easily you can find flaws in them, and how much effort film makers put into creating those animations. The difference? You can put broken code into production, and get away with it easily. Outside of communities like this, let's be honest -- hardly anyone can tell that the code is utter garbage, proven by the fact that most of it IS utter garbage. Then look at how easily you can detect flaws in almost any visual art medium -- you might be surprised at how much effort goes into crafting a fine art photograph, given how easy it is to allow miniscule flaws to break the connection with the viewer.
njharman 16y ago
> Anything less than 100% correct is broken. There is far more gray in code than that! Slow, inefficient code. Poorly written, indecipherable, spaghetti, unmaintainable code. Undocumented code. Untested code. All can be (in theory) not broken, but are far from 100%
seldo 16y ago
This would be fine if it were obvious to all of us that GUIs have advanced as far as they can, and the remainder of the problems we see in them were inherent to the complexity and nondeterministic nature of the systems they manage. But it's not like that. My IDE occasionally gets confused and forgets how to rename a file. Eclipse takes 3 minutes to refresh a source-file tree. People still use vim and emacs for things! There could be no clearer sign to me that IDEs are rubbish pieces of software than the fact that people keep falling back on tools that have barely evolved in 30 years.
- ekiru 16y ago
  vim was released in 1991. emacs did exist 30 years ago, but it's certainly evolved quite a bit since then. My personal emacs installation evolves regularly, although I will admit that it hasn't evolved at all today.
  - leot 16y ago
    vi was released in, apparently, 1976. http://www.linfo.org/vi/history.html http://www.linfo.org/vi/history.html
- jsvaughan 16y ago
  I bet your target directory is not marked as derived
- sp4rki 16y ago
  You are kind of making the assumption that there should be something better than Vim and Emacs because they where created decades ago and are not pretty "gui driven" applications. Programming is simply writing and editing text. Vim and Emacs are editors and they fulfill their jobs marvelously, and that's OK. We don't need no stinking IDEs!
mfukar 16y ago
A science built on abstraction can't have tools with enough level of abstraction? That's almost Poetic.
- jacabado 16y ago
  This is a great point. For me it isn't poetic at all, but a deductible consequence. If our job is creating abstractions it must be really hard to create tools which abstract properly our job. Where abstract properly would be separating what is really our job, the abstractions we are creating, and what are the trivial abstractions, the ones we assume as stable. This is a hard path to reach any usefull conclusions or insights to develop new programming tool features. The separation from what are the abstractions we're creating and the abstractions we're building on top off is always changing and it's in the same place (in the code). For reaching usefull conclusions I would rather think in the different tasks developers need to pursue. Who wants to build a RescueTimeesque tool for developers? Lisp, with his code is data super-feature, and his REPL super-environment has a lot to say in this two issues.
vilya 16y ago
> Media is also far less complex. How do I know if my video is correct? I simply play it. If there any errors, they are all possible to detect in the minutes it takes to play the video. There's actually a level of complexity to video well beyond what you imply. For example, making sure the colours appear the same when you watch something on your laptop screen and when you watch it in the cinema requires a lot of care and attention - and no small amount of science. Also not all video edits are realtime - some things require a lot of processing, which can take just as much time as compiling a decent sized app.
- Tamerlin 16y ago
  Yeah, anyone who thinks that media is less complex or less demanding than programming should spend a day doing some visual effects work for a live action movie (try creating a virtual character sometime) or talk to the guy I'm working with to do my photo finishing. The reality is that it's far, far more demanding than programming, especially with modern languages. With proper up-front design effort, programming is easy. The catch is that the up-front design requires engineering skills and is actually challenging, and most of today's programmers skip that and dive right into programming... leading to the vast mountains of crap we have today. (Look at amazon's codebase sometime. It's such an atrocity that it drives people out of the industry.)

charlief 16y ago

I agree with most of what you are saying, but never, ever is a long time. If I can be optimistic for a moment, I think 100 years or more from now, successive languages and IDEs won't simply be patches to awkwardness, they will probably help with many real programming problems significantly. Ask yourself how many times have you re-invented something over and over again, or the fragmentation of documentation and usage overhead of frameworks. These are just some. Computer science and software engineering are young disciplines. Comparing different IDEs is often a matter of style and personal choice right now, but if there is ever a big milestone, many will know it and many will adopt it, but until that point I don't think being complacent is the answer. Who knows what black swans lie in the future.

sofuture 16y ago

I don't think I really agree with any of that. The binary aspect of software workingness doesn't really matter... Code is just bits of information that gets massaged around, there's no reason why the tools to do so can't improve. Sure the specific example of visualizing an arbitrary algorithm over all inputs might be a little unrealistic, but the point of the post wasn't that we need that specific thing. I'm not denying it's a complex problem (grokking what the code does is hard already, nevermind grokking what it should do), but complex problems aren't fundamentally impossible, they're just... complex!

alextgordon 16y ago
Sure the specific example of visualizing an arbitrary algorithm over all inputs might be a little unrealistic, but the point of the post wasn't that we need that specific thing. On the contrary, this is exactly what we need. Easy visualization is the reason why word processors, photo editors, video editors, music notation and audio software, DTP packages, and 3D programs are so much more powerful than IDEs. WYSIWYG gives the user a view of the entire state of the document they're working on. Users can see what's wrong or what needs doing, then fix it. It's certainly possible to create this in an IDE in a small number of specific cases, but it's totally impossible in general (and I mean this in the truest sense of the word "impossible"). I agree with you and the author of the post that we should definitely work on getting IDEs smarter, and there's a lot of scope for improving them. It's just that computer science places a hard limit on how far we can go.
- sofuture 16y ago
  I entirely disagree that visualization is a/the missing panacea. Code is not a visual thing nor does it even represent a visual thing -- making it visual accomplishes nothing (except for making it visual). Pictures, formatted document text, 3d models and videos are visual things. Music notes are a specific type of visual language, audio is time-linear-spatial (or something less gibberishy like that) and can be represented visually. These things are all extremely different from software.
  - jacabado 16y ago
    Surely it will be really hard to get better ways of visualizing code, it's an abstract thing and so it's hard to represent. But what we are really missing is execution visualization. Applications aren't code, applications are execution systems and it's a shame to test execution/debug like we do today. As someone has said, it's almost impossible to test all inputs for an algorithm, it's impossible to prove the correctness of an application without testing it. Without testing we're nothing, most of us can surely say in which conditions our applications will break, but how sure are we to say in which conditions will it work? Much harder. I would love to work in IDE improvement as I believe there is really a lot of things to improve.

ohyes 16y ago

"Programming on the other hand... code is either 0% correct or 100% correct. Anything less than 100% correct is broken." I don't think that's true. Anything less than 100% correct is incorrect, it isn't necessarily broken. How do I know my program is not broken? I run it. If it produces the answers I want, I can generally assume it is not broken (with a dose of skepticism). If it is actually incorrect, it could still compile, run and/or produce useful answers (it would depend on the input). Almost all of my code has subtle bugs that I have had to iron out at one point or another. I know, I know; What about space shuttle control systems or critical airplane frobnobdicators? Fine. Those aren't lossy and forgiving, but systems like that are few and far between. There is a large subset of programs that are also lossy and forgiving. (Which I assume the majority of us work on). Were it really a binary reality, we would have much less software.

alextgordon 16y ago
I was talking in terms of transformations, such as the clone tool. Clone takes a set of pixels, applies some math, and gives you a new set of pixels that look a bit like what you want. After you've applied clone, you're done (although you might need to apply some finishing touches). There is just no room for such tools in programming. You can't have a tool that applies some transformation to the code but leaves half of it in a broken state. That would be worse than useless. No, a tool has to be 100% correct or introduce errors that are caught by the compiler, otherwise it'll take longer to find and fix its mistakes than it would to apply the transformation manually. And it turns out that making such perfect tools is incredibly hard. How do I know my program is not broken? I run it. If it produces the answers I want, I can generally assume it is not broken (with a dose of skepticism). But notice how much effort is put into making sure code is correct. We have unit testing, integration testing, fuzz testing, static analysis, formal verification, ... Games studios pay scores of people to sit around playing games all day. This is not seen in any other creative art.
- mnemonicsloth 16y ago
  Vim and Emacs are 20+ years old and still popular. They're still around precisely because they're really good tools for transforming source code.

Tamerlin 16y ago

"Programming on the other hand... code is either 0% correct or 100% correct. Anything less than 100% correct is broken." I don't think that's even remotely close to accurate. Spend a day looking at the Daily WTF, and consider that the Daily WTF is a LOT more representative of the IT world than HN is. There are raftloads of garbage code out there, and the people writing it can get away with it because it kind of works, even if most coders write 2000 lines to do what a competent coder would have done with 200. In visual effects, the viewer is far LESS forgiving. Why do computer-generated water effects, even with multi-million dollar budgets, still look CG? It's because we are so familiar with what water looks like that we subconsciously pick up on miniscule flaws that are exceedingly difficult to groom out, because the computer-generated water requires so much computational power. The IT industry as a whole is stark proof that code is far too forgiving. Look at the host of rants about corporate IT -- the vast majority of IT, and the reason that "enterprise" carries the connotations of certain 4-letter words. And look at films that are heavy with visual effects, and see how easily you can find flaws in them, and how much effort film makers put into creating those animations. The difference? You can put broken code into production, and get away with it easily. Outside of communities like this, let's be honest -- hardly anyone can tell that the code is utter garbage, proven by the fact that most of it IS utter garbage. Then look at how easily you can detect flaws in almost any visual art medium -- you might be surprised at how much effort goes into crafting a fine art photograph, given how easy it is to allow miniscule flaws to break the connection with the viewer.

njharman 16y ago

> Anything less than 100% correct is broken. There is far more gray in code than that! Slow, inefficient code. Poorly written, indecipherable, spaghetti, unmaintainable code. Undocumented code. Untested code. All can be (in theory) not broken, but are far from 100%

seldo 16y ago

This would be fine if it were obvious to all of us that GUIs have advanced as far as they can, and the remainder of the problems we see in them were inherent to the complexity and nondeterministic nature of the systems they manage. But it's not like that. My IDE occasionally gets confused and forgets how to rename a file. Eclipse takes 3 minutes to refresh a source-file tree. People still use vim and emacs for things! There could be no clearer sign to me that IDEs are rubbish pieces of software than the fact that people keep falling back on tools that have barely evolved in 30 years.

ekiru 16y ago
vim was released in 1991. emacs did exist 30 years ago, but it's certainly evolved quite a bit since then. My personal emacs installation evolves regularly, although I will admit that it hasn't evolved at all today.
- leot 16y ago
  vi was released in, apparently, 1976. http://www.linfo.org/vi/history.html http://www.linfo.org/vi/history.html
jsvaughan 16y ago
I bet your target directory is not marked as derived
sp4rki 16y ago
You are kind of making the assumption that there should be something better than Vim and Emacs because they where created decades ago and are not pretty "gui driven" applications. Programming is simply writing and editing text. Vim and Emacs are editors and they fulfill their jobs marvelously, and that's OK. We don't need no stinking IDEs!

mfukar 16y ago

A science built on abstraction can't have tools with enough level of abstraction? That's almost Poetic.

jacabado 16y ago
This is a great point. For me it isn't poetic at all, but a deductible consequence. If our job is creating abstractions it must be really hard to create tools which abstract properly our job. Where abstract properly would be separating what is really our job, the abstractions we are creating, and what are the trivial abstractions, the ones we assume as stable. This is a hard path to reach any usefull conclusions or insights to develop new programming tool features. The separation from what are the abstractions we're creating and the abstractions we're building on top off is always changing and it's in the same place (in the code). For reaching usefull conclusions I would rather think in the different tasks developers need to pursue. Who wants to build a RescueTimeesque tool for developers? Lisp, with his code is data super-feature, and his REPL super-environment has a lot to say in this two issues.

vilya 16y ago

> Media is also far less complex. How do I know if my video is correct? I simply play it. If there any errors, they are all possible to detect in the minutes it takes to play the video. There's actually a level of complexity to video well beyond what you imply. For example, making sure the colours appear the same when you watch something on your laptop screen and when you watch it in the cinema requires a lot of care and attention - and no small amount of science. Also not all video edits are realtime - some things require a lot of processing, which can take just as much time as compiling a decent sized app.

Tamerlin 16y ago
Yeah, anyone who thinks that media is less complex or less demanding than programming should spend a day doing some visual effects work for a live action movie (try creating a virtual character sometime) or talk to the guy I'm working with to do my photo finishing. The reality is that it's far, far more demanding than programming, especially with modern languages. With proper up-front design effort, programming is easy. The catch is that the up-front design requires engineering skills and is actually challenging, and most of today's programmers skip that and dive right into programming... leading to the vast mountains of crap we have today. (Look at amazon's codebase sometime. It's such an atrocity that it drives people out of the industry.)