gshulegaard

I don't know, it's a pretty leap for me to consider AI being hard to distinguish from human contributions.

AI is predictive at a token level. I think the usefulness and power of this has been nothing short of astonishing; but this token prediction is fundamentally limiting. The difference between human _driven_ vs AI generated code is usually in design. Overly verbose and leaky abstractions, too many small abstractions that don't provide clear value, broad sweeping refactors when smaller more surgical changes would have met the immediate goals, etc. are the hallmarks of AI generated code in my experience. I don't think those will go away until there is another generational leap beyond just token prediction.

That said, I used human "driven" instead of human "written" somewhat intentionally. I think AI in even its current state will become a revolutionary productivity boosting developer aid (it already is to some degree). Not dissimilar to a other development tools like debuggers and linters, but with much broader usefulness and impact. If a human uses AI in creating a PR, is that something to worry about? If a contribution can pass review and related process checks; does it matter how much or how little AI was used in it's creation?

Personally, my answer is no. But there is a vast difference between a human using AI and an AI generated contribution being able to pass as human. I think there will be increasing degrees of the former, but the latter is improbable to impossible without another generational leap in AI research/technology (at least IMO).

---

As a side note, over usage of AI to generate code _is_ a problem I am currently wrangling with. Contributors who are over relying on vibecoding are creating material overhead in code review and maintenance in my current role. It's making maintenance, which was already a long tail cost generally, an acute pain.

I remember first moving to Philly and getting a SEPTA Key and thinking, "This is dumb, it's literally just a MasterCard. Why can't I use my credit card like NY?" Then a few years later they rolled out support for other bank cards and I immediately took my SEPTA Key out of my wallet.

And yet I included a favorable international comparison as well.

I don't know what your frame of reference is, but BART is above average for US public transit payment systems.

I've lived in the San Francisco Bay Area CA, Portland OR, and Philadelphia PA over the last 10 years. All of those metros have comparable public transit payment systems with auto-loading special use cards and are at various stages of adopting support for tap to pay. Honestly, within the US I can only think of NYC as having a better payment system as they were first movers on tap-to-pay adoption and it's basically fully adopted.

Internationally I think there is a larger range of experiences. I don't travel enough to properly gauge it, but I was in Paris in the last year and I don't think public transit payment was better. Still had to acquire specialized fare cards and navigate different payment systems between RATP and RER. Honestly, SF Bay comes out slightly ahead of Paris if only because Clipper is unified between various transit options (BART, Bus, Ferry, CalTrain) IMO.

I also think asyncio missed the mark when it comes to it's API design. There are a lot of quirks and rough edges to it that, as someone who was using `gevent` heavily before, strike me as curious and even anti-productive.

I feel like this started/greatly accelerated when Guido stepped down as BDFL. Python at is on a path where the essence of what made it popular (readable, well designed, productive) is being crushed under the weight of it’s popularity. The language now feels bloated and needlessly complex in areas that were previously limited, but simple.

I recently chased down a bug where something was accidentally made a class variable because a type hint was left off it by accident and it clicked for me that Python is not the same language I loved at the start of my career.

The only point I put forth is that public fluoridation of water supplies doesn't infringe absolutely on an individual's right to informed consent to treatment since there is at least 1 method (moving) available that an individual can utilize to opt out. Others have pointed out that there may even be additional options available such as de-fluoridating yourself.

Did you have something on topic to contribute?

Or did you just want a soap box to voice your own opinions and I just happen to be collateral damage because you thought casting oblique aspersions about my qualifications would make you sound intelligent?

You could always move to a country which doesn't fluoridate their water supply.

But I am struggling to see how this has anything to do with a white paper highlighting and examining flaws in another white paper.

These days if you want a PostgreSQL based Data Warehouse both Citus and Timescale are extensions/PostgreSQL based databases I would consider before Redshift.

But even in the 9.4 days (~a decade ago) I was pushing Terabytes worth of analytics data daily through a manually managed Postgres cluster with a team of <=5 (so not that difficult). Since then there have been numerous improvements which make scaling beyond this level even easier (parallel query execution, better predicate push down by the query planner, and declarative partitioning to name a few). Throw something like Citus (extension) into the mix for easy access to clustering and (nearly) transparent table sharding and you can go quite far without reaching for specialized data storage solutions.

I just briefly reviewed the README docs, I believe the KlongPy is a custom language which transpiles to Python. The REPL block you are trying to interpret is the KlongPy REPL not a Python one.

Embedding KlongPy in a Python block would look more like this (also from the docs):

    from klongpy import KlongInterpreter
    import numpy as np

    data = np.array([1, 2, 3, 4, 5])
    klong = KlongInterpreter()
    # make the data NumPy array available to KlongPy code by passing it into the interpreter
    # we are creating a symbol in KlongPy called 'data' and assigning the external NumPy array value
    klong['data'] = data
    # define the average function in KlongPY
    klong('avg::{(+/x)%#x}')
    # call the average function with the external data and return the result.
    r = klong('avg(data)')
    print(r) # expected value: 3

Note the calls to "klong('<some-str-of-klong-syntax')".

Let me try again, from the first link I shared:

> The __slots__ declaration allows us to explicitly declare data members, causes Python to reserve space for them in memory, and prevents the creation of __dict__ and __weakref__ attributes. It also prevents the creation of any variables that aren't declared in __slots__.

Emphasis:

> prevents the creation of __dict__ and __weakref__ attributes. It also prevents the creation of any variables that aren't declared in __slots__.

In short, if you create a slotted object with __slots__ it sends you down a fairly orthogonal object lifecycle path which does not create or use __dict__ in anyway. This obviously has drawbacks/limitations like not being able to add new members to the object like a normal Python object.

From the second article:

> However, if you have __slots__, the descriptor is cached (which contains an offset to directly access the PyObjectwithout doing dictionary lookup). In PyMember_GetOne, it uses the descriptor offset to jump directly where the pointer to the object is stored in memory. This will improve cache coherency slightly, as the pointers to objects are stored in 8 byte chunks right next to each other (I’m using a 64-bit version of Python 3.7.1). However, it’s still a PyObject pointer, which means that it could be stored anywhere in memory. Files: ceval.c, object.c, descrobject.c

Which I think addresses your concern about parent dict access...but I could also be misunderstanding your point.