Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please do not use Python for tooling

borud.no

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Please do not use Python for tooling

#61

Post by PaulHoule »

bborud wrote: post #33
icedchai wrote: post #6

Earlier quoted context omitted.

It appears ESP-IDF can already be installed with a virtualenv: https://github.com/espressif/esp-idf/blob/master/tools/idf_t... Perhaps your problems are due to external dependencies (outside of Python)?

So how do you usually install ESP-IDF to ensure smooth sailing? I usually follow a (somewhat more terse) version of the instructions that the Espressif team have on their site. I put that in my blog a while back: https://borud.no/dev/2022/esp-idf-setup/ . How should I modify this procedure to help avoid breakages in the future? UPDATE: interestingly, I decided to check out and re-build an ESP-IDF project I haven't bu…

It's a general story that companies like Espressif couldn't care less about developer experience. Part of why Arduino is a success story is that their dev tools, limited as they are, are easy to get going. Microchip publishes free tools to work with Atmel parts and they have a better feature set but are a hassle to get up and running.

I think there's an expectation that top management decides which board gets used and developers just cope with whatever tools come with the board.

Re: Please do not use Python for tooling

#62

Post by actuallyalys »

schmuelio wrote: post #38
cassianoleal wrote: post #29

Earlier quoted context omitted.

> even though you're not naming your types, the types are still static. Python is strongly typed, but definitely not statically. >>> a = "foo" >>> type(a) >>> a = 3 >>> type(a) The variable `a` has different types at different parts of the program. That's not static.

Your example doesn't show static typing (declaration/re-declaration is the same syntax as assignment in Python), but I think OP was thinking of Strong/Weak? Python is Dynamically typed because: >>> a = "foo" >>> a / 3 Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for /: 'str' and 'int' This isn't a compile error. Edit: Also for the re-declaration thing, you can see thi…

> As for strong/weak, I think it's a bit more fluid because I can't seem to find a set definition that everyone agrees on.

Yes, I've been looking into this lately, and the terms are messy. People tend to use strong to mean "strict in ways I like" and weak to mean "permissive in ways I don't like."

Division is a good example of this ambiguity. It always results in a float, so if you divide two integers, even ones that are evenly divisible, you get a float, so that's kind of a conversion, right? But on the other hand, I don't think a function that was defined as taking two integers and returning a float would be considered an implicit conversion, even if it were overloaded to also accept various combinations of float and integer.

Gary Bernhardt has a good discussion: https://www.destroyallsoftware.com/compendium/types?share_ke...

Re: Please do not use Python for tooling

#63

Post by bb88 »

bborud wrote: post #55
pwinnski wrote: post #20

What a bizarre take. It seems to boil down to: "Tooling should be compiled so it doesn't involve dependencies." If we lived in a world in which most tooling (currently written as python scripts) were actually compiled, we'd be seeing better-reasoned essays begging us to write tooling as easily-editable scripts, rather than closed-off executables. I have had scripts that I needed to edit just slightly almost every tim…

The place where I run into Python is mostly while doing embedded development as the tooling for platforms like Zephyr and ESP-IDF. And they are notoriously brittle. Which has a high cost in terms of lost productivity. So we aren't talking about scripts I maintain, but scripts that are part of the tooling for platforms I use. The point is that it doesn't matter what a theoretical developer could do to lower the "cost…

As a professional python dev, I understand your pain. It took me a while to sort out the pyenv/virtualenv/conda stuff myself.

Could python be better in this regard? Yes, absolutely.

I wrote a comment a while back to help out someone else with python packaging. Once you get your mind around it, it's not too bad frankly.

https://news.ycombinator.com/item?id=32122191

Re: Please do not use Python for tooling

#64

Post by jrockway »

PurpleRamen wrote: post #51
falcolas wrote: post #42

Earlier quoted context omitted.

Yes. The actual image is a tar file, and container runtimes include commands for both exporting and importing. Exceptionally portable. More portable than JAR files and Go binaries, at least.

Wait, which container are we talking about? Docker? AppImage? Kubernetes? What about the runtime?

OCI Images. You can run them in Docker, Podman, Kubernetes, systemd-nspawn, etc.

Nobody is going to use your tool if they have to fetch it from a container registry and have to run it isolated from their filesystem and network, though. OCI images are fine if you have a pet app and you have to ship it to a production server. Not that convenient for interactive tools, though. Consider:

  $ docker run -v /tmp/foobar:/tmp/foobar debian:stable ls /tmp/foobar
  a.txt
