I value choosing between two styles by feel for improving readability and conciseness.
For example, allowing one-liner early-returns if they are concise enough. If they are not, they must be multi-line with a block with curly braces. There’s no linter rule that defines what “simple enough” is, and most linters don’t do rules with condition either.
Web is just one kind of frontend though. And there’s more ways to target web with JavaScript interfacing than transpiling to JavaScript.
Why is single line comments listed when it’s green for all of them? Do they not have multi-line comments?
What are "frontend language"s?
Just wondering if this is very incomplete or due to scoping.
A standard for build output might make sense to me. Maybe just throw cache stuff in .cache and build output to .build (with intermediate artifacts in there as well potentially).
When enabled via flag, dotnet puts stuff into artifacts/obj, artifacts/bin, and artifacts/publish respectively. I like that. So much better than every proj folder having their own.
And there’s really no need to make it a dot folder. For the publish you don’t want to anyway. And you may want to navigate to bin as well, to run a build or inspect the output.
A bit too broad to give a specific answer from my side.
Overall, I prefer web based over apps, because I can CSS hack and if necessary JS hack them.
Web also means it doesn’t litter my PC or mobile phone or tablet. And that it can’t fetch more data than it needs or I want it to have access to.
Bad software is bad software, no matter if it’s installed or on the web.
The git compatibility is necessary for adoption and connected use.
jj does significantly reduce the work interface, but the git compatibility increases complexity again.
I tried it out a little bit a few days ago, and found it interesting. But given my git knowledge and tooling, I can’t reasonably switch. First, I would miss my TortoiseGit Log view (entrypoint to everything). But also, the connection between jj and git seems complex and potentially error prone.
As a fresh and independent tool I can definitely see how it’s much easier and better, especially for people not familiar with Git.
from some time ago
It’s a fair statement and personal experience, but a question is, does this change with tool changes and user experience? Which makes studies like OP important.
Your >95% garbage claim may very well be an isolated issue due to tech or lib or llm usage patters or whatnot. And it may change over time, with different models or tooling.
It’s not a duplicate URL. You posted an image, they posted a link to the study.
I mainly wanted to give the additional context and discussion, more so than say “has already posted”.
I assume I must have compared a modified date or sth, dunno. Misled by it being shown further down in my feed.
(minutes) earlier post linking the study
So many words…
to 
oh god please no
wth is all that coloring [in the design samples]
Stop allowing full unfettered access
There’s a decline button. At least privacy settings don’t repeatedly come up again (what this post is about).
Better flood them with interested users than ask for thumbs up on a ticket.
We want to move down to the next line (line feed) but also to the beginning of that line (carriage return) after all.
Unless you open it in Excel. In which case bad things will happen no matter what you have in the CSV…
They bought Java (not javascript)
They bought Sun, which “owned” Java and JavaScript.
The trademark was originally issued to Sun Microsystems on 6 May 1997, and was transferred to Oracle when they acquired Sun in 2009.
A Python-specific question is better suited to the !python@programming.dev community instead of the general programming one.
I’ll use a gif with each frame being a different country flag. Then I can access them by frame index.
OpenGL is an API standard. It defines data structures, operation interfaces, and behavior.
Mesa 3D is an implementation of OpenGL. It can be used so users of OpenGL can call it to draw stuff.
Vulkan is a newer API standard. It is newer and was designed with a lot of new hardware and hardware capabilities in mind, and significantly reduced what the job of the API is supposed to do compared to OpenGL. Essentially giving API users many more opportunities to control graphics pipeline behavior for better efficiency and performance. Libraries and frameworks exist that provide more convenience and prepared setup or opinionated usage patterns on top of Vulkan.
DirectX had a similar shift with DirectX version 12, which also implemented closer-to-hardware APIs similar to Vulkan vs OpenGL.