▲ 342 ▼ What are your programming hot takes? (lemmy.ml) submitted 3 years ago by 257m@lemmy.ml to c/programming@programming.dev 894 comments fedilink hide all child comments
[–] argv_minus_one@beehaw.org 134 points 3 years ago (6 children) Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It's like the assembly of type systems, except it makes your program slower instead of faster. permalink fedilink source hideshow 12 child comments replies: [–] Cratermaker@discuss.tchncs.de 28 points 3 years ago Nothing like trying to make sense of code you come across and all the function parameters have unhelpful names, are not primitive types, and have no type information whatsoever. Then you get to crawl through the entire thing to make sense of it. permalink fedilink source parent [–] NiftyBeaks@lemm.ee 7 points 3 years ago I'm not sure that's a hot take outside early uni programmers. permalink fedilink source parent [+] railsdev@programming.dev 4 points 3 years ago* (last edited 2 years ago) [deleted] permalink fedilink source parent [–] uniqueid198x@lemmy.dbzer0.com 4 points 3 years ago You can do typing through the compiler at build time, or you can do typing with guard statements at run time. You always end up doing typing tho permalink fedilink source parent [–] Boomkop3@reddthat.com 1 point 2 years ago I kinda wanna say... skill issue? But really, dynamic typing is great as long as it fits the problem your solving and you keep your types simple or even just primitive permalink fedilink source parent [–] Olissipo@programming.dev 1 point 3 years ago* (1 child) I like it in modern PHP, it's balanced. As strict or as loose as you need in each context. Typed function parameters, function returns and object properties. But otherwise I can make a DateTime object become a string and vice-versa, for example. permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) What happens when you coerce a string to a date-and-time but it's not valid? Where I'm from (Rust), error handling is very strict and very explicit, and that's how it should be. It forces you to properly handle everything that can potentially go wrong, instead of just crashing and looking like a fool. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago (1 child) My point is, you won't ever try. You'd only use "weak" variables inside the function you're working on. It's explicit when you absolutely need it to be, when the function is being called and you need to know what arguments to pass and what it'll return permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) A string being parsed as a date-time is presumably user input, which is potentially invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago (1 child) When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing. If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) By “user” I mean the person who is using the application. Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don't know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago you can easily forget to catch it and handle it properly Even if I coded the form by hand and that happened, it's on me, not on the programming language. But I don't, I use a framework which handles all that boilerplate validation for me. permalink fedilink source parent
[–] Cratermaker@discuss.tchncs.de 28 points 3 years ago Nothing like trying to make sense of code you come across and all the function parameters have unhelpful names, are not primitive types, and have no type information whatsoever. Then you get to crawl through the entire thing to make sense of it. permalink fedilink source parent
[–] NiftyBeaks@lemm.ee 7 points 3 years ago I'm not sure that's a hot take outside early uni programmers. permalink fedilink source parent
[+] railsdev@programming.dev 4 points 3 years ago* (last edited 2 years ago) [deleted] permalink fedilink source parent
[–] uniqueid198x@lemmy.dbzer0.com 4 points 3 years ago You can do typing through the compiler at build time, or you can do typing with guard statements at run time. You always end up doing typing tho permalink fedilink source parent
[–] Boomkop3@reddthat.com 1 point 2 years ago I kinda wanna say... skill issue? But really, dynamic typing is great as long as it fits the problem your solving and you keep your types simple or even just primitive permalink fedilink source parent
[–] Olissipo@programming.dev 1 point 3 years ago* (1 child) I like it in modern PHP, it's balanced. As strict or as loose as you need in each context. Typed function parameters, function returns and object properties. But otherwise I can make a DateTime object become a string and vice-versa, for example. permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) What happens when you coerce a string to a date-and-time but it's not valid? Where I'm from (Rust), error handling is very strict and very explicit, and that's how it should be. It forces you to properly handle everything that can potentially go wrong, instead of just crashing and looking like a fool. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago (1 child) My point is, you won't ever try. You'd only use "weak" variables inside the function you're working on. It's explicit when you absolutely need it to be, when the function is being called and you need to know what arguments to pass and what it'll return permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) A string being parsed as a date-time is presumably user input, which is potentially invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago (1 child) When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing. If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) By “user” I mean the person who is using the application. Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don't know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago you can easily forget to catch it and handle it properly Even if I coded the form by hand and that happened, it's on me, not on the programming language. But I don't, I use a framework which handles all that boilerplate validation for me. permalink fedilink source parent
[–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) What happens when you coerce a string to a date-and-time but it's not valid? Where I'm from (Rust), error handling is very strict and very explicit, and that's how it should be. It forces you to properly handle everything that can potentially go wrong, instead of just crashing and looking like a fool. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago (1 child) My point is, you won't ever try. You'd only use "weak" variables inside the function you're working on. It's explicit when you absolutely need it to be, when the function is being called and you need to know what arguments to pass and what it'll return permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) A string being parsed as a date-time is presumably user input, which is potentially invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago (1 child) When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing. If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) By “user” I mean the person who is using the application. Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don't know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago you can easily forget to catch it and handle it properly Even if I coded the form by hand and that happened, it's on me, not on the programming language. But I don't, I use a framework which handles all that boilerplate validation for me. permalink fedilink source parent
[–] Olissipo@programming.dev 1 point 3 years ago (1 child) My point is, you won't ever try. You'd only use "weak" variables inside the function you're working on. It's explicit when you absolutely need it to be, when the function is being called and you need to know what arguments to pass and what it'll return permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) A string being parsed as a date-time is presumably user input, which is potentially invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago (1 child) When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing. If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) By “user” I mean the person who is using the application. Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don't know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago you can easily forget to catch it and handle it properly Even if I coded the form by hand and that happened, it's on me, not on the programming language. But I don't, I use a framework which handles all that boilerplate validation for me. permalink fedilink source parent
[–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) A string being parsed as a date-time is presumably user input, which is potentially invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago (1 child) When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing. If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) By “user” I mean the person who is using the application. Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don't know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago you can easily forget to catch it and handle it properly Even if I coded the form by hand and that happened, it's on me, not on the programming language. But I don't, I use a framework which handles all that boilerplate validation for me. permalink fedilink source parent
[–] Olissipo@programming.dev 1 point 3 years ago (1 child) When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing. If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid. permalink fedilink source parent hideshow 2 child comments replies: [–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) By “user” I mean the person who is using the application. Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don't know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago you can easily forget to catch it and handle it properly Even if I coded the form by hand and that happened, it's on me, not on the programming language. But I don't, I use a framework which handles all that boilerplate validation for me. permalink fedilink source parent
[–] argv_minus_one@beehaw.org 1 point 3 years ago (1 child) By “user” I mean the person who is using the application. Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don't know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes. permalink fedilink source parent hideshow 2 child comments replies: [–] Olissipo@programming.dev 1 point 3 years ago you can easily forget to catch it and handle it properly Even if I coded the form by hand and that happened, it's on me, not on the programming language. But I don't, I use a framework which handles all that boilerplate validation for me. permalink fedilink source parent
[–] Olissipo@programming.dev 1 point 3 years ago you can easily forget to catch it and handle it properly Even if I coded the form by hand and that happened, it's on me, not on the programming language. But I don't, I use a framework which handles all that boilerplate validation for me. permalink fedilink source parent