You really just want to type "ls /tmp/foobar".

Re: Please do not use Python for tooling

#65

Post by pwinnski »

bborud wrote: post #59
wnolens wrote: post #57

Earlier quoted context omitted.

If your point was strong, people would have listened. But it wasn't, so you had to make a meta point which came off as condescending. Instead of reading that sentence above and having the gut reaction of not feeling understood, try and be open to the possibility that you didn't make a very strong argument or perhaps didn't communicate it very well.

I'm certainly open to not having communicated my point well. But it was never going to be the kind of point that would be easy to get across since people want to see any criticism of language choice as a language shitpost.

You took a very specific complaint about toolkits in the embedded systems space and generalized it to an expanded argument about any and all tooling, much of which have requirements that run directly counter to yours.

So yes, I don't think you communicated your point well. An essay about the brittleness of current embedded systems toolkits which suggested that much of the brittleness could be due to the use of Python in those toolkits, that might have been better-received--but wouldn't have gotten the attention a splashy "Please do not use Python for tooling" did.

Perhaps if you'd spent less time predicting what your essay would provoke, and more time thinking about why your essay might provoke that, you'd have written a better essay.

Re: Please do not use Python for tooling

#66

Post by knighthack »

I find it hypocritical that the author writes this: "...If we remove all the pretense, it usually comes down to people defending their personal choices. We have a tendency to try to justify and protect our investment in whatever languages and tools we know and use. This makes sense. But it isn’t always rational behavior."

Yet his entire article is a justification for his defence of his code preferences.

Moreover his article is vague and has no technical depth, despite his controversial statements/advocacy. E.g. not a single line in the article refers to virtual environments of any kind, which is basic to how Python works and dependency management as part of the (arguably Pythonic) tooling process.

Re: Please do not use Python for tooling

#67

Post by bborud »

pwinnski wrote: post #65
bborud wrote: post #59

Earlier quoted context omitted.

I'm certainly open to not having communicated my point well. But it was never going to be the kind of point that would be easy to get across since people want to see any criticism of language choice as a language shitpost.

You took a very specific complaint about toolkits in the embedded systems space and generalized it to an expanded argument about any and all tooling, much of which have requirements that run directly counter to yours. So yes, I don't think you communicated your point well. An essay about the brittleness of current embedded systems toolkits which suggested that much of the brittleness could be due to the use of Python…

Actually, I haven't seen anyone make a compelling argument that counters any of the things I point out. I've mostly seen people either suggest workarounds or being upset that someone would suggest Python isn't the best thing since sliced bread.

You keep harping on about the last point. Which makes me think that you really felt that it hit home with you.

Re: Please do not use Python for tooling

#68

Post by falcolas »

jrockway wrote: post #64
PurpleRamen wrote: post #51

Earlier quoted context omitted.

Wait, which container are we talking about? Docker? AppImage? Kubernetes? What about the runtime?

OCI Images. You can run them in Docker, Podman, Kubernetes, systemd-nspawn, etc. Nobody is going to use your tool if they have to fetch it from a container registry and have to run it isolated from their filesystem and network, though. OCI images are fine if you have a pet app and you have to ship it to a production server. Not that convenient for interactive tools, though. Consider: $ docker run -v /tmp/foobar:/tmp/…

That's something that aliases excel at.

Re: Please do not use Python for tooling

#69

Post by falcolas »

invalidname wrote: post #52
falcolas wrote: post #40

Earlier quoted context omitted.

Modern java relies on Lombak (code generation) and DI frameworks (seriously, fuck DI) to avoid boilerplate. The base language has just as much of it as it always has. And, as I just found out this morning, DI frameworks blow up at runtime despite successful compilation and runs through unit testing.

Nope. Records, lambdas, var, multiline strings, switch pattern matching, improved instanceof, etc. I suggest reading up on Java 18 and some of the upcoming features.

Those are improvements, no doubt, but they don't even begin to touch the quantity of boilerplate removed by Lombak.

Re: Please do not use Python for tooling

#70

Post by thiht »

I have to admit when I need to install a tool, I always prioritize the Go, Rust or ANSI C alternative if it exists. It’s just easier to deal with and usually more performant (Python utilities always feel sluggish for 1 second before starting)
Post reply on HN