A unique argument for loosely typed programming languages

1 pointsunexaminedlife4y ago5 comments

I've been programming for a long time. Over the years I've become way too familiar with the back and forth arguments between different programming language philosophies. I've generally avoided the more religious of the arguments, but know from reading blogs and such that there are definitely plenty of people in the developer community with perspectives on the extreme ends of the spectrum. One of those debates has to do with strongly vs loosely typed languages.

Most of my career I've worked in languages that are on the more loosely typed side of the argument, but never immersed myself in the other end of the spectrum enough to have much of an opinion. Until recently. Because of the sheer number of jobs available for Java and C#, and those typically being the higher paying of the bunch, it's always been in the back of my mind that I probably should do some homework and bring those skills up to snuff.

It's not been difficult. I've been able to transition into these languages mostly seamlessly it seems. However, one thing I'm noticing is my productivity is way down. Part of that, admittedly, is because I'm less familiar with the languages. But now that I'm familiar enough I can take a step back and see pretty clearly that I almost certainly will NEVER be able to get to my previous levels of productivity simply due to the nature of these languages. The fact that they're statically typed seems to have "on its own" been responsible for perhaps as much as 60-80% of these languages' bloat. If I don't know how to do something in a loosely typed language I maybe have to refer to a single page of documentation. When working with strongly-typed languages though, I feel like sometimes in order to get the full picture of what I'm trying to do, I have to jump around to so many pages of documentation I find sometimes I need to step back to reflect on what it was I was trying to do in the first place to make sure I haven't drifted off on a tangent.

One argument that is pretty common is the fact that statically typed languages guarantee certain levels of completeness. If it compiles it probably works. Then again, when I look at the trade-off as to what is necessary in order to make that possible, I'd prefer to be independently proficient and (if necessary / desired) I'd want to be able to (as I've done many times in the past) complete large-scale projects on my own in their entirety in a relatively short period of time. I feel like having complete autonomy in what you're doing SHOULD be a virtue all of us as developers should really strive for.

Granted, our minds work differently and so it's obvious in the open source world that there are a few human beings who have the capacity to create enormous projects on their own in these languages. If I had to guess I would think it's not many people when compared to the number of people who work in loosely typed languages who have accomplished comparably grand achievements.

I don't know exactly how one would measure this, but knowing what I know now about both ends of this spectrum, I'd bet a pretty hefty sum of money that a far larger number of people have been able to achieve comparably amazing things using loosely-typed programming languages as compared with strongly typed languages. If anyone knows of actual metrics being used to track this sort of thing I'd definitely love to learn more.

5 comments

NotSwift4y ago

A good IDE can help tremendously in developing software. It can write a lot of the boiler-plate code that you consider bloat.

With a statically typed language the IDE and the compiler have a lot of information about your program. They can help finding and correcting errors. Good IDE's warn instantly when you are using an unknown function/method and they can even suggest how you could correct it. Also because the IDE knows all the types of variables it is able to show the source code for the corresponding classes and/or the official documentation for these classes.

With loosely typed languages, the IDE and the compiler do not have much information about your objects, so they cannot really help very much.

With loosely typed languages, many problems in the code will become apparent only when the code is running in production. I am probably old-fashioned, but there still some customers that really dislike problems in production systems.

quickthrower24y ago

I don’t think it’s a loose vs strong type thing. Changing languages and being productive is hard in either direction. I’d say I had the same experience from c# to JS.

If you are working in a team types are invaluable unless you have a very disciplined team.

The times I’ve worked on team JS or CoffeeScript code I’ve had to read hundreds of lines of code to understand wtf to pass into an argument. Aaah you want it to be a promise if the first arg is true but a number if it’s false kinda shit. Return type? Sometimes this sometimes that, might be a hydrated object from the wire as-is.

unexaminedlifeOP4y ago

I agree, there are way too many people in those languages that aren't disciplined about documenting what they're doing.

I think my argument certainly falls apart when considering those kinds of teams. Then again I have had the misfortune recently to experience some relatively undisciplined Java teams which creates a different set of problems. So on second thought maybe the discipline argument can go both ways.

What I typically have done when running a project was to require documentation of at least the inputs and outputs of the functions / methods they write. Also to make the names of those functions intuitive so people can get the gist of what it's doing just by reading the name. Also I definitely think it's a matter of discipline as well when people don't think clearly about what they're doing before they do it, which creates those wacky functions that return 5 different data types depending on the specific conditions.

ivxvm4y ago

I've never seen people pulling those "wacky" functions out of thin air on a whim. I usually see them rarely arising in places where they make sense. Like event subscriptions.

For example, in window.addEventListener("click", callback) callback is a procedure that receives MouseEvent, while in window.addEventListener("copy", callback) callback is a procedure that receives ClipboardEvent. So we can say that type of second argument depends on the string passed as first. TypeScripts type system is able to make this statically typed and type checked properly.

Any examples of "wacky" functions where similar dependencies exist but are not necessary?

1 more reply

j / k navigate · click thread line to collapse