Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python, as Reviewed by a C++ Programmer

sgh1.net

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Python, as Reviewed by a C++ Programmer

#61

Post by E6300 »

vertex-four wrote: post #46
vvanders wrote: post #26

Earlier quoted context omitted.

Haha, oh you definitely have to pull out the debugger. Rust doesn't save you from logic errors, control flow issues and ffi gone wrong. That said I get your point about using the debugger less .

Honestly, my programs tend to be simple enough that logic errors are reasonably rare, and the ones that do pop up can be resolved by println debugging. :)

> Honestly, my programs tend to be simple enough that logic errors are reasonably rare

That says more about the particular programs you write than about the language, frankly. Writing trivial bug-free programs is easy in any language. The trick is writing complex bug-free programs.

> println debugging

This is something you should only need to do if you have a wretched debugger of if you're working on a bug where the presence of the debugger alters its behavior.

Re: Python, as Reviewed by a C++ Programmer

#62

Post by humanfromearth »

Rapzid wrote: post #58
striking wrote: post #39

Earlier quoted context omitted.

Sure, but most python code isn't annotated, right? So this might be helpful for code you wrote, but not anywhere it interfaces with other peoples' code (which, in my opinion, is probably the most important place to check for type errors).

Plus, many packages dynamically add members, stomp named parameters by wrapping stuff with kwargs, etc.

So monkey patching is bad you're saying? I agree that it's possible what you're saying about kwargs, but after about 6 years of python I've never encountered that in any of the code that I've worked on.

Re: Python, as Reviewed by a C++ Programmer

#63

Post by asddddd »

striking wrote: post #39
inlineint wrote: post #36

The article doesn't mention type annotations described in PEP484 and added to CPython since Python 3.5. It is possible to add annotations to your code like class Foo: x: int # ... and then run type checks using `mypy`, so that for the annotated code probability of the "passes the checks => won't crash the runtime" case is much larger.

Sure, but most python code isn't annotated, right? So this might be helpful for code you wrote, but not anywhere it interfaces with other peoples' code (which, in my opinion, is probably the most important place to check for type errors).

The older method is docstrings (reST and similar) like here: https://github.com/kennethreitz/requests/blob/master/request...

IDEs like PyCharm can use those and other methods to find most typing issues. In practice this is very effective for most "boring" Python code, but if you get really clever it falls over completely.

Re: Python, as Reviewed by a C++ Programmer

#65

Post by vertex-four »

E6300 wrote: post #61
vertex-four wrote: post #46

Earlier quoted context omitted.

Honestly, my programs tend to be simple enough that logic errors are reasonably rare, and the ones that do pop up can be resolved by println debugging. :)

> Honestly, my programs tend to be simple enough that logic errors are reasonably rare That says more about the particular programs you write than about the language, frankly. Writing trivial bug-free programs is easy in any language. The trick is writing complex bug-free programs. > println debugging This is something you should only need to do if you have a wretched debugger of if you're working on a bug where the…

> Writing trivial bug-free programs is easy in any language.

Not really. Writing programs which don't crash the first few times I run them in a dynamic language is surprisingly hard. Just having a compiler prevents having to get to that point - and then Rust ensures that I handle potential errors correctly and avoid segfaults.

> This is something you should only need to do if you have a wretched debugger of if you're working on a bug where the presence of the debugger alters its behavior.

Or if I can't be arsed configuring gdb with breakpoints for everything from the command line. I can add a println!(), save my file, and watchman will recompile and run my program in a much more reasonable (to me) workflow. I assume that I can somehow integrate gdb into my editor, but that involves a pile of learning new things.

For a so-called "trivial" app I'm most of the way through writing right now, is an OpenID Connect and SCIM server that has had to implement a decent chunk of functionality (JWTs, key fetching and caching, juggling between postgres and redis, etc) from scratch. But for most of the particularly fiddly parts, I've managed to have the type system ensure that I either outright can't have logic errors or they're detected and the program panics, which is rather nice.

Re: Python, as Reviewed by a C++ Programmer

#66

Post by makecheck »

pzh wrote: post #27

