←back to thread

517 points bkolobara | 9 comments | | HN request time: 1.335s | source | bottom
Show context
koakuma-chan ◴[] No.45041723[source]
I encourage every one to at least stop writing code in Python.
replies(5): >>45041794 #>>45041941 #>>45042073 #>>45043031 #>>45049992 #
1. lynndotpy ◴[] No.45043031[source]
Pythons power is in the REPL. It's good for when you want to do something ad-hoc that's too much for Bash or a graphing calculator. It has a large enough ecosystem that you can make a PoC for basically anything in a day.

It's really, really good for <1000 LoC day projects that you won't be maintaining. (And, if you're writing entirely in the REPL, you probably won't even be saving the code in the first place.)

replies(1): >>45043325 #
2. love2read ◴[] No.45043325[source]
the problem is that when you write enough <1kloc projects, a couple of them are useful enough to stay used in which case you are now maintaining python in prod.
replies(3): >>45043501 #>>45044951 #>>45049949 #
3. hnaccount_rng ◴[] No.45043501[source]
Yes but the alternative is "not having those projects at all" not "having them in a 'better' language"
replies(1): >>45044244 #
4. love2read ◴[] No.45044244{3}[source]
Of course not, the alternate is writing these projects in a more maintainable language
replies(1): >>45048545 #
5. lynndotpy ◴[] No.45044951[source]
I don't think that's inevitable, you can just not do that. I've been doing this for 15 years and it hasn't happened to me.
6. noisy_boy ◴[] No.45048545{4}[source]
Or writing them in whatever language gets you going quickly and rewrite the "successful" ones in a more safe language like Rust. Of course write test cases for those ones first and then use LLM help to migrate them, including tests, to a safer language. Problem happens when the velocity of changes is too much and/or there is no appetite for migration - those are a different category of problem.

The ideal scenario is what you are saying but most of the time it boils down to deadline vs familiarity/skill (of the developer and the team) trade-off.

7. sfn42 ◴[] No.45049949[source]
I feel like this is exaggerated. If you spent a couple days building a POC in python and found that it was useful then you can spend a couple days re-building it in a better language. You already know what you're making, probably have a decent plan for how to implement it, should be simple and straight forward to replicate it.
replies(1): >>45050168 #
8. IshKebab ◴[] No.45050168{3}[source]
It's not exaggerated. You can spend a couple of days rebuilding it in a better language (and I have done that!), but what actually happens is people want new features far more than they want you to rebuild it in a better language. So in most cases it gradually grows and gradually gets more unmanageable and it gradually becomes more difficult to justify a rewrite. There's never a solid point where you have to do a rewrite so it grows and grows until you really really wish that you had but it's also way way too late.

Happens all the time in my experience. It goes so far that big companies like Facebook, Google and Dropbox have all ended up writing their own Python/PHP runtimes or even entirely new languages like Hack and Google's new C++ thing rather than rewrite, because rewrites become impossible very quickly.

That's why - despite people saying language doesn't matter - it is very important to pick the right language from the start (if you can).

replies(1): >>45050309 #
9. sfn42 ◴[] No.45050309{4}[source]
That's fair. I wasn't really defending the idea of using python for prototyping. Personally I'd just start with C# for pretty much any project and try to do it right from the beginning.

I suppose most of my point was that in the case described one should jump to the rewrite sooner rather than later, to avoid the situation you describe.