leontrolski

How about just nudge json a couple more notches towards js? https://github.com/leontrolski/dnjs

I've always used snakeviz with the stdlib profiler https://jiffyclub.github.io/snakeviz/

In prod, the pyinstrument profiler has worked well for me https://pyinstrument.readthedocs.io/en/latest/guide.html#pro...

A great walkthrough mucking around with deep Python internals, love it!

A really nice collection of examples in their original and their refactored form - nice work. I'm similarly in two minds about the feature, it's cute, but is it worth it?

I think it's indicative that the nicest use is in AST processing. As someone that works on the occasional parser-y side project it looks pretty cool, but also, 97% of professional Python development is in data-science/application development. I suspect this is a case of the core language devs having a bias towards features that are useful to them as opposed to the community as a whole.

In python/javascript, I'm a big fan of using yield - https://leontrolski.github.io/recursing-with-yield.html

It just feels nice to me.

> What is asserted without evidence can be dismissed without evidence

I was hoping the code in the article would form (an admittedly small) piece of evidence. I'd just really like someone to show off a nice neat counter example, that demonstrates the true beauty of Python OO, and is "unrefactorable" to a data types + functions equivalent.

Pathlib is a great example, maybe a canonical one, of:

> Very occasionally, you come up with a core type that's used so often, it's nice to have the cutesy stuff.

Django's class based views I think could probably reasonably refactored into data types + functions. I'm not too au-fait with Django or its internals, but if someone could send me a "demonstration Django clone in 800 lines", I'd give it a go.

> What if client_a and client_b write to different APIs? ...

Then you use an if statement to split at that point. Again, given a specific toy example, I'm fairly certain a reasonable refactor is possible.

I think you could be on to something - that feels like an area with tightly coupled state and functionality. (Sorry for spamming this thread with comments like this), but would you mind emailing some example code, and we can test what happens?

I'm currently on a project with 100s of thousands of lines of code (admittedly not millions) - working in the bag-of-functions style - and I've yet to miss any OO features.

Surely it's possible to construct a smaller example? It's not like the millions of lines codebase isn't de-composable?

Hi, thanks for the comment. Given the number of _feelings_ in these threads, I'd really like to test my conjecture - if you'd be able to email me a (< 500 line, ideally not super-deep-library-code) bit of code (constructed or otherwise) that you think is "so innately OO friendly that the conjecture won't hold", I'll do a follow-up blog post. Thanks!

Hi, what I'd really like is to test my conjecture - would you (or anyone reading) be able to email me a (< 500 line, ideally not super-deep-library-code) bit of code (constructed or otherwise) that you think is "so innately OO friendly that the conjecture won't hold".

Given some examples, I'll do a follow-up blog post.

Hi, what I'd really like is to test my conjecture - would you (or anyone reading) be able to email me a (< 500 line, ideally not super-deep-library-code) bit of code (constructed or otherwise) that you think is "so innately OO friendly that the conjecture won't hold".

Given some examples, I'll do a follow-up blog post.

Hi, what I'd really like is to test my conjecture - would you (or anyone reading) be able to email me a (< 500 line, ideally not super-deep-library-code) bit of code (constructed or otherwise) that you think is "so innately OO friendly that the conjecture won't hold".

Given some examples, I'll do a follow-up blog post.

There's a lot of backwards and forwards in the comments. What I'd really like is to test my conjecture - could people post/email me a (< 500 line, ideally not deep library code) bit of code that they think is "so innately OO friendly that the conjecture won't hold".

Given some examples, I'll do a follow-up blog post.

Hi, I think you're correct in some domains - I probably should have spelt out that I'm by-and-large talking about application development, where if you have a "sufficiently complex combination of state and code" you probably have a problem rather than a candidate for wrapping in a class.

In game development even there seems to be a shift away from OO, to data + functions under the guise of "Data Orientated/Driven Development" - eg: https://www.youtube.com/watch?v=0_Byw9UMn9g

Edit: ignore me - this person seems to know more what they're talking about - https://news.ycombinator.com/item?id=25933781

