Why are there so many programming languages? And why are there still being so many made? I would think you would try to perfect what you have instead of making new ones all the time. I understand you need new languages sometimes like quantumcomputing or some newer tech like that. But for pc you would think there would be some kind of universal language. I’m learning java btw. I like programming languages. But was just wondering.

    • Mic_Check_One_Two@reddthat.comEnglish
      21·
      1 year ago

      You got to it before I did. Programming languages are like vehicles. You wouldn’t take a sports car off-roading, and you wouldn’t expect a tractor to win a drag race. There is a lot you can do with an all-purpose vehicle, but it’s not going to be as good as something that is purpose-built for a single task.

    • Zalack@startrek.website
      13·
      1 year ago

      I actually don’t think that’s the case for languages. Most languages start out from a desire to do some specific thing better than other languages rather than do everything.

    • lysdexic@programming.devEnglish
      4·
      1 year ago

      If there was a single language, afterwards the same broken logic would be applied to frameworks and libraries, and we all know how many people bitch and whine over Java and it’s extensive standard library.

    • jeffhykin@lemm.ee
      1·
      1 year ago

      JavaScript (is the universal language) (is also the answer of why there are so many languages)

        • Freeman@lemmy.pubEnglish
          61·
          1 year ago

          No doubt they are probably better overall, especially when considering manufacturing. But I swear parts of my house where built with scraps (or the last guy was just a sociopath) and most of the time I encounter them it’s in some rare ass instance and it just pisses me off.

          Last time was when servicing my AC I noticed the breaker was bad (ie wouldn’t reset ). So I had to swap it and by code I needed to swap the box it ran on since it was showing signs. Sure enough 1 of 4 screws holding it to the side of the house is a fuckin Robertson head. So I was neck deep in fixing shit and had to stop and go find my random cup of bit heads out in the shop.

          Now I just carry a bit if I can remember it. But it’s hard to find screws sometimes so I just don’t use it to avoid exacerbating my own problems.

    • Steeve@lemmy.ca
      2·
      1 year ago

      In a lot of cases it feels a lot more like my mother in law buying me a new multi-tool every Christmas

  • explodified@lemmy.worldEnglish
    571·
    1 year ago

    Some languages have a obligation to support older versions, provide upgrade guides. They have old baggage in the forms of old systems or processes that they can’t just abandon.

    Sometimes it’s easier to just start over from a clean slate. Experimenting and seeing how it works. If it fails well you haven’t inconvenienced millions of users.

    It’s all about experimenting, trying to see what works, what it’s good with and what it’s not good with. A language like Java can’t just change to experiment things. Some people are also fixed to the style and methodology that Java provides.

    Aside from that, hobby languages are just hobbyist stuff.

  • glad_cat@lemmy.sdf.orgEnglish
    52·
    1 year ago

    You can’t easily improve a language and stay compatible with the previous versions. C++ does it but they are crazy.

    you would think there would be some kind of universal language

    It does not exist, but anyone is free to try and invent it. It should be low-level like assembly and high-level like BASIC, functional, object-oriented, and have weird stuff like traits, concepts, and alien features from Haskell. It must also have both the pointers/references of C++, and the borrow checker of Rust. And don’t forget to make it as secure as Ada with pre and post conditions. But it must still be easy to use. Also you will have to write a compiler for every operating system ever (mainframe, server, desktop, iOS, Android, every phone, every tablet), and contain a universal GUI that pleases everyone. It’s literally impossible to do right now.

    Last but not least, Java was supposed to be this universal language that you can run everywhere. It failed and it cannot be run everywhere. It also had to be improved a lot, and it’s missing a fuckton of features from every other language.

    • OmnipotentEntity@beehaw.orgEnglish
      14·
      1 year ago

      easily improve … C++

      I assure you that there is absolutely nothing easy about the C++ standardization process, lol.

    • stephenc@waveform.socialEnglish
      9·
      1 year ago

      I’d call it Paradox Lang, or PL for short. It even has features that are contradictory to each other, you just have to declare which mode you want at the top of every file. Can you imagine. :)

      The only feature it doesn’t have is “lightweight and minimal language”.

    • bleph@lemmy.world
      9·
      1 year ago

      Such an abomination could be created. Just imagine all the over engineering that would be required.

      It would run ANYTHING on ANY platform by incorporating every libc and assembler and VM and dynamic interpreter.

      It runs on EVERY platform and thus it can be adequately tested on NO platform.

    • complacent_jerboa@lemmy.world
      51·
      1 year ago

      It should be low-level like assembly and high-level like BASIC, functional, object-oriented, and have weird stuff like traits, concepts, and alien features from Haskell. It must also have both the pointers/references of C++, and the borrow checker of Rust.

      Hang on a minute. Isn’t that literally just Rust CrabLang?

        • complacent_jerboa@lemmy.world
          3·
          1 year ago

          I’ll take your word for it about the missing Haskell features, but with regards to inheritance, they deliberate chose to avoid it. They use an alternative model to achieve the same goals inheritance is meant for, but without the issues that come along with it. Their approach is basically a more advanced version of how Go uses interfaces to define shared behaviour.

            • complacent_jerboa@lemmy.world
              4·
              1 year ago

              It is pretty neat. They’ve made a lot of really interesting design decisions that make for a pretty unique language.

              One of its main selling points is how it guarantees memory safety without using a garbage collector. That, plus the fact that it does a shit-ton of compile-time optimizations, actually makes it pretty fast. Like, 80%-90% as fast as C (which is much faster than all the other high-level languages like Java, Go, etc, partly because they do in fact use garbage collectors).

              If you want to check it out, I recommend this playlist as a solid intro.

          • kono_throwaway_da@sh.itjust.works
            2·
            1 year ago

            Oh yeah, I get all of those, because I am a Rust programmer myself who hates OOP. :D

            I raised the topic up only because of how people were talking about “the ultimate language with everything”.

  • hascat@programming.devEnglish
    30·
    1 year ago

    Sometimes it’s easier to try a new idea in a new language (e.g. the borrow checker in Rust) rather than trying to shoehorn it into an existing language.

    • lysdexic@programming.devEnglish
      14·
      1 year ago

      Rust’s borrow checker is a bad example. There are already a few projects that target C++ and support both runtime and compile-time checks, not to mention static code analysis tools that can be added to any project.

      • hairyballs@programming.dev
        5·
        1 year ago

        Uh, they’re different, though. There is no C++ tool (AFAIK) providing an exhaustive check of ALL the data lifetimes. I even think it’s impossible, because their semantics are really different. Rust is move by default, C++ copy by default; Rust has no inheritance with its constructors, etc.

        • lysdexic@programming.devEnglish
          31·
          1 year ago

          There is no C++ tool (AFAIK) providing an exhaustive check of ALL the data lifetimes.

          Your reply reads like an attempt at moving the goal post.

          The initial point was “Sometimes it’s easier to try a new idea in a new language (e.g. the borrow checker in Rust) rather than trying to shoehorn it into an existing language”, to which I pointed the fact that yes it’s indeed possible to “try a new idea” like borrow checking, and it only takes adding a tool that runs in a post-build/unit test step. It’s simpler, easier, and does not force anyone to rewrite projects from scratch.

          Claiming “oh but it might not work as well” is not an answer or a refuttal.

  • mo_ztt ✅@lemmy.worldEnglish
    241·
    1 year ago

    Different programming languages have different types of strengths. C is good for bare-metal performance and hardware interactions, Python is good at versatile interactions with all kinds of software and systems, Node.JS is good for asynchronous operations, and so on. Some esoteric languages aim to make things easy (or make them possible in the first place), or make things faster, or more secure, or etc. The things you can write in one language don’t always translate to another, and sometimes people create a new language that makes things possible that didn’t used to be possible. Machine learning wouldn’t be where it is if everyone who’s currently using Pytorch was still using C and doing all their own memory management. I’m currently working on a project in Node that would be much more difficult in Java, because Node’s approach to asynchronous operations matches this problem way better than do the primitives that Java’s runtime makes available. And so on.

    Is any given language that gets created going to be the next Python? Probably not. But everyone who makes one has some kind of idea that there’s something unique and wonderful within it, and you can’t tell if they’re right unless you let it happen and see how it plays out.

    Edit: Okay lemme clarify: Node.JS is good for a particular type of (generally I/O bound) asynchronous operations. It makes simple things easy and fast, at the cost of making some complex things pretty much impossible, so there are a bunch of problems it’s not good for. Better with the caveat maybe?

    • TempestTiger@programming.dev
      4·
      1 year ago

      If you have time (and the inclination!), would you mind explaining why Java’s primitives aren’t as good as Node visa vie Async ops?

      • mo_ztt ✅@lemmy.worldEnglish
        101·
        1 year ago

        It’s not a matter of better or worse (in this particular case – there is such a thing as languages that are just plain bad). In my opinion, it’s just what you’re trying to do:

        So Node uses a multiprocessing model where your program won’t be interrupted in unpredictable spots – there are very specific places where a function might pause waiting for something to happen, and give way to another function, but during ordinary (“synchronous”) operations you can be guaranteed that the program won’t be interrupted. That makes things hugely simpler because in general, you don’t have to mutex-protect your data structures, you don’t have as many weird subtle bugs that only crop up during certain thread interactions that are extremely difficult to debug. That’s the upside. The main downside is that because it’s a single-threaded model, which means (a) you can’t easily scale up your program to multiple CPUs and (b) if you have a long CPU-bound operation, it’ll happily block the whole rest of your program from executing no matter how many problems that causes. It’s excellent for network-I/O-bound workloads, because you’re probably not heavy on computation and it’s simpler to program and more robust than using multithreading in that case. Although, you do have to learn some new primitives and make sure to be careful with CPU-heavy operations. Then there are a lot of workloads where it’s awkward to try to use.

        Java tried to do multithreading all the way from the ground up, to make everything thread-safe (which is actually pretty unusual for a full-featured runtime environment, because it’s a lot to take on). The upside is that if you need that, it’s gold; you can write your normal application and then run it on a 64-core processor and all of a sudden (relatively speaking) everything just works, which is great for massive-within-a-single-process scalability. The downside is that (a) you will get people who disagree vehemently with you on whether within-a-single-process scalability is worth the complexity cost you pay, and (b) if you’re just trying to write some code where you don’t care about threads, guess what? You have to care about threads. You need mutexes, you have subtle bugs and deadlocks, you have lots of extra testing headaches, or else: You can sort of close your eyes and run your Java application single-threaded, which defeats some of the purpose, and also God help you if later on you ever want to try to make it multi-threaded.

        Neither one I would say is right or wrong. There’s a whole third way, which is actually what most environments do, which is that you say that a lot of things in the runtime aren’t thread-safe, and so if you want heavy scalability you do it with multiple processes, and if you need threads you need to take on the responsibility of tiptoeing around the non-thread-safe stuff. That’s sort of a mess, which is why both Java and Node take different more coherent approaches to it.

      • Von_Broheim@programming.dev
        81·
        1 year ago

        There isn’t one, java is excellent for async and multithreading and it does it properly unlike node that fakes it by running on a single clever event loop or stealthily launches a bunch of node instances in the background depending on implementation.

        • mo_ztt ✅@lemmy.worldEnglish
          3·
          1 year ago

          I talked up above about my feelings on it – I did Java and J2EE programming for years back in the day, so I’m well familiar with Java and its very real strengths and very real weaknesses. There’s good and bad to the many-threads-in-a-process approach, and to the one-process-per-task approach, and to the one-thread-with-async approach. If what you’re looking for is many-threads-in-a-process, then yes, Java does it right. But if you’re looking for something else, maybe it’s going to be wrong. It just depends.

          Also can you explain a little more about the implementation that stealthily launches a bunch of node instances in the background?

        • TempestTiger@programming.dev
          2·
          1 year ago

          My bad, I was mostly curious about how it matched OP’s project better and why.

          When you say it does it properly, do you mean actually creating proper threads or something else?

  • CodeBlooded@programming.dev
    22·
    1 year ago

    Think about this: Why are there so many automobiles? And why are so many new models still being made? I would think you would try to perfect what you have instead of making new ones all the time. I understand you need new automobiles sometimes, like construction equipment trucks or some treaded military tanks. But for average daily driver you would think there would be some kind of universal automobile. I drive a Corolla btw. I like automobiles. But was just wondering.

    I’m not here to mock you, just providing an analogy. You can deliver just about anything in one language that you can with another. However, like the car, you might need a different type if you want more performance. Maybe you want a fast car. High performance cars often need a lot of attention, they need that premium gas, the mechanics demand higher pay! What if you only care about getting from point A to point B, and you’re more concerned with driving a car that’s cheaper to maintain, maybe there are just more car mechanics for that type of car, and the cost to pay them is cheaper.

    A C application that is very well tuned to manage memory and threads in the name of perfect performance will require more time and computer science knowledge to create when compared to a Python script that does the same thing, but in the most basic possible way running on a single CPU, running hundreds of time slower.

    Sometimes you need the performance, and often you don’t. Sometimes you need a treaded tank, sometimes you need a NASCAR, and most days the Corolla does just fine, it’ll even let you miss a few oil changes before things get bad.

    As to why we don’t perfect what we have now instead of creating more: technology changes, easier to work with abstractions come about, some people enjoy the hobby of creating a language, or maybe a niche language comes about with very specific trade offs for a very specific purpose, no one wants to break backwards compatibility by adding new features and syntax to their language - I’m sure there’s tons more reasons to list.

  • Hector_McG@programming.devEnglish
    221·
    1 year ago

    Partly because sometimes a particular language suits a particular problem set.

    Partly because people just like writing computer languages.

    But mostly because people mistake the fundamental problem of programming, which is programming is really hard. So someone comes along and thinks “Programming is really hard, it must be a problem with the languages available” and sets out to write a computer language that makes programming easy.

    But all that happens is they trade one set of difficulties for another set of difficulties. They might succeed in making writing the initial version easier, but make maintaining that code harder. Or they might solve some memory allocation problems, but create performance issues.

    Either way, someone will write a language because they think they will help solve the issue of programming being hard, and fail. Because the really hard bit about programming is about understanding everything the program needs to do, in microscopic detail, and translating that into a structure that best fits the problem; not the actual coding itself.

  • mspencer712@programming.devEnglish
    20·
    1 year ago

    Think of a programming language as a crutch for the human brain. Processors don’t need it: they don’t have to think about the code, they just execute it. Our mushy human brains need a lot of help, however.

    We need to think about things on our own terms. Different programming languages, different APIs that do the same thing, different object models, these all help people tackle new problems, or even just implement solutions in new ways.

    Some new languages have a completely different model of execution you may not be familiar with. Imperative languages are what we traditionally think of, because they work most similarly to how processors execute code: the major pattern used to make progress, do work, is to create variables and assign values to them. C, COBOL, BASIC, Pascal, C# (my personal favorite), Javascript, even Rust, are all imperative languages.

    But there are also functional languages, like ML or F#. (The latter, I keep installing with Visual Studio but never ever use) The main pattern there is function application. Functions themselves are first order data, and not in a hacky implementation-specific way like you’re passing machine code around. (I’ve only ever used this for grad school homework, never professionally, sadly.)

    And declarative languages like Prolog helped give IBM’s Watson its legendary open question answering ability on national TV. When you need a system to be really, actually smart, not just create smart-sounding text convincingly like a generative AI, why not use a language that lets you declare fact tables? (Again, only grad school homework use for me here)

    Programming is all about solving problems, and there are so many kinds of problems and so many ways to think about them. I know my own personal pile of gray mush needs all the help it can get.

  • lysdexic@programming.devEnglish
    161·
    1 year ago

    I would think you would try to perfect what you have instead of making new ones all the time.

    Perfecting what you have often leads to a completely different language. See C vs C with classes which ended up being C++.

    There is absolutely no problem with creating new languages. These are often designed with specific features in mind, and the success cases often offer features that are in high demand. Take for instance node.js, and how its event loop makes it a near ideal language for network-heavy applications that run on a single thread.

  • stephenc@waveform.socialEnglish
    161·
    1 year ago

    Well I guess I am part of “they” since I have my own programming language pet project. Why did I create it? Because I wanted to, mostly. Sure, there are also some finer language design choices I wanted to choose differently for my preference, but mainly I just wanted to learn how.