Stop comparing programming languages

  • Python is versatile
  • JavaScript is powerful
  • Ruby is elegant
  • C is essential
  • C++
  • Java is robust
  •  Xylight   ( @Xylight@lemdro.id ) 
    link
    fedilink
    English
    49
    edit-2
    4 months ago
    • Python is NameError: name 'term_to_describe_python' is not defined

    • JavaScript is [object Object]

    • Ruby is TypeError: Int can't be coerced into String

    • C is segmentation fault

    • C++

    • Java is

    Exception in thread "main" java.lang.NullPointerException: Cannot read the termToDescribeJava because is null at ThrowNullExcep.main(ThrowNullExcep.java:7)
    Exec.main(ThrowNullExcep.java:7) 
    
    • CSS j ust # sucks
    • Kotlin is type inference failed. The value of the type parameter K should be mentioned in input types
    • Go is unused variable
    • Rust is Compiling term v0.1.0 (/home/james/projects/Term)
      • Oof, slow compile times to target, of all things, the JVM? Implicit methods? Some(null)? Function call syntax where the difference between a tuple argument and a sequence of non-tuple arguments can be determined by whether or not there’s a space before the parentheses?

        There are definitely some major issues with Scala.

          •  sparkle   ( @sparkle@lemm.ee ) 
            link
            fedilink
            Cymraeg
            34 months ago

            I think that’s good when the objective is to improve the language. One key thing that holds many languages back is that they’re stuck with historical baggage, and it can be pretty difficult to replace/remove “outdated” stuff without breaking everything.

            I do not want to be stuck using Python 2, or Scala 2 (although there exist people who use Scala 2 instead of Scala 3).

        •  sparkle   ( @sparkle@lemm.ee ) 
          link
          fedilink
          Cymraeg
          2
          edit-2
          4 months ago

          I agree that the slow compile times are pretty bad (maybe even deal-breakingly for large projects). I think it’s kind of necessary for a language with as powerful of a syntax as Scala though, it’s pretty absurd how expressive you can get. Maybe if it didn’t target the JVM, it’d be able to achieve way faster compile times – I don’t really see a point of even targeting JVM other than for library access (not to say that that isn’t a huge benefit), especially when it has relatively poor compatibility with other JVM languages and it’s nearly impossible to use for Android (don’t try this at home).

          Even more so, I think that null handling isn’t nice – I wish it were more similar to Kotlin’s. One thing I’m really confused as to why Scala didn’t go all-in on is Either/Result like in Rust. Types like that exist, but Scala seems to mostly just encourages you to use exceptions for error propogation/handling rather than returning a Monad.

          A more minor grudge I have is just the high-level primitive types in general – it’s pretty annoying not being able to specify unsigned integers or certain byte-width types by default, but if it really is an issue than it can be worked around. Also things like mutable pointers/references – I don’t actually know if you can do those in Scala… I’ve had many situations where it’d be useful to have such a thing. But that’s mostly because I was probably using Scala for things it’s not as cut out to do.

          With the tuple arguments point, I get it but I haven’t found it much of an issue. I do wish it wasn’t that way and it consistently distinguished between a tuple and an argument list though, either that or make functions take arguments without tuples like in other functional languages or CLI languages (but that’d probably screw a lot of stuff up and make compile times even LONGER). I saw someone on r/ProgrammingLanguages a while back express how their language used commas/delimiters without any brackets to express an argument list.

          I think an actually “perfect” language to me would basically just be Rust but with a bunch of the features that Scala adds – of course the significant functional aspect that Scala has (and the clearly superior lambda syntax), but also the significantly more powerful traits and OOP/OOP-like polymorphism. Scala is the only language that I can say I don’t feel anxious liberally using inheritance in, in fact I use inheritance in it constantly and I enjoy it. Scala’s “enum”/variant inheritance pattern is like Rust enums, but on crack. Obviously, Rust would never get inheritance, but I’ve found myself in multiple situations where I’m thinking “damn, it’s annoying that I have to treat and as almost completely serparate”. It would especially be nice in certain situations with const generic traits that are basically variants of each other.

          Plus, I’ve always personally liked function overloading and default arguments and variadics/variadic generics and stuff, but the Rust community generally seems to be against the former 2. I just really hate there being a hundred functions, all a sea of underscores and adjectives, that are basically the same thing but take different numbers of arguments or slightly different arguments.

          The custom operators are a double-edged sword, I love them and always use them, but at the same time it can be unclear as to what they do without digging into documentation. I guess Haskell has a similar problem though, but I don’t think Scala allows you to specify operator precedence like Haskell does and it just relies on the first character’s precedence. I would still want them though.

          How it goes now, though, is I use Scala 3 for project design/prototyping, scripting, and less performance-sensitive projects, and Rust for pretty much everything else (and anything involving graphics or web). Scala has good linear algebra tooling, but honestly I’ll usually use C++ or Python for that most of the time because they have better tooling (and possibly better performance). I would say R too, but matplotlib has completely replaced it for literally everything regarding math for me.

          • Sounds like we’re actually in agreement about most of this.

            I’m okay with languages limiting their “expressive” power in order to provide stronger correctness guarantees or just limit how “weird” code looks; but this is largely because I’ve worked on many projects where someone had written a heap of difficult-to-understand code, and I doubt such limitations would be appealing if I were working strictly on my own.

            I also don’t really see the appeal of Java-style inheritance, but to be honest I didn’t use Scala for long enough to know whether or not I agree that Scala does inheritance “right”.

            It does make sense that Rust provides mutability in some cases where Scala doesn’t. Rust’s superpower, enabled by the borrow checker, is effectively “safe mutability.” I hope other, simpler languages build on this invention.

        •  odium   ( @odium@programming.dev ) 
          link
          fedilink
          10
          edit-2
          4 months ago

          That makes it versatile, not powerful.

          When I hear powerful language, I think of languages that are good at intensive tasks like assembly, c, rust, Python (because of numpy, pandas, pyspark, cuda, etc.).

          • Python is powerful because it easily wraps C libraries that do real work! Just kidding mostly.

            But yeah, js isn’t a language I would describe as powerful. Ubiquitous? More capable than you would expect given it’s history? Bloated?

        • if its acceptable to force javascript onto the backend and everywhere else, then why not write the frontend in rust, or anything else than can compile to wasm ?

            •  lseif   ( @lseif@sopuli.xyz ) 
              link
              fedilink
              1
              edit-2
              4 months ago

              javascript cannot be compiled natively for the backend or desktop either…

              also libraries like wasm bindgen allow a developer to write almost no javascript. and i wouldnt could a few lines of bootstrapping.

              im dont advocate for wasm when its not necessary. nor do i advocate for backend js when its not necessary.

              • Sorry, I’m not sure what your point is. I realize that you can almost completely avoid JavaScript, but the point I’m making is merely that there is a real technical limitation that limits the choices developers can make for front-end code, and although WASM is making great strides in breaking down that barrier (something I’ve been thrilled to see happen, but which is going much more slowly than I had hoped), the limitation is still there. Conversely, such a barrier has never existed on the backend, except in the sense that C limits what all other languages can do.

                • my point is that languages have their places.

                  javascript is great for the frontend. not just because it’s the only choice, but it’s also a lot easier to write code for ui than say, C or rust.

                  however i do not see a reason why it needs to run on servers or desktop apps, bar a few cases. i know node is popular, but i think fullstack devs just like to have everything in the same language, even if it makes it harder to use and slower to run.

                  likewise C, rust, go, whatever, are great for backends, embedded etc, but they shouldnt be ran on in the browser, unless there is a specific reason like heavy computation with little dom interaction.

                  just because a barrier does not exist doesnt mean that we should write programs in a language not designed for the domain.

  • What is C essential for anymore these days? Genuine question btw.

    I thought C++ was essential for microprocessor control, but that it depends and sometimes I gather people use C instead, but not always.

    Use the language that the company hires you to know:-).

      • It isn’t just a language, but it is a language - as it eventually gets around to saying, but it starts off by saying that it isn’t, then later corrects itself to say that it is, etc. I feel like the focus of this ignores the historical context of what C was written to be for - at the time there was like Assembly, BASIC, Fortran (?), other long-dead languages like was it A and/or A* or whatever, there was a B language too! (developed by Bell Labs, if Google can be trusted these days), etc. - and C was developed to be better than those. So saying that like it lacks type conversions is very much missing the point - those were not invented yet. A lawn mower also lacks those, but it’s okay bc it doesn’t need them:-) I am probably nit-picking far too many points, I suppose to illustrate that the style of the article became a hindrance to me to read it b/c of those reasons. But thank you for sharing regardless.