(Author here) I used to think that, but I've since found myself working on a similar sized codebase where we use very little OO and none of these problems have manifested themselves. Avoiding large function signatures and passing higher order functions around takes a little discipline, but wrapping those things with a bit of OO doesn't make the root problems go away, it just encourages their proliferation. (To reiterate the article, I'm by and large talking application development as opposed to library development).

Here's a link to a recently published paper - "Using Spatiotemporal Modulation to Draw Tactile Patterns in Mid-Air" - https://link.springer.com/chapter/10.1007/978-3-319-93445-7_...

Mithril is the React Facebook would have written if its devs didn't have too much time on their hands - it's wonderfully simple.

I stole their API somewhat for my 33-line-React, if you have any interest in how stuff works under the hood - check it out! https://leontrolski.github.io/33-line-react.html

Reminded me of Geordie Jumpers https://www.youtube.com/watch?v=TOJzPXzcF_g

This doesn't solve your problem, but for anyone else reading who may not be aware - there is (at least one) library that does runtime checking with your type hints: https://typeguard.readthedocs.io/en/latest/userguide.html#us...

Hi, author here. I talked about this in more length here https://leontrolski.github.io/dom-syntax.html and to some extent here https://leontrolski.github.io/33-line-react-thoughts.html. There was also some discussion on the former here https://news.ycombinator.com/item?id=23142300

To clarify, the non-trivial thing I'm building is more for exploring the "unified templating language for backend and frontend" bit. I want to be able to use the same code to:

- render entire pages from a Python backend

- use as components in mithril https://mithril.js.org/

Author here, thanks for the feedback. This is v. much a work-in-progress, I'm in the process of trying to build something non-trivial with it. Just a couple of things to address in general from the comments so far:

- I'm aware of dhall, jsonnet and friends, I think they're cool, but I think the most important for me is this is just js - that means nothing new to learn + you can use it from front end code + free linters etc.

- I think the to-html bit is important, this is something I tangentially talked about in more detail here - https://leontrolski.github.io/dom-syntax.html. There was some discussion on hacker news about that one too, again, I think the important "feature" is that it's just js. Again, to me that's really important, so hiccup, jsx, etc don't cut it.

Original discussion - https://news.ycombinator.com/item?id=22776753

Further musings here - https://news.ycombinator.com/item?id=22791473

thanks!

Author here, nice to see this got some interest! As a very small benchmark (uh-oh!), in a console on the linked page, I tried to make/recreate 10,000 divs:

  const root = document.getElementById('noughts')
  m.render(root, {children: [...Array(10000)].map(_=>m('', {class: ['hi']}, 'hi'))})
  m.render(root, {children: [...Array(10000)].map(_=>m('', {class: ['bye']}, 'bye'))})

wrapped with:

  console.time('a');  ... console.timeEnd('a')

On my laptop (admittedly a fairly new macbook), I got (approx):

  130ms to make divs from scratch
  80ms to switch from 'hi'->'bye'
  50ms to re-render with no changes

I'd be super interested as to what comparable figures would be for React. There's a fair bit of interesting discussion below surrounding performance, but with no datapoints.

Using m or h as VDOM constructors are mithril/hyperscript-isms, I guess that's not obvious if you not worked with those or similar libraries, sorry!

Author here - I did put a warning in guys :-)

  Lots of the code looks pretty code-golfy - I promise I don't do stuff like this at work, neither should you

Happy to s/g/grid/ - writing the whole exercise felt a bit golfy TBH.

Mithril's approach (as robertakarobin refers to) is that diffing VDOMs is cheap (where as updating the DOM itself is expensive), the "library" in this post takes the same approach.

It's interesting, there's a lot of chat about performance with these frameworks, yet I'm not sure how much is relevant to the real world. When I do eg a

  document.querySelectorAll('*')

on airbnb map view (I guess a pretty good example of a mid complexity SPA), there are 3407 DOM elements - doing a diff on the VDOM elements of these should quick.

If I were doing something like a clock on a page (or an animation for example), I'd probably just do it out-of-band of my framework. These kind of things tend to be few and far between anyways.