5 ms·

As I said in another ranty response in this thread, I do not understand how people enjoy spending time debugging trivial issues, that even a simple static type

by anyfoo 5y ago

As I said in another ranty response in this thread, I do not understand how people enjoy spending time debugging trivial issues, that even a simple static type system would just plain tell them at compile time.

dmlittle 5y ago
I think it depends on what you’re doing. The author of the the Reddit post mentioned he’s primarily working with data systems. I can see the appeal of someone running quick, ephemeral data analysis not wanting to deal with static typing. But for long term use cases the static typing guard rails is definitely nice.
- repExpMon 5y ago
  > I can see the appeal of someone running quick, ephemeral data analysis not wanting to deal with static typing I've seen and heard this, (Data science field definitely loves their Python and numpy) but I really believe the common problem of non-reproducible research is partly due to the language choice (and probably more to the root cause - this sentiment in research).
3pt14159 5y ago
I've been programming for over 20 years too, and I like dynamic languages. I like them a lot more when they're properly tested and well architected, but even the tire fire codebases are at least debuggable. The compiled stuff helps with types catching the trivial bugs, yes, but it's way too complicated to quickly debug things like seg faults. Dynamic languages let you introspect and modify things way more easily, and this makes things like fakes and mocks for testing way easier. It makes debugging easier. And not having to wait an hour for something to compile is nice. That said, I love the speed of compiled languages. I once converted a simulation from Python to Cython and saw a 10000x performance boost because of CPU caches and all that. Usually the gains are closer to 10x to 20x, but in some rare moments it's like a rocket ship vs a hang glider.
- anyfoo 5y ago
  EDIT: Reading again, I think you are comparing interpreted with compiled languages, not so much static with dynamic type systems. Seg faults are a prime argument for static typing. The more static and stricter the type system, the less things like seg faults can even happen. Compare Rust to C (both are static, but one more than the other), and at the extreme end handwritten assembly (extremely dynamic). Those are languages used by kernel developers, where errant memory accesses of all kinds are a constant concern. I don't know why dynamic languages would make introspecting things easier, or debugging in general. I agree that mocking can be easier with dynamic types. Compilation rarely takes long nowadays (incrementally it's usually just a few seconds), so the time saved in knowing that the code is still correct at least within the confines of the type system is well worth it.
  - belorn 5y ago
    As an kernel developer, would you want to take some of the many shell scripts that the kernel has and rewrite them in C? Different tools for different purpose. Unless there ecosystem was really designed for it, I would not write a driver in a dynamic language. At the same time, I would prefer not to write all the bootstrap scripts during booting in C. If all I am doing is calling other programs, I use shell. If all I am doing is calling a bunch of low level system calls in a restricted environment I would use C. If I am doing a bunch of string editing, process flow management, data compiling with some calls to external programs, I would use a dynamic langue like Python. I want add a personal opinion in regard to C. Every function gives out an return code which is a kind of "type" that does not get enforced by the compiler. The return code is defined by the manual page and it is up to the programmer to catch it and react correctly to it. If the wrong code occur and the program explode during runtime its the fault of the programmer for not write a program that manage the return code. I would claim that the wast majority of crashes that occur in programs written in C is because programmers failed to realize the full list of possible return codes and what they mean. Here I do prefer dynamic languages because they usually do not leave it up to the manual to defined what return code -42 means compared to -41, and debugging errors when the errors themselves have class names and inheritance tend to be a bit easier in my experience.
wirrbel 5y ago
I mean by now it should be clear to everyone that there are certain trade-offs in the choice dynamic vs static typing. I do like clarity of static type declarations, also the absence of weird polymorphism like functions returning a number or al ist of numbers depending on their parameters, etc. But then, many statically typed code bases are just tested abysmally. It is as if the type signatures would constitute proper tests. I realise that you don't need to write as many tests in a statically typed setting, but in many cases - and esp. in underpowered type systems - the types won't test the program's logic.
- anyfoo 5y ago
  You do need to write less tests with a static language. The types in your program are proof that your program is correct within the confines of the type system (literally, even in the mathematical sense). The stronger the type system, the more properties can be proven through it (at the extreme end there are, unfortunately not Turing complete, languages where you can prove every single property--those are more used as theorem solvers however). Back to "common" statically typed languages, there is still heaps and loads to test, as you say. Not writing those tests is not really the fault of the language...
  - wirrbel 5y ago
    I am bringing up this point that there are tons of miserably tested Java/C++/etc applications because its a problem correlated with their usage, just like runtime type-errors correlate with dynamic languages. A fair comparison mentions both. Of course a strong type system can drastically reduce the unit test coverage you need. But last time I checked, the strong type systems that allowed for this were all not used in our corporate code bases.

