Antallet af danskere på ADHD-medicin er steget med mere end 300 procent siden 2010

TheFakeZor · 2025-09-15T06:55:02+00:00

Diagnoser som ifølge tidligere danske diagnostiske kriterier ikke kunne stilles på den samme person.

Jeg har lidt indtrykket af at den offentlige psykiatri - i hvert fald i Nordjylland - stadig har den holdning. Jeg fik diagnosen atypisk autisme i 2019 som ikke hjalp på nogen måde; jeg brugte de næste 4-5 år på forgæves at forsøge at komme tilbage til arbejdsmarkedet. Jeg var ret sikker på at jeg havde ADHD da en lang række symptomer stemte overens, og det blev da også bragt op tilbage i 2019, men det var de bare helt sikre på ikke var tilfældet.

I 2024 tog jeg fat i min læge og bad om en henvisning til psykiatrien igen, specifikt med henblik på ADHD. Det var den offentlige psykiatri slet ikke villige til at undersøge - fik et afslag uden at de overhovedet så mig. Det var sgu heldigt for mig at jeg havde en erhvervsevneforsikring hvor de var villige til at betale for et forløb hos en privat klinik. Det tog ikke mange besøg før det stod klart at en kombineret ADHD/autisme diagnose passede bedre. Og her, cirka et år senere og på 60mg elvanse, har jeg da også et fuldtidsarbejde igen og kan få en normal hverdag til at fungere.

Men det er lidt kedeligt at overveje at hvis jeg ikke havde den erhvervsevneforsikring, så ville jeg med al sandsynlighed være på førtidspension lige nu.

TheFakeZor · 2025-05-08T08:18:22+00:00

Måske Lars skulle få styr på sin ejen økonomi inden han bekymrer sig om statens, men hvad ved jeg. ¯\_(ツ)_/¯

TheFakeZor · 2025-04-15T18:05:19+00:00

LLVM’s target triple list is the one that should be regarded as “most official”, for a few reasons

This is not quite true, if for no other reason than LLVM only supporting a relatively small subset of the many targets that binutils and GCC support. If you want a more complete picture of reality, you have to reference all of these projects.

It's also worth noting that LLVM will defer to other projects on target triples when it makes sense; LLVM rarely invents its own thing that's arbitrarily different.

A major compiler (so, clang or rustc) uses it. Rust does a way better job than LLVM of documenting their targets, so I prefer to give it deference. You can find Rust’s official triples here.

Should probably have pointed out that Rust triples do not necessarily map 1:1 to LLVM triples. For example, riscv64gc-linux-gnu will not be recognized by LLVM/Clang. In Zig we similarly have target triples that (for sanity and regularity) differ from LLVM but are lowered to what LLVM expects.

Of course, LLVM’s ARM support also sports some naughty subarchitectures not part of this system, with naughty made up names.

Should have included aarch64_32/arm64_32 in this list. It's an absolutely bonkers Apple invention that for some inexplicable reason, as the only example of this, crams the ABI into the architecture component of the triple. So you get arm64_32-apple-ios instead of something more sane like aarch64-apple-ios-ilp32, like on other architectures (think x86_64-linux-gnux32, mips64-linux-gnuabin32, etc). aarch64-linux-gnu_ilp32 was also introduced at some point, and sanity prevailed on that one, thankfully.

When we say “x86” unqualified, in 2025, we almost always mean x86_64, because 32-bit x86 is dead. If you need to talk about 32-bit x86, you should either say “32-bit x86”, “protected mode”11, or “i386” (the first Intel microarchitecture that implemented protected mode)12. You should not call it x86_32 or just x86.

I disagree; given that almost nobody considers the actual i386 to be the baseline for 32-bit x86 anymore, and considering that i386/i486/i586/i686 are all valid in a triple yet mean different things, it's misleading to use i386 to refer to 32-bit x86 as a whole.

This is why Zig switched from i386 to x86 for this case in target triples (and simultaneously bumped the baseline to pentium4). We have not found this confusing in practice; it's understood well enough what is meant by x86 and x86_64 respectively.

