in the subsidized example, xm/Sirius is marketed to users as an "ad-free paid radio broadcast"; the marketing literally attempts to leverage the notion of it being ad-free as a consequence of your purchase (power) in order to highlight its supposed competitive edge and usefulness, and provide the user an incentive to spend money, except for the fact that the marketing is false. you still get served promotions and ads, just less "conventional" ads.

i go to a football game and im literally inundated with ads -- the whole game has time stoppage dedicated to serving ads. i guess my season ticket purchase with the hopes of seeing football in person is.. apparently not spending enough money?

i see this as attempting to move the goalposts and gaslight users on their purchase expectations, as a way to offload the responsibility and accountability back onto the user -- "you don't pay enough, you only think that you pay enough, so we are still going to serve you ads because .

why then is there any expectation of a service being ad-free upon purchasing?

who the hell actually enjoys sitting through 1.5 hours of advertisements and play stoppage?

over time users have been conditioned to just tolerate it, and over time, the advertising reclaims ground it previously gave up one inch at a time in the same way people are price-gouged in those stadiums -- they don't have much alternative, but apparently the problem is the user should fork up more money for tickets so as to align their expectations with reality? while they're getting strong-armed at the concession stand via proximity and circumstance and lack of competition, no less.

are you really trying to tell me the problem there is, they need to make... more money? and THEN and only THEN we can have ad-free, paid for entertainment otherwise known as american football? is this really about user expectations, or is this about companies wanting their cake and eating it, too?

that's called breaking and entering, and generally frowned upon -- by-passing the "closed sign".

broadcast television, paid streaming entertainment is just straight up the most glaringly obvious example of a paid service overflowing with advertisements.

paid radio broadcasts (xm/Sirius).

operating systems (windows serves you ads any chance it gets).

monthly subscriptions to gyms where youre constantly hit with ads, marketing, and promotions be it at the gym or via push notification (you got opted into and therefore have to opt out of intentionally after the service is paid).

mobile phones, especially prepaid come LOADED with ads and bloatware.

i mean the list goes on -- you cannot be serious.

the last 7 years of my life have been filled with nothing but community. from skate diys and meetups, and other outdoor activities to, skate diys, bars, live music, and gym communities (once regular programming resumed post covid).

if you feel this isolated i am inclined to ask -- what is it about your life that seemingly lacks these things? i have somehow managed to find community wherever i go and wherever my interests guide me.

what experience of yours caused you to arrive at "they actually don't"?

people in my city are always out and about and socializing and walking their dogs or getting drinks or coffee or working remotely or at work spaces or in offices or whatever. they go out on weekends and drink and eat and hang with friends.

i recently went to berlin and as an american i could not get enough of the summer vibe, the sparkaufts and casual communal hangs and byob bars.

where do you live?

- it was great to brainstorm with but it routinely introduced edits and dramatic code changes, often unnecessary and many times causing regressions to existing, tested code. - numerous times recursion got introduced to revisions without being prompted or without any justified or good reason - hallucinated a few times regarding c++ type deduction semantics

i eventually had to explicitly tell it to not introduce edits in any working code being iterated on without first discussing the changes, and then being prompted by me to introduce the edits.

all in all i found base chatgpt a lot more productive and accurate and ergonomic for iterating (on the same problem just working it in parallel with gemini).

- code changes were not always arbitrarily introduced or dramatic - it attempted to always work with the given code rather than extrapolate and mind read - hallucinated on some things but quickly corrected and moved forward - was a lot more interactive and documenting - almost always prompted me first before introducing a change (after providing annotated snippets and documentation as the basis for a proposed change or fix)

however, both were great tools to work with when it came to cleaning up or debugging existing code, especially unit testing or anything related to TDD

programming languages have a small, manageable and finite set of vocabulary, idioms, and constructs that most languages share but express differently depending on their intended use. a programmer fluent in programming will be able to pick up most languages. how those pieces are cobbled together to form more complicated abstractions becomes the skill obv.

that does not mean they'll be an expert right away, but it does mean they are usually competent enough at minimum to dive in and work with it just like any other tool -- they know they'll need a screwdriver, maybe a hammer, so they look up what it looks like and how it is used.

my daily drivers are python, cmake/Makefiles, c++, and c, with a sprinkling of bash, powershell.

i've worked with microsoft stacks C#/SQL, JavaScript, and i've written a ton of Lua. i've studied concepts and swe fundamentals in languages i don't really write code in and transcribe into code i do intend to write code in. i learned mostly using Lua first, then i picked up c++.

these are just the tools of my job overall. my main skill is communication and learning imo, and knowing which tools are better suited for a task at hand depending on requirements and limitations (mine or technical or both).

however we can set a standard and expectation for new projects to use c++, and we do and set an expectation to target a specific std.

i see this sentiment quite a lot on hackernews -- feels like a lot of people saying "git gud" -- i would expect a lot more nuance applied here.

