2 ms·
It's not easy to quantify but you can't just dismiss formal methods because we don't know how much development and maintenance overhead they would eliminate. H
by bhaak 5y ago
It's not easy to quantify but you can't just dismiss formal methods because we don't know how much development and maintenance overhead they would eliminate.
How much revenue something generates is a poor metric. Otherwise, we all would probably be programming in PHP.
- bobthechef 5y agoI don't think the OP dismisses formal methods, only the idea that they have pervasive utility that outweighs costs in most scenarios, at least for certain kinds of formal methods. But we can't forget the range of formal methods either. Type systems technically qualify, as the article notes, even if they are lightweight, and they're not new. Given the pervasiveness of Java, we're already making widespread use of at least that formal method and have been for a long time. > How much revenue something generates is a poor metric. Otherwise, we all would probably be programming in PHP. The OP wasn't arguing that revenue is driving or should drive language selection, only that the revenue shows that the lack of formal methods does not seems to prevent companies from making enormous sums of money. > you can't just dismiss formal methods because we don't know how much development and maintenance overhead they would eliminate. That by itself is not much of a positive argument for their use. And do you know how much maintenance overhead they would introduce? In either case, it might be useful to compare how a switch between similar languages (e.g. JS and Typescript) affected code quality (in terms of the number of bug reports filed, for example) and feature delivery time. Maybe there's a point where the trade off makes sense. In which case, languages that support a gradual adoption of formal methods might begin to look attractive.
- oneplane 5y agoThe programming language itself has very little to do with the revenue something generates. Revenue isn't generated by technical details, those are just the implementation of a product that itself is just an implementation of the goals of the business. The reason people are and aren't programming in PHP is just plain and simple: taste. Maybe ff 10 developers in a team want to use PHP they can just do that, as long as at the end of the line the product delivers. If 3/10 want to use PHP, and 7/10 want to use C# then no, it will not likely run on PHP. And if as a developer you prefer certain features or tools over others, you are likely to select the technologies that suit that. None of the technical details had anything to do with the value that was created. If your requirements say that 100 people per minute need to be able to find, basket and purchase product on a website, and those requirements are met, does it really matter if the codebase is a combination of AppleScript and an ActiveX control? (I know, that technically doesn't exist, not the point) Now, if those requirements also include scaling needs, long-term support needs, knowledge sharing, consultancy options, then you might not select those technologies.