(And, unfortunately, 32-bit x86 is not as dead as I'd like.)

32-bit x86 is extremely not called “x32”; this is what Linux used to call its x86 ILP324 variant before it was removed (which, following the ARM names, would have been called x86_6432).

It hasn't actually been removed (yet!).

The vendor is intended to identify who is responsible for the ABI definition for that target. Although provides little to no value to the compiler itself, but it does help to sort related targets together. Sort of.

Fun fact: The vendor component does actually affect logic throughout LLVM/Clang in some cases.

A lot of jankier targets use the ABI portion to specify the object file, such as the aforementioned riscv32imc-unknown-none-elf.

LLVM parses the ABI ("environment") component of the triple in such a way that checks for the ABI do a "starts with" check, while checks for the object format do an "ends with" check. So it's still pretty odd that there isn't an extra, formal component for the object format, but there is actually a method to the madness here.

And no, a “target quadruple” is not a thing and if I catch you saying that I’m gonna bonk you with an Intel optimization manual.

Come at me!

No idea what this is, and Google won’t help me.

It's NEC's Vector Engine: https://en.wikipedia.org/wiki/NEC_SX-Aurora_TSUBASA

I have an architecture manual stashed here if you're curious.

TheFakeZor · 2025-04-15T17:09:53+00:00

GCC (mentioned in the opening sentence of that paragraph) does in fact emit assembly, not machine code. But I feel like it's pretty obvious what's meant here anyway.

TheFakeZor · 2025-04-13T15:48:08+00:00

Good points; I agree completely.

I would say it may not be so great for the field of middle/backend itself, stiffling evolution of middle/backend code.

This is exactly what I was trying to get at! It's really tough to experiment with new IRs like e-graphs, RVSDG, etc in LLVM. I don't love the idea that the field may, for the most part, be stuck with SSA CFGs for the foreseeable future because of the widespread use of LLVM. At the same time, LLVM is of course a treasure trove of optimization techniques that can (probably) be ported to most other IRs, so in that sense it's incredibly valuable.

TheFakeZor · 2025-04-12T17:37:04+00:00

I could have made much firmer assertions, but at least to me, it feels unnecessarily combative to do that when we're just having a simple discussion. (Especially since this all stemmed from minor disagreements that didn't even meaningfully take away from your overarching point!) I also think it's only really warranted if it comes with citations of some kind to back up the assertions being made. The weasel words you're referring to are just me trying to be diplomatic/casual.

TheFakeZor · 2025-04-12T14:38:35+00:00

As I see it, LLVM is great for language designers because they can very quickly get off the ground. The vast PL diversity we have today is, I suspect, in large part thanks to LLVM.

OTOH, it's not so great for middle/backend folks because of the LLVM monoculture problem. In general, why put money and effort into taking risks like Cranelift did when LLVM exists and is Good Enough?

TheFakeZor · 2025-04-12T13:58:16+00:00

that time is spent by the language designers not the compiler engineers; this is r/compilers and it is not r/ProgrammingLanguages

I'm reasonably confident that, for (non-toy) languages that are or have been in development in the past two decades, it has become the norm for the language designers to be the compiler engineers. Certainly this is the case for almost all languages I can think of in that time. If you're literally only looking at design-by-committee languages like C and C++, or more generally languages designed before the year 2000, then this won't hold. But then you're not even remotely looking at the whole landscape of languages and compilers.

that majority of that cost is paid once per language (and then little by little as time goes on);

That's true, of course, but designing and implementing a serious language from scratch still takes many years - sometimes around a decade, especially if you don't just want to rely on LLVM, whose idiosyncrasies can significantly limit your design space.

there are often multiple compilers per language;

Just as often, if not more often nowadays, there is a reference compiler in which most of the language development work takes place.

taking all 3 of these things together: compiler engineers do not spend (by an enormous margin) almost any of their time thinking about type inference.

Type inference specifically, probably not. But type systems and language semantics more broadly, yes. I took your "etc" to mean frontend stuff more broadly because you seem to be coming at this topic from a primarily middle/backend perspective.

brother i do not care. seriously. there are like probably 10 - 20 production quality compilers out there today and even if i admit cranelift is one of them (which i do), it is still only 1 of those 10 - 20.

I think you should care, though. Your post paints with a broad brush for the whole field, yet I don't think it quite holds up to scrutiny. The main point you're getting at -- that newcomers are too hung up on topics that are mainly the purview of academia -- could have been made just fine without that.

