3 ms·

> I think a similar principle could be true for programs, if we just knew the right questions to ask! Those right questions to ask are VERY hard to find, so we

> I think a similar principle could be true for programs, if we just knew the right questions to ask! Those right questions to ask are VERY hard to find, so we programmers have to write many many very accurate answers about how our programs should behave. That process is called programming.

dwohnitmok 6y ago
This is a dilemma that often rears its head (exemplified by the classic "42"). Intuitively difficult situations usually end up "conserving their difficulty." An easy solution means a difficult problem (hard to formulate the problem or the formalization of the problem is usually inapplicable). An easy problem usually means a difficult solution.
im3w1l 6y ago
So many replies, I'll reply to you but it's really for everyone. The thought experiment was just meant to illustrate how much easier things could be if we knew better what programmers wanted to write. It was not a serious suggestion for how programming should work. What I do think should happen, and will happen, is that we will keep getting a better understanding of what behavior people want most of the time -- including the common variations, and make it ever easier to achieve it.
- yetihehe 6y ago
  The ideal programming language would have only two commands: do_what_i_want() and do_it_faster(what). You could use them like this: do_it_faster(do_what_i_want()). > if we knew better what programmers wanted to write It's very simple: they want to write, what was not written before. What fun is to write what has already been written? You can just copy it. Most of what was written is typically embedded in some library/crate/module already. That is an ongoing process which will never* end. Summarising - it's impossible to know what programmers want to write, because the moment you find it and make it easier, they want to write another thing. * For physically possible values of never.

dwohnitmok 6y ago

This is a dilemma that often rears its head (exemplified by the classic "42"). Intuitively difficult situations usually end up "conserving their difficulty." An easy solution means a difficult problem (hard to formulate the problem or the formalization of the problem is usually inapplicable). An easy problem usually means a difficult solution.

im3w1l 6y ago

So many replies, I'll reply to you but it's really for everyone. The thought experiment was just meant to illustrate how much easier things could be if we knew better what programmers wanted to write. It was not a serious suggestion for how programming should work. What I do think should happen, and will happen, is that we will keep getting a better understanding of what behavior people want most of the time -- including the common variations, and make it ever easier to achieve it.

yetihehe 6y ago
The ideal programming language would have only two commands: do_what_i_want() and do_it_faster(what). You could use them like this: do_it_faster(do_what_i_want()). > if we knew better what programmers wanted to write It's very simple: they want to write, what was not written before. What fun is to write what has already been written? You can just copy it. Most of what was written is typically embedded in some library/crate/module already. That is an ongoing process which will never* end. Summarising - it's impossible to know what programmers want to write, because the moment you find it and make it easier, they want to write another thing. * For physically possible values of never.