corethree

>Thus actual solve time and absolute difficulty are almost orthogonal.

No it just means luck is another factor. You have luck, intelligence and length of time. Time is correlated with possibility right? You can get lucky and guess the probability on the get go.

Either way you introduced a third possibility here which goes further to illustrate that this quotation is inaccurate and not intelligent.

>Again no, it was saying one limitation becomes significant in a specific situation. Often these bugs may not actually take long to fix, but you’ll suffer when dealing with them. Even strait forward off by one errors can be annoying when you have to reason about really tricky bits of code.

False. You are absolutely wrong. The statement was made without qualification to a specific situation. Therefore it is made in the context of the universal situation meaning absolutist. Sinking with the ship again.

>That feeling where you spend an hour staring at an IDE with absolutely no clue what’s going on sucks even if it doesn’t take that long to actually fix the issue.

So? This doesn't have anything to do with the topic at hand. The topic at hand is the quotation is wrong. How you feel during debugging is off topic.

It's criminal. The entire doctors profession is the reason why the US is so expensive.

It's cartel based regulations by the AMA. Everything about being a doctor is gate kept. Prescriptions, test results, even becoming a doctor is artificially made harder than it needs to be to keep prices high.

One doctor on HN told me why patients could only get test results through another appointment with the doctor. I thought it was because the docs wanted more money. He told me it was because patients can misinterpret results and go suicide. Yeah makes total sense treating patients like simpletons to keep the money funneling in. Suicide?. Give me a break.

I hope a lawyer jumps on this and sues on behalf of the American public.

Refund all instances of the sold chemical, put the company out of business. Is it possible?

If it can't be refunded funnel the money into actually creating an effective regulatory body. One can dream.

Seems like the entire food regulatory body the USDA and the FDA are just in the pocket of the industry. Lack of funding is the least of it. Paid off and corrupt is likely the better characterisation.

Seems like Literally nothing you eat is regulated at all.

Unless it kills you. Then if it kills people the FDA acts only after they see a good amount of people dying.

Almost all of this is universal knowledge now. I wonder why there's no outrage or pressure to change.

Science is expensive and moves slow. Sometimes anecdotes are all you have.

Just because the science doesn't exist doesn't mean anecdotes are completely invalid.

>Man, you just did.

I just did what. Be clear with Your sentences.

>If your job is C++ development, yes, I absolutely expect you to be familiar with the full C++ documentation and master the parts relevant for your specific usage of it.

So you were unclear. You want someone to master only parts of of the stack but read the full spec. This is completely inconsistent with what you said earlier. You are moving the goal posts. Still it doesn't Make sense to read 1800 pages of the C++20 spec.

Do you read the English dictionary because you use English?

>And the easiest way to get that familiarity is reading the damn documenents. If you cannot be bothered with that, well, let me say I am happy I don't have to work with you.

Then you would be happy to not have to work with the overwhelming majority of programmers on the face of the earth. You being in the minority would make you the problem. Not others. Programmers in general read the spec and docs relevant to the task at hand. They do not generally read the full formal specifications and documentation of what they need.

>All the docs, if taking literally, would mean all the docs for everything you interact with in your life. Obviously impossible, isn't it?

No but even if C++ is the central language of my stack your comment can reasonably be interpreted as suggesting me to read the entire C++ spec. That's not an outlandish interpretation given how many people interpreted what you said this way.

>So, ehy exactly do you think that reading jib and task relevant documentation is not necessary, or even the comoletely wrong approach?

Did I say this? No.

>This isn’t a discussion about all bugs but the class of bugs created from dealing with clever code. Very difficult bugs may be fairly quick to solve in comparison to simple bugs that require some long process to replicate. Time to solve really doesn’t map well to difficulty.

It does. A bug solved in seconds is usually considered less difficult than one solved in weeks. It maps easily.

>False, you clearly missed me stating it intelligence was “one” limitation not the only limitation. Poor tooling can be a massive pain among many other things. Again though this is talking about debugging a very specific kind of unnecessarily complex code.

The quote was suggesting absolutism one limitation. By showing the existence of an equivalency I've shown the quote is not absolute. Therefore the quote is not intelligent. Therefore your statement is false and nonsensical.

>your specific use case, I cannot help you with that

I don't need your help. You need it. I'm helping you realize your statement is wrong.

First you make a statement saying one should read all the docs. Now you say devs should read the relevant docs. Devs do the later anyway. Your argument just evolved into the point you're arguing against.

Clearly you didn't mean to do that. You just meant to read more docs then you normally would on topics a little further from the relevancy at hand. But people are responding to you based not off what you meant but what you said.

Wrong. A more complex program has more possible origins for the bug. So you need to make more hypothesises to check and verify the bug. Time and intelligence are both a factor here. Sometimes one more than the other.

Clearly you don't think bugs are all solved in seconds and limited only based off of intelligence. A harder bug often needs more time to solve. This is common sense.

You're just sinking with the ship now.