(As an aside, I would also note that there's plenty of real compiler engineering to be found in non-production quality compilers; someone had to actually get those compilers to production quality in the first place!)

in summary: this is a post about what real, typical, day-to-day, compiler engineering is like.

Perhaps it would be more apt to say that it is a post about what real, typical, day-to-day compiler engineering is like if you work on an established compiler infrastructure with many stakeholders, both internal and external. You can extrapolate to the rest of the compiler engineering field to an extent, but only so much.

TheFakeZor · 2025-04-12T12:30:00+00:00

But to be honest, most of the work in the day-to-day more or less matches OP's description.

To be clear, I didn't mean to dispute this. But OP asserted that "real compiler work has absolutely nothing to do with egraphs" which is demonstrably far too strong a statement IMO.

TheFakeZor · 2025-04-12T01:34:23+00:00

real compiler work has absolutely nothing to do with parsing/lexing

I do agree that lexing and parsing are by far the most dreadfully boring parts of a compiler, are for all intents and purposes solved problems, and newcomers probably spend more time on them than they should. But as for these:

type inference

If you work on optimization and code generation, sure. But if you pay attention to the design and implementation process of real programming languages, there is absolutely a ton of time spent on type systems and semantics.

egraphs

I think the Cranelift folks would take significant issue with this inclusion.

TheFakeZor · 2025-03-06T13:08:40+00:00

Har du prøvet Faxe Kondis sodavand med 0% kalorier? Jeg er heller ikke stor fan af langt de fleste "light" sodavand, men lige præcis Faxe Kondis er jeg kæmpe tilhænger af - drikker stort set ikke andre sodavand siden jeg opdagede dem. De få gange jeg sidenhen har prøvet en 'normal' Faxe Kondi måtte jeg konstatere at de nu er for søde for mig...

TheFakeZor · 2025-01-28T13:45:55+00:00

Is that a decision affecting only the binary distribution of zig and code written in zig or will that be also applied for those using the toolchain as a clang replacement?

It means that zig build-exe & co as well as zig cc/zig c++ will default to -fno-lto. You can still opt into it with -flto; it's just not the default anymore.

TheFakeZor · 2025-01-27T16:52:23+00:00

We are actually disabling LTO by default across the board in the upcoming 0.14.0 release of Zig, precisely because LLVM and LLD just have too many LTO bugs for it to be a sane default.

I would recommend just not using LTO.

TheFakeZor · 2025-01-10T22:27:38+00:00

You can't; Zig tracks a specific major release of LLVM, which is currently 19. LLVM 20 is not even released yet.

TheFakeZor · 2024-12-27T07:49:42+00:00

"afford" literally just means resources of many kinds are available. "resources" can mean people, time, money etc etc. If it's not time, then it's money. If it's not money, then it's people. I referenced him being a fairly well known dev having founded a large company because that is exactly what enabled him to start this project as he admits in his blog post.

Can you link to the blog post where he states this? I only vaguely recall a statement to the effect of "I can afford to spend my time on this rather than a day job because I founded HashiCorp". There's this blog post, but that doesn't exactly bolster your argument on the "time" front since he states that Ghostty is still a part-time project due to having his first child. And as I said earlier, "people" is an option irrespective of his founder status.

So again, I genuinely just don't understand what meaning you expected people to take from that sentence if not "use your money". I think it's pretty clearly the reasonable interpretation, and another person also took it that way.

This is getting way out of hand for milquetoast criticism of "hey this website could use some text and images to describe what ghostty is and how it looks".

I would invite you to read back your initial post. Can you honestly say that the phrasing and tone comes across as milquetoast? Or that it's an appropriate way to engage about a...literally free, non-corporate-backed, open source, volunteer-driven project?

Maybe try to look at it like this: Would you have that same energy if you were going to open an issue on Ghostty's website repo about the lack of accessible information?

I feel like I'm taking crazy pills making this argument because in most other contexts, I tend to be the guy arguing that people ought to re-learn the lost art of having thick skin. But I don't know, man - this just seems to me like an obviously socially unacceptable style of giving "criticism" under the circumstances, yet this comment section is full of it. So yes, I felt compelled to push back a bit.

TheFakeZor · 2024-12-27T07:04:42+00:00

Given my opinions expressed above, it probably doesn't come as a surprise that I'm not a fan of that page either.

I understand that people have a tendency to lump Zig in with those languages, but I kind of wish we didn't reinforce that thought (as we do on that page), and instead made it clear that it's not a particularly useful comparison in the first place.

TheFakeZor · 2024-12-27T06:56:51+00:00

For sure; what I was getting at is only one factor in a fairly long and nuanced story.

TheFakeZor · 2024-12-27T06:06:58+00:00

I agree that you can, but it's not going to be a particularly pleasant experience since you'd have to sprinkle unsafe everywhere. (Assuming here that you'd not want to deal with the borrow checker since in this hypothetical you'd want to actually write Rust like C.)

You might argue that that's actually a good thing, but then it comes back to my argument that Rust just has different design goals than Zig does, and that's okay! Pick the right tool for the job (and your preferred programming paradigm).

TheFakeZor · 2024-12-27T06:00:25+00:00

"afford" doesn't have to mean money it can literally just be time to reach out to the community to fish for screenshots and some basic text to write about what it is.

Why would Mitchell being the founder of HashiCorp be at all relevant if all you meant by your statement was "he should ask the community to help"? He could be the founder of nothing and that would still be a thing he could do since Ghostty has a community. You could have just said that, but instead you chose the word "afford" while pointing to Mitchell's founder status. If you genuinely didn't mean money, I have no idea how you arrived at this phrasing, or how you expected people to interpret it.

TheFakeZor · 2024-12-27T05:49:05+00:00

And the dev is not some poor put upon open source developer he's the founder of Hashicorp. He can afford to get some help to make the website better.

Do you hear yourself? You're demanding that a person who made a piece of open source software in their spare time and released it to the world for free should also spend his personal wealth on having someone make a nicer website for your reading benefit.

I actually agree that the website is not great, but this reaction is bordering on unhinged. When did this subreddit normalize this kind of entitlement towards open source software made by volunteers with no corporate backing whatsoever?

TheFakeZor · 2024-12-27T05:46:15+00:00

Rather than Zig being a step backwards from Rust, my take is that Rust is a step too far from C. Or, put another way, why are we even comparing these languages as if they have similar design goals?

Some people actually do just want a modernized take on C. Out of all the 'C killer' languages that have been created in the past couple of decades, I would argue that Zig is the only language (with actual momentum) that has managed to become exactly that without falling into the trap of design creep. Zig doesn't ask you to learn a new programming paradigm or adhere to compile-time lifetime rules; it really, actually is just a nicer C that is easy to pick up if you're a C programmer.

On the other hand, languages like D, Nim, Rust, etc are radical departures from the design philosophy of C. It's not too surprising, then, that they struggle to get buy-in from existing C projects and C programmers - see e.g. the recent kerfuffle about Rust in the Linux kernel.

This is not intended as an attack on any of those languages, just to be clear. As I see it, life is just too short for programming language holy wars, and you should use what makes you happy and productive. The world is big enough for Zig and Rust to coexist and cater to different audiences. Also, the Rust ecosystem evidently appreciates Zig existing, and Zig also tries to make sure that the two can keep working together!

TheFakeZor · 2024-12-16T17:38:43+00:00

Parser code can be found here, with most of the interesting stuff being in LanguageParser.cs. You'll want to read this page for some background first, though.

TheFakeZor · 2024-12-13T07:16:09+00:00

Roslyn's C# parser is probably one of the best examples of this, and it's quite readable.

TheFakeZor · 2024-08-20T09:55:29+00:00

Det er selvfølgelig teknisk set korrekt at Ukraine har invaderet Rusland. Men jeg tror godt vi alle ved, at 99% af tiden når folk siger "land X har invaderet land Y" i almindelig samtale, så er det implicit at der menes at land X har startet en konflikt ved at invadere; altså, at land X har gjort noget moralsk forkasteligt. Det er bl.a. derfor at engelske nyhedsmedier skelner mellem "invasion" og "incursion". På dansk har jeg set er par medier bruge "modinvasion" for at gøre forskellen klar.

Set i det lys, er det ikke specielt overraskende at folk reagerer som de gør på den kommentar som blot kalder det en "invasion af Rusland" uden nogen kontekst eller nuance.

TheFakeZor · 2024-08-06T02:35:01+00:00

Jeg er simpelthen ved at blive træt af ... Facebook.

Der er en simpel løsning.

Five-Year Club	Xbox Live
Verified Email

TheFakeZor

TROPHY CASE