Comment by MaxBarraclough | Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

Parent Full thread

> It actually makes python safer then C++ even though python is dynamically typed.

Yes, Python is safer than C++. C++ makes no pretence of being a safe language. Static typing is not the same thing as safety.

> It is far easier to debug a error caused by out of bounds memory writing/reading in python then it is in a strictly typed language like C++. This is because C++ doesn't actually fail hard and fast when you do this.

Out-of-bounds array access is undefined behaviour in C++, but that isn't a result of C++ being statically typed. If you want a statically typed language with bounds-checked arrays, look at Java, Ada, or Rust.

More broadly, languages with static type systems aren't precluded from using runtime checks.

> python is by far less error prone then C++ despite being untyped.

Again this doesn't generalise to all statically typed languages.

Also, Python isn't untyped, it's dynamically typed. An untyped language is a language with no concept of type, such as assembly or Forth. [0]

> Javascript is actually the same, though a little worse then python because how an undefined can get propagated deep into a program.

How is JavaScript different from Python here?

> I would argue that it doesn't depend on whether the language is dynamically typed, but more on the traceability of crashes.

I'm not sure I follow, what doesn't depend?

I agree that for a language to score highly on debugging, there's more to it than being statically typed.

[0] https://en.wikipedia.org/wiki/Programming_language#Typed_ver...

> C++ makes no pretence of being a safe language

Yes it does. Throughout the entire history of C++ has been touted as as a "better C", where "better" includes "safer". This was not just empty marketing; the claims were justified.

For instance, std::string is a heck of a lot safer than manipulating character arrays. You can do str1 = str2 + str3 without worrying about memory allocation. Not to mention "return str1" as if it were a scalar value.

There are ways of using C++ that are entirely safe, along those lines. Not just modern C++ either, but old C++98. You carefully develop some classes that are nicely behaved, and then use only those classes. No C arrays, no C pointers.

> Yes it does. Throughout the entire history of C++ has been touted as as a "better C", where "better" includes "safer". This was not just empty marketing; the claims were justified.

You're arguing that C++ makes safety improvements over C. I broadly agree, but that's not the topic at hand. C++ is still quite plainly not a safe language.

Whether it's safer than C isn't the point, but this causes undefined behaviour in both C and C++:

    int i;
    int j = i;

as does this statement:

    int i = 1 / 0;

as does:

    int i = INT_MIN * -1;

as does:

    int i = INT_MAX + 1;

> There are ways of using C++ that are entirely safe, along those lines. [...] No C arrays, no C pointers.

Practically speaking, no, there are not. As I showed above, it's not just arrays and pointers that have safety issues in C and C++. I've rambled before about how there's no practical way to entirely avoid the unsafety pitfalls of C and C++ (short of formal verification). [0][1]

Compare this against the Safe Rust subset of Rust. Safe Rust really is a safe language, at least by their (very strong) definition of the term as guaranteed to be free of undefined behaviour. [2] It's not possible to define a practical subset of C or C++ with this property.

[0] https://news.ycombinator.com/item?id=26307709

[1] https://news.ycombinator.com/item?id=30597750

[2] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

> You're arguing that C++ makes safety improvements over C. I broadly agree, but that's not the topic at hand. C++ is still quite plainly not a safe language.

The topic at hand is not what your purporting it to be either. You seem to be thinking that the topic at hand is C++ is a language that touts itself to be safer then python. And you are responding to me as if I made that claim. I never did.

Obviously the person you're responding to is making the claim that C++ does tout itself as "safer" then C but not necessarily "safer" then python. But he is responding to an Actual claim you made saying that C++ doesn't tout itself as safe.

> Practically speaking, no, there are not.

Yes, there are. C++ has constructors which ensure that uninitialized objects don't happen.

   mynumber i;        // i is initialized by constructor
   mynumber j = i;    


   mynumber x = mynumber(1) / 0;  // reliable exception is thrown

   i * INT_MAX;       // exception or bignum support in mynum

> Yes, there are.

We're not talking only about read-before-write and integer arithmetic, we're talking about all causes of undefined behaviour.

If it were possible to define a practical subset of C/C++ which guarantees the absence of undefined behaviour, someone would have done so by now, and cybersecurity would be in a much better place. The subset would have a name, would be widely discussed and studied, and we'd be able to point to a large security-sensitive project making successful use of it. I don't believe any of those are the case.

We have subsets like MISRA C and MISRA C++, but they do not offer solid guarantees against UB. We have ambitious formal verification systems such as [0] which are able to reason about C/C++ programs to help the developer produce a solution guaranteed to be free of undefined behaviour.

All that said it would be an interesting project to see how far you could get with a truly safe C++ subset. Like MISRA C, it would be important that there be an automatic way to check conformity.

