Hacker News Reader

Comment by gdulli | Hacker News Reader

> Thank you Guido, after learning Python, I never looked back

That matches my experience. All the pros and cons that in principle apply to any language, whether newer than Python or older, mean nothing to me in practice. Python is the one that feels right, the others feel like a chore. Since I started with Python 10 years ago, nothing has changed that.

There's ways I'll insist that Python is the best at [x], and ways I'll concede some other language is better at [y]. But it never amounts to anything close to a debate about what language I should use.

View on HN

There are a lot of times where Python is an inappropriate language choice. Anytime you have concurrency for instance. Definitely any time you need to distribute an application directly to an end user.

Beyond times when Python is clearly wrong, there are other issues, mainly around tooling and documentation. Languages have come a long way in the past 20 years.

"But it never amounts to anything close to a debate about what language I should use."

So if your task was to deliver let's say commercial grade FFT library ( substitute with any other long computationally extensive process ) for consumption by others you would write it in Python?

Given the success of the Python numerical computing stack (numpy, scipy, etc) it would probably be a good idea to do just that. Of course you’d profile the library and move some of the performance-critical bits to C / C++ / Rust. Thankfully Python has some well-trodden paths to that solution.

IMO a good an practical idea would be to write it in C/C++, expose as flat C API and then offer wrappers in whatever popular consumer languages there are (python included). The world of software does not end with Python

Yes, definitely a good approach as well. One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal.

On my team, we've been successful with this rough approach:

1. write a prototype in Python to explore the idea/ensure correctness

2. extract the core library and re-implement it in Rust

3. consume the core from Javascript via WASM and Python via pyo3 (Python/Rust bindings)

One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal.

Interestingly I've found something quite opposite for computational algorithms. The problem was that execution of Python under debugger was unbearably slow for me (I used VS Code for this case). So waiting until the code gets to the point I need was not fun. With C however it would get there almost instantly. Compile time for isolated computational function was nearly instant as well. Maybe debugging under VS code was the culprit but I did not feel that for this particular task Python was any more interactive than plain C.

Yes, I can see that being tiresome. Our projects are closer to simulations, so rather than focusing on a tight core at first, we have a number of factors that can be in play during each time step.

Rather than worry about figuring out structures for our simulation objects like we might need to do in a lower-level language, Python lets us just throw together some numpy arrays and dicts as needed, and really iterate quickly on the solution. If I was working on something with a tight computational core I would probably take the low-level first approach like you have. Horses for courses, and all that.

Clearly his statement is predicated on the kind of work he does. Dont be obtuse.

If this is "predicated by the type of work" then why make generic statement? Am I the one being obtuse?

Do most generic statements start with "This matches my experience"?

Kinda seems like you are, mate.

Not sure how they start but sure look generic when they end like this:

There's ways I'll insist that Python is the best at [x], and ways I'll concede some other language is better at [y]. But it never amounts to anything close to a debate about what language I should use

Anyways I should know better then discuss Python

Of course there are scenarios where you can't choose your favorite language, I'm not going to write an Xbox game client in Python.

To the extent I have a choice, I'll go out of my way to use Python and I'll be a little creative to fit it into certain uses cases where it's not a perfect fit, consciously accepting a reasonable penalty. But yeah, sometimes it won't fit at all.

The point is more that I'd go so far as to avoid taking a job or gravitating towards a project where the development would not be enjoyable based on the tools I'd have to use.

"The point is more that I'd go so far as to avoid taking a job or gravitating towards a project where the development would not be enjoyable based on the tools I'd have to use."

I can definitely understand this point of view. Well sorta. I was/am always goal oriented. I find satisfaction in creating a product used by other people. The actual process of implementation is 90% boring work and language for me is just a tool. I do not get too excited by languages.

Reply on news.ycombinator.com