6

Can it be that applications written on certain languages are inherently less safe, no matter how hard you try to get it straight?

Or, can it be that some programming paradigms are less safe than others?

That is, should the development of safety critical software consider avoiding, or using (or using with care) certain languages?

Improve this question
2
  • 1
    I don't think this is too broad. @TomLeek gave a good answer. It was answerable, has a good answer, and is not too long. I am therefore voting to reopen. Commented Mar 16, 2016 at 19:30
  • Along these lines, is Python less safe because instance attributes such as self are accessible outside the class that contains it? Commented Mar 17, 2016 at 15:36

1 Answer 1

Reset to default
9

Safe programming is a subset of correct programming -- every exploitable vulnerability is, basically, a bug such that the consequences of exercising the bug are advantageous to an ill-intentioned individual (the "attacker").

Languages offer facilities which help or not help in making correct programming. For instance, if the task at hand involves doing things with character strings, languages that have an inherent type for character strings, handled as immutable values, make things much easier for the developer. Many modern languages such as C#, Python, PHP or even Javascript fall in that category. Conversely, more low-level languages like C and Assembly require the developer to handle allocation for buffers holding strings, taking care of all lengths and deallocation at the proper time. In that sense, C and Assembly are "less safe" languages than most others when it comes to handling character strings, because they require more care from the developer. "Care" is a scarce resource.

In the same vein, some languages include a lot of "magic" such as automatic trans-typing, which means that a seemingly simple expression may hide a lot of complexity, that may bite the unwary developer. Some modern languages such as C#, Python, PHP or Javascript have that flaw. Conversely, low-level languages such as C and Assembly tend to be "safer" in that everything they do is explicit. The developer just has to read what is in front of his eyes, with less mental inferences on what the interpreter/compiler will do. "Thinking time" is a scarce resource.

There is no paradigm that is inherently less safe than any other; however, lack of a defined paradigm is assuredly less safe. Safe programming, ultimately, is about a developer who knows what he is doing, and this comes from discipline.

Edit: "Discipline" means never writing any code whose complete behaviour, under all possible combinations of normal and abnormal input data, is not fully understood by the developer. In particular, it implies not throwing code together and tweaking until the thing accepts to run. Similarly, copy&pasting from Stack Overflow is poor discipline -- reading solutions on SO is very fine, but it must be followed by thorough understanding of what the code does.

Improve this answer
3
  • What kind of discipline? A brief explanation would be great Commented Mar 16, 2016 at 14:47
  • 1
    Wouldn't a language enforcing static type-checking be safer? Couldn't the behavior of a dynamic language be more unpredictable, and therefore more apt for being exploited? Commented Mar 16, 2016 at 14:53
  • 1
    Proponents of static (respectively dynamic) types always present their favourite language feature as the best way to achieve "safety" but it is not really substantiated in actual practice -- developer's discipline is much more important. But note that not all developers are equivalent; some will be more at ease with static type-checking, while others will be more efficient with dynamic type-checking. In general, the best language a developer may choose is the one he masters, and that won't be the same language for every developer. Commented Mar 16, 2016 at 14:57

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.