Is programming language just a tool?

General Prog (Archived)
1

one of my friend keep telling everyone if programming language is just a tool

but :

  1. is all programming language are the same tool ?
  2. if it so, why there is more than 50 programming language exist in this world
  3. and why new language are keep coming and coming
  4. why Keras Framework are written in Python, not C/Assembly ?
  5. why X framework/application are written in X language not in Elixir language

please give your opinion about programming language is just a tool

1 Like
2

Are cars just tools?
If so, why there are so many models?
And why new ones keep coming and coming?

:wink:

4 Likes
3

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!

2 Likes
4

I prefer another analogy I saw somewhere:

Programming languages are materials.

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.

12 Likes
5

@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:

  1. is all programming language are the same tool ?

No, they are all different! :slightly_smiling_face:

  1. if it so, why there is more than 50 programming language exist in this world
  2. 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.

  1. 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.

  1. 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)
3 Likes
6

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.

2 Likes
7

An interesting recent study on this subject: On the Impact of Programming Languages on Code Quality

1 Like
8

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.

2 Likes
9

This paper, a reproduction of an older paper, shows that the claims made by the original paper cannot be made. The original paper (A large scale study of programming languages and code quality in github | Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering)

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.

2 Likes
10

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. ^.^