Dear Programming Languages,

if you only support weakly typed constructs, I wish you a special place in hell.

Dear Fellow Developers,

if you use a language that allows strong typing with weak typing, the next time we will meet after I have to fix a shitty bug due to that I will play piano on your teeth, and a melody you won't like.

And yes, that means PHP as well. PHP allows for strict types since php7.

So. Just. Fucking. Use. It.

There are no excuses!

I don't care if you don't see the benefit or find it "annoying" and tedious to write it out. Use a decent editor and it will be mostly code-completion anyway.

I just don't want to fix your fuckups. And if your fuckup is due to a typing issue that "slipped" by, you are part of the problem.

If you write software, it should be clear what type each and every variable or object has.

There are no excuses but your laziness.

If you want to be ambiguous, try poetry.

You contradict yourself: "If you write software, it should be clear what type each and every variable or object has."

I agree with that, which is why static languages just get in the way after a certain point. They offer no real benefit beyond restricting what you can do with the language and forcing you down a certain path, and therefore the only ones who benefit from it are poor programmers who can't keep their code straight without the language telling them what they can or cannot do.

Programming languages are like tools, and statically-typed languages are like a flathead screwdriver that refuses to work on a Phillips screw.

@runfrodorun Of course static languages are going to be simpler in their compiled form, because they don't need runtime checks, etc. The language can avoid a lot of that by the work it does at compile time. That's their nature.

But I'm arguing from the point of view of capability. If you're arguing there's a tradeoff between power and compiled efficiency, I'm not arguing that, nor am I saying that static languages don't have their place.

But the post was attacking dynamic languages in general as being flawed, and that I completely disagree with. They are far more powerful. And yes, with power comes responsibility and yes there are way more ways to fuck up in a dynamic language, but those are not good arguments to me. It's like saying that everyone should use matches because blowtorches are too dangerous.

@runfrodorun It may be more elegant to do certain things with, if those things are allowed by the language.

All I'm saying is I've run into too many limitations using statically typed languages that I've just grown sick of it, and working with a language that actually lets *me* do what *I* want is a breath of fresh air.

Also I'm not sure we're on the same page here. C# is a statically-typed language as far as I'm concerned. It may have runtime reflection/modification but I'd hardly call it a dynamic language like PHP/JavaScript.

precisely the main reason why i strongly dislike most of the "modern" and "hip" languages. js, python... programming is basically just transforming data, how are you supposed to do it properly when you have no (sane) way of defining and assigning the data types and structures?

@devios1 Let me rephrase.

When I am saying:

"If you write software, it should be clear what type each and every variable or object has."

Then yes, it should be clear. Yet to you, as, as a human being, it won't always be clear.

You assume you know. Yet you will forget. You will make those annoying and oh-so-preventable mistakes.

That timestamp needs to be formatted into an iso string? Ups. That weird API returns that particular field as a string even though it's just a number? Gosh. Why does my method crash even though -- oh I get a `null`.

It's not about being limited by the language. It's about catching bugs *before* they happen.

My IDE is configured so that whenever the types are not matching, I see a pink line and the file is marked as erroneous.

I haven't executed the tests yet, and I haven't even executed a thing.

Which is why I get mad if some lazy bastard comes along, does some `any` casting to implement their "quick fix" and prevents maintainability by other devs.

And yes, loosely typed languages allow for some clever dynamic coding. I have yet to see a valid use case for this cleverness.

It appears rather as a FUCK YOU shout to whichever poor souls comes after you having the misfortune of having to clean up your clevermess.

Maintainability and thereby readability and thereby trust in the data structures of the codebase is paramount.

I have lost too many hours debugging clever-ware.

Dynamic languages have their place, imho, but that place is limited to scripting and prototyping.

As a Java developer, I hate seeing java.lang.Object used in codebase, especially when you KNOW that the code consuming it is expecting something specific, and can't operate on something so generic. Now take this to 100% and you have a weekly typed language. No compile time checks. I can pass a Car to a function which expects Shoe as a parameter and I won't know I made a mistake until I run the code. Or worse, I use a library which returns data to me, I pass it to another library. They work for a while, then I upgrade, and shit starts to blow up. Why? Because they had no types defined in the contracts they were providing.

Of course this leads to doing adapters incessantly and converting data types and writing stupid code. But at least I can sleep at night knowing that my code won't be type tested in production.

@k0pernikus I hear ya. No arguments from me there. I wish I could have it both ways. Like if languages treated type violations as warnings instead. 😉

