You are viewing a single thread.
View all comments View context
23 points

Which is why I’m of the opinion that dynamically typed languages are evil. !!“false” should either be caught at compile time or raise an exception.

I’m thoroughly convinced that the only use of dynamically typed languages is to introduce bugs

permalink
report
parent
reply
4 points

Dynamically typed doesn’t imply it’s monotyped. And monotyped languages can work just fine, you just have to not hide different operations under the same symbols just differing by type like JS does.

The entire problem with JS is that it both is monotyped and it isn’t.

permalink
report
parent
reply
1 point

Isn’t the whole point of dynamic languages that they’re monotyped? They’re equivalent to a type system with only one type, any. Really, most dynamic languages are equivalent to having a single tagged union of all the different sorts of values in the language.

If you add additional types, you get into gradual type systems.

permalink
report
parent
reply
1 point

A language has dynamic types if the type-resolution is done at runtime. The other kind is static types, where it’s done at compile-time.

A language is monotyped if every value is compatible with every operation, so there’s actually no type resolution.

A language has explicit types if you declare your types, implicit ones if you can’t declare them, type derivation if declarations are optional but they exist and are static you declaring or not, or gradual types if declarations are optional but they exist and are dynamic you declaring them or not.

All of those things are different.

Also, some people will insist “types” can only be static. Go ask those people whatever is the name of the things Python have, because either they just invented some different words, or they are only trying to confuse you.

permalink
report
parent
reply
8 points

I am with you. To me these are non-obvious details, just a bug waiting to silently happen in production.

permalink
report
parent
reply
1 point

Why? IMO that’s perfectly valid. The various type coercions are sometimes crazy, but IMO the rule that non-empty string is coerced to true and empty string to false is very simple to follow. The snippet is not even a gotcha, I don’t see anything worth failing over. Putting “true” or “false” in a string doesn’t change that.

permalink
report
parent
reply
5 points
*

I am dumb. The more things I need to think about when reading code that is not the logic of the code, the worse it is. Any time I have to spend thinking about the peculiarities of the way the language handles something is time wasted.

I’ll give a very simple example, think like you’re trying to find a bug. Assume we’re in a dynamic language that allows implicit conversion like this. We can write our code very “cleanly” as follows:

if(!someVar) doSomething();

-> ok, now we gotta check where someVar’s value is last set to know what type of data this is. Then I need to remember or look up how those specific types are coerced into a bool.

When trying the same code in a statically typed language that doesn’t do implicit coercion that code will fail to run/compile so probably you’ll have something like this:

if(someVar.length() == 0) doSomething();

-> this time I can just look at the type of someVar to see it’s a string and it’s clear what the condition actually means.

The second option is both easier to read and less bug prone even without the type system. It takes maybe 3 seconds longer to type, but if your productivity in coding is that limited by typing speed then I envy you

permalink
report
parent
reply

Programmer Humor

!programmer_humor@programming.dev

Create post

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

  • Keep content in english
  • No advertisements
  • Posts must be related to programming or programmer topics

Community stats

  • 7.2K

    Monthly active users

  • 954

    Posts

  • 36K

    Comments