• vzq@lemmy.blahaj.zone
    1·
    5 months ago

    Rust is more like Esperanto isn’t it? It’s Latin, but regularized and with the rough edges sanded off.

    Python is more like Spanish. A billion speakers in the world, and really easy to pick up a few phrases, but a small European minority still think they run it.

    • geneva_convenience@lemmy.ml
      0·
      5 months ago

      Esperanto is just Spanish pretending to be a neutral language.

      Honestly a very bad language. Nothing intuitive or easy about it. It’s as well thought out as QWERTY.

    • x0x7@lemmy.world
      0·
      5 months ago

      If you think Rust has zero rough edges you might have drunk too much kool aid.

  • Mad_Punda@feddit.org
    1·
    5 months ago

    I suspect there’s more people who speak Python fluently than Esperanto. So that comparison sits very wrong with me. The rest was funny :)

    • zero_spelled_with_an_ecks@programming.dev
      1·
      5 months ago

      Esperanto always struck me as more perl-like with each part of speech having its own suffix like perl has $ for scalars, @ for arrays, and % for hashes. Though perl is probably more like a bunch of pidgins…

      • umbraroze@lemmy.world
        0·
        5 months ago

        Yeah, I was about to say.

        Perl 5 is like Esperanto: borrowed neat features from many languages, somehow kinda vaguely making a bit of sense. Enjoyed some popularity back in the day but is kind of niche nowadays.

        PHP is like Volapük: same deal, but without the linguistic competence and failing miserably at being consistent.

        Raku (Perl 6) is like Esperanto reformation efforts: Noble and interesting scholarly pursuits, with dozens of fans around the multiverse.

    • where_am_i@sh.itjust.works
      0·
      5 months ago

      Esperanto’s equivalent would probably be Haskell.

      Python is probably more like Spanish. Very easy basics, but then people from different regions of where it’s has spread out barely understand each other

  • Lysergid@lemmy.ml
    0·
    5 months ago

    Can anyone actually tell what exactly complicated in Java? Verbose, maybe it was at some point but I find it very straightforward and easy.

    • frezik@midwest.social
      0·
      5 months ago

      Its standard library reads like someone’s Object Oriented Programming 101 final project, and they probably got a B- for it. Everything works and follows OO principles, but they didn’t stop to think about how it’s actually going to be used.

      Let’s try to read a file line-by-line:

      BufferedReader reader = new BufferedReader(new FileReader("sample.txt"));
String line = reader.readLine();

      We’re having to instantiate two objects (FileReader and then BufferedReader) just to get an object that has a readLine() method. Why? Can’t BufferedReader take a file name on its own and work it out? Or FileReader just provides readLine() itself?

      Not only that, but being parsimonious with what we import would result in:

      import java.io.BufferedReader;
