Made with KolourPaint and screenshots from Kate (with the GitHub theme).

  • Oriel Jutty :hhHHHAAAH:@infosec.exchange
    171·
    14 days ago

    Because let x: y is syntactically unambiguous, but you need to know that y names a type in order to correctly parse y x. (Or at least that’s the case in C where a(b) may be a variable declaration or a function call depending on what typedefs are in scope.)

    • HiddenLayer555@lemmy.mlOPEnglish
      111·
      14 days ago

      Can’t say I’ve ever experienced this kind of confusion in Java but that’s probably because they intentionally restricted the syntax so there’s no ambiguity.

    • Gamma@beehaw.orgEnglish
      5·
      14 days ago

      Also useful when the types are optional, like Python. Though they don’t use any let or var or anything so maybe throw that entire point out the window

  • charje@lemmy.ml
    15·
    14 days ago

    well, the : String is supposed to be optional right? type inference should know what it is. In truth though, return type polymorphism makes us write more type annotations than I would like.

  • Shanmugha@lemmy.world
    8·
    14 days ago

    My attempt of an honest answer to my best knowledge:

    As @TootSweet@lemmy.world mentioned, to make a programming language closer to spoken English language, most likely (hi, Python, I am looking at you too). Which infuriates me immensely: when programming, I do not speak languages, I express data structures and operations on them, stacked one upon another. The last thing I need here is ambiguity, loose structure and information duplication (forgot correct term for the last one) that are typical to natural languages of human communication

  • PowerCrazy@lemmy.mlEnglish
    92·
    13 days ago

    Enlightenment is realizing that variables don’t have nor need a type, they are all just arrays of bits.

    • balsoft@lemmy.ml
      12·
      13 days ago

      True enlightenment is realizing that variables don’t exist, it’s all just a sequence of bits in RAM that we assign meaning to as desired.

      Ascension is realizing that bits don’t exist, it’s all just trapped electrons in transistors which we imagine to be bits.

      Transcendence is realizing that transistors or code doesn’t exist, and it’s just some quarks and electrons attracted and repulsed by weird forces, vibrating and convulsing in a soup with entropy constantly rising until the heat death of the universe, of which we make futile attempts to make sense or purpose.

    • NotSteve_@lemmy.ca
      7·
      13 days ago

      Are you the person who’s writing these APIs that just return dynamically generated untyped JSON that I need to deal with on my team at work? Typing absolutely matters and I will die on this hill

      • PowerCrazy@lemmy.mlEnglish
        2·
        13 days ago

        How can my JSON response have any concept of Type? If I return a number and you treat it is a string, my API doesn’t have any concept of that. Now in the actual spec of the API I could say that specific URI will return an int, but it’s up to your side to classify the array of bits as an int instead of a str.

        • NotSteve_@lemmy.ca
          3·
          12 days ago

          I guess it’s less the response itself but the response objects in the codebase. The main code base I work on is fully typed Python/FastAPI but we depend on an API from another team that was, up until recently, untyped entirely. The responses were just dictionaries that were dynamically generated randomly in 10 layer deep functions. There was absolutely no way to tell what they would actually return, let alone what types they would be. It’s like, if you see a function that’s just called get_big_fat_entity_findings() with no typing, how would you handle that without spending an hour reading through the code line by line? Typing is important for any project that’s bigger than a quick script

  • ThirdConsul@lemmy.ml
    71·
    13 days ago

    To be honest I always disliked variable declaration without value assignment, so to me both options suck. :)

    • notarobot@lemm.ee
      5·
      13 days ago

      What about

      Let ret: Number
If (someCondition) {
    <a lot of expensive calculations>
    ret = resultOfOperations
} else {
    <a lot of other different expensive operations>
    ret = resultOfOtherOperations
}
return ret

      You can’t declare ret inside the brackets

      • ferric_carcinization@lemmy.mlEnglish
        4·
        13 days ago

        Rust would allow you to

        let ret = if some_condition {
    <a lot of expensive calculations>
    result_of_operations
} else {
    <a lot of other different expensive calculations>
    result_of_other_operations
};

        Now you don’t have to declare it inside the blocks.

          • ferric_carcinization@lemmy.mlEnglish
            4·
            13 days ago

            What’s disgusting about it? The only thing I can think of is the implicit return, which felt a bit icky at first.

            Also, as the if expression is an expression, you can call methods on it like so:

            if 1 > 2 {
    3
} else {
    4
}.min(5)

            (the above is still an expression, so it could be used, for example, as part of a condition for another if)

            Of course, you can write horrible code in any language, but the ability to use blocks where expressions are expected can be great sometimes.

    • CarrotsHaveEars@lemmy.ml
      2·
      13 days ago

      What about you declare (then it gets allocated in stack) it and pass it to a different context for assignment?

      • ThirdConsul@lemmy.ml
        2·
        13 days ago

        Well, I don’t know your use case well enough, but I guess you might have perfect reason for that behavior.

        One thing that comes to my mind is the old Try in C#

        bool parsedSuccessfully = int.TryParse("123", out int result);

        But I guess more popular approach would be to use Error as Values, right?

        E.g. something like this

        Outcome<Exception, Int> result = int.TotallyNewParse("123");
          • ThirdConsul@lemmy.ml
            2·
            12 days ago

            Great example.

            Wouldn’t getchar() be more appropriate here? Last time I used C it was 16 years ago.

            • CarrotsHaveEars@lemmy.ml
              3·
              12 days ago

              Yes, and no, sir, you missed the point. The procedure here is to allocate then give away, not reading a fixed-length returned value.

              Say you can only afford to have ten bytes in the stack. You allocate char s[10]; then give it to a library to parse something. Also telling it to abort if it’s going to be longer than ten bytes, of course.

  • ByteWelder@feddit.nlEnglish
    5·
    13 days ago

    In Kotlin, you can have the type become implicit with the former syntax: let text = number.toString() (text is a String here)