453 karma · joined December 1, 2011
Having also worked on a social network and dealt with bots brigading back in 2016-2017, it is possible to apply facts and logic and ethics to these situations. Worshipping a "network" as some kind of neutral aether is greatly downplaying the significant opportunities for tuning the data streams based on knowledge and compliance.
Maybe it's because I'm in Canada where free speech is not what is protected explicitly, it's free expression that's protected as long as it's not invoked at the expense of any other Charter Rights. Hate speech is also illegal in the Criminal Code. These are factual matters that do not get the same amount of unquestioning reverence that free speech without consequences seems to get in some parts of the US.
About the historical theory that it's human nature to want kings and nobility, it seems that is mostly just our particular colonial and patriarchal part of the world. I'm not a historian or anthropologist but am pretty sure there have been societies that operated differently.
If I am querying something technical for work or hobby development I use the HN Algolia search.
Twitter is the only other social network I keep an account on, but barely ever visit because of the firehose of noise despite having a painstakingly selected list of accounts followed. E.g. lots of journalists doing great work, but also posting a lot of personal life updates that are not relevant to me.
It might be that they are less fixed, as you say. That is a feature rather than a bug. It would take so much more text to describe everything literally than to use literary devices, which seem to be things that humans are really good at grasping. They are everywhere in film and TV but not everyone has experience naming them and referring to them in text at a meta level.
Imagine writing a symbolic AI in Go or C. There is a reason why people use Lisps and functional languages for very dense abstractions. They just do a lot of work, which some folks choose to deride as magic.
And yet, mediocre content abounds in the media. How should that be explained?
Was shopping for ETFs a while back and came across the WealthSimple SRI portfolio which is based on their funds. They use a normal ESG index but it also de-lists any companies in the top 25% of emissions for their category.
This would seem to help avoid some collusion and complacency in industries like software that are just at a natural advantage in absolute terms compared with, say, coal plants.
Of course, it's a retail investor and consumer driven thing which leaves too much on the table for some, but I think there's something to the idea of getting companies to compete on the rate of improvement relative to each industry, in addition to internalizing some of the costs through taxes.
It feels like two different lenses onto the same reality.
Why is it Frances Haugen's responsibility to fix everything? Can't the author start with "yes, and"?
I guess it just seems unproductive to use such a click-baity title.
Same here but mostly brown hair except red in the beard. I suspect it's not limited to red haired folks but that the gene occurs in people with relatively northern ancestors (Ireland, Scotland, Scandinavia).
IIRC there were lots of red haired people in the continental Celtic population too. Would they have the same adaptation for less need of sunlight?
Also makes me wonder how the Inuit manage.
EDIT: looks like it got added here https://github.com/glushchenko/fsnotes/pull/704
Take my money!
EDIT 2: darn, the footnotes in markdown still need to be manually incremented. Why can't it work like auto-incrementing numbered lists already do?
There is always the risk of over-simplifying and dumbing down the inherent complexity of problems. Instead of representing the problem space with a good data model, programmers who love to brag about their love of "simplicity" sometimes end up with many extra "simple" layers than are necessary.
It's not a binary because there are a lot of factors that go into simplicity and some matter more than others in different contexts. One person's simplicity is another's tedious verbosity. And another's use of specialized programming techniques is someone else's scary learning curve.
Much easier to just label My Preferred Solution as The Most Simple and Parsimonious because clearly I am the smartest and most scientific thinker in the group. Other approaches are Too Complex, therefore I don't need to understand them. It's just projection of insecurity about knowledge gaps by hiding under the appearance of being an iconoclast.
That said, there are definitely some castle-in-the-sky and nonsense-on-stilts implementations out there :) Some would say ORMs, others would point to the actor model, and others would even say anything higher level than pointers and for-loops. For what purpose though?
That said, I'm not sure universal exchange formats like OWL are really necessary for any use case. Maybe RDF is even overkill, but the concept of subject-predicate-object triples is powerful and opens up a nice space for using rules engines to explore amorphous and multi-dimensional graphs of data.
Also I think the line between data and metadata is pretty blurry and not so easy to separate. At what point is a property of an entity considered "meta"? I'd argue that if the thing it is on can be considered an entity at all, that collecting data about it is just part of the concrete definition.
Assuming that queer people will somehow take over the world and cause an unsustainable birth rate sounds a bit like the right-wing "gay agenda" conspiracy theory. Not to mention that people born with a vagina can have a male gender identity and still get pregnant, and some trans women can get others pregnant. Sex != gender. Also because gender identity isn't just a lifestyle choice, it's not like all the straight people will somehow get converted.
I will also add that goroutines (and actors and other first-class concurrency constructs) built into a language doesn't really help with web startups that aren't targeting large scale consumer traffic or systems level apps, and even if it did, multiprocessing GIL languages has never been an issue. It's a cool feature for sure, but language fundamentalism is just a way for insecure devs to feel cooler.
One of my favourite tools for teams these days is Hasura, which is written in Haskell. I could not imagine a product like this being written in Go.
What I find the most difficult, by far, is "coaching up". Coaching down and motivating junior and intermediate developers comes easy by leveraging the inherent mutual respect that craftspeople have for expert colleagues who are fair and supportive. But coaching up is really hard. Because it often requires convincing superiors with less technical understanding and experience in building teams.
In contract world, it is easier to be accountable for the Whole Project™ because that's how liability works and we have full power to get it done. As an employee who might have to report to nascent technical and product managers, that initiative can be perceived as stepping on toes, and can invite being thrown under the bus for their mistakes. I don't have a solution, but any company that can solve this issue and is good on the other material benefits should have no problem retaining talent IMHO.
This, combined with exposure to KNN over TF-IDF (either live indexes like Elasticsearch under the hood or GiST over trigrams in Postgres or custom trained models), allowed me to discover a kind of "ratcheting" of knowledge.
If the I/O of the program is like an interview with a client, then it's possible to have a "topic stack" where each frame represents a volley in that conversation. I think chatbots also go deep on "dialog engines" like this (see RavenClaw).
For each fact being input, it's possible to check all the policies (rules) that might apply in a declarative way where the developer doesn't need to care about order. Rete takes care of performance concerns, but it's not horizontally scalable (which doesn't really matter IMHO).
Then, for the same stack frame, checking what all other facts are by doing that light KNN to see which other fact patterns were similar, and computing the rule matching on those selectively. This is like making analogies to case law.
Rinse and repeat that flow until some kind of solution is found/suggested/validated by the user, etc. See SHYSTER paper which covered this approach in the 90s.