And when tools are just tools why are so many different tools? You need the right tools for the job. So a programming language is just a tool and you have to pick the right one for the job.
When all you have is a hammer, everything looks like a nail!
Editor/IDEs are tools. Tools are not parts of your final product, but materials are.
The properties of the language are reflected onto the software. Is it fast? resilient? easy to maintain? They depend on what you use to build it, and how you build it.
Using the suitable language to build software as if using the suitable material to build stuff.
@Kabie I disagree with you: For one, programming languages themselves usually disappear from the application, while the method of thinking they impose on developers using them definitely makes it to the application. On the other hand, tools definitely have an impact on what you make: If you try to sculpt using a sledgehammer instead of a chisel, your final sculpture will definitely be more rough-hewn.
While editing environments definitely are also tools (and arguably more interchangeable ones than languages are), they also have an impact on what you make. An simple example: when you are writing a program in C and use clang-tidy, the chance of common memory errors will be lowered (somewhat).
However, I actually find the âtoolâ metaphor to be limiting, because:
what about metaprogramming? Tools to build tools (to build tools to build tools⊠?)
what about a compiled application? Isnât this just another tool/means to do something useful? (Isnât the âsomething useful happensâ the thing we want to archieve, rather than âwe have an applicationâ?).
This is why I prefer a different phrasing of âa programming language is just a toolâ, which is: âprogramming languages are a means, not an endâ. I think that captures the essence more clearly (and has a smaller chance of being misunderstood).
It happens with some frequency that people are fooled by âAll (general purpose) programming languages are Turing-Complete, so are they not 100% interchangeable?â: while it is true that this means that all programming languages can calculate everything that other languages can,
certain calculations will be simpler to conceptualize and implement in language (a) than in language (b) (and others might be simpler in language (b)).
Turing-Completeness only talks about single-threaded, serial execution. Programming languages are definitely not created equal when talking about their approach to multithreading.
So:
is all programming language are the same tool ?
No, they are all different!
if it so, why there is more than 50 programming language exist in this world
and why new language are keep coming and coming
Programming languages reflect the state of mind of their creators (and, to a certain degree, their users). This is why so many different languages with different approaches and concepts exist.
why Keras Framework are written in Python, not C/Assembly ?
This is an educated guess (if you want to be sure, ask the maintainers of Keras), but looking at their homepage, it seems that user friendlyness is an important guiding principle of the library. Python is generally considered as more approachable and user-friendly than C or assembly because of the manual work required and non-existent or highly leaky abstractions in C/assembly.
why X framework/application are written in X language not in Elixir language
Either or both of the following:
did not know about it.
Elixir would not have been a good match for the concept. Things that Elixir is notably bad at are:
Computation-heavy applications.
Libraries in which you want to work with/create a very strongly typed API.
Elixir would have been a good match, was not around when the thing was first created, or the developer(s)
I like this analogy, as people can easily understand that building a wooden framed house is quicker and easier than one built with rocks, yet wonât possibly be as sturdy. Depending on the environment (how is the weather? are there hurricanes? Tsunamis? Does it get really cold in winter? Humid?) as well as the time and money you have, you wonât want to chose the same materials, regardless of the ease of building. It is also cheaper to hire people who will pour some concrete and add a cheap wood frame on top than specialised stone masons, carpenters, etc.
Thatâs an interesting paper, although it seems to mostly be a metastudy of older papers, so it is lacking newer languages like Rust and Elixir, even in their own research (which did not follow the older papers in all cases due to thinking things through a bit better), though they did add Go.
In essence though, languages with GCâs have fewer memory errors (the most common form of error), except Java, which actually has âmoreâ memory errors. Functional languages have fewer errors in general than non-functional languages. Strongly statically typed languages have fewer errors in general than non strongly statically typed languages. Languages with inherently single-threaded memory models (Python, Ruby, OCaml, etcâŠ) have fewer general bugs than concurrent memory models (though I doubt thatâs the case on the BEAM or Rust).
They had to remove some languages like typescript because there was not enough data in the past paper since it got conflated with an XML translation file that also used the .ts extension, and C++ got expanded because the old paper did not check all standard file extensions.
It did find that only 4 languages did have a statistically significant association with defects (clojure (-0.15), haskell (-0.12), ruby (-0.08) and C++ (0.16)) but that the effect was exceedingly small. There is not even much difference between the ultra dynamic ruby vs the super strict haskell.
Strongly statically typed languages have fewer errors in general than non strongly statically typed languages
That was one of the claims of the original study, which I wouldnât say is backed up by this study. There is not enough good data. The data that is there shows a dynamic language (clojure) being associated with fewer bugs than (haskell), but even ruby (the most dynamic language?) shows a negative association with bugs.
Because of the findings in this new paper I think the conclusions made in the original paper must be disregarded at this stage.
Not entirely disregarded, rather some languages balanced out excessively different from the original paper. In addition, they are still only git commit message scraping, and people use words for things a lot that wouldnât apply for their searches, in addition a lot of âfixesâ and so forth get squashed (I really hate that losing history) so they vanish in general. None of the studies will be accurate unless people actually go over a lot of git repoâs that have complete history. ^.^