this post was submitted on 06 Jul 2023
50 points (100.0% liked)
Programming
423 readers
5 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Overall I agree with what the author says, though I have a few further thoughts:
These two arguments contradict each other and together are an argument for static typing, not against. Which just shows how weak these arguments are.
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.
I would go one step further here. It should support OOP and procedural paradigms as well. No single programming paradigm is best suited to all problems. Sometimes a mixed approach is best. Any language that heavily leans oneway at the expense of the others limits itself to the problems it can best solve. I do admit the far too many languages lean too much towards OOP at the expense of functional style.
So it is easy to push for a functional style over OOP in new languages. But I would be weary of purely functional language as well.
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.
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.
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.
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.
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.
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.
The main argument against strictly typed languages imo isn't that types are time-consuming to write, it's that they forbid some otherwise valid programs. When writing down your types you are forced to write down some of the assumptions you make about your data (which is usually a good thing) but all assumptions aren't necessarily possible or ergonomic to express in your given programming languages type system.
Overall I have a strong preference for statically typed languages as they (usually) make code more readable and help prevent prevent bugs, but it's important to not strawman fans of dynamic types either!
Can you give any examples of such "otherwise valid programs"? Because a lot of times static typing also has ways to do everything dynamic typing can but it is just more difficult or (obviously) won't have the benefits of static typing.
I think the way some dynamically typed languages use maps is interesting. In most languages if you have a hashmap, all values have to have the same type. In a dynamic language you can have some members be methods, some members be values of potentially different types and so on. Of course, depending on what you want to achieve, you might be able to use a struct for example. A map is more flexible though. You can union two different maps, or you can have a function that takes a map that has either a or b. It's not necessarily impossible to express this in static types either, but there are many things here that quickly become tedious to do with types that Just Work in dynamically typed languages.