mwhite

28 dni temudiscuss

[dead]

w zeszłym miesiącudiscuss

I know this is a code about me behaving as if I went to a world-class university for undergrad. I could have gotten into almost any world class university, so that's what I do.

mwhite

2 miesiące temudiscuss

[dead]

mwhite

2 miesiące temudiscuss

Ok, I am on an injection. I had about four or five minor hallucinations prior to taking anti-psychotics. I was pretty sure that I was getting a code in pages on the Internet, i.e., it clearly seemed to be statistically significant, which seemed to happen soon after I switched to Arch Linux in 2018. Also, I have both put out some writing on AI takeover eschatology from a young age and called myself an ersatz cryptographer/cryptanalyst when I thought ersatz had a different meaning than it does.

mwhite

2 miesiące temudiscuss

Hello HN, I consider this my life's work. Note the following:

  * The editor can be integrated with an LLM.
  
  * DOM-manipulating and MVC apps can be automatically rewritten as functional-reactive

I am gearing up to begin implementing this, apart from the already finished React JSON API and mostly finished SQLAlchemy GBAC, under a restrictive non-commercial human-only otherwise free license. Let me know if you'd like to contribute.

mwhite

2 miesiące temudiscuss

I think it may be something to do with the ISS or Norge. I hope I didn't get myself into something I can't handle.

mwhite

2 miesiące temudiscuss

[flagged]

mwhite

6 miesięcy temudiscuss

Thanks, while not mentioning it in the original post, I was actually diagnosed with schizophrenia in 2015 and receive treatment for it, but I was actually told I would be told I had schizophrenia because the real condition was so rare or had no name. My mom has delusional disorder, which is non-schizotypal and supposed to be caused by a single recessive mutation.

The 15 or 16 companies other than GetchaBooks and MyGEDCOMs on the list, which contain some of the biggest tech companies in the world, and 11 or so technologies were actually founded by me in a few days, weeks or months at the age of 5 or 6 after creating the initial implementation of the Python programming language as a halo effect from my paper "A Self-Hosting Point-and-Click Editor for Any Functionally-Specified GUI-DB Application" and a few other pieces of writing, a completed version of which I emailed to a number of prominent individuals at the time and (this may be a secret) posted on LKML as a lark. The paper contains a high percentage of "magic". I'll PM you a link to a draft of the current version.

Edit: I think I am getting filtered so not sure if I want to email you at the address on your profile. Here is the draft, which is also linked from my CV on michaelawhite.net https://www.overleaf.com/read/ymsbmtwnydft#efbba5

mwhite

6 miesięcy temudiscuss

No, but I have read a lot of apparently AI-generated material without successfully identifying it as such to anyone else I know.

Maybe we are seeing different versions of the page? I hear a very powerful entity may rewrite any page on the fly.

Not sure if advisable to say. A network infrastructure operator with a human-level AI can potentially rewrite any content on the Internet in a granular fashion. Was hoping to get on the inside.

mwhite

6 miesięcy temudiscuss

It's the truth, most likely, or potentially I don't understand something about childhood events.

mwhite

6 lat temudiscuss

"spirit of the times" /stopped reading

mwhite

6 lat temudiscuss

One-level deep inheritance can be great for abstracting common functionality, and multi-level inheritance sometimes makes sense in very large applications. What you want to watch out for is multi-level inheritance with an inheritance hierarchy that parallels some hierarchy that is merely incidental to the code's functionality, like the page navigation hierarchy.

I would say that having a multi-level inheritance hierarchy with greater than "constant" number of children per parent in one package is a code smell.

mwhite

6 lat temudiscuss

Isn't structs which embed structs composition, not inheritance?

mwhite

9 lat temudiscuss

There are few things that truly exemplify quality; I count the simple but not minimalist visual aesthetic of GNOME 2 as one of them.

It is unfortunate that they changed the aesthetic so much with GNOME 3, particularly making it more minimalist. I prefer the prevailing toolbar aesthetic in GNOME 2 of icons with text, and the less integrated desktop management scheme at a high level in comparison respect to the Shell. Even if the old toolbar style wasted space and the new desktop scheme provides more power, they destroyed the configurable simplicity of GNOME 2 in favor of minimalism. In addition, you have to respect the history of a product's UI if you wish to retain users who want to stay comfortable in the software they use.

mwhite

10 lat temudiscuss

Haskell is mainly developed and used by academics in the field of programming language theory, and occasionally such academics who do some work in industry, so it's not really the whole story to call it "software programmers build for each other".

mwhite

10 lat temudiscuss

That's the absolute additional deaths, not the change ratio.