For me the biggest downside of dynamically typed lanaguages like Python and Javascript is that a small error in passing a function's parameters can propagate very far in a complex system. E.g. if you mistakenly interchange two consecutive function parameters, you could spend several hours debugging the effect several modules down. This is an error that a C++ compiler would catch right away.

C++ is not always able to detect common parameter errors, especially for things like implicit conversions of numbers. Arguably Python’s option of keyword arguments make certain classes of parameter errors go away, too.

Several years ago I remember someone who (perhaps unwisely) wrote a C++ function with many floating-point values as parameters and a single default "bool". At some point the function was extended to have another float. The compiler did not catch calling code that failed to add an extra float; it simply allowed the formerly-flag arguments to be assigned to the new float argument instead. In fact, implicit conversion of parameters is such a common C++ problem that I occasionally define wrapping types for the sole purpose of being parameter types: then the compiler has to trip over them when they are used incorrectly and callers have to do some kind of explicit action to indicate what their values really are.

Re: Python, as Reviewed by a C++ Programmer

#67

Post by E6300 »

vertex-four wrote: post #65
E6300 wrote: post #61

Earlier quoted context omitted.

> Honestly, my programs tend to be simple enough that logic errors are reasonably rare That says more about the particular programs you write than about the language, frankly. Writing trivial bug-free programs is easy in any language. The trick is writing complex bug-free programs. > println debugging This is something you should only need to do if you have a wretched debugger of if you're working on a bug where the…

> Writing trivial bug-free programs is easy in any language. Not really. Writing programs which don't crash the first few times I run them in a dynamic language is surprisingly hard. Just having a compiler prevents having to get to that point - and then Rust ensures that I handle potential errors correctly and avoid segfaults. > This is something you should only need to do if you have a wretched debugger of if you're…

> Writing programs which don't crash the first few times I run them in a dynamic language is surprisingly hard.

Writing correct programs in JS is difficult, I agree. Writing correct trivial programs is easy, though.

> Or if I can't be arsed configuring gdb with breakpoints for everything from the command line. I can add a println!(), save my file, and watchman will recompile and run my program in a much more reasonable (to me) workflow. I assume that I can somehow integrate gdb into my editor, but that involves a pile of learning new things.

That's not a third alternative, that's just gdb being wretched, as it's always been.

Re: Python, as Reviewed by a C++ Programmer

#68

Post by user5994461 »

markbnj wrote: post #48
user5994461 wrote: post #43

Earlier quoted context omitted.

It's possible to pass a reference by reference.

In which case the argument is still a value, containing a pointer to a value, which is a pointer to the object.

In C semantics, that's about it.

Re: Python, as Reviewed by a C++ Programmer

#69

Post by mathw »

makecheck wrote: post #66
pzh wrote: post #27

For me the biggest downside of dynamically typed lanaguages like Python and Javascript is that a small error in passing a function's parameters can propagate very far in a complex system. E.g. if you mistakenly interchange two consecutive function parameters, you could spend several hours debugging the effect several modules down. This is an error that a C++ compiler would catch right away.

C++ is not always able to detect common parameter errors, especially for things like implicit conversions of numbers. Arguably Python’s option of keyword arguments make certain classes of parameter errors go away, too. Several years ago I remember someone who (perhaps unwisely) wrote a C++ function with many floating-point values as parameters and a single default "bool". At some point the function was extended to ha…

Those implicit conversion rules (largely inherited from C) are one of the bits of C++ that bit me the most when I was a primary C++ dev.

Re: Python, as Reviewed by a C++ Programmer

#70

Post by Pica_soO »

markbnj wrote: post #31
monochromatic wrote: post #18

Earlier quoted context omitted.

It may be implemented as call-by-reference, but the semantics are not the same as what one thinks of when he hears that phrase.

In what way are they different?

Im mostly experienced with the Lua Reference handling, so beware.

Usually there is one global hash-table, and a local hash table. Everything (every function, every object, every string is stored once, depending on the calling situation. So passing a reference to a object is passing the reference to that one global object, until you change it, or make a local copy of it. That sounds really strange and in a way is it. It also means, that your list of objects, will not contain duplicates. It means no useless work is done to copy data.

The model involved borrows basically from the concept of lazy loading and flat copys. Do work only when needed. Super difficult to explain to new users without CS background.

Post reply on HN