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.
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.
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?
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.
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.
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?
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.
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.
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.
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.
A given programming language often has limitations which are largely different than the limitations from others. This means that different languages are often used on different kinds of problems. Want something fast, use C. Want to write something quickly, use python. Want it to run on just about anything, use Java. And so on.
So why don’t we make one ultimate one or a few that fulfill all needs? Well, partially because we haven’t figured out how to do that, but also it’s really easy to learn yet another language once your understand how they work. I can write in python, js, c, c++, c#, Java, kotlin, rust, perl, ruby, php, forth, lisp, and I could keep on going for quite a while. The underlying concepts are largely the same and so picking up a new language is no big deal (though being good at it is a bigger deal). We have so many because ultimately it just doesn’t really matter that we have so many.
Different languages take different approaches and models to do stuff. Thus making each one better or worse for different challenges.
For example, python is easy and quick to get up and running. Bug it’s slow and unsuited for low level programming (like OSes, drivers, and embedded stuff). On the other hand, C is very fast and very low level, allowing you to make both high performance programs and low level stuff, but it’s a nightmare to use and you will run into all sorts of problems that an easier language, like python would avoid. All of this is mostly due to python being interpreted (instead of compiled) and c having manual memory management.
But they might also take a different approach at computation, like for functional languages (opposed to imperative languages) which try to solve problems in a more “mathematical” and declarative way, instead of defining a sequence of instructions.
Or, even more, logic programming languages, in which you define a series of logical statements and the language tries to find solution and draw conclusions from them.
And some languages are designed around some particular concept that they think is beneficial and worth exploring, maybe taken from various other languages and put together, like rust which is designed around the RAII design pattern and takes large inspiration from functional languages, while still being and imperative procedural language (like C, so not object oriented).
Or java which was designed to be a portanle but performante object oriented language, with support for low powered embedded system, full of features but simpler than c++, etc… all stuff that now is nothing special, but remember that java us very old.
Or kotlin which tries to be java (they are interoperable), but modern and better and more “pure” or “consistent”.
Or c++ that started as an object oriented superset of c, but then started adding every single feature of every other imperative language, and never giving up on older stuff, to the point of becoming very hard to use correctly while making it very easy to screw yourself in the most intricate ways.
And of course there are domain specific languages (opposed to general purpose languages). Which aren’t even necessarily Turing complete. They are designed for one purpose only, and they do that better than general purpose languages. For example AWK for text processing, or SQL for databases, or matlab for scientific calculations, or TeX for typesetting, or GLSL for shaders, or coq for theorem proving. And here imagination truly is the limit.
So, the point is, every language is more suited then other for some kind of work. And when people stumble across some problem that is hard to tackle and come up with some approach to solve it, or when they grow fed up with the issues of some older languages, they often like to make a new language around that. And some times this leads to entirely new paradigms which are worth exploring.
Generally the most supported language on the tool/platform you want to target is the best one. Like SQL on databases, JS/ES in browsers, python in data science related stuff, etc. If multiple are heavily supported then just pick the one that’s the most comfortable.
It’s not a dumb question. The answer is “it depends”, it’s mostly a choice. The general rule is that when yo start a project, you choose the language that you think will help you the most, whether that is because you already know the language, or because you have to work with stuff that already use that language, or because the language is better at doing that.
Regarding whether to stick to a language or learn a new one, in general your CS teachers will tell you (and they are correct) that you should not “learn to program in a language” but just “learn to program” and then apply that knowledge to whatever language you need. So, you should always learn languages that are different from the ones you already know in order to learn new paradigms, and then when you need a specific language, just learn the details about it.
BUT, even if this way you will be able to use most languages, you will not be “good” at most, so you should also have some languages that you know really well and are experienced in. And for that you should choose the ones that are more useful to you (or maybe useful for your job) or the ones that you like.
Rust is based off of C/C++
Ruby is based off of Perl, Smalltalk, Eiffel, Ada, BASIC, Java, and Lisp
Just a couple of examples. Quite frankly, it’s dependent on what system, what infrastructure .etc that’ll be the call for a specific programming language. Nothing wrong with just picking one or two and sticking to them.
And I think that’s what a lot of beginners in wanting to study programming languages can fall into, they want to be the jack of all trades in programming. But there’s this problem of a new language coming in all of the time and it can get very wiry trying to remember them all.
If any of you happen to still be on Reddit, I actually maintain a “catalog” of these newer languages, as they come across my radar. One of my more recent finds is MiniScript, which the author of that has been using to port a fair amount of classic BASIC games from that GitHub archive I posted about recently. I got sucked into Nim, which seems like a good synthesis of Python, Javascript, and C++; c/nim exists for anyone interested.
Yeah but javascript has 473 popular frameworks and counting, and the churn is immense. Your codebase becomes out of date before you’ve finished writing it.
And the debugging?! I’ll try to finish writing this paragraph despite the uncontrollable twitching. Let’s just say that javascript is the kind of language that looks at your car with a missing left front wheel and says “let’s go”, while your IDE whispers “Yes, but maybe just don’t turn right. Certainly don’t turn right fast, unless you want to of course.”
Yeah but javascript has 473 popular frameworks and counting, and the churn is immense. Your codebase becomes out of date before you’ve finished writing it.
That’s not really the case anymore, it was back at around 2015 for a few years when nodejs blew up and we realized that JS is capable of much more than we initially thought.
We threw a thousand different things to the wall and a few frameworks stuck. Today the ecosystem is pretty stable, especially of you choose a popular framework like React or Angular.
Who said you need to use a framework? vanilla-js.com
Yes, debugging is a pain and the language fails in many aspects and I also hate it but I also realized it is the future and everything else will fade away.
I’m somewhat on the fence about this. Having the frameworks provide some of the functionalities built-in was pretty nice. Having some of that structural opinion to work off of meant I’m not wasting time just figuring out how to architect the whole thing from scratch. At the same time, I would prefer to stick with vanilla, so it’s less overhead and perhaps, the debugging would be more straight-forward. Trying to decipher React’s large error messages was irritating at best.
There are a lot of people with a lot of opinions and preferences that are trying to do a lot of different things in a lot different ways. The same reason we have so many of anything.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
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.
This is why we need low code solutions /s
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?
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?
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.
Tysm for your response! Really appreciate it (◍•ᴗ•◍)✧*。
No problem, glad it was helpful 👍
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.
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?
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?
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.
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.
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.
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.
A given programming language often has limitations which are largely different than the limitations from others. This means that different languages are often used on different kinds of problems. Want something fast, use C. Want to write something quickly, use python. Want it to run on just about anything, use Java. And so on.
So why don’t we make one ultimate one or a few that fulfill all needs? Well, partially because we haven’t figured out how to do that, but also it’s really easy to learn yet another language once your understand how they work. I can write in python, js, c, c++, c#, Java, kotlin, rust, perl, ruby, php, forth, lisp, and I could keep on going for quite a while. The underlying concepts are largely the same and so picking up a new language is no big deal (though being good at it is a bigger deal). We have so many because ultimately it just doesn’t really matter that we have so many.
No idea, HolyC is the only language we need.
HolyC and Brainfuck are for noobs, I only use Whitespace
For various reasons.
Different languages take different approaches and models to do stuff. Thus making each one better or worse for different challenges.
For example, python is easy and quick to get up and running. Bug it’s slow and unsuited for low level programming (like OSes, drivers, and embedded stuff). On the other hand, C is very fast and very low level, allowing you to make both high performance programs and low level stuff, but it’s a nightmare to use and you will run into all sorts of problems that an easier language, like python would avoid. All of this is mostly due to python being interpreted (instead of compiled) and c having manual memory management.
But they might also take a different approach at computation, like for functional languages (opposed to imperative languages) which try to solve problems in a more “mathematical” and declarative way, instead of defining a sequence of instructions. Or, even more, logic programming languages, in which you define a series of logical statements and the language tries to find solution and draw conclusions from them.
And some languages are designed around some particular concept that they think is beneficial and worth exploring, maybe taken from various other languages and put together, like rust which is designed around the RAII design pattern and takes large inspiration from functional languages, while still being and imperative procedural language (like C, so not object oriented). Or java which was designed to be a portanle but performante object oriented language, with support for low powered embedded system, full of features but simpler than c++, etc… all stuff that now is nothing special, but remember that java us very old. Or kotlin which tries to be java (they are interoperable), but modern and better and more “pure” or “consistent”. Or c++ that started as an object oriented superset of c, but then started adding every single feature of every other imperative language, and never giving up on older stuff, to the point of becoming very hard to use correctly while making it very easy to screw yourself in the most intricate ways.
And of course there are domain specific languages (opposed to general purpose languages). Which aren’t even necessarily Turing complete. They are designed for one purpose only, and they do that better than general purpose languages. For example AWK for text processing, or SQL for databases, or matlab for scientific calculations, or TeX for typesetting, or GLSL for shaders, or coq for theorem proving. And here imagination truly is the limit.
So, the point is, every language is more suited then other for some kind of work. And when people stumble across some problem that is hard to tackle and come up with some approach to solve it, or when they grow fed up with the issues of some older languages, they often like to make a new language around that. And some times this leads to entirely new paradigms which are worth exploring.
P.s.: I like languages:)
How do you know which language to use? And how do you know if you should stick to a language that you already know or if you should learn a new one?
Sorry if this is a dumb question I only just finished my first year of being a comp sci major
Generally the most supported language on the tool/platform you want to target is the best one. Like SQL on databases, JS/ES in browsers, python in data science related stuff, etc. If multiple are heavily supported then just pick the one that’s the most comfortable.
It’s not a dumb question. The answer is “it depends”, it’s mostly a choice. The general rule is that when yo start a project, you choose the language that you think will help you the most, whether that is because you already know the language, or because you have to work with stuff that already use that language, or because the language is better at doing that.
Regarding whether to stick to a language or learn a new one, in general your CS teachers will tell you (and they are correct) that you should not “learn to program in a language” but just “learn to program” and then apply that knowledge to whatever language you need. So, you should always learn languages that are different from the ones you already know in order to learn new paradigms, and then when you need a specific language, just learn the details about it. BUT, even if this way you will be able to use most languages, you will not be “good” at most, so you should also have some languages that you know really well and are experienced in. And for that you should choose the ones that are more useful to you (or maybe useful for your job) or the ones that you like.
Especially if one of them is based off the other.
Rust is based off of C/C++
Ruby is based off of Perl, Smalltalk, Eiffel, Ada, BASIC, Java, and Lisp
Just a couple of examples. Quite frankly, it’s dependent on what system, what infrastructure .etc that’ll be the call for a specific programming language. Nothing wrong with just picking one or two and sticking to them.
And I think that’s what a lot of beginners in wanting to study programming languages can fall into, they want to be the jack of all trades in programming. But there’s this problem of a new language coming in all of the time and it can get very wiry trying to remember them all.
Aside from all the pragmatic reasons that were already listed, it’s also just fun to write all the parts required to make a programming language.
If any of you happen to still be on Reddit, I actually maintain a “catalog” of these newer languages, as they come across my radar. One of my more recent finds is MiniScript, which the author of that has been using to port a fair amount of classic BASIC games from that GitHub archive I posted about recently. I got sucked into Nim, which seems like a good synthesis of Python, Javascript, and C++; c/nim exists for anyone interested.
Because people don’t want to admit that JavaScript will be the only programming language in the future and that resistance is futile.
Ngl I thought you were meme-ing and was sad to see you downvoted.
That’s kind of the “problem” of JS. We can do memes like that but the truth is that it is taking over everything.
Exactly right.
Ahaha fair point :D
Yeah but javascript has 473 popular frameworks and counting, and the churn is immense. Your codebase becomes out of date before you’ve finished writing it.
And the debugging?! I’ll try to finish writing this paragraph despite the uncontrollable twitching. Let’s just say that javascript is the kind of language that looks at your car with a missing left front wheel and says “let’s go”, while your IDE whispers “Yes, but maybe just don’t turn right. Certainly don’t turn right fast, unless you want to of course.”
That’s not really the case anymore, it was back at around 2015 for a few years when nodejs blew up and we realized that JS is capable of much more than we initially thought.
We threw a thousand different things to the wall and a few frameworks stuck. Today the ecosystem is pretty stable, especially of you choose a popular framework like React or Angular.
Who said you need to use a framework? vanilla-js.com Yes, debugging is a pain and the language fails in many aspects and I also hate it but I also realized it is the future and everything else will fade away.
I can’t believe I’m about to say this, but if JavaScript is the future, then I’m going to stick to my old fashioned COBOL.
Gotta admit, I love how cheeky that is.
I’m somewhat on the fence about this. Having the frameworks provide some of the functionalities built-in was pretty nice. Having some of that structural opinion to work off of meant I’m not wasting time just figuring out how to architect the whole thing from scratch. At the same time, I would prefer to stick with vanilla, so it’s less overhead and perhaps, the debugging would be more straight-forward. Trying to decipher React’s large error messages was irritating at best.
There are a lot of people with a lot of opinions and preferences that are trying to do a lot of different things in a lot different ways. The same reason we have so many of anything.
they should have stopped after x86 ASM 😔
Sounds like a XKCD.
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.
01001010 01110101 01110011 01110100 00100000 01100011 01101111 01100100 01100101 00100000 01101001 01101110 00100000 01100010 01101001 01101110 01100001 01110010 01111001 00100000
We don’t/ None of them are a significant improvement on PL/1 other that having objects (which hadn’t been invented.) I blogged on this recently. https://bobbrowning.wordpress.com/2023/07/02/typescript-i-quite-like-it-plus-bonus-rant-about-languages/