In the end every general program language is Turing complete, so they are all evenly powerful.

The only difference is the expressiveness, eg what can you program in 100 lines if code. This is higher in dynamic typed languages, for obvious reasons. But this comes at a cost, specifically type checking is not possible, which is a great feature of any language. So it is what you want to do.

I prefer dynamic language for small projects(<500 LOC) where you have an easy overview of all your code. But when projects and project groups get larger it, you can't have a good overview. So then I prefer strongly typed language.

BTW the dynamic part in c# should also not be used frequently, it is mainly added for interoperability with F#. So I think that c# is strongly typed. Reflection is a library, which is also possible with c++ when you generate enough Metadata. But any reflection should only be used in cases where no other way is possible.

@devios1 Yeah actually i said that. The expressiveness of a turing machine is very very low, so you absolutely don't want to write programs in such a automata, it's even worse than assembly.

Speaking abstractly, I see a programming language as an interface to the computer. It is my hands, reaching virtually into the realm of the infinitely possible. Dynamic languages that have fewer rules and are built upon simpler reusable concepts almost always tend to be more powerful because their pieces are more interchangeable.

Static languages on the other hand tend to impose a less abstract way of doing things and as a result you need explicit concepts like interfaces to increase abstraction.

You can still write dynamic code that is safe: you can check if a function is defined before calling it, etc. And if you want to forbid something you can throw an exception, though you do have to catch it at runtime, which is one of the tradeoffs.

But it's just as possible to be a bad programmer in a static language as it is to be a good programmer in a dynamic language. Maybe the effects are minimized, but I don't think the language should apologize for people who can't use it properly.

@micfort Sorry you're right I didn't mean to jump to conclusions there.

@runfrodorun There is 1 reason and that is metrics, that is very easy to do with reflection and more difficult to do directly on the original code, still possible but more difficult. But then you are treating code like data, and then to read that data using an API that's fine.

For the rest, yes theoretically that is possible, as i said, these are all turing complete, so what is possible in C++ without reflection is possible with C# with reflection and the other way around. But sometimes it is easy to decouple(which is a good thing) a library from the object it's working on. For example, serialization. In C# it about 3 lines of code, and with C++ you have a serialization function for every class (difference in expressiveness and more error prone). Another example for decoupling is unit tests, like NUnit uses reflection to find all the tests. Also dynamic loading of plugins, you can find classes that implement a certain interface.

But yeah it should not be everywhere.

@runfrodorun By the way, every language that runs on an OS handle memory access case by case. Memory for a process on any OS is not continuous and you get a segvault when writing outside your boundaries. This is al done by the combination of kernel and CPU.

Sure there are languages with more checks, but that is a matter of choice. But it also happens with C++ as with C# as with python.

@runfrodorun yes, very much so, and by the documentation, you have to write at least a serialize method for every class. If the class is a bit more complex, then you have to write a save and load method for that class. So yes it is possible, but with .Net serialization this all goes automatically and in C++ you have to write these classes. More code means more bugs. So yeah, it is possible and sometimes you need it's performance, but in my personal experience, most applications don't need that performance(not saying that it is not an issue)

Btw, this is easily solvable by creating code template that generate these kind of data classes. Then the only difference is that the templates do it at compile-time and .net does it at JIT-time(where I assume the reflection is cached, by compiling the serialization code)

@runfrodorun Sure, I tend to agree, but your are making a choice in safety against performance and i'm saying that a lot of programmers makes the choice of performance above safety. which in a lot of cases is not necessary. Also it is a choice in expressiveness against performance and I know that working for personal projects and projects with hard deadlines sometimes expressiveness is preferred.

Off-course this can back-fire when using dynamically types languages and everything becomes a mess because you haven't have your types straight.

@runfrodorun Yeah actually it was one of the libraries I actually enjoyed working with in C++. So I do encourage using that library, but it is a bit easier with .net using serialization(where reflection is used in a very structural way).

@runfrodorun Seriously you have won me over, that last argument. I have no words. It is that good.

Oh a shit flinging contest with @runfrodorun and I'm not part of! It's a good day

It's a joy to rag on you 😆

Edit: Disclaimer: this is a joke and should be taken as one 😄

I don't disagree with you, but but but what about job security ;)

Surprised nobody mentioned Rust.

@DLMousey That's my point: it should work. You and I know it'll work, but the language won't let you. That was the analogy.

@runfrodorun my comment