4 ms·

You have to understand the code at a level sufficient to make accurate annotations, which isn't that much easier. And you're not getting as much safety bang for

You have to understand the code at a level sufficient to make accurate annotations, which isn't that much easier. And you're not getting as much safety bang for your buck for the effort as you would in a rewrite in actually safe language.

uecker 2y ago
You certainly could get the same level of safety via annotations as you can in safe language. And if you transition existing code, you do not need to rewrite that will introduce new bugs and invalidate all the testing.
awaythrow999 2y ago
>> understand the code at a level sufficient to make accurate annotations, which isn't that much easier. And you're not getting as much safety bang for your buck for the effort as you would in a rewrite in But rewriting assumes I learn a new language on top of rewriting.
flohofwoe 2y ago
It's still better than a complete rewrite, which will very likely introduce new bugs that had already been fixed in the existing code (no matter what languages are used).
jmull 2y ago
> You have to understand the code at a level sufficient to make accurate annotations, which isn't that much easier That's not necessarily true though. Half decent C code already has a coherent memory management strategy. The problem is that humans can't follow even pretty straight-forward memory management strategies 100% of the time. If you have a function that returns memory the caller is required to free, or accepts a parameter that the function takes ownership of, that can be easily expressed but hard to get right every time. In fact, functions typically document this... in half-decent C code. So we're really talking about formalizing the expression of memory management documentation that already exists and is already understood. > And you're not getting as much safety bang for your buck for the effort as you would in a rewrite in actually safe language. I just can't think of what the rational argument for this could be. A complete deep rewrite -- where the new language requires reorganizing the code at a low level so that a lot of existing logic cannot be reused (as-is, or transformed in certain specific ways) -- is extremely costly. It is on the order of the total cost of writing the software in the first place plus the entire cost already spent maintaining it over time. Some costs -- like the goodwill of users/adpoters -- simply cannot be paid again at the same rate. For large scale software there would be numerous regressions over a long period of time, while at the same time the software stops adding many new features, since all the focus will on the rewrite and bugs related to the rewrite. I will stand corrected if there is more than one or two exceptional cases of large scale software making a successful transition of this sort without paying a massive cost.
DougN7 2y ago
If you don’t understand the code well enough to annotate it, it seems hard to believe you’d able to rewrite it and end up with the same functionality (same processing rules, accepts identical input, produces identical output, etc).

uecker 2y ago

You certainly could get the same level of safety via annotations as you can in safe language. And if you transition existing code, you do not need to rewrite that will introduce new bugs and invalidate all the testing.

awaythrow999 2y ago

>> understand the code at a level sufficient to make accurate annotations, which isn't that much easier. And you're not getting as much safety bang for your buck for the effort as you would in a rewrite in But rewriting assumes I learn a new language on top of rewriting.

flohofwoe 2y ago

It's still better than a complete rewrite, which will very likely introduce new bugs that had already been fixed in the existing code (no matter what languages are used).

jmull 2y ago

> You have to understand the code at a level sufficient to make accurate annotations, which isn't that much easier That's not necessarily true though. Half decent C code already has a coherent memory management strategy. The problem is that humans can't follow even pretty straight-forward memory management strategies 100% of the time. If you have a function that returns memory the caller is required to free, or accepts a parameter that the function takes ownership of, that can be easily expressed but hard to get right every time. In fact, functions typically document this... in half-decent C code. So we're really talking about formalizing the expression of memory management documentation that already exists and is already understood. > And you're not getting as much safety bang for your buck for the effort as you would in a rewrite in actually safe language. I just can't think of what the rational argument for this could be. A complete deep rewrite -- where the new language requires reorganizing the code at a low level so that a lot of existing logic cannot be reused (as-is, or transformed in certain specific ways) -- is extremely costly. It is on the order of the total cost of writing the software in the first place plus the entire cost already spent maintaining it over time. Some costs -- like the goodwill of users/adpoters -- simply cannot be paid again at the same rate. For large scale software there would be numerous regressions over a long period of time, while at the same time the software stops adding many new features, since all the focus will on the rewrite and bugs related to the rewrite. I will stand corrected if there is more than one or two exceptional cases of large scale software making a successful transition of this sort without paying a massive cost.

DougN7 2y ago

If you don’t understand the code well enough to annotate it, it seems hard to believe you’d able to rewrite it and end up with the same functionality (same processing rules, accepts identical input, produces identical output, etc).