4 ms·

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 f

by ausjke 7y ago

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.

kbp 7y ago
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?).
- ausjke 7y ago
  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.
  - gridspy 7y ago
    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.
    - ausjke 7y ago
      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 :)
  - heavenlyblue 7y ago
    >> 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.
- coldtea 7y ago
  >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...
  - kbp 7y ago
    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.
    - coldtea 7y ago
      >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).
  - hope-striker 7y ago
    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/longobject.c#L43 https://github.com/python/cpython/blob/master/Objects/longob...
nirvdrum 7y ago
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.
- ausjke 7y ago
  not the case for me, my background is in EE and cpu architecture, and I know hardware better than software actually...
  - gridspy 7y ago
    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."
    - deleted 7y ago
      [deleted]
coldtea 7y ago
>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...
- hope-striker 7y ago
  Yep, this is totally implementation-defined behavior, so it's actually kind of harmful to think that you should "know some internal designs" here.
kelnos 7y ago
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.
iLemming 7y ago
> I feel golang has the right trade off for programmers Have you tried Clojure?

by ausjke 7y ago

kbp 7y ago

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?).

ausjke 7y ago
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.
- gridspy 7y ago
  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.
  - ausjke 7y ago
    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 :)
- heavenlyblue 7y ago
  >> 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.
coldtea 7y ago
>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...
- kbp 7y ago
  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.
  - coldtea 7y ago
    >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).
- hope-striker 7y ago
  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/longobject.c#L43 https://github.com/python/cpython/blob/master/Objects/longob...

nirvdrum 7y ago

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.

ausjke 7y ago
not the case for me, my background is in EE and cpu architecture, and I know hardware better than software actually...
- gridspy 7y ago
  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."
  - deleted 7y ago
    [deleted]

coldtea 7y ago

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

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

kelnos 7y ago

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.

iLemming 7y ago

> I feel golang has the right trade off for programmers Have you tried Clojure?