3 ms·
Here is a fun fact that you don't realize. Say you can do the project in 2 ways. First way is to use a strongly typed language, think about the data, and desi
by ActorNightly 3y ago
Here is a fun fact that you don't realize.
Say you can do the project in 2 ways.
First way is to use a strongly typed language, think about the data, and design your code in the appropriate way. You code it up, go through the loop of compiling and fixing errors, and get your code to run.
The second way is to write your code in Python, without worrying about strong types. You complete the code quite a bit faster, but since you also want your code to be correct, you spend time writing an end to end test suit for your code.
The second approach is not only faster (since you are writing tests in both cases), its overall better. Spending time writing tests allows you to essentially validate things that modern mainstream strongly typed languages can't catch at compile time (for example, what happens when the input is unicode strings?). It also forces you to think about end to end behavior and making sure that is correct, rather than just the behavior within your code.
Strong typing is a simply hand-holding tool for programmers. If you cannot write correct code without it, you are on a fast track to being replaced by AI eventually. The future of programming is not going to be designing data structures and types, its going to be using English to generate large chunks of code in most likely Python, and then tweak fine details in those.
- jghn 3y agoUsing your example - have a type that that enforces Unicode strings (or vice versa)
- gdcbe 3y agoCall me sceptical, but I don’t buy it. What makes you certain that’s the (one) future… Also programming is a super broad field, and more then a field is almost more like a medium then a field. I honestly don’t know if we’ll still program by hand or not, but I do look skeptical at people who are very certain we won’t. Don’t think that’s the first time in history people make that prediction…
- ActorNightly 3y agoCompilation at its core is a translation problem. Right now, it would be fairly trivial to train an LLM to essentially be a compiler. And, you can already prompt LLMs on generating code for a wide array of things. As far as adoption, there is a reason why dynamic type languages that feature a lot more natural syntax (Node, Python) are used WAY more than others.
- _dain_ 3y agowhy can't I write it in a statically-typed language and also write end-to-end tests? also it's pretty ridiculous to say "static type systems are handholding" and then say the remedy is to write your code with AI ..
- ActorNightly 3y agoYou can, but the reason you do this in practice is because the static typing languages are often not sufficient or strong enough. And if you are writing tests, you may as well do everything through testing and focus on rapid dev rather than worrying about types.
- cjfd 3y agoI think this is completely false. It completely breaks down as soon as you get into your first refactoring that is a bit larger than completely trivial. Typically the mess one ends up is one or more of the following. (1) Nothing is refactored because people do not dare to do it. (2) Not just some but most of the uncommon code paths are broken. (3) Tools that are used to interact with a running application are regularly in a broken state. You want to prevent these problems with 100% test coverage. As such this may be a laudable goal on occasion but I do notice that the code described in (2) and (3) are highly non-trivial to cover 100%. I also have to wonder what mythical developer is does not have the discipline to use static typing but does have the discipline to attain 100% code coverage. I first want to see such a developer before I believe in his/her existence.
- ActorNightly 3y ago>It completely breaks down as soon as you get into your first refactoring that is a bit larger than completely trivial. This is, in fact, MUCH easier to do with a strong test suite that only cares about input and output rather than internals. The most common approach to starting a refactoring project is write or enhance a test suite to the point where there is no undefined behavior, either the program works or handles the appropriate errors. You don't need to aim for 100% test coverage either, you just need your tests to cover all possible inputs (including fuzzing).
- gwervc 3y agoExcept the kind of people "saving time" writing in a dynamic language will skip the step of writing tests as well since it can be viewed as lost time.