this post was submitted on 04 Aug 2023
175 points (94.0% liked)

Programming

17407 readers
92 users here now

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

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago
MODERATORS
snowe
Ategon
[email protected]
175
Why do they keep making new languages (lemmy.stonansh.org)
submitted 1 year ago by [email protected] to c/programming
117 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 year ago (2 children)

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.

[–] [email protected] 5 points 1 year ago

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.

[–] mifuyne 1 points 1 year ago

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.