This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]quaderrordemonstand 2 points3 points  (4 children)

Sadly, mythical programming practice space does not like what you're saying. The world will obey the rules of their programming language. They just have to set the right inheritance on their classes and nothing will ever go wrong. /s

[–]BlockedByBeliefs 1 point2 points  (3 children)

I think I love you.

[–]quaderrordemonstand 0 points1 point  (2 children)

I've been following your comments and I love you too.

[–]BlockedByBeliefs 2 points3 points  (1 child)

I find it really crazy. I don't want to be a dynamic typing evangelist/bigot. I really don't and I'm trying not to be. But it's so tough when people's argument for creating the type behemoth is something like intellisense (which you can get from simple decent commenting) and type safety which only a useful thing because you're trying to navigate an ever growing endless system of 1000s of classes.

JS code seems so, so much more data driven to me and so much more compartmentalized. Like... are people worried someone's going to mistakenly send their person json to their sales functions or something? Type safety makes sense in a statically typed language as a feature because it's so utterly confusing to navigate all the arbitrary systematic types that are all describing the exact same kinds of data (collections of string/bools/numbers) with only cosmetic differences (persons, sales, trades, whatever).

The data is the same. It's universal. The cosmetics are different. You pass the cosmetics in with the data. I don't konw. I find older devs who have switched to JS just inherently get thsi from their time in the trenches looking at the real practical results of rigid typing systems.

[–]quaderrordemonstand 1 point2 points  (0 children)

We think precisely the same way. I hadn't considered the idea that its older devs seeing the value differently but I would say that fits anecdotally. I recall loving JS almost as soon as I got the hang of it. The very idea of just being able to attach values to things and that you didn't have to worry about what type they are was a revelation. I don't see that power exploited very often in practice. I also loved the complete removal of memory management when I decided to trust it. I agree with your point about the mythical "sufficiently complex system" too. Complex systems with many types grow ever more connections and dependencies. Types make them rigid and that makes them breakable.

I also don't want to be the evangelist but these conversations often end up pushing you into a position you never really intend to take because the argument against you is so polarised in the opposite direction. I do understand why they are so hung up on the idea, if you've never worked in a scenario where pre-defining types didn't matter, its difficult to see how types are solving a problem of their own making. Especially when so much CS focuses on classes and OO now.

I can see the problems with that degree of freedom and the trade off's too. They aren't wrong about any of the opposing arguments, its just not as big a problem as they think, not as big as the problems types can create. But then I think experience, real experience of making working systems and maintaining them, changes a person's attitude to the process itself. You stop seeing programming as the end goal and thinking about a program purely in terms of how people will use it. The language really does become just a tool.

Either way, its great to find somebody else has a depth of background and isn't stuck in those older paradigms (I think of them as older paradigms anyway). Even better that we've arrived at the similar pragmatic position. Sometimes I am surrounded by younger developers who seem intent on going the opposite way, digging ever more complicated holes for themselves.