It's as "false" as his premise of relating difficulty to intelligence. My point is the existence of an alternative statement that is equally and fuzzily true shows that this quote is not really that intelligent.

Reread my post. I literally said neither definition is absolutely true.

Yeah but he obviously didn't mean zero.

You should mention this in your reply because it seems like an attempt at refutation. Like the generality is obviously wrong. It's not. The broad brush is correct. Your experience is the anomaly.

Probably not? So your advice is wrong.

You are obviously picking and choosing your documentation based on how easy it is to read. So your advice isnt universal. Clearly you don't fully follow it.

There's a lot of contrarian opinions here due entirely to the fact that people won't read certain documents for the same reason you avoid reading the c++ spec.

Right he's talking about a developer who is caught in the trap.

A better way to put it, is a developer about thinks he's excellent. What someone thinks is, the majority of the time, not inline with what he actually is. Especially for developers who think they are excellent. Looking at you Brian Camacho.

You should try this for C++ and Linux. Read the spec of each cover to cover.

Not an intelligent quotation. Hardness can be defined as how long it takes to accomplish a task. Following this definition everything can be debugged. It just takes twice as long.

This definition isn't absolute and neither is the definition by Brian. The truth is much more complicated.

Video games make way more money then Hollywood. I mean not to be insulting but it's like asking the question are movies actually entertaining?

There's also many different genres of video games like there are movies and each genre scratches a different itch. The itch you're describing is sort of a "leveling up" goal oriented genre.

That's not the only genre. For example what's the purpose of VR? How does it help with "leveling up" or getting to the next "campaign"? The whole point of VR is immersion.

Too many people view gaming from a biased corner from their own little niche interest without realizing how big the industry is.

>That's a broad brush you're painting with, amigo. As a 49yo father w/ two teen daughters (17 and 15), I've been surprised and delighted at the strong bonds I have w/ each of them (esp. my 17yo). We "hang out", and seek each others' company, to our mutual enjoyment -- it's absolutely nothing like my relationship w/ my own parents at their age.

This is not the norm though. I wonder why people think countering something with an individual experience that's clearly distinct from the norm is a counter? It's not. His generalization is correct, your counter isn't evidence against it.

Part of the reason for the generational gap isn't just because of different culture. But it's also because where kids and adults are all day. Adults are at work, kids are at school. So the social connections, hierarchy and the dynamics are all completely different universes.

A lot of kids don't give a shit about grades because often that's not part of the social hierarchy at school. Money isn't even that huge either. It's when they get out of school all the rules change. That's why there's always this younger generational gap between teens and adults but less of a gap between say 20s and 30s.

>It is a little sad to see so many be so dismissive of unit tests.

You're preaching to the choir. The overwhelming majority of people worship unit tests like dogma. There's almost no point in saying the above. It's like saying it's a little sad to see some people who are so dismissive about eating and breathing to stay alive.

Your next part is the one that's interesting. Mocking 80 percent of a system to get unit tests to work. I've seen so much of this from developers who don't even realize the pointlessness of what theyre doing that it's nuts. They worship test so much that they can't see the nuance and the downside.

Take this article. This article is literally presenting evidence for why unit tests are bad. He literally created an error that would not have existed in the first place we're it not for his tests. Yet he has to spin it in such a strange way to make it support the existing dogma of test test test.

It exists for all software that has configuration and has a plugin system.

Think games. If I'm playing a game and I want to change the configuration to easy mode and up the resolution to wide screen I need to write a program or script to do it? No it should be a dumb setting configurable via gui.

If I want to modify a game beyond the dumb config or modify the config itself then scripts make sense. It's called mods. In games and in software with plugins, configs and scripts live side by side. It's one of the most common patterns in the world.

Additionally you're not seeing what I'm proposing here.

All configs and packages have to go through the "dumb" system. There is zero alternative. This is exactly what games do.

If you want to modify the configs then you go through the modding system. This can use the nix language.

Either way as it exists right now nix can't have a GUI for its config. If I make changes on a GUI how does the program know how to modify your config file which is a custom script that you could of wrote in a thousand different ways? It can't. You want a GUI, you need a dumb config, end of story. Unless you want nix stuck in the niche group of power users you need a GUI.

Well if you want to be this pedantic. How can a website have opinions?

You most obviously must be referring to the owners of the website.

Or are you referring to the comments?

Because both the users and the owners of said website have vastly different opinions here.

Additionally at one point Sam Altman was literally a "darling" for the company, before he got fired.

Your statement is ambigiuose and therefore wrong.

False. And wrong.

Read: https://en.m.wikipedia.org/wiki/Consistency_(database_system...

We are talking about the word consistency. Which is most often used in the context of databases. Eventual consistency is here:

https://en.m.wikipedia.org/wiki/Eventual_consistency

It refers to the same concept and technically and colloquially its referring to databases or things similar to databases. If it didn't then every system on the face of the earth is eventually consistent because of browsers and caches and timing. Every browser eventually presents an outdated view if it's not refreshed. If that's the case what is the point of the word? The word is obviously used for categorization.