> C++ has constructors which ensure that uninitialized objects don't happen.

Yes, Boost offers a library for safe integer arithmetic [1] and it's a pity it's so rare for that kind of approach to be taken. A similar approach could presumably be taken to close the door on unsafe union operations, by insisting on using std::variant instead. C++ is particularly amenable to this kind of thing, on account of its operator overloading.

Unfortunately there are many other areas of the C++ language where it's not so straightforward, such as concurrent programming and memory management. Again please see my linked comments where I give a number of examples.

On the memory management front I imagine the way to go would be to ban pointers outright, but permit smart pointers, and have strict rules regarding references.

Also, here's a neat blog post I stumbled across on how std::string_view is unsafe, among other things. [2] edit I now see you've already seen it. [3]

[0] http://www.eschertech.com/products/

[1] https://www.boost.org/doc/libs/1_79_0/libs/safe_numerics/doc...

[2] https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

[3] https://news.ycombinator.com/item?id=26948129

>Yes, Python is safer than C++. C++ makes no pretence of being a safe language. Static typing is not the same thing as safety.

I'm just addressing the posters comment on statically typed langauges. Not saying anything about "pretenses".

>Out-of-bounds array access is undefined behaviour in C++, but that isn't a result of C++ being statically typed. If you want a statically typed language with bounds-checked arrays, look at Java, Ada, or Rust.

Yeah I know.

>Again this doesn't generalise to all statically typed languages.

I never said this. I am just commenting on the opposite generalization the poster I'm replying to made. In general statically typed is safer the dynamically typed but this doesn't apply to all actual languages with these properties. There are actual statically typed languages like C++ that are less safe then a dynamically typed language like python.

>Also, Python isn't untyped, it's dynamically typed.

This is just a semantic mistake. Clearly I meant dynamically typed. Not untyped. But I hope people get the meaning.

>How is JavaScript different from Python here?

Javascript doesn't crash as much as python. For example Calling someHashTable[nonexistentKey] in javascript returns a value that can actually be propagated far along into the datapath before throwing an error. IN python that's an instant crash. This makes python much easier to debug then js. I use the words less error prone, because python in the long run ends up having less errors due to creators implementing failures that happen quickly and early.

>I'm not sure I follow, what doesn't depend?

Statically typed languages prevent run time errors related to types. I am saying that while this is great this property isn't that important then errors that are easily traceable.

What's by far more important is that even if the programming language has many holes where run time errors can occur it is better just to have those runtime errors easily traceable to the source of the error. The existence of errors that are hard to trace in C++ actually makes it much much less safe then python despite the extensive type system. It indicates that type safety is much less important.

> Statically typed languages prevent run time errors related to types. I am saying that while this is great this property isn't that important then errors that are easily traceable.

I don't think I agree, it's very beneficial to catch a bug at compile time (or at least 'type-check time') rather than at runtime. It's particularly valuable for refactoring. Even if it's easy to trace a runtime error, it's still a win to transform it into a compile-time error, or a bright red line in an IDE.

> Statically typed languages prevent run time errors related to types.

The upper-limit on what can be done with type-systems isn't terribly clear, as sophisticated type systems (of the kind we don't see in today's mainstream languages) can prevent errors which aren't simply passing the wrong kind of data. An old Rust example: [0].

> What's by far more important is that even if the programming language has many holes where run time errors can occur it is better just to have those runtime errors easily traceable to the source of the error.

An error might be very rare or might only occur when a malicious action is taken, so it's important for a language to be helpful in writing correct code. Consider a buffer-overflow in a C codebase that only happens when a malicious packet is received.

Of course, type systems aren't the only way for a language to help the programmer write correct/safe/secure code. For example GCC has a flag to have the compiler insert code to explode noisily if the program tries to dereference NULL. That's an improvement in safety when compared to what standard C gives you (undefined behaviour of course), but doesn't relate at all to type systems.

[0] https://yoric.github.io/post/rust-typestate/ (although typestates were since removed from the Rust language)

>I don't think I agree, it's very beneficial to catch a bug at compile time (or at least 'type-check time') rather than at runtime. It's particularly valuable for refactoring. Even if it's easy to trace a runtime error, it's still a win to transform it into a compile-time error, or a bright red line in an IDE.

Well explain python then. Why is python easier to work with then C++? There is literally so much raw data to back up my statement on how python is "easier" then C++. Anyone who has worked extensively with both languages, and I mean very extensively, knows how painful C++ is compared with python.

I think you may not agree. But that's just your own unique opinion. In general, I'm the one who's right.

>An error might be very rare or might only occur when a malicious action is taken, so it's important for a language to be helpful in writing correct code. Consider a buffer-overflow in a C codebase that only happens when a malicious packet is received.

