Hacker News Reader

Comment by ausjke | Hacker News Reader

I tried to learn those languages, my IQ level can handle java/golang/python/c just fine, but c++ and rust is beyond my comfort zone for sure, for c++, getting familiar with it is OK, but getting good at it is hard, really hard, mastering it is impossible for me. similar can be said to rust as far as I can tell.

even python has some "tricks", try "x=256; y=256; x is y" and "x=257, y=257, x is y" under python, or 'x=[], y=[], x is y; x=y=[], x is y' you will know what I mean, you actually need know some internal designs to use python properly.

At the moment I feel golang has the right trade off for programmers, be it beginners or senior developers.

View on HN

I love high-level languages and think they've had a great democratizing effect that lets people across a wide array of backgrounds be reasonably productive without a ton of background knowledge. But, the underlying computer isn't magic. In many ways, it's pretty dumb. I suspect if you spent a bit of time looking at a system architecture, a lot of things would click into place.

Early in studies, I couldn't really wrap my head around pointers. I mean, I knew what they were and how I needed to work with them, but they just seemed like a weird abstraction. A short intro to assembly and later on, a computer architecture class, cleared that all up.

Everyone learns differently, so my experience likely isn't applicable. But, for me, no longer treating the CPU as a black box helped me get a much better mental model of lower-level languages. And I think I'm a better high-level developer for it.

not the case for me, my background is in EE and cpu architecture, and I know hardware better than software actually...

Relating to the "Python Tricks" you mention, remember that "is" means "these two pointers (x & y) point to the same place".

You should never be to surprised when you create a bunch of new values and a language like python isn't "smart" enough to say "these are all the same value, so I'll create one of those and have x, y, etc all point to the same thing."

I think you just need to give yourself some time. C++ is a large enough language now that "mastering" it will likely take several years of daily/professional use. I used to be decent at C++ (in the early/mid 00s), but given that I haven't touched it since then, I'm completely lost as to current best practice. If I wanted to, I'd have to spend many months catching up to all the changes in the language since I last used it.

Rust has a much smaller surface area, but does have some unique things to understand like the borrowing and lifetimes. The good thing is that as the borrow and lifetime checkers in the compiler get smarter, the less you have to know about those things while writing plain-jane code.

You mention downthread that you have an EE/comp-arch background. I do as well, and have found that useful on occasion when working on embedded systems, but perhaps not a huge asset when dealing with language esoterica. Sure, perhaps understanding pointers and memory access is easier when you understand how memory actually works, but it'll only get you so far.

I don't think that's a great example for Python; that's just knowing what "is" is for. The fact that it works the same as == for small integers in CPython is an optimisation showing through, but only in a place where it doesn't really matter.

You still need to have a grasp on the difference between reference equality and value equality without getting into anything anyone would call tricks or implementation details (eg, after `x = []; y = []; x.append(1)`, how many elements does y have?).

x=x.append(1) and guess what, now x is "None", yes it makes perfect sense for those who coded python for a while, but it's a disaster for newcomers.

too many similar demos

by the way I actually like python and use it often, just saying it can surprise you when you start, not intuitive per se until you become good at it.

Sure, x.append doesn't return a value. So x=x.append is None. You learn that one pretty quick.

Perhaps use x = x + [1] instead?

But yeah, surprises like this (unexpected return values) are actually a pretty strong case for using a language like Rust or C++ where the compiler will tell you this before you run the program.

x=1; id(x); x+=1; id(x); # different id, means x points to new location

x=[1,2],id(x), x+=[3], id(x) ; # same id, means x stay at the original location

there should be a blog page to list those surprises for beginners :)

>> yes it makes perfect sense for those who coded python for a while, but it's a disaster for newcomers.

It’s a disaster for newcomers to programming in general. I am pretty sure a seasoned developer in any other language would understand why that returns None, too.

>I don't think that's a great example for Python; that's just knowing what "is" is for. The fact that it works the same as == for small integers in CPython is an optimisation showing through, but only in a place where it doesn't really matter.

Python should have prevented checking primitives with is though -- only let object pointers...

I believe they're still object pointers in CPython, they're just ordinary singletons; in other implementations, they aren't even singletons. Python's object model doesn't have primitives. Adding special rules around them would significantly complicate the language as well as limit the implementors' ability to fiddle with the ranges of pre-allocated instances, for minimal benefit.

>in other implementations, they aren't even singletons

That would have been less surprising (since for < 256 the singleton-ness means all same valued instances have the same "address" (id), so behave in equality check as if they were plain numbers).

Integers are object pointers, too. CPython just so happens to preallocate a range of small integers[0].

[0]: https://github.com/python/cpython/blob/master/Objects/longob...

>even python has some "tricks", try "x=256; y=256; x is y" and "x=257, y=257, x is y" under python, or 'x=[], y=[], x is y; x=y=[], x is y' you will know what I mean, you actually need know some internal designs to use python properly.

Or don't compare numbers with "is", since you're not supposed to? Then you can remain oblivious to the underlying mechanics that break "is" comparison for larger integers...

Yep, this is totally implementation-defined behavior, so it's actually kind of harmful to think that you should "know some internal designs" here.

> I feel golang has the right trade off for programmers

Have you tried Clojure?

Reply on news.ycombinator.com