16

Dynamically typed languages suck. God I hate them

It's like one big clunky free for all. I don't understand how people can work in Python or even JavaScript and tell me that they're good languages with a straight face

Not having proper autocomplete or documentation (a somewhat seperate issue of Python) is a kick in the stomach for productivity.
I've seen people advocate for using EXTERNAL DOCUMENTATION VIEWERS. WHAT

I hate not being able to enforce types so I can reason about little parts of my program. I hate not having an IDE that can actually help me. I hate having to see stupid grep'ed code snippets instead of nicely formatted javadocs. I hate having to double and triple check everything when trying to code. I hate handling effectively opaque values where I don't know anything about the type without looking it up. And I especially hate not knowing what types function parameters need to be.

Dynamic typing doesn't remove types. That, although completely unfeasible, I could respect.
Oh no, the types are still there. Just not for you

It's like solving a jigsaw puzzle with a blindfold on

Comments
  • 3
    Any language that has a whole ecosystem of other languages that "transpile" to it ... Well, maybe it has some issues.
  • 7
    Back when dynamic languages appeared, idea was to increase productivity by removing type enforcement and it worked, some were intended for scripting. Over years, when already tons of shit were written in them devs realized that types are necessary to keep code maintainable, so now most dynamic languages (python, php, javascript via typescript, most functional languages (have supported them for ages)) already support types by choice. Of course there’re room for improvement for some, but python and typescript has really powerful typing system.

    In the end, there are use cases where dynamic languages are much more suitable than static typed ones.
  • 1
    @SevenDeadlyBugs TypeScript has a kinda cool type system (string literals as types?) but Python just sucks. I don't see anything good about it. Not having atleast type annotations is inexcusable but they alone don't help much. Especially if absolutely no one (including the god awful Python standard library) is using them
  • 4
    There are type hints in python. Use them.
  • 1
    @irene I use them everywhere. Nobody else does though
  • 1
    @irene You can't use them for everything, though. Local variables declared in a for loop can't be hinted. Fields are also hard to hint (my ide doesn't care about them)
  • 1
    @irene type hinting doesn't necesarily a static typing i guess. Perhaps mypy would be a better alternatives
  • 1
    @wowotek Not using Python would be the alternative :)
  • 1
    @12bitfloat the types are deduced by the iterator. Isn't it?
  • 1
    @12bitfloat yes and also that would be a great choice to pick
  • 0
    @irene Well, yes. But you can't type it out, so you always have to check the type hint of the list you're iterating over
  • 0
    It just gives my anxiety being constantly unaware of the types I'm dealing with (and it's annoying). Especially for return values. You just have to treat them as opaque. Even if you check the documentation I don't feel right because it's not guarenteed that they actually give me that type
  • 0
    @12bitfloat but you know the types inside small blocks.
  • 0
    @irene True. And that's perfectly reasonable (because it's essentially just like type inference for local variables). I just want to have strongly typed with optional inferred instead of dynamically typed with optional hints. Especially function signatures and fields should be strongly typed
  • 0
    @12bitfloat they are strongly typed. But not statically typed.
  • 0
    @irene Statically I mean
  • 1
    /**
    * @type {YoMama}
    **/
    const mamaVar;

    done, there you have your hints.
  • 0
    If that would be anywhere near standard the documentation part of that would be fine (please note how this is a straight rip of javadoc comments :) ). But we have docstrings -- oh yeah, and you can't even document variables with docstrings. And this isn't even static typing anyways. The type of variable is THE most important property it has (right before the name) imo so why put it somewhere in a magic tag in a comment
  • 0
    @12bitfloat variable is just a label for some value. It doesn't necessary need a type.
  • 0
    @irene If you are declaring a variable, you wan't to store some value. If you have a value to store you know what the value is supposed to be. If you know what it's supposed to be, you know it's type. Dynamic/weak typing makes no sense in my opinion
  • 0
    Which is exactly my primary criticism about dynamic typing. The types still exist because they *are* important. It just doesn't show you them. What's the point of that?
  • 0
    @12bitfloat nope. It's not a value. It's a label. Dynamic typing makes perfect sense in this view.

    Weak typing is an abomination which should be eradicated.
  • 0
    @12bitfloat because often you don't need types but interfaces and different types can have same interfaces.
  • 0
    @irene Just because a variable is technically just a label doesn't mean we don't need strong types in practice. We do. 100% coverage tests are stupid
  • 0
    @12bitfloat python is strongly typed. Labels are strongly typed and do not treat values as of different type than they are.
  • 0
    @irene Interfaces are still types, though. And interfaces fit *perfectly* into static typing. Foo&Bar intersection types also exist in some languages
  • 0
    @irene I'm taking about static typing; the act of enforcing types of values stored in variables.
  • 2
    @12bitfloat no, interfaces are not types.
  • 0
    @irene Depends on your definition. For me they're types because I think statically typed
  • 0
    @irene Also name one advantage of dynamic typing over static typing with type inference
  • 0
    @12bitfloat reduction of the amount or labels. No need for several slightly different implementations which are different by only type names. No need for template atrocities like in C++ or any other strongly typed language which tries to solve the interface problem that way.
  • 0
    @irene Reducing verbosity is only good until you remove vital information from screen so you have to constantly remember it. "Several slightly different" implementations isn't due to static typing more because of inheritance instead of composition. And it might sound funny but it makes sense. If the types do the same thing but aren't logically related there's no reason they should share code. That makes it impossible to refactor properly. It also doesn't happen very often and if the are logically related you can either use inheritance or composition, why not.

    The template problem is very much a C++ problem. It also solves things Python can't do: Compile-time logic (Not that that's needed in a scripting language). Normal problems with verbose generic parameters can easily be solved with generic inference. I don't understand what you mean with "interface problem" though
  • 0
    @12bitfloat no, you can't use inheritance nor composition if all the interface is only one function name. It will reduce to interface hell if you would need to explicitly stated every used one-function interface you're going to use inside a complex type.
  • 0
    @irene Is that really a problem? I've been programming Java for quite a few years and I've never seen more than a handful of interfaces implemented in a single class. Even if that is the case in some codebases. I'd still rather type out all the interfaces in the class definition once and have it black on white than having to remember/imply that they should be implemented.
  • 0
    @12bitfloat it's just another way of doing things.
  • 0
    @irene Sure. I guess I personally just don't see the advantages of dynamic typing that would justify the disadvantages IMO
  • 1
    @12bitfloat you're just a Java verbosity adept 🙃
  • 0
    @irene Funnily enough it actually doesn't bother me too much
  • 0
    @12bitfloat heretic 😱
  • 0
    @irene My scripting language will be terse comparable to python though
  • 0
  • 0
    @irene Opposite of verbose. It'll look a bit like python
  • 1
    var pi = 3.1415; # float
    var one = 1; # int
    var zero = "0" # string
    var foo = pi + zero + one; # ???
    var bar = one + pi + zero; #???

    Full dynamic typing _can_ drive you nuts, allright.

    As for C++ templates, they aren't a problem but a very powerful tool and their own Turing complete language. (TMP)
  • 0
    @Yamakuzure Templates are great but only because we don't have anything better. They're *way* to verbose and restrictive compared to functional code which is essentially what they are
  • 3
    It gets worse. JSDoc generates documentation from a DSL in JavaScript comments. Since it cannot infer anything about types from JS itself (assuming no type annotations, but if you had them, it's not JS), you have to maintain all of that by hand, including location information to structure the HTML output.

    So you have a tool that offers to make life easier by generating documentation at the itsy bitsy price of hand-tweaking type information in comments because the language can't clue tools into anything.

    And the real kicker that no one seems to notice is that since everyone has gaps in their JSDoc, the generated docs are unstructured to the point that links and entire nav sections collide with the same names.

    Meaning you have to know where the original JSDoc comment or related code is to know what doc page you want to look at.

    Meaning you already know where the docs you wrote are in the code.

    Meaning you never needed generated docs.

    Meaning JSDoc did jack shit.
  • 1
    I call these 'hippie languages'.
  • 0
    @zyrolasting I don't like docs for dynamic languages anyway. They tell you what's *supposed* to be what but the code itself doesn't have to care about it. And while documentation is nice for humans, it doesn't help IDEs help humans
  • 0
    @12bitfloat What could be better?
    You can unify code for similar types and add specialization for types that need it.
    You can even make a template inherit from its own specislization. Makes storage constructs easy to write and powerful as hell.

    Well, I guess we have different experience on that matter... 🤔
  • 0
    @Yamakuzure Static typing 😉

    Documentation is great to establish a high level contract. But you need proper typing to ensure correctness (atleast to some degree)
  • 0
    Well if you love Java then of course you'll have that opinion. I personally work with C# and Python and both of them serve me well for when I decide to use them. Machine learning in Python is much simpler imo and I'll always use it for such
  • 0
    @SoulSkrix C# is no different in regard to types to Java, except type inference via 'var' (which Java now also has), which is exactly the type of type inference I'm advocating for.

    Again, if you like Python that's fine. I personally just don't understand how one can effectively use such a loose type system
  • 0
    I'm also not saying that there is no place for a language like Python, or even Python itself. Of course you need a "simple" language for scripting and glue logic. I just don't Python is good enough to be worth using
  • 0
    @12bitfloat erm... Templates *are* statically typed.

    I guess, being a Java guy, you do not have that much experience with C++ templates, do you?

    When you invoke a templated function, the compiler generates a variant with the types you use for the invocation. The same happens with templated structs and classes.

    In a non-templated language like C, you would have to Copy, Paste & edit for each type you use.
    And in C the function parameters are not a part of the function signature, so you have to name each copy individually.

    The strength of templating versus being typeless is, that it happens at compile time, not runtime.
  • 1
    I hate developers who overly rely on IDEs and fall flat when given a coding exercise in a plan notepad
  • 1
    @Yamakuzure your example is about weak typing. Not dynamic.
  • 0
    @Froot As someone who fixed one problem but broke syntax-highlighting in a VSCode plugin for 2 people, I'm feeling your comment right now.
  • 0
    If you knew what you were doing within the language, you wouldn’t be complaining right now.

    We all have our preferences, and that’s completely fine. But just because you can’t comprehend how to utilize a language properly, doesn’t make it a bad language.

    Stick to your preferred languages, and then we won’t have to deal with rants like this.
  • 3
    @Froot Why? Tools are there to help us and we all have our preferred ones. In my daily work, I am not paid to do coding exercises, I am paid to accomplish tasks. I my employer told me that autocomplete was for weaklings and they will henceforth only allow coding to be done in notepad, I would quit. Because my employer would be an idiot.
  • 0
    god dam enterprise nerds always talking shit.
    but thats ok. ima duck. ducks r happy.
  • 1
    @irene thanks, you are right, I confused the two terms. Sorry! 💐
  • 1
    @monkeyboy Agreed but it's a slippery slope from "this helps me to code faster and better" to "I don't really know of much it works, my IDE just makes it work for me"

    It's the latter that I hate
  • 2
    @Froot if you don't know what you are doing, no IDE in this universe can magically make you productive.
  • 0
    static types are for the weak.

    do you whine as much about the weather being different every day?
  • 0
    @nitwhiz I've never said templates aren't statically typed. That's what this thread is mainly about. I've your gonna hate me at least hate me for the right reasons
  • 0
    @nitwhiz I've dynamic typing is great then please actually respond to any of my points of criticism
  • 2
    @Yamakuzure Oh but that's the problem, you can. I've ran into countless examples of devs writing complete spaghetti and relying on eslint --fix to clean it up for example. While ESlint is not an IDE is illustrates the point
  • 0
    @Froot sure it does...

    ... I'd just wouldn't call that "productive" in a sense of "ending up with something feasible"... 🤔
  • 0
    @Froot if you wanna format your code by hand go ahead.
    I prefer to let the computer do the dumb stuff for me ;)

    I know what you mean and Ive met people like that but formatting isnt a great example tbh.
  • 0
    @musician I think it's a great example because if you format it by hand you get used to it and start writing that way, you learn. At first the linter is a cruch, bit you grow out of it. If you continue to write spaghetti and let the linter clean it up for you you'll always write spaghetti.
  • 0
    @Froot so what? Noone will care how I write my code as long as it looks good after I commit it. For me its faster to write spaghetti and let the computer do the formatting for me. I could format it by hand but why waste my time? I dont learn anything doing it.

    We have tools for a reason. Otherwise go back to writing code without syntax highlighting (since thats a crutch as well ;))
  • 1
    @musician @Froot There are two writers with perfect grammar. One punctuates by hand and the other writes for speed and then lets their editor fix grammatical errors. Their output quality is the same, and both have perfectly sound processes. Still, I'd rather hire the more careful writer because (s)he would adapt more quickly when an editor is unavailable. When I interview candidates, someone who (wisely) delegates to the computer gets docked points if they (unwisely) allow that to engender passivity.
  • 0
    @zyrolasting as I said I know how to format my code by hand but its faster to let the computer do it.
    So why not hire the guy who works more efficiently?
  • 0
    @musician That's where you're wrong. It's no faster if you're good at formating. I write code with little linting errors naturally at this point, and I'm no slower than I would be if I wrote spaghetti. If anything, I'm faster, because what I write reflects the outcome almost perfectly so I don't have to go over it again

    Edit: I assume you double check the changes your editor makes right?

    Edit: about the efficiency. Engineers don't get paid per line, at least good ones dont.
    If anything, the lines of code you write is inversely proportional to what you make. Less is more.
  • 0
    @Froot of course they dont get paid by loc's. Did I say that anywhere?

    To each his own. If you prefer to work like that its fine but stop assuming everyone who doesn't is a worse programmer because of it.

    Also its mostly little things like inserting semicolons / trailing commas and the correct quotes according to the coding standards that the linter auto fixes. If you prefer to do that by hand good for you. I certainly dont. Programming is taxing enough mentally. The less I need to worry about mundane things like that the more I can think about the important stuff.
  • 1
    @Froot @musician
    A good editor auto-indents. However, some do not auto-format everything according to my style guide.
    Visual Studio is such an example.
    The code I write is already well formatted, as I do this already and have the help of the IDE.
    But before I can commit, I have to run astyle over it to fix all the tiny things where VS thought it knew better than me, and those, where I slacked.
  • 2
    @musician @Yamakuzure I guess we'll never convince each other here 😀
    I still think writing code and then letting the editor fix it for you is perverse 😀

    PS: I might not have worded my point very well. I think autocompletions and the like is fine, I use that obviously. My point is that I want to know exactly what I write and thus autoformating my completed code is a no no for me
  • 0
    @musician Well, there's more to efficiency than auto-formatting code. Someone who autoformats code but produces tight coupling and technical debt is not always going to be more efficient over someone who writes code by hand that is likely to stay unchanged for a while.

    Hiring is complex, and I certainly wouldn't make a hiring decision based on someone's decision to autoformat in isolation. But attitude and habits do matter a lot. Assuming oneself to be more efficient than others (context be damned) and continuing to argue based on that speaks way more to impact on team efficiency than autoformatting itself.

    Let's say you deliver a patch sooner than everyone else. But, if you are also one to insists that we change our code to work with your tools, or produce code that costs a lot to maintain... Well, that can outpace any time savings you started with pretty quickly. Are you sure your code is perfect?
  • 1
    @Froot just to make this clear: none of my tools *fixes* code. The only one who fixes mistakes is me, after the compiler had its say.

    I guess I misunderstood you there. I thought of formatting tools like astyle or uncrustify. Not something that adds missing semicolons and stuff like that.
Your Job Suck?
Get a Better Job
Add Comment