So what's your point? Your stating this because of what?

>Of course, type systems aren't the only way for a language to help the programmer write correct/safe/secure code.

Why are you telling me this? Did I say type systems were the only way?

>That's an improvement in safety when compared to what standard C gives you (undefined behaviour of course), but doesn't relate at all to type systems.

Another improvement is to make a programming language that is impossible to crash. Several languages already have this ability. But this is a tangent. Again I really don't want to dive to deep into this.

The point remains this: Python is more safe then C++ despite having more holes for crashing and no type system. Can you prove otherwise or not?

> explain python then. Why is python easier to work with then C++?

This isn't an apples-to-apples comparison. They're very different languages, in terms of everything from memory management to build models to type systems to concurrency to historical baggage.

Python is certainly more writeable than C++, for countless reasons. In terms of maintainability, Python's dynamic types are a disadvantage, but Python is also a much simpler and safer language than C++, which is very beneficial.

> I think you may not agree. But that's just your own unique opinion. In general, I'm the one who's right.

Please refrain from this kind of thing on HackerNews.

> what's your point?

Traceability of errors isn't everything. It's also important for a language to help the programmer avoid introducing defects in the first place.

Neither Python nor C++ do this particularly well. Neither is anywhere near, say, Ada or Haskell.

> Why are you telling me this? Did I say type systems were the only way?

There's no reason to be defensive. Not everything is a refutation.

> Another improvement is to make a programming language that is impossible to crash. Several languages already have this ability.

I'm not certain what you mean here. Which languages are you thinking of?

It's very often useful for a language to have runtime checks that may result in immediate termination, rather than continue with unaddressed erroneous execution. Examples are when Java throws on an out-of-bounds array access, or on divide-by-zero, or on dereferencing null.

> Python is more safe then C++ despite having more holes for crashing and no type system.

We're agreed on this point, although I'm not sure I'd say Python has more holes for crashing. Python is the safer of the two languages. [0] C++ is a minefield of undefined behaviour, [1] Python is not.

Our discussion has not been limited to safety.

[0] https://news.ycombinator.com/item?id=31223659

[1] https://news.ycombinator.com/item?id=31224310

>This isn't an apples-to-apples comparison

Sure but the comparison or topic at hand was safety. In the case of safety, python is more safe.

>Please refrain from this kind of thing on HackerNews.

Why? I'm saying the general opinion among most people is that my point is correct. Your point is unique and more exclusive to you. Why refrain from stating general opinions and distinctions? I think you should refrain from telling people not to state reasonable things.

>In terms of maintainability, Python's dynamic types are a disadvantage,

Safety is correlated with maintainability. Before I address this, let me say that python now has type annotations and when paired with external type checkers during build time, python effectively becomes a statically typed language with compile time type checking and a type system more consistent and powerful then C++.

That being said. My claim is EVEN without using type annotations, python is by far more safe and more maintainable then C++, simply because of higher traceability of errors.

>Traceability of errors isn't everything. It's also important for a language to help the programmer avoid introducing defects in the first place.

Yes of course. But again this isn't the point. The point is python vs. C++. That being said my claim on the side also supports the notion that error traceability is more important then pre-compile time safety.

>There's no reason to be defensive. Not everything is a refutation.

Not being defensive. Just not seeing the point. There's a topic, but your introducing topics that are obvious? It's like you saying the sky is blue. Thank you for letting me know, but why?

>I'm not certain what you mean here. Which languages are you thinking of?

Crashes or undefined sections of a language are defined by the language itself. You can always design a language where every hole is filled. Outside of using up too much memory and FFI there are languages that are defined so that they can never crash and that there is zero undefined behavior period.

>It's very often useful for a language to have runtime checks that may result in immediate termination,

There are languages that don't even compile with out of bounds access. Such languages force you to write handler logic in order to even work.

>We're agreed on this point, although I'm not sure I'd say Python has more holes for crashing.

Python does have more holes for crashing. The thing is those holes aren't "undefined" though. They're very much defined behavior. That's why they're so traceable, but these are still holes in my mind because there are languages so safe that crashing holes don't even exist.

>Our discussion has not been limited to safety.

No it has not. but mainly because you've been taking it on tangents. I've been addressing your tangents but the main point is: Python is safer then C++. If we agree then the discussion is finished in my mind. I stated that here.

https://news.ycombinator.com/item?id=31225265

I mean I'm ok with tangents but in a lot of discussions, this one included, the tangents are introduced in a way that obfuscate the main point. There's a discussion where I'm trying to prove a singular point and then suddenly one person introduces 20 different topics and pretty soon the singular point is lost in the weeds. Nobody was a definitively right or wrong.

Reply on news.ycombinator.com