Live data from Hacker News

Python, as Reviewed by a C++ Programmer

sgh1.net

21–30 of 79 posts

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

#21
post #9
post #5

Earlier quoted context omitted.

One thing where Rust is rather lacking is the missionarism of some people in the community.

The Rust Evangelism Strike Force is a huge turnoff to the language. It's gotten to the point where we can't have reasoned discussions about C++ or C, let alone about their merits, without a newly enlightened user coming in and trying to direct the conversation to Rust. It's really okay to have a future where C++ and Rust are both popular, widely used languages. I'm happy to acknowledge the merits of Rust as a languag…

Their entire selling point is that c is dangerous and rust is safe. It sort of creates an adversarial relationship.

That said, while it might be annoying to serious c programmers, they aren't really the intended audience. It's new programmers that matter. Or people who bounce between languages anyway.

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

#22
post #8
post #2

Interesting perspective on some of python's features, but I hate to see this "python is neither call by value nor call by reference" silliness perpetuated with a link to the original silly blog post. I'm surprised a C++ programmer was caught by that obviously incorrect assertion.

Claims that Python/C#/Java etc., are call by value where the 'value' is the value of the pointer does not help. It only muddies things. There really ought to be different name for such call semantics and there is. Its called call by object. In C++ lingo call by const pointer comes closest: one cannot change what the pointer points to. However the pointed object may not be a const

Scott's book "Programming Language Pragmatics" calls it "call by sharing" IIRC. BTW, that book describes like 6 or 7 modes of parameter passing. Languages like Ada have some quite original modes.

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

#23
post #5

Earlier quoted context omitted.

One thing where Rust is rather lacking is the missionarism of some people in the community.

So true. I want rust to take off, as even bounds checking at compile time would save me a lot of trouble. I don't know if I'll ever be able to deal with the community, though. On the other hand, I've never seen people get as passionate about c++ as I have python and rust, so maybe that says something about the benefits, even if its just as beginners see them.

I find that within the Rust community people are amazing, it's just at the boundaries that I've found problems.

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

#25

One thing that is a bless and a curse is the use of indentation for code blocks. http://www.secnetix.de/olli/Python/block_indentation.hawk

I read that, and it absolutely does not try to make the point that indentation is a curse. Maybe it is to some (not to me!), but you would need to cite something else. This is just an explanation of how it works.

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

#26
post #7

Earlier quoted context omitted.

I think you see people passionate because they've dealt with all the pain around C++. That said I don't agree with the GP. As much as I like Rust there's still a ton of areas that keep Rust from being used today. Library selection, even though it's hard to hire for C++, it's easier than Rust and a few other things. That said for all my personal/greenfield stuff I've been using Rust and really happy with it.

There's a lot of people passionate about it because it's the first low-level language that's reasonably approachable to people who mostly code in Python/Ruby/etc - you rarely ever have to pull out a debugger, for example.

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.

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

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

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

#28
post #13
post #8

Earlier quoted context omitted.

Claims that Python/C#/Java etc., are call by value where the 'value' is the value of the pointer does not help. It only muddies things. There really ought to be different name for such call semantics and there is. Its called call by object. In C++ lingo call by const pointer comes closest: one cannot change what the pointer points to. However the pointed object may not be a const

No, no, no there is no "call by object." It is precisely this mistaken idea which muddies the waters, as you put it. Virtually all modern processors are stack-based architectures. All arguments to functions are passed on the stack or in registers. The only thing that can be placed onto the stack or into a register are numbers. Those numbers can represent either an actual value or an address in memory. The former is c…

In Java, this code will print the string representation of Lassie:

  Dog toby = new Dog("Toby");
  
  public static void replaceDogWithToby ( Dog d )
  {
    d = toby;
  }
  
  public static void main ( String[] args )
  {
    Dog d = new Dog("Lassie");
    replaceDogWithToby(d);
    System.out.println(d);
  }
In Pascal, this will print Toby:

  var
    toby:tDog;
  
  procedure replaceDogWithToby ( var d:tDog );
  begin
    d := toby;
  end;

  var
    lassie:tDog;
  begin
    {code to initialize toby and lassie here}
    d := lassie;
    replaceDogWithToby(d);
    writeln(getDogName(d));
  end.
The first is call by object (or call by sharing, in my book). The second is call by reference. The behavior is totally different.

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

#29
post #8
post #2

Interesting perspective on some of python's features, but I hate to see this "python is neither call by value nor call by reference" silliness perpetuated with a link to the original silly blog post. I'm surprised a C++ programmer was caught by that obviously incorrect assertion.

Claims that Python/C#/Java etc., are call by value where the 'value' is the value of the pointer does not help. It only muddies things. There really ought to be different name for such call semantics and there is. Its called call by object. In C++ lingo call by const pointer comes closest: one cannot change what the pointer points to. However the pointed object may not be a const

Python is "pass reference by value", in C++ semantics.

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

#30
post #13
post #8

Earlier quoted context omitted.

Claims that Python/C#/Java etc., are call by value where the 'value' is the value of the pointer does not help. It only muddies things. There really ought to be different name for such call semantics and there is. Its called call by object. In C++ lingo call by const pointer comes closest: one cannot change what the pointer points to. However the pointed object may not be a const

No, no, no there is no "call by object." It is precisely this mistaken idea which muddies the waters, as you put it. Virtually all modern processors are stack-based architectures. All arguments to functions are passed on the stack or in registers. The only thing that can be placed onto the stack or into a register are numbers. Those numbers can represent either an actual value or an address in memory. The former is c…

"Variables in Python are object references. When you call a Python function the arguments are copies of the references to the original object." -- I personally wouldn't worry about what to call it(though call by reference would be my pick too), in the end I just visualize it as being similar to how assignment works in Python.
Post reply on HN