3 ms·
>yet programmers tend to prefer untyped languages to typed languages The more strongly typed a language is the more it forces you to think about the big pictur
by simias 8y ago
>yet programmers tend to prefer untyped languages to typed languages
The more strongly typed a language is the more it forces you to think about the big picture and architecture your entire application in a way that will map nicely to the type system. For instance with a language like Rust which is both strongly typed and integrates concepts like lifetimes into the type system you need to think long and hard early on about how your "data" and your "processes" are going to interact to figure out a way to map everything cleanly.
Doing this correctly requires a lot of experience. You need to be able to project quite accurately what your project is going to look like (lest you end up to refactoring everything a few weeks from now or worse, lose a lot of time fighting the type system instead of leaning onto it) and you need a deep understanding of your tools to figure out what's the best way to model it and the tradeoffs involved.
If you're a beginner it can be seen as overwhelming and maybe even counter-productive, let me code and stop bothering me about integer to string conversions!
At this point I'm tempted to draw the conclusion that "dynamic languages are for n00bs and static typing is for the 31337" but my self-awareness douche alarm is starting to beep very hard so I'm going to deviate and concede that many brilliant programmers seem to favor dynamic languages so clearly some strive in this environment. So instead I'm going to draw a weaker conclusion: while competent programmers may or may not prefer dynamic languages, beginners will almost certainly favor the more forgiving nature of dynamically typed languages. That biases towards dynamic languages in the general population (and especially the population who cares about engaging in language wars in the first place. Us experienced coders know that the only worthwhile debate is tabs vs. spaces. It's spaces by the way).
- hhmc 8y ago> The more strongly typed a language is the more it forces you to think about the big picture This is a good point. A straightforward corollary is that the size of the picture can be drastically different for beginners and experts. One would imagine that beginners work on more small toy projects than experts. In such cases the protections that static languages offer can seem less valuable, and the friction more painful.
- btilly 8y agoI believe that Steve Yegge got it right in https://plus.google.com/110981030061712822816/posts/KaSKeg4vQtz https://plus.google.com/110981030061712822816/posts/KaSKeg4v... and it is all about your political leaning. Or more precisely, it is about how much ceremony you are willing to go through for some promised benefit. If you're willing to go through a lot of ceremony, you're a software conservative. If you don't see a point to the ceremony (either because it gets in your way, or you don't believe that the promised benefit is no that big), then you're a software liberal. Which you are likely to be is a combination of a function of your personality, and what kind of software you write. It really isn't about competence. Competent programmers can fall into either camp. However there is a strong tendency for people to conclude that people who disagree with them are incompetent. As you just did. And then backed up to realize that there are good people who disagree with you. I would also disagree with your weaker conclusion. In general bad programmers agree with whatever role-model they have most recently imprinted on. If they've picked up a Java book that talks about typing, they assume that it is right and types are worthwhile. If they pick up a PHP book, then vice versa. The current popularity of Javascript and Python mean that a lot are going to be on the dynamic side, but far from all.
- veebat 8y agoI think most of the dynamic/static bias depends on the specific experiences of your problem domain. If you have a lot of types of data to model(layers of records, sequences, indirection, etc), dynamic types make it easy to start bodging something together, but result in write-only code. So you end up wanting to have additional structure and definition - maybe not immediately, but just after prototyping is done and you have a first working example. If you're just applying a routine algorithm that ultimately does a round trip from SQL, you don't need that additional assurance. The database is already doing the important part of the work. If you have simple data but it needs to go as fast as possible, you end up wanting to work at a low level, and then the machine size of the data becomes important - so you end up with a static types bias.