Hacker News Reader

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

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.

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.

Not really. As much as I love vim and Visual Studio, I use them because there's nothing better.

I'd love something better (maybe someday I'll care so much that I'll sit down and write it myself).

Uh? I don't know about vim, but emacs doesn't even get syntax highlight right for most languages.

It's a great text editor, and I appreciate it as such, but it understands way too little of programming languages other than Lisp to deserve being called an IDE.

Emacs doesn't really come with out-of-the-box great support for most languages. Even for one language there are usually several alternative modes available, from which you have to choose. Even for Lisp you probably want to consider SLIME instead of the default.

Unfortunately not every popular language has a truly great mode available. And the whole mode-ecosystem feel like a pita (especially for newcomers), but at least you have a choice, which you don't have with most other editors/IDE-s.

But your talk about syntax highlighting is just unfair. I for example use a JavaScript mode written by Steve Yegge, which actually contains a full-blown JavaScript parser which pretty much ensures that under normal circumstances I don't make syntax errors. Oh... and it also has syntax highlighting :)

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

You would have all of these things with or without a 'clone' tool that produces approximately correct code. As long as it produces code that is in some way human readable, can be debugged using standard (above) means, and doesn't make too many mistakes, it would be fine (no worse than me writing code, at least).

I think that your assumption that it would make a lot of mistakes and that they would be tedious and difficult to debug is just that, an assumption. It might be as simple as the programmer simply 'touching things up'. We haven't seen the tool, it doesn't exist, so arguing about what it would do is a moot point.

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

The pre-packaged refactorings in the Smalltalk Refactoring Browser are like this. There are checks to see if the refactoring is guaranteed to be correct, and if the refactoring runs, you can be very sure it is. The refactoring commands are even undo/redo-able.

> Anything less than 100% correct is incorrect, it isn't necessarily broken.

> run and/or produce useful answers (it would depend on the input)

The fact companies can and do sell broken products that generate wrong answers, lock-up or crash from time to time has no relation to the fact the products are broken.

An old joke said that IBM stood for "Inferior, but marketable"

You'll note, that isn't what I was arguing.

You can have code that is not 100% correct, it still runs and generates reasonable answers, without crashing, and is very useful. Even code that has been worked on for years still has subtle bugs lurking in it.

Take the Linux kernel. It has bugs in it. Somewhere, there is a bug! I'm 100% sure of this. Same with Windows, OSX.

A non-trivial piece of software with a bug is a tautology. We don't say that these products are broken, because then all software products would necessarily be broken.

Sure, in software development we are doing our damnedest to approximate correctness, but we never get there.

A tool that writes approximately correct code would be very useful.

How would it be useful to me, if I spent my time scrutinizing and debugging the code output by the tool?

I'm sorry, but this kind of inconsiderate, care-free attitude about bugs is an obstacle to me as a developer, to the brink of being downright offensive. Assuming of course we're writing code which is more complex than Hello World.

All I want, as a programmer, is a tool which aids me in reading, writing and manipulating code, without getting in the way. A clone feature is completely useless to me; a proper IDE has (or would have, actually) a library of code that I can choose from for my purposes, or perhaps would let me choose from my own snippets I've written in the past. Simply letting me drag a function to the point(s) in the code I'd like it to be called and then placing the necessary #include directives and/or the necessary compiler/linker options, and perhaps taking care of some parameters based on default values, a conceptually simple task, seems like science fiction to vim or emacs.

It's utterly stupid. The article is right on. We're wasting our time on syntax errors.

We don't appreciate our craft.

<sarcasm> In other words your code validates past computation and adds error correction code to all files you have to the HDD? After all if you don't do that then it will often produce buggy output and crash. (http://www.pcguide.com/ref/hdd/perf/qual/specRates-c.html) </sarcasm>

At best software running on commodity hardware works most of the time and acceptably broken really is good enough. Granted we want to minimize failures, but there is a wide range between good enough to be useful and perfect.

