Hacker News Reader

Arguably no one’s goal is to glue pieces of C together. That’s too abstract. Their goal is to do something like write a performant web server, maybe easily and quickly. Python’s approach is one way to do that, but there are other ways that might be better. Having to write code in two languages to solve a problem, one of which that is difficult to write and has lots of footguns, has some clear downsides.

Ritchie and Thompson might disagree with you.

Gluing pieces of C together was literally the reason I started using Python back in the 1990s.

My other two main options were Tcl and Perl. Tcl was excellent at gluing, but worse at scaling, with no namespaces (then) and OO only as third-party add-ons.

Perl extensions were not so easy (better with Perl 5), and much as I enjoyed the language, handling complex data structures, was not for the faint-hearted.

Gluing pieces of C together is why we have NumPy, PyQt, pywin32, wxPython, and tens of thousands of other packages that work with C/C++/Fortran libraries.

Basically nobody's goal is to "write a performant web server" either, it's to serve data to customers quickly and efficiently. And that highlights why it may not be worth optimizing the Python web ecosystem. There are so many newer alternatives for that overall goal - Firebase, Amazon Lambda, ditching webapps for native mobile, etc - that it may not make sense to try to optimize an application server unless you work for Google or Amazon, because very few people setup a standalone webserver on bare-metal hardware anymore, and those that do probably aren't going to try a new and untested alternative.

Nobody's goal is to serve data to customers quickly and efficiently either. It's more like, get this startup acquired and buy a ranch in New Zealand.

Haha you might like this old comment I made where I gradually go up the abstraction ladder about what you "really care" about (in the unlikely event you see this comment):

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

Root of the subthread: https://news.ycombinator.com/item?id=9775799

> for the use case that Python is intended for

Where is this single use case intent articulated, by whom, and what year was it? What is the use case?

Today, it seems that Python is pitched for almost everything, short of ethernet drivers.

From https://www.python.org/about/ (mouse over the "About" menu) :

'Python is a programming language that lets you work more quickly and integrate your systems more effectively.'

This is one of the biggest misunderstandings in computing for the last decade, I feel.

That's not a specific use case. That's like brochure pitch.

>Today, it seems that Python is pitched for almost everything, short of ethernet drivers.

I think the "Python is pitched for almost everything" in that sentence shows a misinterpretation of gp's phrasing of "use case".

The "use case" isn't about different subject matter domains as if it was a claim about using Python as a universal language for writing database kernels or AAA games.

Instead, the "use case" is about the 2-level 2-language architecture of (1) a high-level scripting language and (2) extension modules that can be written in low-level C and imported into the interpreter. That's the "glue language" + "C Language" to combine the strengths of each language approach. (In contrast, Julia took approach of designing a language that was "fast enough" to avoid the "2 languages issue".)

>Where is this single use case intent articulated, by whom, and what year was it? What is the use case?

The Python "ergonomics use case" (not "domains use case") was originated by Python's inventor Guido van Rossum from the beginning in 1991. A clone of the 1991 Python source code has Guido's commentary for importing C modules:

https://github.com/smontanaro/python-0.9.1

Modern frameworks and libraries like TensorFlow and Pytorch continue the same use case of "high-level script glue code calling low-level C code" that was there in 1991. You can't write a tight cpu loop in pure Python code to paint a 60fps video game. That's not Python's intended use case. That philosophy is why a library like Tensorflow only has Python code for users to "glue" together the neural network graph which then calls out to the C++ code for the expensive cpu loops of backpropagation, gradient descent, etc.

I liked it back when we used "use case" for that concept with the actor executing a concrete interaction with a system to achieve a specific goal, and "architecture" for how the pieces fit together, without mixing or equating the two. :)

> I was briefly tempted to write an API-compatible reimplementation of Django with the core in C++ when I left Google, but by then Django (and server-side web programming) was already falling out of favor, and if you're just shipping JSON to a SPA you can use cjson with any number of fast wsgi or asgi gateways.

I like Django. I need to process data on the server side and like to write that in python because it is more convenient than C. I also built my GUI in Django without knowing JavaScript. "just shipping JSON" seems like a different use case.

I have a piece of hardware (a laboratory hardware switch) that exposes a REST API for CRUD. I wanted to build a GUI that formats and summarizes information and offers convenient control. The data is small enough so that python can process it without becoming the bottleneck. I used Django ORM to model the data and django forms with htmx for the GUI. Authentication was easily added to Django.

The ORM part was a bit painful as Django forms expect a queryset and a queryset is not be the result of a raw sql query. There is a way to feed list of tuples into a choices argument but I decided against that , and instead dumbed down my query so I was able to write it as an django ORM language query.

This is the problem with SQL queries and Django Forms I am talking about

https://stackoverflow.com/questions/17330158/django-how-to-u...

I've been playing around with HTMX with Django, and it seems simple enough for server side rendering. It works well with the Django templating system.

I feel like as an industry we should step back and take a serious look at front end frameworks from first principles. One aspect that's clear to me, is that we should make modifications to HTML to support HTMX like transactions.