by anyfoo 5y ago

dmlittle 5y ago

I think it depends on what you’re doing. The author of the the Reddit post mentioned he’s primarily working with data systems. I can see the appeal of someone running quick, ephemeral data analysis not wanting to deal with static typing. But for long term use cases the static typing guard rails is definitely nice.

repExpMon 5y ago
> I can see the appeal of someone running quick, ephemeral data analysis not wanting to deal with static typing I've seen and heard this, (Data science field definitely loves their Python and numpy) but I really believe the common problem of non-reproducible research is partly due to the language choice (and probably more to the root cause - this sentiment in research).

3pt14159 5y ago

I've been programming for over 20 years too, and I like dynamic languages. I like them a lot more when they're properly tested and well architected, but even the tire fire codebases are at least debuggable. The compiled stuff helps with types catching the trivial bugs, yes, but it's way too complicated to quickly debug things like seg faults. Dynamic languages let you introspect and modify things way more easily, and this makes things like fakes and mocks for testing way easier. It makes debugging easier. And not having to wait an hour for something to compile is nice. That said, I love the speed of compiled languages. I once converted a simulation from Python to Cython and saw a 10000x performance boost because of CPU caches and all that. Usually the gains are closer to 10x to 20x, but in some rare moments it's like a rocket ship vs a hang glider.

anyfoo 5y ago
EDIT: Reading again, I think you are comparing interpreted with compiled languages, not so much static with dynamic type systems. Seg faults are a prime argument for static typing. The more static and stricter the type system, the less things like seg faults can even happen. Compare Rust to C (both are static, but one more than the other), and at the extreme end handwritten assembly (extremely dynamic). Those are languages used by kernel developers, where errant memory accesses of all kinds are a constant concern. I don't know why dynamic languages would make introspecting things easier, or debugging in general. I agree that mocking can be easier with dynamic types. Compilation rarely takes long nowadays (incrementally it's usually just a few seconds), so the time saved in knowing that the code is still correct at least within the confines of the type system is well worth it.
- belorn 5y ago
  As an kernel developer, would you want to take some of the many shell scripts that the kernel has and rewrite them in C? Different tools for different purpose. Unless there ecosystem was really designed for it, I would not write a driver in a dynamic language. At the same time, I would prefer not to write all the bootstrap scripts during booting in C. If all I am doing is calling other programs, I use shell. If all I am doing is calling a bunch of low level system calls in a restricted environment I would use C. If I am doing a bunch of string editing, process flow management, data compiling with some calls to external programs, I would use a dynamic langue like Python. I want add a personal opinion in regard to C. Every function gives out an return code which is a kind of "type" that does not get enforced by the compiler. The return code is defined by the manual page and it is up to the programmer to catch it and react correctly to it. If the wrong code occur and the program explode during runtime its the fault of the programmer for not write a program that manage the return code. I would claim that the wast majority of crashes that occur in programs written in C is because programmers failed to realize the full list of possible return codes and what they mean. Here I do prefer dynamic languages because they usually do not leave it up to the manual to defined what return code -42 means compared to -41, and debugging errors when the errors themselves have class names and inheritance tend to be a bit easier in my experience.

wirrbel 5y ago

I mean by now it should be clear to everyone that there are certain trade-offs in the choice dynamic vs static typing. I do like clarity of static type declarations, also the absence of weird polymorphism like functions returning a number or al ist of numbers depending on their parameters, etc. But then, many statically typed code bases are just tested abysmally. It is as if the type signatures would constitute proper tests. I realise that you don't need to write as many tests in a statically typed setting, but in many cases - and esp. in underpowered type systems - the types won't test the program's logic.

anyfoo 5y ago
You do need to write less tests with a static language. The types in your program are proof that your program is correct within the confines of the type system (literally, even in the mathematical sense). The stronger the type system, the more properties can be proven through it (at the extreme end there are, unfortunately not Turing complete, languages where you can prove every single property--those are more used as theorem solvers however). Back to "common" statically typed languages, there is still heaps and loads to test, as you say. Not writing those tests is not really the fault of the language...
- wirrbel 5y ago
  I am bringing up this point that there are tons of miserably tested Java/C++/etc applications because its a problem correlated with their usage, just like runtime type-errors correlate with dynamic languages. A fair comparison mentions both. Of course a strong type system can drastically reduce the unit test coverage you need. But last time I checked, the strong type systems that allowed for this were all not used in our corporate code bases.