76
you are viewing a single comment's thread
view the rest of the comments
[-] NiftyBeaks@vlemmy.net 3 points 1 year ago

These two arguments contradict each other and together are an argument for static typing, not against. Which just shows how weak these arguments are.

The way I read it, he wasn't suggesting that was a good argument at all. He was just explaining what he believes dynamic type enthusiasts say.

This bit I am not convinced by. Inferring the API of a function from its body makes it harder to see breaking changes when you refactor the body. It can be useful for internal private helpers, but IMO public APIs should be explicit about their signature.

Well, in F# at least, this inference is the default. However, anybody can still fully type out the function signature. I think I get what you are saying, but in the case of a public API or interfaces the programmer can simply just add the type specifications.

I would go one step further here. It should support OOP and procedural paradigms as well.

Yea I somewhat agree with this. Though I mostly abhor OOP, it taken in small doses can be good. And procedural programming is always invaluable of course.

[-] nous@programming.dev 4 points 1 year ago

The way I read it, he wasn’t suggesting that was a good argument at all. He was just explaining what he believes dynamic type enthusiasts say.

Oh I read it the same way. I was just pointing out how much those two arguments contradict each other and that alone is almost enough of an argument without the extra ones the author gave. Though at the same time they are a bit of a straw man.

Well, in F# at least, this inference is the default. However, anybody can still fully type out the function signature. I think I get what you are saying, but in the case of a public API or interfaces the programmer can simply just add the type specifications.

But the problem with this being the default is most people wont go through the extra steps involved when they dont need to - which means you cannot really benefit from it most of the time. And the author implies that inferred types from bodies are always (or almost) the better option - which I disagree with.

Though I mostly abhor OOP, it taken in small doses can be good

Do you though? Or do you abhor inheritance. There are a lot of good ideas from OOP style code if you ignore inheritance (which was not originally part of the definition of OOP, in fact the original definition was very similar to some traits of function styles). It was only in later years and more modern times that OOP and inheritance was intertwined and IMO as a style it still has a lot to offer if you drop that one anti-feature.

this post was submitted on 06 Jul 2023
76 points (98.7% liked)

Programming

17025 readers
187 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS