[glass-z13]

I had a similar experience when i was in highschool and learning python. I wrote a image->ascii image convertor using PIL as you did, one image would take a few hundred ms and it was fine, but as i played with it and added more features/learned more i tried to do it on video frames extracted with ffmpeg and it would take atleast 4x the duration of the video or even more to convert it in ascii video. Few months ago i coded it in go since i got back into programming and it was significantly faster(The overall code was also smaller but maybe that's just because i have a bit more experience now) even tho in both cases the implementations was the most naive one i could come up with, without any optimizations.

Edit: I went ahead and tested both, took me 30 mintues to set them with identic parameters on 3602 frames(roughly 1 minute video) Keep in mind that this is just a naive implementation with 2 nested loops itereting in a step of 12 over the pixels of the image, no fancy math or numpy used in the python version. Image for reference[0]. Also keep in mind that the step and length of the ascii charmap used affects performance but here i used a simple one "_^:-=fg#%@" so it's a bit easier for the python code, here are the results on my i7 9th gen laptop

1 Minute video 720p 60fps

GO - Execution time: 359647 ms, 5.9 minutes ("asciifying the frames") + 30~ seconds ffmpeg video conversion

Python 3.12.3 - Execution time: 0:16:25.002945, minus ~25-30 seconds ffmpeg

[0]: https://i.postimg.cc/CK30z1jt/frame-000039.png [1]: Video using a more detailed ascii charmap(" .,:;i1tfgLCG08@#") in the go version -> https://streamable.com/7h8jc3

[rbanffy]

A lot of these notes follow a similar pattern: we start with Python, get a working program, and then rewrite it in X with a huge performance gain.

That’s fair. We use the easy language to get a correct program, then we use the “hard” language to get a fast program, now that we know what a correct one looks like.

This is the key here. If you try to start with the lower level language, you might spend a much longer time getting to the correct program.

It’s much easier to optimise a program that’s working than to debug one that isn’t.

[pjmlp]

Or just use something that offers both from the start.

One day, Python will finally catch up with 1990's Smalltalk, SELF, Lisp, Dylan and Scheme.

[glass-z13]

What would you recommend that gives both worlds? You can learn most of the syntax of python/go to a usable level in about a day.

[pjmlp]

Go I agree, as for Python using it on and off since version 1.6, that would be a very very basic knowledge after one day.

Since you mention Go, placing dynamic and static on the same basket.

Common Lisp, Scheme, Raket, Clojure, Scala, Kotlin, F#, OCaml, Pharo, JavaScript/Typescript.

There are other candidates, only listing the ones with good out of the box REPL experience, JIT/AOT toolchains in the reference implementation, and not going crazy with their type systems for strong typing.

[tejinderss]

One of the strengths python has is its ecosystem. All the languages you listed don’t come close to python’s ecosystem except perhaps TypeScript/nodeJS (whose quality of ecosystem is questionable although improving in recent times).

[mrguyorama]

>This is the key here

No, this was very much NOT my point. The java version of my program was just as easy if not easier to write, precisely because I COULD write the naive version and trust that it would work out fine performance wise.

Hell, the java version didn't even require the extra library (Pillow/PIL) that python required!