however for some niche os specific things, and existing legacy products where oversight is involved, simply rolling out a c++ porting of it on the next release is, well, not a reality, and often not worth the bureaucratic investment.

while i have no commentary on the post because i'm not really a c programmer, i think a lot of comments forget some projects have requirements, and sometimes those requirements become obsolete, but you're struck with what you got until gen2, or lazyloading standardization across teams.

do you know many people who interpret the emotional weight of "that's fucking stupid" versus "that's stupid" as the same?

anecdotally everyone in my worldview would react differently to both, and further reactions will depend largely on how it is said -- not because of some ambiguous meaning collectively (mis)understood.

i have always found people who want to wipe clean the slate of language and all its slang and "offensive" words in favor of established definitions and order -- contextually or otherwise -- often lack a lot of emotional expression in their correspondence.

people emote. physically and verbally. and we have all kinds of mechanics to capture the nuances in contextual languages -- slang is one of the best features, and the nuances can run super deep, nuances a lot of formal writing or correspondence can lose in its rigor and strictness. especially not withstanding cadence and emotion.

youre going to have vastly different experience reading stevenson and then say twain, for example. even speaking it aloud -- but i encourage you to spot a common denominator.

their dialogue often reflects the character, the context, and the emotional state, and largely not formal. and there's a heft amount of literature that utilizes formal writing in its dialogue, and one of the first things lost in the narrative is cohesion, and therefore immersion, bc that's not how most people speak -- only a distinct subset talks like that culturally and even then it is still not totally real life.

humans are very rarely strictly formal in correspondence in practice -- we only established professional dialogue as a norm to separate the haves from the have-nots, and then made it a moral high-ground to keep the "peasants" in line.

express yourselves. say what you mean. stop letting people convince you that you should be scared of saying something like "that's fucking stupid" bc it means more for you to say "that's stupid" for the sake of arbitrary professional standards.

source: literally seen quite a few hundreds of concerts.

i have splits for dev, splits for building and testing, splits for sandboxing -- it allows me to multi-task with more screen real estate than using something like vscode or vstudio or some other conventional IDE.

implying i need to be dependent on a school to help me retain learning is a concept that is foreign to me. if i had that kind of dependency in my learning life, i'd be unemployed.

math is communication, and the deeper you go, the more fluent you become, and the more open ended your application gets because you are problem solving, which is a direct consequence of applying critical thinking skills -- you have to consider your solution against a set of possible solutions, and determine pros, cons, and also attempt to disprove your own ideas.

wild statement.

you don't have to treat rebases or merges as this black hole of "i have no recourse for not getting it perfect the first time".

in my 8 years of using git as a primary tool for vc, i have not once run into confusion on how to switch branches, create branches, prune branches, sync remotes with locals, and other common workflows.

does that mean i have only dealt with simple merges or haven't fucked something up bc i did not understand something and made things way harder than necessary (merging/replaying 50 commits vs squash rebase workflows, for example).

and no, you don't need to 'fetch' before you switch, fetching is only relevant if you're needing to bring in remotes or you're preparing for merges etc.

someone committing bunk to a main branch or something considered a production branch is not a git problem -- that's just bad development practices, and the onus is on the developer there to not do that and to understand why it is bad.

as for your other complaints, these are much more easily managed when the developers are not just arbitrarily commiting to branches without any strategic thought, but to point out, a lot of those problems are solved via working with commit hashes and branching, assuming you have already plugged the leak that is committing breaking changes to a main branch.

why are breaking changes that are mega changes even making it through to main?

yes, to understand an application, you must also understand the underlying data structures, architectures, models, use cases -- i am not sure what there's to roll eyes at. but there's no requirement that says that understanding has to be deep in order to work on it, or use it.

i think if you treat it like cleaning a large room, by picking out one corner at time and focusing on cleaning that before moving on, you'll find that the room is cleaned in no time, and git isn't anywhere nearly as complicated as it may feel.

there is absolutely no reason to digest a guide this dense for use-cases in every day production settings, bc those usages only make up about 10% of what this guide covers.

yes, learning things can be overwhelming, challenging, full of darkness and terrors, but that's what learning is, until you've learned.

but here is the catch imo: once you've learned, you don't stop learning and the challenges don't go away. you just become better at navigating the darkness, bc you get better at learning and managing feelings of overwhelm and confusion which are by products of complexity -- real or perceived or both.

jump in. it ain't that scary, even if it feels scary. i promise. i've been there, and you can overcome it.

as someone who works largely in C and C++ codebases, these kinds of comments are gems, especially when i learn something.

what about it seems condescending? we are on a public forum, literally designed for discussion -- unsolicited perspectives, factual or otherwise -- are the norm, not some off-beaten, micro-transgression.

to reciprocate using a similar tone to the one you used with OP: i just do not understand how people find this offenses -- what are you so sensitive about?