Perhaps JetBrains should reconsider AppCode, since Xcode only got this crappy recently. Apparently they didn't get the market share they had hoped for.
It gets exponentially more crappy every time, which creates an impression that it only got crappy recently. I remember it doing this since 2010. The usual counter is to stay on the same version until either of you is literally dead.
Although I didn’t find AppCode more useful for my simple tasks. If anything, it felt android-ish in ux, if you know what I mean.
I've always felt like it was slow and annoying to use personally. At least coming from the IntelliJ world, maybe if you were only in Xcode it was pretty decent until recently.
Xcode has been slow, messy, buggy and all around atrocious to use since day one. Being forced to migrate from MPW and Code Warrior to this utter piece of garbage has actually pushed me to web development.
Actually not tangential but very relevant here. In the technique i mention you have to physically focus your eyes for the mind to focus its attention there.
In traditional Martial Arts it is said; "Wherever the Eyes go, the Mind follows" and the highest stage is "When the Body becomes all eyes" i.e. an all-encompassing awareness. Philip Zarrilli wrote a book with the above name on the South-Indian Martial Art of Kalarippayattu - https://archive.org/details/when-the-body-becomes-all-eyes-p... It is not a book of techniques but deals with traditional philosophies/principles/practices which can be learnt from for use with any sport.
When Snowden was escaping capture form the West, err, I mean, US, we, the US, err, the Obama admin, wanted to know which plane he was in to see of they could have it "diverted".
Also, don't pretend to "go hiking" along the Iranian border...
Or you can recognise that ‘Meta’ isn’t a conscious entity, and that it’s perfectly likely that there are some people over there doing amazing open-source work, and different people over there making ethically dubious decisions when building their LLMs.
I’ve worked for dozens of organisations in my career. Large and small, competent and not. Usually not.
In that time did I make some ‘ethically correct’ choice to leave an enormous organisation because some other part of that organisation did something that wasn’t ethically perfect?
Never. Not one time.
And I’m an ethical person. I consider this stuff deeply. Here I am bothering to have this conversation with you.
But, what, every person who has an interesting job doing good things — remember, we’re talking about engineers developing a new audio codec — so those people who have interesting jobs doing good things with a great team are expected to look over there to some distant part of the org, to teams they’re barely aware of, let alone have spoken to, and they’re expected to quit their jobs because of the ‘ethically dubious’ stuff going on over there?
Sorry. Unrealistic, idealistic bullshit. I’ve never done it and neither have you.
Not the person you're responding to, but I guess I would just have to flip that back around and say really this is bullshit to be honest.
I guess I don't really feel that you can just say you're an ethical person and have it absolve yourself of impact of your work.
It doesn't seem a stretch to say that the goals of meta are propagated by the things meta focuses work on, and even if one isn't on the forefront of stealing data, intruding on privacy, or maximizing engagement at all costs, doesn't mean nothing they do will play a part in those teams.
At the end of the day, even accounting at the orphan crushing factory plays a part in the orphan crushing machine.
What projects need manual memory management? Those where the hardware costs are comparable to development/maintenance costs. That is much rarer than people think.
RAM is cheap, and few applications really need bespoke allocation. And it's not just a question of skill; even the most disciplined make mistakes. It's one of how much brainpower you want to allocate to... memory allocation.
In practice I found C/C++ "manual memory management" fans to know surprisingly little about memory management, or even how much manual memory management costs them in performance.
High end games programming sometimes knocks the love of malloc()/free() (and naive RAII) out of them.
In practice I find malloc()/free() mentioned almost exclusively by GC proponents. I don't know any "manual memory management" fans but only people who think that GC is worse than fully designing a memory management scheme for data-intensive applications. And these people shy away from using malloc(), because it is 1) slow/unpredictable (and yes, slower than GC allocation) 2) A general purpose allocator, which gives us little control 3) requires to match every call with a corresponding free(), which is tedious and error prone.
Note also that with (tracing) GC, you not only pay for the cost of allocation, but also pay for the time your allocated objects live.
Then you have a pretty nice bubble (this is not in jest, I honestly envy you).
A more nuanced take is that I can, in practice, map considerable chunk of developers I met and their understanding of memory as:
"it's magic" > "manual memory management rulz! my C/C++/Rust will be always better than GC" >>> people who actually studied automatic memory management a bit >> people who adjust memory management techniques to specific use cases
The fall off is pretty much exponential in amount of people, which I will admit does make some people defensive thanks to second group being both numerically big and undying because programmers suck at educating new generations. Same can be seen in various other areas, not just GC (though GC links with general trope of "opinions formed from people repeating things learnt from xeroxed half dog eaten copies of notes somewhat relevant on 256kB IBM 5150 PC and Turbo Pascal")
A lot of the time I do encounter people who essentially parrot claims about GC without any understanding of what's happening underneath, and indeed sometimes going about "crazy awesome non-GC solution!" that turns out to call out to whatever malloc()/free() happens to live in libc when I pull the cover and with just as much unpredictability as you can get.
As for paying - allocations in GC systems tend to be blindingly fast, but yes, collection does involve other costs.
What does knowing a lot about memory management look like? Is it like being familiar with heap allocation, the structure of fastbins and co., and some knowledge of lifetime and ownership?
In addition to that, also knowing at least basics (a bit like "classes of algorithms") of automated memory management, memory pooling, understanding and using the knowledge of allocation and mutation patterns in one's program.
A funny story related to all that from one of my previous jobs includes a high performance C++ code base that used forking to utilize preloaded code and data and to easily clean up after itself.
Turned out that naive-ish (even with jemalloc dropped in) memory management in C++ code resulted in latency spikes not because of allocation/freeing, but because they put no control over where things got allocated which resulted in huge TLB and pagetable thrashing as copy-on-write got engaged after forking.
To the point that using something like Ravenbrook's Memory Pool System (a GC) with threads quite possible would let them hit performance targets better.
No, I don't. But Bitcoin also isn't particularly interesting because it's not (very) programmable and not useful for mainstream use anyway. I don't consider Ethereum itself a pyramid scheme, just useless. The protocols on top of these chains though, nearly all pyramid schemes. The best way to describe Ethereum is that it provides a platform for pyramid schemes.
That is when you realize "free market" means "our buddies at the top can charge whatever they want, and you may not compete". Same with healthcare, telecom, financial services...
https://www.nature.com/articles/s41598-021-83148-6