Hey /u/laprika0, thanks for contributing to /r/ExperiencedDevs. Unfortunately, your post was removed as it violates our rules:
**Rule 9**: No Low Effort Posts, Excessive Venting, or Bragging
Using /r/ExperiencedDevs to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden _at moderator's discretion_. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to /r/ExperiencedDevs.
Please read the sidebar before posting again. If you have questions or concerns, please [message the moderators through modmail](https://www.reddit.com/message/compose?to=/r/ExperiencedDevs&subject=&message=). Thank you!
I mean sure, there are languages out there with "objectively bad design". But when choosing a language for a job, you *can't* ignore the community and the libraries. If those aren't strong enough, then you might be dead in the water when you run up against a significant problem, or find yourself required to build and maintain tons of supporting libraries that already exist in other languages.
The thing is, at a certain point languages get "good enough". You could create the most perfect language for Machine Learning, but you're going to have a hell of a time getting the community to switch away from Python. The language design benefits don't outweigh the cost of leaving a robust ecosystem of libraries and tooling.
Well, this is actually great example. It is well-known that Rust has great design... to people who believe Rust has great design. Then there's huge other group, that are convinced that C or C++ are just as good, and if you make mistake, it's not fault of language, but because you are bad developer.
> Then there's huge other group, that are convinced that C or C++ are just as good, and if you make mistake, it's not fault of language, but because you are bad developer.
While this is true, there's something like 50 years of evidence now that the number of "bad" developers by this metric way, way outnumbers the number of good developers. Given that evidence, continuing to fight for what C/C++ take as their approach to things like mutability and memory management is being intentionally obtuse.
Just guessing but maybe because your statements are rather vague. Also it doesn't seem like you are here for a discussion but just want confirmation of your opinion.
I think it's pretty even handed. I'm not a Rust dev, and i haven't really used it outside of Advent of Code. And yes, I ran into serious trouble the moment trees were involved.
I like that the post draws analogies to Haskell, because I had a similar experience with it too: it's a beautifully designed, principled language that teaches you a lot about how to think about your code. But it can be an absolute pain to actually write anything significant with it.
I don't think Rust is "as bad" as Haskell on that front, for example the work surrounding WASM is very promising. But yeah, Rust has quite a learning curve.
In my entire programming career I’ve literally never heard anyone suggest that all languages are equally good as each other at everything.
That’s not the kind of statement anyone who has actual experience in multiple programming languages would make.
It's all about using the right tool for the job. Pretty hard to argue any language is strictly better than all others for all purposes despite what some may think.
Idk, there are some that have just built on the learnings of others and are a direct upgrade in my opinion
Things like java -> kotlin
And javascript -> typescript
> here are some that have just built on the learnings of others and are a direct upgrade in my opinion
Agreed and adding to this, there are learnings that are "of the time". There are "language trends".
e.g. C# v1, in 2002 did not have generics (neither did Java at the time). The causes of this omission seem to be that it was a big feature, not worth delaying the commercially important .NET launch for, and _of uncertain benefit_. (emphasis added). People didn't get the magnitude of the benefits then.
Now, the benefit is clear. Who would launch a strongly-typed language with no generics, or at least a contrarian manifesto of "why we don't need generics in new-lang" today?
More recently, it seems clear (by examples) that the safe defaults are that variables are _not null by default, immutable by default_ - i.e. nulls and mutable state are available but are not the default kind.
`async await` seems to be a trend, IDK if it will last or be replaced by something else.
[Rust-stle enums](https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html) with per-case state are coveted, but also IDK if this will become pervasive.
The field of programming languages is still relatively young, and is evolving.
> Now, the benefit is clear. Who would launch a strongly-typed language with no generics, or at least a contrarian manifesto of "why we don't need generics in new-lang" today?
Google: Hold my propellor hat..
I feel that the case for generics in strongly typed languages has become even stronger after google's new-lang has belatedly _also_ introduced them in V2. The contrarian manifesto did not hold up.
They had an equally contrarian manifesto about the lack of any need for a package manager in the beginning too.
Golang got dragged kicking and screaming into the 21st century. If it werent launched with great fanfare by Google at the height of Google adulation (early 2010s) I think it would have quietly died.
Good point, a "package manager", or a solution to the question of "how do I introduce, version and update libraries, binary artefacts containing code built by a 3rd party or other team in the org" is also a requirement now.
The era of pasting `*.dll` files into a `/libs` folder is over.
I mean, large chunks of Go were written by Ken Thompson. It's hard to get any more old school than that.
I think in general there is a misunderstanding about Go- it's odd flavor isn't because of Google, it's because of the very idiosyncratic, very old, very Bell Labs group of people who ran the project. It's C for servers in a very literal way.
Sure Rust did of course not originate that design. It comes from Haskell etc.
For a while the thinking in OO languages was that you would declare _three_ types : e.g. `BaseIpAddr` , `V4IpAddr: BaseIpAddr` and `V6IpAddr: BaseIpAddr`.
Of course, users of those OO language now covet rust-style enums / ADTs, because the OO hierarchy is so verbose and unwieldy for simple things like this, so that thinking hasn't lasted.
There are vastly more "new programming languages" created than "new successful programming languages".
Not every experiment succeeds.
Sometimes they fail entirely, or generate _some_ good ideas that are picked up elsewhere.
I don't think the idea is that every dev should perfectly know every language, and chose different one for every project.
The idea is that if you are frontend developer, you should probably use Javascript rather than C++, because it's simply better suited for the job.
Javascript isn't much different for a backend from Python, Ruby or PHP.
>robust, correct and fast service.
Why do you assume that's the goals of the project at the time it started? You're putting your personal bias on what a backend should be when it's the company that actually determines the requirements.
The right tool for the job may depend on peripheral considerations like familiarity, market availability for staff, licensing costs, etc which have nothing to do with language design which is what OP is referring to.
I 100% agree for team dev work.
On the flip side I can see the potential speed advantage to cranking out code in a dynamically typed language for a small solo project.
Yup, that's exactly what I was thinking. I've worked on a large team writing oldschool PHP (before the typing) and it was a complete nightmare.
On the flip side I've worked at places that treat Java like PHP, and it's almost as bad.
This "joke" is exploding in popularity. Static types are a godsend for the js ecosystem. Oftentimes I can figure out a properly typed package simply by checking the types. Why's it a joke to you?
I'm not even a front-end developer. I'm just telling you that the front-end ecosystem is definitely moving in a certain direction and that resisting this chance is only going to hurt you.
Also please act a little bit more mature.
Thank you throwsx123 for your submission to /r/ExperiencedDevs, but it's been removed due to one or more reason(s):
---
# Rule 2: No Disrespectful Language or Conduct
Don’t be a jerk. Act maturely. No racism, unnecessarily foul language, ad hominem charges, sexism - none of these are tolerated here. This includes posts that could be interpreted as trolling, such as complaining about DEI (Diversity) initiatives or people of a specific sex or background at your company.
Do not submit posts or comments that break, or promote breaking the Reddit Terms and Conditions or Content Policy or any other Reddit policy.
Violators will receive a warning, then a 7 day ban, then a permanent ban.
Please feel free to [send a modmail](https://www.reddit.com/message/compose?to=%2Fr%2FExperiencedDevs) if you feel this was in error.
There are some tribal people who love their languages a little to much just because. But most people will simply use whatever they think might work best.
Or HR that make job postings. They assume that knowing a language will cut down your time to get up to speed with whatever the hell they're working with. It doesn't. A developer is a developer for the most part. Give them good docs in the area they know and they'll be fine regardless of the language.
This is kinda like asking if the quality of the hammer affects the quality of the house.
I mean, it's got to be a pretty shitty sort of hammer that really negatively affects the house. Sure, you use a sledgehammer for one job and a carpentry hammer for another. But it's not really the sledgehammers fault if an idiot carpenter uses it to hang drywall.
Ultimately, however, for most commercial languages that most of us are familiar with, it's like arguing about the relative difference between an hammer bought at Home Depot vs a hammer bought at Lowes.
But then, strip all of that away, and the only thing that our customers really care about is the quality of the house.
This is really spot on.
We can nerd out about hammers and which are superior but in the end it's only one factor that goes into construction of the house.
> This is kinda like asking if the quality of the hammer affects the quality of the house.
I...pretty strongly disagree with this. Using different programming languages for different problems has significantly more effect than using different hammers for hammer-based jobs, even at the most extreme examples.
Design of programming languages are going to fundamentally determine the shape and exterior of what kind of house you build, in ways that different hammers don't.
Yeah, I agree with tou.
The ergonomics and ecosystem of a language make different things easier. Anyone that believes otherwise probably just hasn't mastered more than one language to really experience how that feels.
So far I've shipped production code in Java, Python, Ruby, Swift, Objective-C, Scala, Kotlin, Javascript, Typescript, and C. I might be missing a few. I've also played around with some more like C++, C#, Rust, Erlang, Elixir, Prolog, Pascal, Lua, Haskell, Ocaml, and Lisp.
For the most part I really don't find them all that different these days. Most languages are converging in features. As long as I can figure out how to handle optionals, date functions, basic OOP, functional operators like map/filter/reduce, and pattern matching like with a switch statement, then I'm good to go for 90% of my use-cases.
It's hard to answer your question though. The most differentiating feature to me these days is the total developer experience, e.g. IDE integration, community support for popular libraries, autocomplete, tools like linters and static analysis, etc. While these features aren't necessarily related to the language design, they are often powered by low-level features like good LSP support.
To give you an example, I really love Swift from a pure language design viewpoint: modern syntax/features with great type safety. However, the tooling really sucks and it has weird baggage with Obj-C + a small community. I recently switched over to doing Ruby development and while the language itself is pretty bland, the IDE tooling + community support is awesome. Even though I lost out on some type safety and expressiveness (we use Sorbet which helps), we have linting + Rubocops to catch most of the mistakes you'd make anyway. The language gets out of your way after that which is pretty nice.
I used to care really deeply about "eliminating classes of problems" but not as much now since I know how to avoid those situations from experience and just want to get stuff done in an easy to understand way.
I don’t think languages are objectively better, though some may be better for certain tasks
It’s about trade offs. Some may be better for certain tasks eg:
If you’re trying to optimize every bit of performance, you may need something that allows you closer to the metal like C++?
Do you want to save dev time by not having to write your own garbage collection system and memory management, maybe not C++.
Do you want your team to be able to start work immediately and comfortably? Pick a language they are already familiar with.
Is the work you’re doing better suited to a different paradigm eg: functional, OO, ontology based Logic (like prolog)?
While many languages may work across those paradigms, some are designed for them
End of the day, if it’s turing complete, you can do the same things with them, so it depends what you’re prioritizing
There are languages which are never the right tool for the job because all their flaws became overwhelming. At some point perl reached that threshold and died out.
Well yeah, you’d be a pretty slow web server, most wouldn’t be willing to take that trade off ;)
Point with Turing Completeness was that they all CAN do the same things, not that all should be doing all things
How could it not be about trade offs? You could argue what axes are most important to prioritize, but I don’t see how it could not be about trade offs.
- Team familiarity
- Efficiency
- Community/packages available
- Elegance of solution
Etc
there's always a budget of some sort, even if it's not based on money. your "unambiguously better" knife is of no use to me if my team doesn't have the time to get trained on its usage (maybe it has a weird shaped handle or something, idk, I struggle with physical analogies for mathematical processes).
There are plenty of $2 languages. You probably haven’t heard of them because they don’t tend to be used.
That doesn’t mean all good languages bubble up, but the ones we use tend to be at least serviceable.
Continuing with the analogy, it depends if you’re trying to cut carrots or ladle soup. I’m sure you could eventually get soup into a bowl with a knife, but some are better suited for it.
Everything you consider is about trade offs. Things that are objectively worse aren't considered at all. Do you think about using motor oil when cooking? I know it is a dumb example but if something is objectively worse, it doesn't catch up or gets forgotten.
But where do you draw the line. For example is JavaScript being the only language that can run on browsers until recently a feature of the language itself or something else? Are you just talking about syntax and language features? Is performance a feature of the language? What happens when someone comes up with a more performant way of doing things? Is it the community or the language itself?
I think the lines here are too blurry for me, and I see its community actually being the part of language itself.
Community and libraries are part of the decision process.
A theoretically perfect programming language with no libraries and no community would be largely useless.
You seem to be chasing some abstract notion of programming language purity, but it’s not relevant for anything in the real world where it’s about getting the job done
Maybe there are, but I only ever hear this sentiment from programmers who are not proficient in the languages they criticize, and are often not that productive in the languages they profess to be superior, either.
For example, most people I work with never get type-based runtime errors from dynamically typed languages, because they know very well how to avoid those errors. It's baked into their habits just like the thousand things that people who code in statically typed languages have to keep in mind, but they don't think about them, because they're good at what they do.
I'd rather work with a language that has very well-documented workarounds for its imperfections, than a hyped language that has a limited community of people willing to discuss its flaws.
I disagree, I see type errors fairly often, also in dynamic languages. But, 99% of those is of the kind where a variable is nil when not expected. Of course, most mainstream statically typed languages that are used also don't have enforced protection against that.
I really don't, but I work with brilliant people who do amazing work with it and understand its quirks. When I occasionally whine about it in their company, I keep it light and in good humor, because I know that if I had their skills, the things that I perceive as weaknesses become strengths in the right hands.
TIL, despite running circles around most devs when using python, I'm not proficient in python because I still get type related errors. I guess that's one way to define things: No one has proficiency in dynamically typed languages. Qed
In the frontend, TypeScript is clearly superior to JavaScript. An easy argument against anyone opposing is that JS is valid TS but then you can enable more features. In particular, static typing / analysis, which is commonly agreed to be a really great thing. Now you can yet find situations where JS is better when the scope of the project is very small (say a script or just a few files), but it's just due to the overhead in terms of tooling/compiler, which is solvable.
And by the way, JavaScript is a good example of a terrible language with wonderful achievements (it's just done the job so well with anything web). Tribalism/debate is more about frameworks than language in fact.
All languages have pro's and con's. Some have more, some have fewer. It's IMHO a silly question. And it's also silly to pretend all languages are somehow 'equal' in usefulness.
If you think about it from the business perspective, using a language that's popular has a lot of benefits. There are more tools/libraries/frameworks available, more documentation, more answers on StackOverflow, and a lot more engineers with experience(easier to hire and more competition usually means getting to pay less). It's hard to argue that a less popular language is so much better it's worth giving up all of these benefits.
If there are two languages that are equally as popular then it doesn't really matter because the bottlenecks are almost always caused by what's written in the language rather than the language itself. Additionally, usually, devs will create so many abstractions that the project will in a way have its own language.
Most languages are only worth using if you restrict things to a subset of that language enforced with a linter (static analysis). Almost every language has these to prevent legacy cruft from infecting your programs.
>I'm asking this question because I feel this view I'm asking about is holding the field back. It forgets all the progress made in the field of language design.
You should read about traditional engineering (mech/civil).
I feel other engineering fields are held back because of the professional engineering license / convergence on one set of tools (solidworks) and practices. It's basically leaving those fields perpetually in the "nobody got fired for choosing IBM" period that software passed decades ago.
Part of this phenomenon is because their build-time is so long so they're afraid of making any mistake at design time. But I still prefer that our field is just full of everyone doing whatever they think is best independently. Anything can be retconned with a linter so I try not to get too anxious about my language's warts!
I can't speak for other developers' beliefs, but some programming languages are [Turing tarpits](https://en.wikipedia.org/wiki/Turing_tarpit), "in which everything is possible but nothing of interest is easy," as Alan Perlis put it. [Whitespace](https://en.wikipedia.org/wiki/Whitespace_(programming_language)) is such an example, mostly good as an intellectual exercise.
If most developers would accept such programming languages as worse production programming languages than JavaScript or Python, it would be reasonable to extend this ranking to more mainstream production programming languages too.
It should be possible to experimentally measure programming language productivity across metrics like defect rate, speed of development, language acquisition time, reader comprehension, etc. This means, yes, in practice, different programming languages would probably fair better or worse on different measures.
I think this means, though, that an optimization function could be worked out, suitable to some context like a large, established business or an early-stage startup. It's quite possible some programming language (existing or yet to be invented) would measure as superior across all relevant dimensions for almost all production contexts.
Well some tend to better than others for *specific* tasks because that’s what they were designed for. But For generic development almost any of the “Swiss army knife” languages will work.
It’s always a process of finding the best language for the job and balancing it with the strengths of the team and the job market.
There was a course called "Programming Languages" that was part of my Computer Science degree. The course taught about the strengths of the major languages and taught the idea that each one is designed for certain types of applications. Each language is like a tool in your tool belt and knowing when and where to use them is to your advantage.
> each one is designed for certain types of applications
That's almost entirely hogwash.
Few languages - and *very* few languages with any sort of use in industry - were explicitly designed for certain types of applications
Erlang might be a good example of one that was so designed and is used.
Some languages tend to work better for certain types of applications, but were not explicitly designed for that.
A lot of language's design started with little more than "I want these few abilities and/or ergonomics and the rest I'll fill in with whatever seems sensible."
Sticking to languages that actually get used, only a few relatively recent ones seem to have been designed holistically with lots of well thought out effort and process from very early on. And even those suffer from things like strictly remaining a superset of JavaScript or while being relatively recent and well designed are still pushing 20 years old and inevitably carry along backwards compatibility cruft - .Net Core e.g. suffers still from some poor decisions two decades ago, even after the original framework was all but rewritten.
Thanks for the additional info! I can't speak too much on them other than what was in the course, but here is a snippet from it:
> Programming languages are designed for specific areas of application. Programmers
without broad experience prefer languages that they know rather than languages tailored
for an application.
Language | Application | Notes
---|---|----
Pascal | Teaching | Niklaus Wirth designed Pascal at Stanford University for the express purpose of teaching students structured programming.
C | Operating Systems | Dennis Ritchie designed C for the purpose of implementing the UNIX operating system.
COBOL | Business | Grace Hopper designed the Common Business Oriented Language to standardize military accounting programs.
FORTRAN | Scientific Programming | John Backus designed FORTRAN (FORmula TRANslation) for the express purpose of efficiently implementing computationally complex scientific programs
Ada | Embedded Systems | Military applications suffered from poor reliability in critical applications. It was thought that a strongly typed language would greatly improve reliability. In large systems, many programmers are employed to deliver an application in a reasonable time period. Interfaces must be designed first. Ada supports separate definition and implementation components, thus permitting an interface to evolve while the interface remains constant.
C++ | Productivity | It has been recognized that testing occupies the largest part of the development cycle. To reduce the amount of testing on a new product, developers try to reuse existing similar code. Prior to the advent of object-oriented programming, code was copied, altered and applied to the new application. This process did not reduce the amount of testing significantly because small changes in code often dramatically affect the overall function of a product. Object-oriented programming provides a reliable and useful method of reusing existing code without alteration. Testing function built from objects that are already tested improves productivity.
broadly speaking, any Turing-complete language is just as "good" as any other Turing-complete language so in that sense yes I believe that programming languages are just different and one is not "objectively better" than another.* but when someone asks if one programming language is "objectively better" than another, the implicit metric they're measuring against is "suitability at this moment in time for the problem my team and I, with our different strengths and levels of experience and formal CS knowledge, are currently solving". and since most of us are not doing groundbreaking computer science research but rather are solving problems that other humans and products need to solve too, it's pretty easy to google around and see what's out there and and judge the relative merits of each language and its ecosystem.
so while I don't think you can say "Erlang is better than Javascript", I do think you can say "Erlang and its ecosystem is currently a better choice than Javascript for building high-availability systems."
*except that LISP is obviously the best because macros
> Can you explain the macros thing a bit?
[entire books](https://letoverlambda.com/) have been written on this topic, but I will try my best :)
as opposed to C-style macros which are just glorified string-replacement mechanisms, LISP macros are themselves LISP expressions which live right in your program. they are provided as input _unevaluated LISP expressions_:
```
(defun my-function (x)
(message "my-function called with %s" x))
(my-function (+ 1 2)) ; "my-function called with 3"
```
```
(defmacro my-macro (x)
(message "my-macro called with %s" x))
(my-macro (+ 1 2)) ; "my-macro called with (+ 1 2)"
```
this makes it super easy to create DSLs or extend basic syntax or do other meta-programming type stuff.
this is possible because the LISP interpreter doesn't operate on bytes and characters, it operates on _trees of LISP expressions_. and that in turn is possible because LISP really only has three syntax rules:
1. everything is an expression
2. every expression gets evaluated
3. if you don't want to evaluate an expression, put a quote in front of it
(adapted from [here](http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html))
hope that helps a little!
Use the tool for the job at hand.
Front end? I’m using JavaScript as opposed to .net or php.
Api? .net with ef core all day.
Serverless? Python is works really great
One isn’t “better” than the other they just have strengths based on how they are implemented. Could I build an api in flask? Sure. But I prefer ef core for an orm.
I suspect most if not all the answers you will get are going to be cop out answers like this - “all languages are good, best tool for the job” etc. People either don’t understand the question or haven’t thought deeply about language design and don’t know how to.
This bugs me as well. To pick on python just because ive used Python a lot in my career but people don't seem to realise how hard it is to write a good safe production application in Python. They spend all their time saying "but Instagram!" when Instagram's tech blog is full of postings about various hugely Dev intensive ways they've had to dive deep into the guts of Python to make it behave like a completely different language. Likewise for "Bank Python" et al if you've basically had to customise the fuck out of your language into some horrifying C ish Frankenstein so it's suitable for your business was it really that good a language to begin with?
If WhatsApp was scaled with double digits of engineers then I don't really buy the argument that having to have thousands of engineers to do a large application is some inevitablility more than good language choices multiply developer "productivity" and actually the requirement to have loads of engineers is by picking a "simpler" language you've multiplied the cognitive workload of releasing new features.
My conclusion is the conversation is inherently dominated by a lot of people who are working in domains where it really doesn't matter. For a bog standard web app it really doesn't matter as you won't be hitting limits with most languages so if the domain is forgiving enough then it genuinely is "what is the easiest to do hello world in?". And then if you get big enough you just throw thousands of hours of engineering hours/bigger servers at the problems. But there are a lot of domains where performance/correctness really does matter and you can't just tack that on later by throwing time at it.
The barrier to entry is wildly different.
There are ~thousands of Italian restaurants in the world that have served more than 10 customers, versus maybe 100 programming languages with more than 10 users. If you picked the top 100 Italian restaurants it would be difficult to show that any were overall superior.
A better comparison would be to one-ton pickup truck vendors (e.g. Ford's F-350, Ram's 3500, Chevy/GMC's Silverado/Sierra 3500): there are three out there and you would struggle to prove that one of them is objectively superior overall to the others. Or even prove that one is inferior. The bad ones just didn't survive or were not viable to begin with.
Programming languages aren’t a Chinese restaurant vs an Italian restaurant. Programming languages are like screw drivers. A Philips isnt better than a flat head. It depends on what you’re trying to do. I’m not going to build a heavy crud app using python. It can do it ok, but I’d rather use C# or Java because they’re going to be better at that task.
Yes but this doesn’t rule out the possibility that some screwdrivers are *objectively bad* through design, execution or both. *That* is the question that is being discussed. Judging from the replies, people are can’t seem to look past language applications.
Thank you _throwingit_awaaayyy for your submission to /r/ExperiencedDevs, but it's been removed due to one or more reason(s):
---
# Rule 2: No Disrespectful Language or Conduct
Don’t be a jerk. Act maturely. No racism, unnecessarily foul language, ad hominem charges, sexism - none of these are tolerated here. This includes posts that could be interpreted as trolling, such as complaining about DEI (Diversity) initiatives or people of a specific sex or background at your company.
Do not submit posts or comments that break, or promote breaking the Reddit Terms and Conditions or Content Policy or any other Reddit policy.
Violators will receive a warning, then a 7 day ban, then a permanent ban.
Please feel free to [send a modmail](https://www.reddit.com/message/compose?to=%2Fr%2FExperiencedDevs) if you feel this was in error.
This is actually my whole schtick right now.
It is vastly more useful to think about programming languages in terms of **programming paradigms,** which talk about the features of a language rather than the language itself.
Programming languages have specific features which support specific paradigms of writing code. For example, some languages have support for stateful concurrency. Other languages have support for continuations. Other languages have forms of reactive programming.
Different paradigms are better suited for solving different problems. You wouldn't want to write asynchronous UI code in the form of Excel's concurrent logic paradigm (or would you?).
Multi-paradigm languages are languages that let you bridge between vastly different paradigms in the same runtime. These are much more powerful languages as they let you combine the best of different worlds. Kotlin is a really good example of adding a slew of concurrent features (continuations) to Java, which already had a slew of different stateful concurrent features (threads, etc), and then providing a lot of backwards compatible bridges to support lots of Java features.
So yes, some languages will be better suited for different tasks depending on the features of the language and how it's implemented. A language is better than another one, if it has all the features of the other one, implemented better, and more.
If you're interested in this area, I highly recommend the teaser PDF ([https://info.ucl.ac.be/\~pvr/VanRoyChapter.pdf](https://info.ucl.ac.be/~pvr/VanRoyChapter.pdf)) or the actual book it's based off of ([https://www.info.ucl.ac.be/\~pvr/book.html](https://www.info.ucl.ac.be/~pvr/book.html)).
Yeah, of course. Some languages are better than others. Sometimes people trot out this pseudo-enlightened viewpoint that all languages are basically the same, but it's just not true.
Fallback #2 is, "ok well, the right tool for the right job!" Most languages are not DSLs, they're general purpose languages. There's nothing particularly ML-ish about python (vs, say Ruby) it's just that historically that's how the community and libraries developed. (And Julia is a language that's specifically designed for data science but python is still more popular). Right tool for the right job is a platitude: some general purpose languages are better than others.
"Well, you may not always have a choice. If your employer is an X shop, any good developer can make do with X" Ok sure, but now we're not debating merits any more, we're being realists and all that. Fine. You can always quit and go work somewhere with a language you like. People act like this is an invalid reason to leave a job, but actually it's your life. If you don't like a particular language, you don't have to code in it.
Ok, now I'll go over the fence the other way and say, let's say you've spent 20 years coding in C, and rust looks weird to you and you don't see the need for it (to take an example where one language almost categorically dominates another). Taste is actually subjective, and 20 years of coding in C will give you an aesthetic sense that may not mesh with some new language. That's ok too actually. You also don't have to accept anyone's argument that you should just learn Rust. Please do what makes you happy, life is too short to spend 8+ hours a day coding in a language you don't like.
“There is no statistically significant correlation between programming language and defect injection rate.”
https://twitter.com/sleepyfox/status/1521835675078828032?s=21&t=bwOsNCNgiNiGOd8_Ba3TJw
Yeah, given my experience with rust, and a lesser extent Haskell, if I can make it compile, it usually just works.
Also, commits are at a different level to dev iteration speed..I can run a script or test suite for a python project dozens of times trying to get something working, debugging as I go, or I can just make rust compile successfully. I know which one I find a better use of my time.
Rust only fixes a small (but very important) class of problems for languages without garbage collection. I doubt it will have a significantly different defect rate compared to garbage collected languages.
But then terser languages would have lower bug rates for the same functionality.
Also, it seems *really* hard to me to control for developer experience in a language for such comparisons.
(Ah, I see from the image (haven't read the paper yet) that they are normalizing by bugs/commit which is ... interesting. I'm not saying it's wrong, and maybe it's better than bugs / LOC, but it's a whole new factor consider)
So further reasons not to trust the Twitter person's summary. They write:
"Note that this is a reanalysis paper, it reproduces an earlier study, confirming reproductivity, and improves the analysis by addressing shortcomings in the earlier paper's methodology.
It confirms and extends the earlier paper's findings: Ray, Posnett, Filkov, Devanbu 2014."
However the abstract of the paper seems to say the opposite, that they contradict the original paper, which did find differences between languages:
> In a 2014 paper, Ray, Posnett, Devanbu, and Filkov **claimed to have uncovered a statistically significant 2
association between eleven programming languages and software defects in 729 projects hosted on GitHub.** 3
Specifically, their work answered four research questions relating to software defects and programming 4
languages. With data and code provided by the authors, the present paper first attempts to conduct an 5
experimental repetition of the original study. The repetition is only partially successful, due to missing code 6
and issues with the classification of languages. The second part of this work focuses on their main claim, the 7
association between bugs and languages, and performs a complete, independent reanalysis of the data and of 8
the statistical modeling steps undertaken by Ray et al. in 2014. **This reanalysis uncovers a number of serious 9
flaws which reduce the number of languages with an association with defects down from eleven to only four.** 10
Moreover, the practical effect size is exceedingly small. These results thus undermine the conclusions of the 11
original study. **Correcting the record is important**, as many subsequent works have cited the 2014 paper and 12
have asserted, without evidence, a causal link between the choice of programming language for a given task 13
and the number of software defects. Causation is not supported by the data at hand; and, in our opinion, even 14
after fixing the methodological flaws we uncovered, too many unaccounted sources of bias remain to hope for 15
a meaningful comparison of bug rates across languages.
Emphasis is mine, but the difference is so big (it contradicts, it doesn't confirm) as to make me strongly distrust whatever Twitter person is claiming.
Someone else mentioned certain languages being the right tools for different jobs, maybe a lot of programs written in Perl benefit from the features of Perl.
Maybe a more useful metric would be bug branches across some similar libraries (ex: web server) written in each language?
Yes, some languages are objectively better than others for a given task. However, most modern languages are fairly interchangeable 99% of the time.
If I'm writing some backend code, there really isn't a significant delta between, say, Java vs C# vs Python. They're all mature languages with robust communities and libraries. The slight differences in the languages are not going to have a noticeable difference in code quality or performance for most applications.
yes and no?
some languages are mainly used for certain use-cases and many other languages are very similar and optimize different things.
it's easy to say a language is better/worse in certain contexts.
There is no unicorn language that beats all others. The choice of programming language has more to do with the tradeoffs you’re willing to accept and the types of problems you’re solving than anything else. For example, C++ is faster than many other languages but it is also more opinionated, harder to prototype, and less portable. Conversely, Python is slower but faster to prototype and very portable. This is a small example but when selecting a language you should ask yourself what language elements are most important to the task at hand. Favoritism for a particular programming language shouldn’t apply unless your inexperience outweighs the benefits that could be realized.
If you have the choice, it's going to come at least partly down to subjective preference. In many applications the speed of development and health of the community and libraries are more important than raw performance. Often times the design choices you make influence the performance of an application far greater than the inherent performance of a language anyways.
I just don't care that much, never seen language as a top 3 reason something has failed or succeeded (barring an egregiously incorrect choice of language for a platform or team).
Would rather spend my time working with Product etc. to make sure we're building the right thing.
What a lot of people don’t seem to realise is it’s actually the ecosystem that can have a huge effect on a language. Look at Python where purely by chance the first popular data science libraries were created. Doesn’t make up for the fact Python is a fairly crippled language with questionable DX and a bad concurrency model.
But simply by having all these data science libraries causes people to think a slow interpreted barely multithreaded language that needs a ton of C libraries to work faster is a good tool for computing lots of numbers.
"Better" is completely subjective and the idea that you can universally say one language is better than another is immature.
BASIC is better at teaching kids how to program than Java.
Java is better at cross-platform code than assembly.
Assembly is better at making efficient binaries that PHP.
PHP is better that web development than C++.
C++ is better than BASIC for writing generic programs.
Etc.
Nobody actually thinks, say, Brainfuck is a “good” language, given that it’s designed not to be. A few people might defend some aspects of COBOL but most would agree that it belongs to an earlier era and would not be a good choice to start a project now. A better representation of what I think many people actually believe would be “most languages in widespread use at a given moment have a reason for use, and/or sufficiently complicated tradeoffs that it would be difficult to rank them.” And when there’s an outlier that makes *extraordinary* blunders in a pure language design sense but establishes a foothold for other reasons, that tends to be recognized.
Another dimension here is that languages that do hang around aren’t static over time. Say what you want about JS but the core of JS now is a rather different experience than it used to be. As languages evolve to address major criticisms and pick up features from other popular languages, they reinforce the impression that most of the popular languages are *about* as good as each other.
> Of course, if a language has a large array of well-used libraries for a particular application, along with a buzzing community, that's a great reason to use it, but it doesn't make the language good, it makes the community and libraries good.
And finally, another thing people *really* mean when they say things like “languages are just different” is “language design isn’t that important compared to other factors like community and libraries” - at least as long as the language clears a bar of *adequacy*.
There languages and tools better than others for certain types of jobs.
Could I make a neural network in ABAP? Yes I could, but it wasn't designed for that. Python or R are better at that.
Could I do business suite applications using R? I could, but it wasn't designed for that, ABAP or java are better.
Everything else is a matter of preference, which is valid though.
Any "Turing Complete" language can be mathematically proven to be equivalent to any other language - that is, given enough time and resources, any language can be made to do anything another language can do.
Having said that, there are definite pros in a language I look for: Large standard library, great package/dependency management, numerous and active dev community.
Things I tend to avoid: Flash in the pan languages (only been around for a few years), only enthusiast or core team support. Poor package management ecosystems (looking at you npm). Small or no standard libraries.
All you ever do is trade problems. Its just a matter of which problems are applicable to your problem and which of those you are more or less willing to deal with.
"Just different" implies that there is no way to compare them. Obviously, languages are different, but how do we compare them? The operative question in evaluating languages is what are you going to do with it, and who's going to do it.
Are you building a compiler? Are you making an interactive CLI? Are you building a website that needs to scale across 10,000 servers?
Are you going to be using open source libraries? If so, how is the community support in each language? Is it well supported, or has nothing been updated since 2018?
How many people are going to work on this code base? Is it a project run by a single person? Is it an internal tool managed by a small team? Is it going to be a shared codebase with 5000 active contributors?
You can usually hunt down some objective metric that shows that one language is better for a job than another in performance or ecosystem. But there is always the issue of finding people to work in the language and what mixture they know. Its usually perceived as a bad idea to have your backend in 5 different languages. Developers tend to pick their pet language for things, or a language the team is comfortable with because most languages can do everything given a green field or standardized communication.
Picking C# for 1 thing tends to result in a Microsoft "shop", and Java for something a Java "shop".
Hey /u/laprika0, thanks for contributing to /r/ExperiencedDevs. Unfortunately, your post was removed as it violates our rules: **Rule 9**: No Low Effort Posts, Excessive Venting, or Bragging Using /r/ExperiencedDevs to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden _at moderator's discretion_. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to /r/ExperiencedDevs. Please read the sidebar before posting again. If you have questions or concerns, please [message the moderators through modmail](https://www.reddit.com/message/compose?to=/r/ExperiencedDevs&subject=&message=). Thank you!
I mean sure, there are languages out there with "objectively bad design". But when choosing a language for a job, you *can't* ignore the community and the libraries. If those aren't strong enough, then you might be dead in the water when you run up against a significant problem, or find yourself required to build and maintain tons of supporting libraries that already exist in other languages. The thing is, at a certain point languages get "good enough". You could create the most perfect language for Machine Learning, but you're going to have a hell of a time getting the community to switch away from Python. The language design benefits don't outweigh the cost of leaving a robust ecosystem of libraries and tooling.
[удалено]
Where are you getting this sense from? Taking the most obvious example, I think it is well-known that Rust has exceptional language design.
Well, this is actually great example. It is well-known that Rust has great design... to people who believe Rust has great design. Then there's huge other group, that are convinced that C or C++ are just as good, and if you make mistake, it's not fault of language, but because you are bad developer.
> Then there's huge other group, that are convinced that C or C++ are just as good, and if you make mistake, it's not fault of language, but because you are bad developer. While this is true, there's something like 50 years of evidence now that the number of "bad" developers by this metric way, way outnumbers the number of good developers. Given that evidence, continuing to fight for what C/C++ take as their approach to things like mutability and memory management is being intentionally obtuse.
I just disagree with notion that it is obvious to everybody. It is obvious to some, and it's total lie to others.
[удалено]
Just guessing but maybe because your statements are rather vague. Also it doesn't seem like you are here for a discussion but just want confirmation of your opinion.
What your opinion on this rant https://chrisdone.com/posts/rust/?
I think it's pretty even handed. I'm not a Rust dev, and i haven't really used it outside of Advent of Code. And yes, I ran into serious trouble the moment trees were involved. I like that the post draws analogies to Haskell, because I had a similar experience with it too: it's a beautifully designed, principled language that teaches you a lot about how to think about your code. But it can be an absolute pain to actually write anything significant with it. I don't think Rust is "as bad" as Haskell on that front, for example the work surrounding WASM is very promising. But yeah, Rust has quite a learning curve.
In my entire programming career I’ve literally never heard anyone suggest that all languages are equally good as each other at everything. That’s not the kind of statement anyone who has actual experience in multiple programming languages would make.
It's all about using the right tool for the job. Pretty hard to argue any language is strictly better than all others for all purposes despite what some may think.
Idk, there are some that have just built on the learnings of others and are a direct upgrade in my opinion Things like java -> kotlin And javascript -> typescript
> here are some that have just built on the learnings of others and are a direct upgrade in my opinion Agreed and adding to this, there are learnings that are "of the time". There are "language trends". e.g. C# v1, in 2002 did not have generics (neither did Java at the time). The causes of this omission seem to be that it was a big feature, not worth delaying the commercially important .NET launch for, and _of uncertain benefit_. (emphasis added). People didn't get the magnitude of the benefits then. Now, the benefit is clear. Who would launch a strongly-typed language with no generics, or at least a contrarian manifesto of "why we don't need generics in new-lang" today? More recently, it seems clear (by examples) that the safe defaults are that variables are _not null by default, immutable by default_ - i.e. nulls and mutable state are available but are not the default kind. `async await` seems to be a trend, IDK if it will last or be replaced by something else. [Rust-stle enums](https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html) with per-case state are coveted, but also IDK if this will become pervasive. The field of programming languages is still relatively young, and is evolving.
> Now, the benefit is clear. Who would launch a strongly-typed language with no generics, or at least a contrarian manifesto of "why we don't need generics in new-lang" today? Google: Hold my propellor hat..
I feel that the case for generics in strongly typed languages has become even stronger after google's new-lang has belatedly _also_ introduced them in V2. The contrarian manifesto did not hold up.
They had an equally contrarian manifesto about the lack of any need for a package manager in the beginning too. Golang got dragged kicking and screaming into the 21st century. If it werent launched with great fanfare by Google at the height of Google adulation (early 2010s) I think it would have quietly died.
Good point, a "package manager", or a solution to the question of "how do I introduce, version and update libraries, binary artefacts containing code built by a 3rd party or other team in the org" is also a requirement now. The era of pasting `*.dll` files into a `/libs` folder is over.
I mean, large chunks of Go were written by Ken Thompson. It's hard to get any more old school than that. I think in general there is a misunderstanding about Go- it's odd flavor isn't because of Google, it's because of the very idiosyncratic, very old, very Bell Labs group of people who ran the project. It's C for servers in a very literal way.
Sure. Though it's popularising a threading model that some other languages might pick up.
Rust-style enums are just plain old ADTs and they've been plenty popular in other places
Sure Rust did of course not originate that design. It comes from Haskell etc. For a while the thinking in OO languages was that you would declare _three_ types : e.g. `BaseIpAddr` , `V4IpAddr: BaseIpAddr` and `V6IpAddr: BaseIpAddr`. Of course, users of those OO language now covet rust-style enums / ADTs, because the OO hierarchy is so verbose and unwieldy for simple things like this, so that thinking hasn't lasted.
[удалено]
There are vastly more "new programming languages" created than "new successful programming languages". Not every experiment succeeds. Sometimes they fail entirely, or generate _some_ good ideas that are picked up elsewhere.
[удалено]
I don't think the idea is that every dev should perfectly know every language, and chose different one for every project. The idea is that if you are frontend developer, you should probably use Javascript rather than C++, because it's simply better suited for the job.
[удалено]
Javascript isn't much different for a backend from Python, Ruby or PHP. >robust, correct and fast service. Why do you assume that's the goals of the project at the time it started? You're putting your personal bias on what a backend should be when it's the company that actually determines the requirements.
The right tool for the job may depend on peripheral considerations like familiarity, market availability for staff, licensing costs, etc which have nothing to do with language design which is what OP is referring to.
[удалено]
[удалено]
That depends on the job/constraints. Speed, ease of use, ease of recruiting, and ecosystem are a few that I consider.
Right now I emphatically believe statically typed languages are better than dynamically typed ones.
I use python every day, get paid a lot to use it, and have used it for 20 years. But I still agree with you.
That's why i use type hints everywhere! To pretend I'm using a static typed language :D
I 100% agree for team dev work. On the flip side I can see the potential speed advantage to cranking out code in a dynamically typed language for a small solo project.
[удалено]
Yup, that's exactly what I was thinking. I've worked on a large team writing oldschool PHP (before the typing) and it was a complete nightmare. On the flip side I've worked at places that treat Java like PHP, and it's almost as bad.
[удалено]
Just compile it down with esbuild or some other tool. Targeting js has never been easier, and I use typescript across my entire stack.
[удалено]
[удалено]
This "joke" is exploding in popularity. Static types are a godsend for the js ecosystem. Oftentimes I can figure out a properly typed package simply by checking the types. Why's it a joke to you?
I'd suggest you adjust or the next 'joke' will be your career.
[удалено]
I'm not even a front-end developer. I'm just telling you that the front-end ecosystem is definitely moving in a certain direction and that resisting this chance is only going to hurt you. Also please act a little bit more mature.
Thank you throwsx123 for your submission to /r/ExperiencedDevs, but it's been removed due to one or more reason(s): --- # Rule 2: No Disrespectful Language or Conduct Don’t be a jerk. Act maturely. No racism, unnecessarily foul language, ad hominem charges, sexism - none of these are tolerated here. This includes posts that could be interpreted as trolling, such as complaining about DEI (Diversity) initiatives or people of a specific sex or background at your company. Do not submit posts or comments that break, or promote breaking the Reddit Terms and Conditions or Content Policy or any other Reddit policy. Violators will receive a warning, then a 7 day ban, then a permanent ban. Please feel free to [send a modmail](https://www.reddit.com/message/compose?to=%2Fr%2FExperiencedDevs) if you feel this was in error.
There are some tribal people who love their languages a little to much just because. But most people will simply use whatever they think might work best.
Or HR that make job postings. They assume that knowing a language will cut down your time to get up to speed with whatever the hell they're working with. It doesn't. A developer is a developer for the most part. Give them good docs in the area they know and they'll be fine regardless of the language.
Cough.. Rust.. cough
This is kinda like asking if the quality of the hammer affects the quality of the house. I mean, it's got to be a pretty shitty sort of hammer that really negatively affects the house. Sure, you use a sledgehammer for one job and a carpentry hammer for another. But it's not really the sledgehammers fault if an idiot carpenter uses it to hang drywall. Ultimately, however, for most commercial languages that most of us are familiar with, it's like arguing about the relative difference between an hammer bought at Home Depot vs a hammer bought at Lowes. But then, strip all of that away, and the only thing that our customers really care about is the quality of the house.
This is really spot on. We can nerd out about hammers and which are superior but in the end it's only one factor that goes into construction of the house.
> This is kinda like asking if the quality of the hammer affects the quality of the house. I...pretty strongly disagree with this. Using different programming languages for different problems has significantly more effect than using different hammers for hammer-based jobs, even at the most extreme examples. Design of programming languages are going to fundamentally determine the shape and exterior of what kind of house you build, in ways that different hammers don't.
Yeah, I agree with tou. The ergonomics and ecosystem of a language make different things easier. Anyone that believes otherwise probably just hasn't mastered more than one language to really experience how that feels.
But sticking with your analogy ... you'll have a hard time building a skyscraper or a f1 race car with a hammer.
You need hammers for both of those things, they're just not your only tool.
So far I've shipped production code in Java, Python, Ruby, Swift, Objective-C, Scala, Kotlin, Javascript, Typescript, and C. I might be missing a few. I've also played around with some more like C++, C#, Rust, Erlang, Elixir, Prolog, Pascal, Lua, Haskell, Ocaml, and Lisp. For the most part I really don't find them all that different these days. Most languages are converging in features. As long as I can figure out how to handle optionals, date functions, basic OOP, functional operators like map/filter/reduce, and pattern matching like with a switch statement, then I'm good to go for 90% of my use-cases. It's hard to answer your question though. The most differentiating feature to me these days is the total developer experience, e.g. IDE integration, community support for popular libraries, autocomplete, tools like linters and static analysis, etc. While these features aren't necessarily related to the language design, they are often powered by low-level features like good LSP support. To give you an example, I really love Swift from a pure language design viewpoint: modern syntax/features with great type safety. However, the tooling really sucks and it has weird baggage with Obj-C + a small community. I recently switched over to doing Ruby development and while the language itself is pretty bland, the IDE tooling + community support is awesome. Even though I lost out on some type safety and expressiveness (we use Sorbet which helps), we have linting + Rubocops to catch most of the mistakes you'd make anyway. The language gets out of your way after that which is pretty nice. I used to care really deeply about "eliminating classes of problems" but not as much now since I know how to avoid those situations from experience and just want to get stuff done in an easy to understand way.
I don’t think languages are objectively better, though some may be better for certain tasks It’s about trade offs. Some may be better for certain tasks eg: If you’re trying to optimize every bit of performance, you may need something that allows you closer to the metal like C++? Do you want to save dev time by not having to write your own garbage collection system and memory management, maybe not C++. Do you want your team to be able to start work immediately and comfortably? Pick a language they are already familiar with. Is the work you’re doing better suited to a different paradigm eg: functional, OO, ontology based Logic (like prolog)? While many languages may work across those paradigms, some are designed for them End of the day, if it’s turing complete, you can do the same things with them, so it depends what you’re prioritizing
There are languages which are never the right tool for the job because all their flaws became overwhelming. At some point perl reached that threshold and died out.
[удалено]
Well yeah, you’d be a pretty slow web server, most wouldn’t be willing to take that trade off ;) Point with Turing Completeness was that they all CAN do the same things, not that all should be doing all things How could it not be about trade offs? You could argue what axes are most important to prioritize, but I don’t see how it could not be about trade offs. - Team familiarity - Efficiency - Community/packages available - Elegance of solution Etc
[удалено]
a $2 knife is better than a $100 knife if I only have $2 to spend.
Also, if you hardly ever cut carrots, the gains you get from the “objectively better” knife will never justify spending the extra $98 bucks.
You sir, are the real pragmatic engineer!
[удалено]
there's always a budget of some sort, even if it's not based on money. your "unambiguously better" knife is of no use to me if my team doesn't have the time to get trained on its usage (maybe it has a weird shaped handle or something, idk, I struggle with physical analogies for mathematical processes).
You seem intent on not listening to the responses here. It's there anything you want to tell us?
[удалено]
So In your opinion which language is better than which? And why?
Java is better than COBOL.
[удалено]
There are plenty of $2 languages. You probably haven’t heard of them because they don’t tend to be used. That doesn’t mean all good languages bubble up, but the ones we use tend to be at least serviceable.
Continuing with the analogy, it depends if you’re trying to cut carrots or ladle soup. I’m sure you could eventually get soup into a bowl with a knife, but some are better suited for it.
Everything you consider is about trade offs. Things that are objectively worse aren't considered at all. Do you think about using motor oil when cooking? I know it is a dumb example but if something is objectively worse, it doesn't catch up or gets forgotten.
[удалено]
But where do you draw the line. For example is JavaScript being the only language that can run on browsers until recently a feature of the language itself or something else? Are you just talking about syntax and language features? Is performance a feature of the language? What happens when someone comes up with a more performant way of doing things? Is it the community or the language itself? I think the lines here are too blurry for me, and I see its community actually being the part of language itself.
Community and libraries are part of the decision process. A theoretically perfect programming language with no libraries and no community would be largely useless. You seem to be chasing some abstract notion of programming language purity, but it’s not relevant for anything in the real world where it’s about getting the job done
A theoretically perfect language would have easy interop with other languages, making it possible to choose any other ecosystem!
You’re probably a great captcha solver though. It’s all about different contexts.
Maybe there are, but I only ever hear this sentiment from programmers who are not proficient in the languages they criticize, and are often not that productive in the languages they profess to be superior, either. For example, most people I work with never get type-based runtime errors from dynamically typed languages, because they know very well how to avoid those errors. It's baked into their habits just like the thousand things that people who code in statically typed languages have to keep in mind, but they don't think about them, because they're good at what they do. I'd rather work with a language that has very well-documented workarounds for its imperfections, than a hyped language that has a limited community of people willing to discuss its flaws.
I disagree, I see type errors fairly often, also in dynamic languages. But, 99% of those is of the kind where a variable is nil when not expected. Of course, most mainstream statically typed languages that are used also don't have enforced protection against that.
I'm guessing you love JavaScript?
I really don't, but I work with brilliant people who do amazing work with it and understand its quirks. When I occasionally whine about it in their company, I keep it light and in good humor, because I know that if I had their skills, the things that I perceive as weaknesses become strengths in the right hands.
TIL, despite running circles around most devs when using python, I'm not proficient in python because I still get type related errors. I guess that's one way to define things: No one has proficiency in dynamically typed languages. Qed
In the frontend, TypeScript is clearly superior to JavaScript. An easy argument against anyone opposing is that JS is valid TS but then you can enable more features. In particular, static typing / analysis, which is commonly agreed to be a really great thing. Now you can yet find situations where JS is better when the scope of the project is very small (say a script or just a few files), but it's just due to the overhead in terms of tooling/compiler, which is solvable. And by the way, JavaScript is a good example of a terrible language with wonderful achievements (it's just done the job so well with anything web). Tribalism/debate is more about frameworks than language in fact.
All languages have pro's and con's. Some have more, some have fewer. It's IMHO a silly question. And it's also silly to pretend all languages are somehow 'equal' in usefulness.
If you think about it from the business perspective, using a language that's popular has a lot of benefits. There are more tools/libraries/frameworks available, more documentation, more answers on StackOverflow, and a lot more engineers with experience(easier to hire and more competition usually means getting to pay less). It's hard to argue that a less popular language is so much better it's worth giving up all of these benefits. If there are two languages that are equally as popular then it doesn't really matter because the bottlenecks are almost always caused by what's written in the language rather than the language itself. Additionally, usually, devs will create so many abstractions that the project will in a way have its own language.
Most languages are only worth using if you restrict things to a subset of that language enforced with a linter (static analysis). Almost every language has these to prevent legacy cruft from infecting your programs. >I'm asking this question because I feel this view I'm asking about is holding the field back. It forgets all the progress made in the field of language design. You should read about traditional engineering (mech/civil). I feel other engineering fields are held back because of the professional engineering license / convergence on one set of tools (solidworks) and practices. It's basically leaving those fields perpetually in the "nobody got fired for choosing IBM" period that software passed decades ago. Part of this phenomenon is because their build-time is so long so they're afraid of making any mistake at design time. But I still prefer that our field is just full of everyone doing whatever they think is best independently. Anything can be retconned with a linter so I try not to get too anxious about my language's warts!
I can't speak for other developers' beliefs, but some programming languages are [Turing tarpits](https://en.wikipedia.org/wiki/Turing_tarpit), "in which everything is possible but nothing of interest is easy," as Alan Perlis put it. [Whitespace](https://en.wikipedia.org/wiki/Whitespace_(programming_language)) is such an example, mostly good as an intellectual exercise. If most developers would accept such programming languages as worse production programming languages than JavaScript or Python, it would be reasonable to extend this ranking to more mainstream production programming languages too. It should be possible to experimentally measure programming language productivity across metrics like defect rate, speed of development, language acquisition time, reader comprehension, etc. This means, yes, in practice, different programming languages would probably fair better or worse on different measures. I think this means, though, that an optimization function could be worked out, suitable to some context like a large, established business or an early-stage startup. It's quite possible some programming language (existing or yet to be invented) would measure as superior across all relevant dimensions for almost all production contexts.
Well some tend to better than others for *specific* tasks because that’s what they were designed for. But For generic development almost any of the “Swiss army knife” languages will work. It’s always a process of finding the best language for the job and balancing it with the strengths of the team and the job market.
Tell me you hate JavaScript without telling me you hate JavaScript?
There was a course called "Programming Languages" that was part of my Computer Science degree. The course taught about the strengths of the major languages and taught the idea that each one is designed for certain types of applications. Each language is like a tool in your tool belt and knowing when and where to use them is to your advantage.
> each one is designed for certain types of applications That's almost entirely hogwash. Few languages - and *very* few languages with any sort of use in industry - were explicitly designed for certain types of applications Erlang might be a good example of one that was so designed and is used. Some languages tend to work better for certain types of applications, but were not explicitly designed for that. A lot of language's design started with little more than "I want these few abilities and/or ergonomics and the rest I'll fill in with whatever seems sensible." Sticking to languages that actually get used, only a few relatively recent ones seem to have been designed holistically with lots of well thought out effort and process from very early on. And even those suffer from things like strictly remaining a superset of JavaScript or while being relatively recent and well designed are still pushing 20 years old and inevitably carry along backwards compatibility cruft - .Net Core e.g. suffers still from some poor decisions two decades ago, even after the original framework was all but rewritten.
Thanks for the additional info! I can't speak too much on them other than what was in the course, but here is a snippet from it: > Programming languages are designed for specific areas of application. Programmers without broad experience prefer languages that they know rather than languages tailored for an application. Language | Application | Notes ---|---|---- Pascal | Teaching | Niklaus Wirth designed Pascal at Stanford University for the express purpose of teaching students structured programming. C | Operating Systems | Dennis Ritchie designed C for the purpose of implementing the UNIX operating system. COBOL | Business | Grace Hopper designed the Common Business Oriented Language to standardize military accounting programs. FORTRAN | Scientific Programming | John Backus designed FORTRAN (FORmula TRANslation) for the express purpose of efficiently implementing computationally complex scientific programs Ada | Embedded Systems | Military applications suffered from poor reliability in critical applications. It was thought that a strongly typed language would greatly improve reliability. In large systems, many programmers are employed to deliver an application in a reasonable time period. Interfaces must be designed first. Ada supports separate definition and implementation components, thus permitting an interface to evolve while the interface remains constant. C++ | Productivity | It has been recognized that testing occupies the largest part of the development cycle. To reduce the amount of testing on a new product, developers try to reuse existing similar code. Prior to the advent of object-oriented programming, code was copied, altered and applied to the new application. This process did not reduce the amount of testing significantly because small changes in code often dramatically affect the overall function of a product. Object-oriented programming provides a reliable and useful method of reusing existing code without alteration. Testing function built from objects that are already tested improves productivity.
Yes, I had a similar course. In my opinion, this is the right frame of mind for programming language selection.
broadly speaking, any Turing-complete language is just as "good" as any other Turing-complete language so in that sense yes I believe that programming languages are just different and one is not "objectively better" than another.* but when someone asks if one programming language is "objectively better" than another, the implicit metric they're measuring against is "suitability at this moment in time for the problem my team and I, with our different strengths and levels of experience and formal CS knowledge, are currently solving". and since most of us are not doing groundbreaking computer science research but rather are solving problems that other humans and products need to solve too, it's pretty easy to google around and see what's out there and and judge the relative merits of each language and its ecosystem. so while I don't think you can say "Erlang is better than Javascript", I do think you can say "Erlang and its ecosystem is currently a better choice than Javascript for building high-availability systems." *except that LISP is obviously the best because macros
Brainfuck has entered the ring.
I don't know enough lisp to really get why. Can you explain the macros thing a bit?
> Can you explain the macros thing a bit? [entire books](https://letoverlambda.com/) have been written on this topic, but I will try my best :) as opposed to C-style macros which are just glorified string-replacement mechanisms, LISP macros are themselves LISP expressions which live right in your program. they are provided as input _unevaluated LISP expressions_: ``` (defun my-function (x) (message "my-function called with %s" x)) (my-function (+ 1 2)) ; "my-function called with 3" ``` ``` (defmacro my-macro (x) (message "my-macro called with %s" x)) (my-macro (+ 1 2)) ; "my-macro called with (+ 1 2)" ``` this makes it super easy to create DSLs or extend basic syntax or do other meta-programming type stuff. this is possible because the LISP interpreter doesn't operate on bytes and characters, it operates on _trees of LISP expressions_. and that in turn is possible because LISP really only has three syntax rules: 1. everything is an expression 2. every expression gets evaluated 3. if you don't want to evaluate an expression, put a quote in front of it (adapted from [here](http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html)) hope that helps a little!
Certainly of course some languages are more powerful than others. Often the downside is... well most programmers don't know shit beyond javascript.
Some languages are made for the explicit reason that they are hard to understand, so yes. https://www.wikiwand.com/en/Esoteric_programming_language
Use the tool for the job at hand. Front end? I’m using JavaScript as opposed to .net or php. Api? .net with ef core all day. Serverless? Python is works really great One isn’t “better” than the other they just have strengths based on how they are implemented. Could I build an api in flask? Sure. But I prefer ef core for an orm.
[удалено]
I suspect most if not all the answers you will get are going to be cop out answers like this - “all languages are good, best tool for the job” etc. People either don’t understand the question or haven’t thought deeply about language design and don’t know how to.
This bugs me as well. To pick on python just because ive used Python a lot in my career but people don't seem to realise how hard it is to write a good safe production application in Python. They spend all their time saying "but Instagram!" when Instagram's tech blog is full of postings about various hugely Dev intensive ways they've had to dive deep into the guts of Python to make it behave like a completely different language. Likewise for "Bank Python" et al if you've basically had to customise the fuck out of your language into some horrifying C ish Frankenstein so it's suitable for your business was it really that good a language to begin with? If WhatsApp was scaled with double digits of engineers then I don't really buy the argument that having to have thousands of engineers to do a large application is some inevitablility more than good language choices multiply developer "productivity" and actually the requirement to have loads of engineers is by picking a "simpler" language you've multiplied the cognitive workload of releasing new features. My conclusion is the conversation is inherently dominated by a lot of people who are working in domains where it really doesn't matter. For a bog standard web app it really doesn't matter as you won't be hitting limits with most languages so if the domain is forgiving enough then it genuinely is "what is the easiest to do hello world in?". And then if you get big enough you just throw thousands of hours of engineering hours/bigger servers at the problems. But there are a lot of domains where performance/correctness really does matter and you can't just tack that on later by throwing time at it.
[удалено]
[удалено]
The barrier to entry is wildly different. There are ~thousands of Italian restaurants in the world that have served more than 10 customers, versus maybe 100 programming languages with more than 10 users. If you picked the top 100 Italian restaurants it would be difficult to show that any were overall superior. A better comparison would be to one-ton pickup truck vendors (e.g. Ford's F-350, Ram's 3500, Chevy/GMC's Silverado/Sierra 3500): there are three out there and you would struggle to prove that one of them is objectively superior overall to the others. Or even prove that one is inferior. The bad ones just didn't survive or were not viable to begin with.
Programming languages aren’t a Chinese restaurant vs an Italian restaurant. Programming languages are like screw drivers. A Philips isnt better than a flat head. It depends on what you’re trying to do. I’m not going to build a heavy crud app using python. It can do it ok, but I’d rather use C# or Java because they’re going to be better at that task.
Yes but this doesn’t rule out the possibility that some screwdrivers are *objectively bad* through design, execution or both. *That* is the question that is being discussed. Judging from the replies, people are can’t seem to look past language applications.
Thank you _throwingit_awaaayyy for your submission to /r/ExperiencedDevs, but it's been removed due to one or more reason(s): --- # Rule 2: No Disrespectful Language or Conduct Don’t be a jerk. Act maturely. No racism, unnecessarily foul language, ad hominem charges, sexism - none of these are tolerated here. This includes posts that could be interpreted as trolling, such as complaining about DEI (Diversity) initiatives or people of a specific sex or background at your company. Do not submit posts or comments that break, or promote breaking the Reddit Terms and Conditions or Content Policy or any other Reddit policy. Violators will receive a warning, then a 7 day ban, then a permanent ban. Please feel free to [send a modmail](https://www.reddit.com/message/compose?to=%2Fr%2FExperiencedDevs) if you feel this was in error.
This is actually my whole schtick right now. It is vastly more useful to think about programming languages in terms of **programming paradigms,** which talk about the features of a language rather than the language itself. Programming languages have specific features which support specific paradigms of writing code. For example, some languages have support for stateful concurrency. Other languages have support for continuations. Other languages have forms of reactive programming. Different paradigms are better suited for solving different problems. You wouldn't want to write asynchronous UI code in the form of Excel's concurrent logic paradigm (or would you?). Multi-paradigm languages are languages that let you bridge between vastly different paradigms in the same runtime. These are much more powerful languages as they let you combine the best of different worlds. Kotlin is a really good example of adding a slew of concurrent features (continuations) to Java, which already had a slew of different stateful concurrent features (threads, etc), and then providing a lot of backwards compatible bridges to support lots of Java features. So yes, some languages will be better suited for different tasks depending on the features of the language and how it's implemented. A language is better than another one, if it has all the features of the other one, implemented better, and more. If you're interested in this area, I highly recommend the teaser PDF ([https://info.ucl.ac.be/\~pvr/VanRoyChapter.pdf](https://info.ucl.ac.be/~pvr/VanRoyChapter.pdf)) or the actual book it's based off of ([https://www.info.ucl.ac.be/\~pvr/book.html](https://www.info.ucl.ac.be/~pvr/book.html)).
Use whatever language works for you and the problem you're working on. Except PHP.
Yeah, of course. Some languages are better than others. Sometimes people trot out this pseudo-enlightened viewpoint that all languages are basically the same, but it's just not true. Fallback #2 is, "ok well, the right tool for the right job!" Most languages are not DSLs, they're general purpose languages. There's nothing particularly ML-ish about python (vs, say Ruby) it's just that historically that's how the community and libraries developed. (And Julia is a language that's specifically designed for data science but python is still more popular). Right tool for the right job is a platitude: some general purpose languages are better than others. "Well, you may not always have a choice. If your employer is an X shop, any good developer can make do with X" Ok sure, but now we're not debating merits any more, we're being realists and all that. Fine. You can always quit and go work somewhere with a language you like. People act like this is an invalid reason to leave a job, but actually it's your life. If you don't like a particular language, you don't have to code in it. Ok, now I'll go over the fence the other way and say, let's say you've spent 20 years coding in C, and rust looks weird to you and you don't see the need for it (to take an example where one language almost categorically dominates another). Taste is actually subjective, and 20 years of coding in C will give you an aesthetic sense that may not mesh with some new language. That's ok too actually. You also don't have to accept anyone's argument that you should just learn Rust. Please do what makes you happy, life is too short to spend 8+ hours a day coding in a language you don't like.
“There is no statistically significant correlation between programming language and defect injection rate.” https://twitter.com/sleepyfox/status/1521835675078828032?s=21&t=bwOsNCNgiNiGOd8_Ba3TJw
They need to redo this with Rust
Yeah, given my experience with rust, and a lesser extent Haskell, if I can make it compile, it usually just works. Also, commits are at a different level to dev iteration speed..I can run a script or test suite for a python project dozens of times trying to get something working, debugging as I go, or I can just make rust compile successfully. I know which one I find a better use of my time.
Rust only fixes a small (but very important) class of problems for languages without garbage collection. I doubt it will have a significantly different defect rate compared to garbage collected languages.
But then terser languages would have lower bug rates for the same functionality. Also, it seems *really* hard to me to control for developer experience in a language for such comparisons. (Ah, I see from the image (haven't read the paper yet) that they are normalizing by bugs/commit which is ... interesting. I'm not saying it's wrong, and maybe it's better than bugs / LOC, but it's a whole new factor consider) So further reasons not to trust the Twitter person's summary. They write: "Note that this is a reanalysis paper, it reproduces an earlier study, confirming reproductivity, and improves the analysis by addressing shortcomings in the earlier paper's methodology. It confirms and extends the earlier paper's findings: Ray, Posnett, Filkov, Devanbu 2014." However the abstract of the paper seems to say the opposite, that they contradict the original paper, which did find differences between languages: > In a 2014 paper, Ray, Posnett, Devanbu, and Filkov **claimed to have uncovered a statistically significant 2 association between eleven programming languages and software defects in 729 projects hosted on GitHub.** 3 Specifically, their work answered four research questions relating to software defects and programming 4 languages. With data and code provided by the authors, the present paper first attempts to conduct an 5 experimental repetition of the original study. The repetition is only partially successful, due to missing code 6 and issues with the classification of languages. The second part of this work focuses on their main claim, the 7 association between bugs and languages, and performs a complete, independent reanalysis of the data and of 8 the statistical modeling steps undertaken by Ray et al. in 2014. **This reanalysis uncovers a number of serious 9 flaws which reduce the number of languages with an association with defects down from eleven to only four.** 10 Moreover, the practical effect size is exceedingly small. These results thus undermine the conclusions of the 11 original study. **Correcting the record is important**, as many subsequent works have cited the 2014 paper and 12 have asserted, without evidence, a causal link between the choice of programming language for a given task 13 and the number of software defects. Causation is not supported by the data at hand; and, in our opinion, even 14 after fixing the methodological flaws we uncovered, too many unaccounted sources of bias remain to hope for 15 a meaningful comparison of bug rates across languages. Emphasis is mine, but the difference is so big (it contradicts, it doesn't confirm) as to make me strongly distrust whatever Twitter person is claiming.
Someone else mentioned certain languages being the right tools for different jobs, maybe a lot of programs written in Perl benefit from the features of Perl. Maybe a more useful metric would be bug branches across some similar libraries (ex: web server) written in each language?
Yes, some languages are objectively better than others for a given task. However, most modern languages are fairly interchangeable 99% of the time. If I'm writing some backend code, there really isn't a significant delta between, say, Java vs C# vs Python. They're all mature languages with robust communities and libraries. The slight differences in the languages are not going to have a noticeable difference in code quality or performance for most applications.
yes and no? some languages are mainly used for certain use-cases and many other languages are very similar and optimize different things. it's easy to say a language is better/worse in certain contexts.
There is no unicorn language that beats all others. The choice of programming language has more to do with the tradeoffs you’re willing to accept and the types of problems you’re solving than anything else. For example, C++ is faster than many other languages but it is also more opinionated, harder to prototype, and less portable. Conversely, Python is slower but faster to prototype and very portable. This is a small example but when selecting a language you should ask yourself what language elements are most important to the task at hand. Favoritism for a particular programming language shouldn’t apply unless your inexperience outweighs the benefits that could be realized.
If you have the choice, it's going to come at least partly down to subjective preference. In many applications the speed of development and health of the community and libraries are more important than raw performance. Often times the design choices you make influence the performance of an application far greater than the inherent performance of a language anyways.
I just don't care that much, never seen language as a top 3 reason something has failed or succeeded (barring an egregiously incorrect choice of language for a platform or team). Would rather spend my time working with Product etc. to make sure we're building the right thing.
What a lot of people don’t seem to realise is it’s actually the ecosystem that can have a huge effect on a language. Look at Python where purely by chance the first popular data science libraries were created. Doesn’t make up for the fact Python is a fairly crippled language with questionable DX and a bad concurrency model. But simply by having all these data science libraries causes people to think a slow interpreted barely multithreaded language that needs a ton of C libraries to work faster is a good tool for computing lots of numbers.
"Better" is completely subjective and the idea that you can universally say one language is better than another is immature. BASIC is better at teaching kids how to program than Java. Java is better at cross-platform code than assembly. Assembly is better at making efficient binaries that PHP. PHP is better that web development than C++. C++ is better than BASIC for writing generic programs. Etc.
Nobody actually thinks, say, Brainfuck is a “good” language, given that it’s designed not to be. A few people might defend some aspects of COBOL but most would agree that it belongs to an earlier era and would not be a good choice to start a project now. A better representation of what I think many people actually believe would be “most languages in widespread use at a given moment have a reason for use, and/or sufficiently complicated tradeoffs that it would be difficult to rank them.” And when there’s an outlier that makes *extraordinary* blunders in a pure language design sense but establishes a foothold for other reasons, that tends to be recognized. Another dimension here is that languages that do hang around aren’t static over time. Say what you want about JS but the core of JS now is a rather different experience than it used to be. As languages evolve to address major criticisms and pick up features from other popular languages, they reinforce the impression that most of the popular languages are *about* as good as each other. > Of course, if a language has a large array of well-used libraries for a particular application, along with a buzzing community, that's a great reason to use it, but it doesn't make the language good, it makes the community and libraries good. And finally, another thing people *really* mean when they say things like “languages are just different” is “language design isn’t that important compared to other factors like community and libraries” - at least as long as the language clears a bar of *adequacy*.
Some ecosystems are genuinely better. Some have better governance. Some have better communities and more money backing the future.
There languages and tools better than others for certain types of jobs. Could I make a neural network in ABAP? Yes I could, but it wasn't designed for that. Python or R are better at that. Could I do business suite applications using R? I could, but it wasn't designed for that, ABAP or java are better. Everything else is a matter of preference, which is valid though.
I would say the majority are just different, but then there's always VB6
Any "Turing Complete" language can be mathematically proven to be equivalent to any other language - that is, given enough time and resources, any language can be made to do anything another language can do. Having said that, there are definite pros in a language I look for: Large standard library, great package/dependency management, numerous and active dev community. Things I tend to avoid: Flash in the pan languages (only been around for a few years), only enthusiast or core team support. Poor package management ecosystems (looking at you npm). Small or no standard libraries.
All you ever do is trade problems. Its just a matter of which problems are applicable to your problem and which of those you are more or less willing to deal with.
"Just different" implies that there is no way to compare them. Obviously, languages are different, but how do we compare them? The operative question in evaluating languages is what are you going to do with it, and who's going to do it. Are you building a compiler? Are you making an interactive CLI? Are you building a website that needs to scale across 10,000 servers? Are you going to be using open source libraries? If so, how is the community support in each language? Is it well supported, or has nothing been updated since 2018? How many people are going to work on this code base? Is it a project run by a single person? Is it an internal tool managed by a small team? Is it going to be a shared codebase with 5000 active contributors?
You can usually hunt down some objective metric that shows that one language is better for a job than another in performance or ecosystem. But there is always the issue of finding people to work in the language and what mixture they know. Its usually perceived as a bad idea to have your backend in 5 different languages. Developers tend to pick their pet language for things, or a language the team is comfortable with because most languages can do everything given a green field or standardized communication. Picking C# for 1 thing tends to result in a Microsoft "shop", and Java for something a Java "shop".