Yeah, that's why we don't have anyone fixing bugs encountered in software we use.

Please.

PS. Who cares about perfect? You can't have perfect, and that wasn't my point. Please reread.

PPS. I'm happy to see you're invalidating all the subject of my current work (carrier-grade systems) based on what's good enough on commodity systems. Extrapolating is bad.

PPPS. Sarcasm tags are so 17th century Protestant.

That mindset often results in over engineered crap.

I once wrote a program to parse a source code in ways that is provably limited. However, based on way the code was written it worked often enough to be extremely useful. Just because an approach can never cover all cases does not mean must be ignored.

Sniper bullets have tighter tolerances than the average bullet but this increase costs and becomes useless at high rates of fire. Suggesting all systems need to be as accurate as possible is ignorant.

PS: I have written and used plenty of code sitting on DoD computers and believe me it’s not all golden. Walk around the Pentagon and guess what Windows is sitting on the vast majority of peoples desks.

Again, you're extrapolating just to prove me wrong. I admit it may seem 'extreme' to some, but advanced tools aren't a threat to us. However, our current culture as programmers shows that we don't even trust other people's source code, let alone tools, to do our job. In this context of today, a tool that "writes code" (imperfect, of course) is not to be trusted any more than me, you, or our colleagues.

But do not downplay the importance of not producing, fixing, and avoiding bugs. It's just wrong.

There are basically two ways to write software you can either completely understand the problem and create a completely understood solution, or you can approximate a reasonable solution and then patch. Now when it’s possible the first approach is far better, unfortunately some of the worst systems where created when people tried to use the first approach when it was simply too complex for any one person to understand.

If you have ever copied a function changed the name and modified the code you are on the second path. Now plenty of people have gone down that path and know it’s likely to produce bugs, but as long as you have reasonable mitigation strategies it can still be a good idea. Building a tool that does similar things with larger sections of code would be dangerous, but with a little care it could still be useful.

In the early days of Fortran compilers they tended to be buggy so people would often money patch the output. http://en.wikipedia.org/wiki/Monkey_patch While error prone this was significantly faster than hand coding in assembler from the start. This died out with the invention of better compilers, but plenty of good software was written before then.

PS: I wish most software could be written using the first approach. I just don't think that's possible.

"How would it be useful to me, if I spent my time scrutinizing and debugging the code output by the tool?"

How would it be useful to me, if I spent my time scrutinizing and debugging code put out by myself?

I am going to do the scrutinizing and debugging either way!

How is my attitude about bugs carefree? They are everywhere. They are inevitable. That isn't carefree, those are the facts of life. You screw up, I screw up, Tom screws up. (I consider myself more of the paranoid camp wrt bugs, personally).

I agree that at a minimum an IDE has to do the things you listed.

If I had a tool that generated code pretty much as good as mine, that I could debug and ship, where would the loss be? The tool doesn't exist, and probably won't exist, but if it did, it would be awesome.

"How would it be useful to me, if I spent my time scrutinizing and debugging the code output by the tool?"

How would it be useful to me, if I spent my time scrutinizing and debugging code put out by myself? ------

Small point: I'd much rather debug errors I introduced than ones a program did. If I made the errors, they will have a familiarity about them - "oh, I always misspell that," or "I wasn't paying attention there." I can't predict how a program might get it wrong.

I'd much rather debug errors I didn't write myself, they are much easier to find. I find that code I wrote (often) scans the way I intended to write it, not the way I wrote it.

"How would it be useful to me, if I spent my time scrutinizing and debugging the code output by the tool?"

How would it be useful to me, if I spent my time scrutinizing and debugging code put out by myself?

To contrast those too, consider the familiarity you already possess with your code, as opposed to the code that was written by others.

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

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!

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.

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.

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.

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

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.

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.

vi was released in, apparently, 1976. http://www.linfo.org/vi/history.html

I bet your target directory is not marked as derived

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!

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.

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

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

A science built on abstraction can't have tools with enough level of abstraction?

That's almost Poetic.

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.