> Planned out-of-hospital birth was associated with a higher rate of perinatal death than was planned in-hospital birth (3.9 vs. 1.8 deaths per 1000 deliveries, P=0.003; odds ratio after adjustment for maternal characteristics and medical conditions, 2.43; 95% confidence interval [CI], 1.37 to 4.30; adjusted risk difference, 1.52 deaths per 1000 births; 95% CI, 0.51 to 2.54). The odds for neonatal seizure were higher and the odds for admission to a neonatal intensive care unit lower with planned out-of-hospital births than with planned in-hospital birth. Planned out-of-hospital birth was also strongly associated with unassisted vaginal delivery (93.8%, vs. 71.9% with planned in-hospital births; P<0.001) and with decreased odds for obstetrical procedures

mwhite

10 lat temudiscuss

Sorry for being unclear. I'm not proposing NoSQL. I'm saying that many NoSQL users really mainly want NoDDL, which can be implemented on top of Postgres JSON storage while retaining SQL.

- data (string type, int id, json fields)

- fk (string type, int subj_id, int obj_id)

  select
    data.id,
    data.fields,
    fk_1.obj_id as 'foo_id'
    fk_2.obj_id as 'bar_id'
  from data
  join fk as fk_1 on data.id = fk_1.subj_id
  join fk as fk_2 on data.id = fk_2.subj_id
  where 
    data.type = 'my_table'
    and fk_1.type = 'foo'
    and fk_2.type = 'bar'

What would the performance characteristics of that be versus if "foreign keys" are stored in the same table as the data, if fk has the optimal indexes?

mwhite

10 lat temudiscuss

Postgres (and at least one other RDBMS) has partial indexes, which pretty much solves the index namespace problem you mention: http://www.postgresql.org/docs/8.0/static/indexes-partial.ht... Partial indexes are integrated into the proof-of-concept repo I linked.

Storing a data type field in the generic storage table enables the same partitioning ability as a standard schema.

99% of NoSQL database users just don't want to deal with migrations, even if they're "free" (another big issue is synchronizing application code state and DB migration state of production, testing, and developer machines), so what they really need is NoDDL, YesSQL.

> Almost all database engines can add columns for "free" because they don't go mutate existing rows. Some can drop columns for "free" too by marking the field as obsolete and only bothering to remove it if the rows are touched.

Didn't know that, thanks.

> It can also introduce contention (depending on locking strategies) where there wouldn't normally be any.

Didn't think of that. I'm aiming this at 99% of NoSQL users in which doing things you could do with SQL requires much more effort, so allowing them to do it with SQL can accept a modest performance degradation, but if you have any good links relevant to how this storage design would affect lock contention, please share.

mwhite

10 lat temudiscuss

It's called NoSQL, which removes the need for schema migrations for things like adding or deleting columns.

This could be solved for relational databases if you implemented application-level abstractions that allowed you to store all your data using JSON storage, but create non-JSON views in order to query it in your application using traditional ORMs, etc.

So, store all data using these tables, which never have to be changed:

- data_type

- data (int type_id, int id, json data)

- foreign_key_type (...)

- foreign_keys (int type_id, int subject_id, int object_id)

(we'll ignore many-to-many for the moment)

And then at deploy time, gather the list of developer-facing tables and their columns from the developer-defined ORM subclasses, make a request to the application-level schema/view management abstraction to update the views to the latest version of the "schema", along the lines of https://github.com/mwhite/JSONAlchemy.

With the foreign key table, performance would suffer, but probably not enough to matter for most use cases.

For non-trivial migrations where you have to actually move data around, I can't see why these should ever be done at deploy time. You should write your application to be able to work with the both the old and new version of the schema, and have the application do the migration on demand as each piece of data is accessed. If you need to run the migration sooner, then run it all at once using a management application that's not connected to deploy -- with the migration for each row in a single transaction, eliminating downtime for migrating large tables.

I don't have that much experience with serious production database usage, so tell me if this there's something I'm missing, but I honestly think this could be really useful.

mwhite

10 lat temudiscuss

A team of developers all working off of master doesn't necessarily require much communication about who's working where.

If your code is well organized into modules broken down by functional area, it should reduce the number of potential conflicts.

Also, fear of merge conflicts is somewhat unjustified; most conflicts can be resolved and rebased against using git rebase without that much work; the git rerere option [1] and git imerge [2] can also help with this.

If developers would actually learn how to resolve merge conflicts, and not be afraid of the occasional conflict resolution which requires understanding the other change and how to write new code that incorporates both changes, it's less overhead than communicating about pending changes.

[1] https://git-scm.com/docs/git-rerere [2] https://github.com/mhagger/git-imerge

Submissions

[untitled]

A Self-Hosting Point-and-Click Editor for Any GUI-DB Application [pdf]

Seeking Co-Founder for Declarative Application Editor

Committee to re-legitimize bare try: except: in Python, assemble

React 0.14: Why Local Component State Is a Trap

The Problems of Open Source (2009)

Silicon Valley may not be fixable

The Anatomy of Slavespeak

Show HN: What are you listening to?

Show HN: JSONAlchemy

The Ultimate Git Alias Setup

Markdown Resumé

Ask HN: How would you manage the law using version control?

Will the techno-optimists save the world?

Programming as Theory Building

Ask HN: List of great web development shops

comments