import java.io.FileReader;

      But we’re much more likely to be lazy and import everything with import java.io.*;. Which is sloppy, but I understand.

      I can see what they were thinking when separating these concerns, but it resulted in more complexity than necessary.

      There’s a concept of “Huffman Coding” in language design. The term itself comes from data compression, but it can be generalized to mean that things you do often in a programming language should be short and easy. The above is not good Huffman Coding.

      • Lysergid@lemmy.ml
        0·
        5 months ago

        Library built this way because it supposed to be flexible and provide ground for complex usecases. It can only be flexible if your API works with simple abstractions which you can then compose. It’s not driven by “I need this specific utility for this specific scenario”. That would be zoo you have in JS where you have 10 ways to iterate over array and 9 of them wrong for your scenario.

        Java’s OO is great because they design library with SPR principle in mind making sure there is few but good ways to do things.

        BufferedReader cannot accept file name because it makes arbitrary reader… well buffered. It’s not BufferedFileReader, even that would accept something like Path or File, not string, because File can be remote file, should Reader now know all possible local and remote protocols and path formats? What else it must do?

        Having it designed the way it is, allows Java to have utilities for various scenarios. Your scenario covered by standard lib too. See Files.readAllLines which, surprise-surprise, built on top of BufferedReader.

        • frezik@midwest.social
          0·
          5 months ago

          BufferedReader cannot accept file name because it makes arbitrary reader… well buffered. It’s not BufferedFileReader, even that would accept something like Path or File, not string, because File can be remote file, should Reader now know all possible local and remote protocols and path formats? What else it must do?

          You’re just describing the problem. Yes, I see where they’re going with this. It’s still a usability nightmare. I can’t think of another language that makes you jump through hoops like this on IO, and they get along fine without it.

          • PlexSheep@infosec.pub
            0·
            5 months ago

            I agree with you. It’s a neat design idea to make things a bit more maintainable perhaps, but it’s just annoying to program with.

        • vzq@lemmy.blahaj.zone
          0·
          5 months ago

          Library built this way because it supposed to be flexible and provide ground for complex usecases.

          It’s definitely that, and not the fact that it was written in the first half of the nineties when everyone and their mother was all in on OOP/OOD to the detriment of usability.

    • houseofleft@slrpnk.netEnglish
      0·
      5 months ago

      I think a lot of it is “ceremony”, so it’s pretty common in java to:

      • create a get method for every object variable
      • create a set method for every object variable

      Then add on top that you have the increased code of type annotations PLUS the increased code of having to check if a value is null all the time because all types are nullable.

      None of that is hugely complicated compared to sone of the concepts in say Rust, but it does lead to a codebase with a lot more lines of code than you’d see in other similar languages.

      • houseofleft@slrpnk.netEnglish
        0·
        5 months ago

        Before someone says it, I know a lot of this stuff doesn’t need to be done. I’m just giving it as examples for why Java has the rep it does.

        • WhyJiffie@sh.itjust.worksEnglish
          0·
          5 months ago

          i still don’t understand. is it easier in python or JS to make getters and setters? with python my experience has been the opposite, with the decorator based solution in mind.
          or if the problem is that they exist, as an option to be used, why is that a problem? they can be implemented in any other language, and it can be useful.

          then yeah, you should check for nulls. just like for None’s in python, or if you have the correct type at all, because if it’s entirely different but ends up having a function or variable with the same name then who knows what happens.
          then in javascript besides null, you also have undefined and NaN!

          • houseofleft@slrpnk.netEnglish
            0·
            5 months ago

            It’s not easier to do getters or setters but especially in python there’s a big culture of just not having getters or setters and accessing object variables directly. Which makes code bases smaller.

            Same with the types (although most languages for instance doesn’t consider None a valid value for an int type) Javascript has sooo many dynamic options, but I don’t see people checking much.

            I think it boils down to, java has a lot of ceremony, which is designed to improve stability. I think this makes code bases more complex, and gives it the reputation it has.

            • WhyJiffie@sh.itjust.worksEnglish
              0·
              5 months ago

              I think it boils down to, java has a lot of ceremony, which is designed to improve stability. I think this makes code bases more complex, and gives it the reputation it has.

              I’m not a java programmer, but I like it more because python and js projects are often very messy

        • WhyJiffie@sh.itjust.worksEnglish
          0·
          5 months ago

          i still don’t understand. is it easier in python or JS to make getters and setters? with python my experience has been the opposite, with the decorator based solution in mind.
          or if the problem is that they exist, as an option to be used, why is that a problem? they can be implemented in any other language, and it can be useful.

          then yeah, you should check for nulls. just like for None’s in python, or if you have the correct type at all, because if it’s entirely different but ends up having a function or variable with the same name then who knows what happens.
          then in javascript besides null, you also have undefined and NaN!

    • dejected_warp_core@lemmy.world
      0·
      5 months ago

      Java itself is kind of blissful in how restricted and straightforward it is.

      Java programs, however, tend to be very large and sprawling code-bases built on even bigger mountains of shared libraries. This is a product of the language’s simplicity, the design decisions present in the standard library, and how the Java community chooses to solve problems as a group (e.g. “dependency injection”). This presents a big learning challenge to people encountering Java projects on the job: there’s a huge amount of stuff to take in. Were Java a spoken language it would be as if everyone talked in a highly formal and elaborate prose all the time.

      People tend to conflate these two learning tasks (language vs practice), lumping it all together as “Java is complicated.”

      $0.02: Java is the only technology stack where I have encountered a logging plugin designed to filter out common libraries in stack traces. The call depth on J2EE architecture is so incredibly deep at times, this is almost essential to make sense of errors in any reasonable amount of time. JavaScript, Python, PHP, Go, Rust, ASP, C++, C#, every other language and framework I have used professionally has had a much shallower call stack by comparison. IMO, this is a direct consequence of the sheer volume of code present in professional Java solutions, and the complexity that Java engineers must learn to handle.

      Some articles showing the knock-on effects of this phenomenon:

    • beveradb@lemm.ee
      0·
      5 months ago

      Char count for same functionality is still at least double in java vs python. It just feels like a chore to me. jetbrains helped, but still python is just so light

      • Lysergid@lemmy.ml
        0·
        5 months ago

        Char count is poor complexity metric. Perl is better than Python with your logic as it is more condensed.

  • dosuser123456@lemmy.sdf.org
    0·
    3 months ago

    basic is like toki pona then i guess, like python but even easeier

    no wait, that ones gray snail (minimalist vocabulary: it has only 4 commands)

    • CheesyFox@lemmy.sdf.org
      0·
      5 months ago

      the thing with russian is that it’s not spoken only by russians. Russian-speaking part of the internet is quite large actually.

  • bonus_crab@lemmy.world
    0·
    5 months ago

    Rust is esperanto because its only actually used by a small group of nerds,

    python is russian because everything made in it is unreliable.

    • sexual_tomato@lemmy.dbzer0.com
      0·
      5 months ago

      Python is Spanish; a ton of people learned a bit in school and never picked it back up again. Places that speak it natively all have their own conventions because, even though the native languages were replaced by colonizers, a lot of the native languages patterns remained in place. Most places that speak it are super welcoming and stoked that you’re trying to learn.

    • Dessalines@lemmy.mlOP
      0·
      5 months ago

      I was tempted to say Ruby, but based on my friends that are learning (or tried to learn Japanese), it seems like Ruby is trying to be the opposite. So not sure.

      Ruby would maybe fit with toki pona : terse, simple, predictable.

      • MBM@lemmings.world
        0·
        5 months ago

        I was going to say toki pona is not quite brainfuck but at least somewhere in that direction, with its tiny vocab

      • SkunkWorkz@lemmy.world
        0·
        5 months ago

        Ruby is literally Japanese. It was invented there. Plus a Danish guy popularized it outside of Japan. Like how weebs spurred interest in Japan and the Japanese language outside Japan.

      • Match!!@pawb.socialEnglish
        0·
        5 months ago

        as someone with some knowledge of japanese, japanese is extraordinarily terse, simple, and predictable. anyone who’s seen some anime should be familiar with this - there’s an incredible number of set phrases that carry a conversation in a precise way (that minimizes surprise)

      • PlexSheep@infosec.pub
        0·
        5 months ago

        The something else is called kanji, and are very complicated characters stolen from China with many meanings and pronunciation. Learning Japanese is very 楽しい (it is really)

  • CanadaPlus@lemmy.sdf.org
    0·
    5 months ago

    Гарантийный без ошибка памяти!

    I unironically think it would be hilarious to write a borrow checker for Адрес.

      • CanadaPlus@lemmy.sdf.org
        0·
        5 months ago

        Not surprised. The Russian Wikipedia page on it is just a stub. The English one is actually longer.

        I can’t find any online introductions to it or compilers for it either, in English or написал по-Русски. Or Ukrainian for that matter, assuming I’d know it if I see it, although the Wikipedia page is longer.

  • Snot Flickerman@lemmy.blahaj.zoneEnglish
    0·
    5 months ago

    Literally all of these languages are rooted in English.

    C: printf()

    C++: cout

    JavaScript: document.write() or window.print()

    Java: system.out.println()

    Python: print()

    Rust: print()

    Exactly zero of those reference a language other than English. I’m not even a linguist and this is just silly. It’s literally part of why English is becoming the dominant world language, because if you learn computer programming you basically have to learn English.

  • Codex@lemmy.world
    0·
    5 months ago

    I guess assembler is sumerien then, only still written and understood? And cobol or fortran? Linear a and b?