7 ms·
While the author speaks about difficulties due to momentum, habit, and baggage, I think the fundamental problem is much, much harder. Many have described the p
by pron 6y ago
While the author speaks about difficulties due to momentum, habit, and baggage, I think the fundamental problem is much, much harder.
Many have described the problem in different ways, from Fred Brooks's essential vs. accidental complexity to results on the intrinsic "hardness" of programming we've learned from computational complexity theory in the past two decades, but my favourite is the succinct description Gilles Dowek gave at a talk at NASA [1]:
> Computers have been invented to surprise us... If we knew what computers do, we would not use them, and we would not have built any.
In other words, not only is writing the programs we want hard because of some "reasonable" Brooks-like argument or some rigorous computational-complexity argument, but we write programs in the first place because it is hard.
In practice, not only has Brooks's prediction about no 10x improvement in programming productivity due to a single development -- which was rejected by many at the time as too pessimistic -- been vindicated, but the reality is worse: we have not seen a 10x boost due to all developments combined and in over 30 years! And the boosts we have seen are mostly due to the availability of open-source software, and widespread knowledge sharing on the internet.
[1]: https://shemesh.larc.nasa.gov/NFM2018/talks/Dowek.pdf https://shemesh.larc.nasa.gov/NFM2018/talks/Dowek.pdf
- AlexSW 6y agoSeems like a calculator is a good example of a program which we would write even though it is entirely unsurprising; even if we needed nothing else on a computer we might invent it still? It seems to me that we create computer programs not to surprise us but typically to do things very quickly or conveniently. Even a complex beast like Photoshop is reasonably unsurprising.
- stult 6y agoThe point is that the outputs of the calculator are fundamentally surprising, in the sense that if any individual programmer could easily know all the expected outputs in advance, they wouldn't need the calculator in the first place. Photoshop surprises us by calculating the precise location of millions of pixels based on relatively simple inputs like a handful of clicks on a screen. This logic does not apply to every single imaginable program, but it does apply to the non-trivial ones.
- spaced-out 6y agoSo "surprising" == anything not previously known? That's not the definition I'm used to. I might not know the exact answer to sqrt(10), but I wouldn't be surprised by the answer considering I already know it's between 3 and 4.
- ukj 6y agoIt is Shannon’s definition. Surprise == new information. Lack of surprise == lack of new information.
- js8 6y agoTo add to the other answer, Shannon's information is also sometimes called "surprisal". And it doesn't describe only what is not known, but rather what can be predicted. So if you can predict new information, it has low surprisal, even if it previously wasn't known (with certainty).
- magicalhippo 6y ago> Computers have been invented to surprise us... If we knew what computers do, we would not use them, and we would not have built any. This is just trying to sound clever for the sake of sounding clever. The first bit is factually wrong in any non-trivial way, and the counter argument for the second bit is the very next slide.
- K0balt 6y ago... If the answer to the square root of 91287346540 is unsurprising, you should just be able to say precisely what it is without working it out. I think the issue is the definition of surprise is the issue here. It may be unsurprising to receive a birthday gift, but the exact gift is still a surprise.
- magicalhippo 6y agoThe answer to the square root of 91287346540 is trivially surprising. It is not surprising in any interesting way.
- Joker_vD 6y ago...what is the least trivially surprising natural number? That is, would such a number still be trivially surprising?
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- magicalhippo 6y ago> what is the least trivially surprising natural number? Whatever it is, if it exists, it's not what computers were invented to find.
- ukj 6y ago
- hhas01 6y ago“but the reality is worse: we have not seen a 10x boost due to all developments combined and in over 30 years” [citation]?
- oblio 6y agoI don't think we even need a citation to refute that. Have a developer create something modern with technology from 1990. It would be close to impossible. Compared to what was available then, our building blocks are more akin to entire neighborhoods being delivered pre-assembled in order to create instant cities.
- commandlinefan 6y agoWell, wait a minute, which part? Commercially available microprocessors back then weren't fast enough to render 3D graphics the way they can today, but otherwise, most of what we do today was perfectly achievable then: if anything, UIs have declined since then because we're putting everything on the web (for pragmatic reasons) rather than writing custom desktop applications.
- hombre_fatal 6y agoScreens have arbitrary resolution and dimensions these days and they range all the way down to a small phone. Our state of the art (web) is still evolving towards better solutions to address that. Software in 1990 targeted a couple fixed dimensions and only for a single OS and a desktop input device.
- oblio 6y agoLook at some of the cloud offerings and thing about how long it would take to implement those things from scratch with things available in 1990. Stuff like NLP or Maps. Back then if you wanted to put a map on your website is was probably impossible. Now it's a widget a 12 year old can put on their website.
- commandlinefan 6y ago
- nindalf 6y ago> And the boosts we have seen are mostly due to the availability of open-source software, and widespread knowledge sharing on the internet. Except the source of most productivity improvements is the dissemination of knowledge of improved techniques. A good analogy (https://johnhcochrane.blogspot.com/2019/05/free-solo-and-economic-growth.html https://johnhcochrane.blogspot.com/2019/05/free-solo-and-eco...) is with rock climbing. The rock climbers today are not much fitter or physically superior to climbers 100 years ago. At best there are minor improvements in shoes, but that's it. What allows someone to free solo El Capitan in 4 hours was standing on the shoulders of giants who had discovered and disseminated climbing techniques in the last century. This effect is even more pronounced with software, because of how easy it is to reuse others' work. I don't need to learn from the collective experience of Linus Torvalds and other kernel developers, I just use Linux. I don't need to understand the intricacies of text rendering (https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/) or compiling or the universe of hardware. I can still add economic value with my software while standing on the shoulders of these giants. I can gain knowledge from all the great documentation out there, as well as helpful Q&A websites. Imagine how many projects would have been abandoned and economic value lost without knowledge being disseminated on StackOverflow. That is the productivity gain of the last few decades. If someone can't see that, or wants to condescend about the lowering of standards, they're missing the point.
- pron 6y agoThat may well be (and there are techniques believed to have helped significantly, like automated unit-tests and automatic memory management), but the outcome is still worse than Brooks's prediction, which many rejected for being too pessimistic.
- AnimalMuppet 6y agoI'm not sure I agree with that. I suspect that we have enough libraries available today that I can write 1/10 of the code. That's a 10x speedup for my programming.
- nindalf 6y ago
- taffer 6y agoAs far as I know, the value produced by programmers per unit of time is extremely difficult if not impossible to measure. You could argue that a programmer in 2020 is not 10 times faster at writing 1990 style gui software, and maybe you are right. However, if you would try to write a modern web application like Basecamp only with methods and technologies from 1990, this is not going to work out at all. There would be no web frameworks, no web server, no browser, no Ruby, no Java, no stackoverflow, no Google, no automated testing, no git, no stripe, no script, no css - no anything. You would probably give up and go for something like a client-server application with Delphi and Oracle. And you'd probably work with a waterfall development style, create tons of features that nobody wants, and then ship the whole thing as a bunch of floppy disks. Who would pay for something like that? Even if you sold it at 1/10th of what people pay for Basecamp or Jira, no one would want it. It would be trash. There have simply been fundamental improvements in the capabilities of software, and in our abilities and methods of writing such software, so that it is not even possible to compare them, and yes, I would say this is at least an order of magnitude of improvement.
- mikewarot 6y agoHaving programmed since the 1980s, you're somewhat right. Git is way better than pkZip and floppies full of dated zip files. It's not 10x better though. A single developer wrote most things back them for a single customer. We had text with attributes, colors, images, all of that under Windows 3.1 and later. When you deployed a program, you knew it was going to run in Windows, on 640x480 or larger... maybe as big as 1024x768 if the user had thousands of dollars for a nice graphics card and a big Sony Trinitron Multisync. We had multiuser databases, like Access, that allowed all of the users of a system to share data across their organizations. Programs were shipped on disks, either floppy or CDs. They then worked forever. The Waterfall Programming model was meant as a joke. On the small scale, I did it once... the program took 2 months from start to finish... the customer was happy that we met the requirements, but then wanted more. We negotiated a deal and I spent the next year doing rapid prototyping (agile?) on site, with lots of user testing. That application deployed with hardware in one site visit, and was usually run forever after that with only the occasional phone call, or field trip for faulty hardware. Things are NOT better today than they were. In Delphi, for example, every function had a working example included in the documentation. You didn't need to search Stackoverflow every ten minutes... it just worked. The fact that the deployment platform was known, and you had control over the code all the way made things incredibly easy to ship to a customer and support over the phone. Today, I can write applications in Lazarus/Free pascal, and ship them in a single zip file. The customer's screen looks exactly like mine does, there's no need to worry about dependencies, internet connectivity issues, etc. Recently I reached back into my archives from 1994 for a string function I wanted... and it worked. Things are mostly just different today, not mostly better.