It depends on the country. This is true in American English and it's what we teach in schools. In British English (which, in my experience, is what most ESL learners outside the US end up learning), they go outside the quotes. Source.

As a professional Haskell developer, I tend to agree. I loathe any and all lens code I find using a ton of operators (though I just dislike lenses in general). Operators from base are generally fine, but for the rest, just use normal functions damnit. Operators suck for code navigation too.

Umm, you do realize no one manually enters all of the spaces, right? Basically all editors support an expandtab feature which inserts the amount of spaces you want whenever you hit the tab key.

Code formatters behave exactly the same regardless if you're using tabs or spaces, so not sure what you're talking about.

I did not miss the point. I fully understand that's why people want tabs. I just think it's a pretty stupid and petty reason to make for a worse experience when viewing code in places you don't control. I still don't know why using spaces is an issue when we enforce standards in literally every other facet of contributing to a codebase. We enforce coding styles. Indentation is part of the coding style.

This is simply false, many systems have them configured by default to 8, particularly most CLI tools. Git, for example, is 8, and btw, changing it is not readily done and requires you to hack around it by using a custom pager command. In fact, all core gnu utils (and even bash itself) default to 8, as well vim, emacs, nano, gedit, etc.

I use 2 spaces since I work in Haskell, which is a significant whitespace language where you want certain syntactic constructs to exist at a different level of indentation from your main code block. So yes, I have configured it. 2 spaces is also exceedingly common for HTML (browser Dev tools renders HTML with 2 spaces, even).

There is not a universal indentation width, though it is almost always universal within a particular language or perhaps project, in which case it's much better to have everything standardized. Code formatters enforced on a project are the norm, and those are way more impactful on how the code is read. But they are valuable because consistency is valuable. And yet, somehow you don't have huge scores of developers complaining about being forced to format their code in a way they don't like.

As I said, you don't necessarily control the environment in which you are viewing code. A common example is reading code over a shared screen. So you can easily end up reading code in a way you don't like anyway, so it may as well be some reasonable (if not preferable) standard that everyone is using.

That's what warnings are for and -werror for production builds in literally any other language. This has been a solved problem for a very long time.

So... A lot of the time?

Neither are acceptable, especially when it's propagating ugly labels. All of it is really unnecessary. Swipe left on people you aren't attracted to, and if you talk to someone and find a dealbreaker, politely disengage without making them feel shitty or othered. It really isn't that difficult.

I don't think it would be effective, I just found a certain amount of irony in the analogy.

I do think smartphones should probably be banned in schools, but that's another topic.

Huh, now that you mention it that's definitely a nice thing about playing on the steam deck. Just put it to sleep.

I find it highly overrated in terms of productivity in general, particularly when writing anything remotely non-trivial/company-specific.

There's also the absolutely massive issue of licensing/IP/etc. Any company that's not full of dumbasses should recognize the massive risk and liability involved and stay the fuck away.

Sure, just like businesses have always wanted "no-code" solutions to their problems to cut out the need for software engineers. We all know how that turned out. There was no threat then, and there's no threat now.

Learning frameworks has never been hard, and frankly does not make up the majority of a developer's job. Maybe you do it while onboarding. Big whoop. Any good developer can do that fairly easily, and LLMs are entirely superfluous. Worse yet, since they are so commonly confidently incorrect, you have to constantly check if it's even correct. I'd prefer to just read the documentation, thanks.

A mature engineering organization is not pumping out greenfield projects in new languages/frameworks all the time. Greenfield is usually pretty rare, and when you do get a greenfield project, it's supposed to be done using established tools that everyone already knows.A tiny fraction of a developer's job is actually writing code. Most of it is the soft skills necessary to navigate ambiguous requirements and drive a project to completion. And when we do actually program, it's much more reading code than it is writing code, generally to gain enough understanding of the system in order to make a minor change.

LLMs are highly overrated. And even if it does manage to produce something useful, there's much more to a codebase itself. There's the socialization of knowledge around it and the thought process that went into it, none of which you gain when using an LLM. It's adequate for producing boilerplate no one reads anyway, but that's such a small fraction of what we even do (and hopefully, you can abstract away that boilerplate so you're not writing it over and over again anyway).