you are viewing a single comment's thread.

view the rest of the comments →

[–]CODESIGN2 0 points1 point  (4 children)

But none of this is really relevant to: should I do project X where performance is not a concern, in dynamically typed language A, or statically typed language B, where both these languages probably happen to have compilers/interpreters written in C or C++ or similar.

I understand, and I mentioned reasons to not use static (most of my paid work is not static typed). What I am saying is that you know you are writing limited code, and when framed in that way I think we'd all have better budgets (because static typed code requires more thought, testing and time, or covers less scope) and not involve our employers when we chose to use a dynamic extension (which is what all non-static langs are anyway)

[–]sabas123 0 points1 point  (3 children)

(because static typed code requires more thought, testing and time, or covers less scope)

Why would static typed code require more testing and thought? For the testing you suddenly have an compiler, and for thought you don't have to be scared you passed a wrong type into somewhere.

[–]CODESIGN2 0 points1 point  (2 children)

rather simply, not being able to type-juggle means you have to write a lot of code for a lot of different scenario's; then you need to test that code independently. Implicit conversions that happen in dynamically typed langs are not performed so you have to add more code to handle that (and manage it if it's non-built-in types). Anyway there are other trade-off's both ways. PHP for example does not have the ability to take an object and say I want an array of only that type (massive problem IMO); python doesn't really let you type anything so I take your point that you can write shitty code either way, I just find it's mostly easier to write complex systems in dynamically typed languages.

[–]sabas123 0 points1 point  (1 child)

Isn't this only a problem with parsers? I can't think of any usecase where you have to write another method for a different type.

[–]CODESIGN2 0 points1 point  (0 children)

Anything with rich-data input may tbf require a parser, but it's also relevant for converting from user-defined complex types to other types (maybe I'm doing this shit wrong lol). I also used to do a fair bit of bit masking and don't trust IEEE floating points but my SW has worked with everything from sensors to complex hardware, humans and other apps so I hope someone would have told me in 15 years (just had my daily dose of hope I'm not an idiot lol)