Thus The scope is usually and colloquially a database systems or some combination of services that represent a source of truth.

If you read further into the article you cited you will encounter this:

"In order to ensure replica convergence, a system must reconcile differences between multiple copies of distributed data. This consists of two part..."

Literally the article assumes we are talking about distributed systems where replicas can exist.

Is a cache a replica? Is a browser a replica? No. The scope is obviously the source of truth at the resolution where you can have replicas aka: two or more sources of truth.

>The event store and the cache are both part of the same system, and it's this whole system that is "eventually consistent".

Then every single system of the face of the earth at a high enough level has a consistency issue. Just go to the level of the full client and backend system using web browsers. You don't refresh the browser you of course will eventually have a "consistency" issue.

Usually when they refer to this stuff it's referring to the source of truth: The database. When you shard the database into two synchronizing copies, you increase the availability with a second copy but that leads to the potential for both copies to be inconsistent.

Then it's an outdated materialized view. If you don't refresh your view from a browser is it a consistency issue? No. Not in in the way the term is usually used.

I wouldn't call that a consistency issue. That's just lag. The aggregation is valid for a specific time point. Caches aren't the source of truth. The source of truth remains consistent here.

Actually event driven stuff is highly consistent. Event insertion is fast as hell and all of it is timestamped and tagged with a unique Id so there's no consistency issues.

The problem is availability. You have to aggregate those events to get anything meaningful about it and aggregation can be really really slow.

Two ways to do it.

1. Use a database designed for this stuff. Google big query, Amazon redshift, clickhouse..etc. all current data is essentially a type of aggregation. Or in other words it's equivalent to a group-by query on an event database.

It makes sense right? With events I can technically rebuild the current state or the past state of the data through some aggregation query.

2. Rename your relational storage and call it a caching layer that lives next to the event system. It's functionally the same thing but won't trigger any red flags in people who are obsessed with making everything event driven.

The architecture he describes exists. It's just massively complicated so services that utilize it usually do very targeted things. Think Google analytics, data dog, splunk... etc. Etc.

Eh. The model he describes is actually standard for analytics.

And because it's standard there are literally databases designed and optimized to do what he says. It's not madness when it already exists and is really common.

Think, redshift, snowflake, biq query, clickhouse..

Additionally their already exists user interfaces and web services that already do what he says.

Datadog, splunk, Google analytics... Anything related to logs, analytics and aggregation of those analytics. What he proposes actually already exists.

That being said I don't agree with the articles point to replace everything with this model. Usually these types of services target very specific use cases.

I think your reaction is a bit extreme here. I don't agree with his proposed model but I see where he's coming from and it's not that the model won't work... It's been proven to work from all the examples I gave above.

The problem with it is that it's just slower and much more complicated. But his proposal does increase the capabilities of your data.

You can increase speed by having a pre-caching layer for your aggregations. Basically what was originally your static store is now a caching layer where the developer or user pre specifies an aggregation that the system should count live as the events come in as well as throwing the events into the event db. If when querying for that aggregation you get a "cache miss" then it hits the event layer and has to do the aggregation job live.

So essentially if you build it like this you have all the capabilities and speed of your original static data store but now you have the ability to re aggregate events differently so you have MORE ways to deal with your data. It can work and it will have more features its just really really really complicated to make an entire system centered around events. Additionally theres also a boatload of extra data to deal with which is another engineering problem.

That's why when people do build these systems it's usually centered around some business requirement that absolutely needs this ability to dynamically query and aggregate events. Logs and analytics being the two big ones. Or some service to data scientists as well.

The theory behind it is attractive. All static data can be represented as a series of events. In fact static data is simply the result of a certain of aggregation query on an event database. It's attractive to use smaller primitives in programming and build higher level abstractions through composition so this style of event driven services seems more fundamental and proper. But of course like I said there's practical issues with it when you look past the theory such that this model is usually only applied to the specific use cases I mentioned above.

So there is a failure here. Not of your intelligence. Failure of your experience.

And as I side note I agree with you on the tone of the article. He's trying to be witty but he's trying too hard.

You know HN is ycombinator right?

That when you come to this site you have to type in the words ycombinator for the url right?

You said Sam is HNs darling. That's different from saying HN viewers. So you literally did not say what you said here.

You know he got fired from Y-combinator right?

It was a direct order from Paul Graham. He keeps mum about it but I have trusted sources who know the truth. Additionally, it's sort of public knowledge:

https://www.washingtonpost.com/technology/2023/11/22/sam-alt...

I don't have a full view into exactly why he was fired from both OpenAI and Y-combinator. But from what I hear the reasoning is a bit similar. Sam Altman is a bit of a political snake. He lacks ethics and he's not honest either. The last part is just me speculating on a lot of the anecdotes from quips I've heard over the years from people who know Sam.

Sams public persona is very different. And I think a lot of HN viewers worship that public persona. But Sam being a darling of the HN and Ycombinator themselves? No way. They fired him so it's unlikely.