If a product is 10x better than what's currently available, it will see rapid adoption. There was obviously something about git that made it MUCH better than the precursors and that's why it obliterated everything else.
I highly doubt that new tools will be 10x better than git. Maybe 20%?
One way I compare the git to jj transition (if it happens, or for whom it happens) to the svn to git transition is: branching in svn was awful. It was heavyweight and you were signing up for pain later down the road. Git made branching easy and normal, almost something you barely need to think about. jj does a similar thing for rebasing. For someone whose familiarity with git is clone, pull, push, merge, creating branches (so, basic/working/practical familiarity but even "rebase -i" might be pushing the limits)- for someone like that what jj offers is a similar "lift" of a feature (rebase) from "scary" to "normal" similar to what git did for branching compared to svn.
That's just one aspect of the whole thing, and of course if you're a git rebase wizard (or have tools that make you that) then this won't seem relevant. But I think for a lot of people this might be a salient point.
I'm happy to give it a try when I have some time, but I have 0 problems with git right now so it's not top of my list. My critique is also really not towards jj specifically, I'm just discussing the idea that git has extremely wide adoption now and that this has benefits :)
No. Central to the trolley problem is that you're in a _runaway_ trolley. In this case, OpenAI not only chose to start the trolley, they also chose to not brake even when it became apparent that they were going to run somebody over.
The tradeoff suggested above (not saying that it's the right way around or correct) is:
* If you provide ChatGPT then 5 people who would have died will live and 1 person who would have lived will die. ("go to the doctor" vs "don't tell anyone that you're suicidal")
* If you don't provide ChatGPT then 1 person who would have died will live and 5 people who would have lived will die.
Like many things, it's a tradeoff and the tradeoffs might not be obvious up front.
> One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’
There's no project manager role in Scrum so he was already doing it wrong.
Dresden is kind of a semiconductor hotspot in Germany. AMD and Infineon have factories there for example which also attracted suppliers and related technology to the area.
My perspective (as a die-hard JetBrains evangelist) is that the "focused" IDEs tend to have easier mental models to map onto the underlying language, versus trying to find the 8 panel's deep dialog that configures the facets for the plugin you care about. That's not even comparing the "what is happening here?!" difference between the plugin versions and the version bundled in the standalone IDE[1]. I would suspect over sufficient spans of time they may converge, but for the most part the standalone IDE bundle is actually QA-ed and the plugins are "well, it compiled!" (or at least that's how it seems from the outside)
The advantage of using the plugins in IJ (or I guess CLion in this case) is heterogeneous development is a little easier if one already has IJ muscle memory in ways that are similarly awkward to do in in the focused distributions
1: to this very second the virtualenv management difference between PyCharm and the python plugin make me chose PyCharm 100% of the time
Largely what commenter above says. Also, the full-featured IDEs signal, and back up IME, a higher level of polish and investment.
Also, I _love_ JetBrains and have access to two different all products pack licenses (one personal, one from my employer) so there is no additional license concern.
"Learning the piano" is nothing like Guitar Hero, though. These apps just tell you (and check) which key to press in what order. They don't teach you anything about musicality like dynamics or articulation. They often can't even tell if you played multiple notes simultaneously or if your timing was correct.
If you cannot already play the piano, what you get is just a fancy way to learn reading (parts of) sheet music with the ability to connect a MIDI keyboard.
Most people with a programming or Unix sysadmin background know about Make and what it is for (i.e. compiling source code, plus building and installing system tools).
Knowing that 'Just' is an alternative to Make for running project utility scripts, it may gain popularity and become as well known.
I'm not sure `make` is any less of a mess, to be fair. Especially when you're trying to use `make` for general project automation rather than the standard set of build tasks.
What? That's the absolute opposite of what happens. More vitamins are retained in the food in a pressure cooker because of less water/more steam and less oxygen.
