mwhite

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.

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.

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 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.

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

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.

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

"spirit of the times" /stopped reading

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.

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

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.

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".

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

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'

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.

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.

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

It seems like NoSQL could be left behind except for the .001% of use cases that actually require it and can't be easily replaced with extensions or (hopefully) automatable configurations of Postgres, but it would require application-level abstractions, and the database community doesn't value those enough, as evidenced by SQLAlchemy [1] not being highlighted on the homepage of every RDBMS project because of the awesome power and flexibility it gives the developer.

Specifically, a JSON column should be used to store everything other than primary keys and foreign keys, and views and indexes should be automatically created based on the schema defined in the application (i.e., get the schema from the ORM at deploy time and post the data to a schema/migration management system) using something like https://github.com/mwhite/JSONAlchemy

It is entirely possible to implement the CouchDB or MongoDB API on top of Postgres JSON, for instance.

[1] http://www.sqlalchemy.org/

Enough of it's luck that it's unlikely that a team would go undefeated for half of a season, but it's also the fact that it's hard to get a team with only the best players; most teams have a mixture of player ability. If you put the best major league team in the minor leagues they'd probably have a 90%+ winning percentage. (Highest MLB season winning percentage is 76%, longest winning streak is 26 games out of 162, including a tie.)

English-speaking countries are not all alike. The level of non-English speaking immigration to a country (which happens in all English-speaking countries, but to a much greater degree in some than others) has a large impact on the ability to maintain high standards for the language.

As I'm sure you know, English spelling is also much less phonetically obvious than Italian (and I would not be surprised to learn that English is slightly grammatically more complicated than Italian, although frankly, as far as I'm concerned, any language with grammatical gender wins for difficulty), so emphasizing correct writing might be slightly harder.

I think by script tags he means JS modules that only "export" things using globals.

No one is saying that no one should still use tech that was previously state of the art. No one is saying that you need to rewrite existing apps if there's no business need to.

I use Backbone models in a React app because Backbone is still the best library for models. I haven't tried Redux because it doesn't solve any problem I know I have.

Plenty of people skipped Angular because they knew it wasn't going to be on top of the hill for very long in the evolution of the frontend ecosystem.

I meant that your code could parse the supposed lave code before running it to verify that it is limited to the known lave constructs (which does not include arbitrary code execution). It would quite slow but enough to make it somewhat safe against an attacker providing malicious lave code.

It seems like it theoretically shouldn't be too hard to add the ability to validate that the data is a valid lave output if you're concerned about that. That more or less leaves only the issue of anonymous functions in the data being replaced with malicious functions, but frankly the only reason to be serializing functions is if they're user input, otherwise you should instead be serializing function name/key strings or some other well-defined form of function references and/or arguments.

On second thought, I'm not sure if a backbone-react mixin is even necessary. You can explicitly subscribe and unsubscribe to events with only a couple lines of code in componentWillMount() and componentWillUnmount().

You could try using Flask-Restless with Backbone-Relational and then integrate with something like React using something like https://github.com/magalhas/backbone-react-component

https://flask-restless.readthedocs.org/en/stable/

http://backbonerelational.org/

Allowing sellers not to fill out additional information that they easily could provides a useful signal to buyers about how well the transaction is likely to go.

Idea: crowd-sourced issue triaging across many open source projects that rewards issue triagers with reputation points.

Cool, but a more meaningful number concerning the original meaning of "six degrees of separation" than the average of the average of the degrees of separation between each individual and everyone else would be the average of the average of the 90th, 95th, 99th etc percentiles of the degrees of separation between each individual and the most distantly separated other individuals in the graph (maybe excluding outliers who only have a few Facebook friends).

That is the distribution of the average degrees of separation for each person. What would be useful is the distribution of distributions of the degree of separation between each person and every other person.