Answers to a reader's questions about bits of tech | Hacker News Reader

Answers to a reader's questions about bits of tech

rachelbythebay.com

24 pointszdw9 comments

This is probably already well known, but if you're using Python and want to exploit SIMD instructions, one of the simpler ways is to reformulate stuff as matrix operations and let numpy handle them. The speed-up can be staggering.

TensorFlow also can use these SIMD instructions, just that the standard installation (the one you get with pip) does not [1]. This is why you might see this message when you run it on your machine "Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2".

[1] https://stackoverflow.com/questions/47068709/your-cpu-suppor...

The questioner asserts that Google requires SWEs to know python.

Although it can quite helpful, Google doesn't require that. Google does assume that you can figure things out, and that if you need to figure something out in Python, you will, but that isn't the same as requiring you to know python.

>I don't use Python if I can help it. There's a time and a place for Python just like there's a time and a place for shell scripts, but you quickly exceed the limits of sanity for both.

Some of the stuff that makes it easy to start scripting such as as lack of strong typing and using whitespace for scoping, become big problems when the project gets large, is long lived, or has a lot of people contributing to it.

Technically, Python does have strong typing: it's just dynamic, not statically typed. I can see how static typing helps avoid errors on a larger project.

It's hard for me to understand how using indentation for scoping would be a "big problem" on a large/long-lived project. Whitespace vs brackets seems purely an aesthetic choice to me. Don't most people indent their bracketed languages anyway?

>It's hard for me to understand how using indentation for scoping would be a "big problem" on a large/long-lived project.

Editors screw up whitespace all the time. Many times when moving a block of code using cut and paste, it is easy to screw up the indenting. With brackets/braces, it is a simple thing to just reformat. With python, you have to make sure that you did not screw up the semantics (is this statement part of the if or not). A long-lived project likely undergoes a decent amount of refactoring and code reorganization. Having to worry about messing up the semantics of your code every time you move a block of code is not that great.

Sounds like a tooling problem, not a language problem.

If editors screw up whitespace "all the time" it's only because whitespace is non-significant in many programming languages. Maybe we need better Python-focused editors that will automatically strip out irrelevant curly braces.

There is the mypy static type checker that works very well with Python. It works with the typing module that allows unions of types, and other methods. Using the --disallow-untyped-defs command line argument provides more checking. A function prototype could look like the following where the str and int are the types.

def strlen(check_str:str) -> int:

Unfortunately, one of those 'time and place' uses for python is white boarding interviews.

Sure - you can use whatever you want, but python is probably an advantage for more easily solving those class of problems on a whiteboard.

Python on a whiteboard is functionally indistinguishable from pseudocode.

Reply on news.ycombinator.com