3 ms·

It does not matter. Your concerns are entirely academic. Simplicity wins. > I can call `qsort(arrayOfInts, num, sizeof(float), funcThatComparesTwoStrings)` Do

It does not matter. Your concerns are entirely academic. Simplicity wins. > I can call `qsort(arrayOfInts, num, sizeof(float), funcThatComparesTwoStrings)` Don't do this. Do "qsort(a, n, sizeof *a, compare)" > with absolutely no way for the compiler to tell me I'm doing something obviously wrong. In the event that it does not work, two things are very likely true. 1) it was a really dumb mistake. 2) you will notice immediately and can fix the mistake. The idea that everything must be caught by the compiler is narrow-minded and ultimately can't be achieved. Stop worrying about hypothetical problems that aren't problems in practice. There are enough real problems to work on.

hota_mazi 5y ago
> you will notice immediately No, you won't notice immediately. You will only notice when you run your code, because it will crash. And it might not crash right away, because the bad code is not being run, so you have a crash waiting to happen at some time in the future, which might have been avoided with a competent type system. Users of statically typed languages have a different understanding of "immediately" than you do. If the compiler knows my code will crash, it should simply refuse to compile it until I fix it. > The idea that everything must be caught by the compiler is narrow-minded and ultimately can't be achieved. Ah, the famous fallacy "We can't reach 100% so let's just be content with 0%". That's not how the world works. Static types provide not just non crash guarantees but plenty of other advantages (automatic refactorings, performance, code that's easier to read and maintain, etc...). You have just gotten used to a crappy developer experience because you are using a dynamically typed (or very badly typed) programming language. Get out of that boiling pot and be more exigent from your programming language, there are some very good ones available today which will make you go back to your statements above in a few years and think "Yeah... that was a pretty silly thing to say, but I know better now".
- jstimpfle 5y ago
  > You will only notice when you run your code How did you infer that that's not immediately? > If the compiler knows my code will crash, it should simply refuse to compile it until I fix it. Sure but what if it doesn't know that, then I won't complain about the next best opportunity, which is pressing F5 once and seeing the code I just typed doesn't work as intended. > Static types provide not just non crash guarantees How about no? > Ah, the famous fallacy "We can't reach 100% so let's just be content with 0%". If using a void-pointer parameter once in a blue moon for some convenience (callback function pointer), how is that 0% and not 99%? I recognize I've written too many comments, seeing as the replies are starting to get extremely poor. Ignoring the rest.
Zababa 5y ago
Since type safety is entirely academic, you should take a look at void (https://github.com/kyouko-taiga/void-lang https://github.com/kyouko-taiga/void-lang), it seems like the perfect programming language for you.
- jstimpfle 5y ago
  You should take a look at what I wrote, because I did not make any such claim.
  - Zababa 5y ago
    I've taken a look at pretty much all of your comments on this story, and that seems to be the logical conclusion of your stance on generics. I'm not really sure how you could think otherwise and write the comment I replied to, and lots of others in here. To someone that said "Even ignoring performance, it has no support for checking the types, which in C means it can easily mess up memory badly." you replied "It does not matter. Your concerns are entirely academic. Simplicity wins.". Type safety is a real concern, and lack of it has conséquences in the real world, often in the form of bugs or vulnerablities, but you seem deaf to any arguments so I don't see the point of arguing with you. Instead, I've linked you something that you might like.
    - jstimpfle 5y ago
      My point is there is no need to be so preconcerned about a rarely used function that requires giving up a little safety (in a place with very little "code entropy" even). Doing so does not equal giving up type safety completely, not even 1% of it. There are way bigger issues to address even in the best of codebases. > Type safety is a real concern, and lack of it has conséquences in the real world, often in the form of bugs or vulnerablities To me type safety is first and foremost a usability feature - already a primitive type system like C's saves tons of time when changing code. But is it a great concern with regards to bugs and vulnerabilities? Type safety is static, once you've run a particular section of code, you can be relatively sure that there are no type issues on that path. (Granted that to run all code sections even once can be lots of work). That is contrary to other types of bugs which might only show up on rare occasions, and possibly require malicious intent.

hota_mazi 5y ago

> you will notice immediately No, you won't notice immediately. You will only notice when you run your code, because it will crash. And it might not crash right away, because the bad code is not being run, so you have a crash waiting to happen at some time in the future, which might have been avoided with a competent type system. Users of statically typed languages have a different understanding of "immediately" than you do. If the compiler knows my code will crash, it should simply refuse to compile it until I fix it. > The idea that everything must be caught by the compiler is narrow-minded and ultimately can't be achieved. Ah, the famous fallacy "We can't reach 100% so let's just be content with 0%". That's not how the world works. Static types provide not just non crash guarantees but plenty of other advantages (automatic refactorings, performance, code that's easier to read and maintain, etc...). You have just gotten used to a crappy developer experience because you are using a dynamically typed (or very badly typed) programming language. Get out of that boiling pot and be more exigent from your programming language, there are some very good ones available today which will make you go back to your statements above in a few years and think "Yeah... that was a pretty silly thing to say, but I know better now".

jstimpfle 5y ago
> You will only notice when you run your code How did you infer that that's not immediately? > If the compiler knows my code will crash, it should simply refuse to compile it until I fix it. Sure but what if it doesn't know that, then I won't complain about the next best opportunity, which is pressing F5 once and seeing the code I just typed doesn't work as intended. > Static types provide not just non crash guarantees How about no? > Ah, the famous fallacy "We can't reach 100% so let's just be content with 0%". If using a void-pointer parameter once in a blue moon for some convenience (callback function pointer), how is that 0% and not 99%? I recognize I've written too many comments, seeing as the replies are starting to get extremely poor. Ignoring the rest.

Zababa 5y ago

Since type safety is entirely academic, you should take a look at void (https://github.com/kyouko-taiga/void-lang https://github.com/kyouko-taiga/void-lang), it seems like the perfect programming language for you.

jstimpfle 5y ago
You should take a look at what I wrote, because I did not make any such claim.
- Zababa 5y ago
  I've taken a look at pretty much all of your comments on this story, and that seems to be the logical conclusion of your stance on generics. I'm not really sure how you could think otherwise and write the comment I replied to, and lots of others in here. To someone that said "Even ignoring performance, it has no support for checking the types, which in C means it can easily mess up memory badly." you replied "It does not matter. Your concerns are entirely academic. Simplicity wins.". Type safety is a real concern, and lack of it has conséquences in the real world, often in the form of bugs or vulnerablities, but you seem deaf to any arguments so I don't see the point of arguing with you. Instead, I've linked you something that you might like.
  - jstimpfle 5y ago
    My point is there is no need to be so preconcerned about a rarely used function that requires giving up a little safety (in a place with very little "code entropy" even). Doing so does not equal giving up type safety completely, not even 1% of it. There are way bigger issues to address even in the best of codebases. > Type safety is a real concern, and lack of it has conséquences in the real world, often in the form of bugs or vulnerablities To me type safety is first and foremost a usability feature - already a primitive type system like C's saves tons of time when changing code. But is it a great concern with regards to bugs and vulnerabilities? Type safety is static, once you've run a particular section of code, you can be relatively sure that there are no type issues on that path. (Granted that to run all code sections even once can be lots of work). That is contrary to other types of bugs which might only show up on rare occasions, and possibly require malicious intent.