1. It's not a ban on using social media, it's a requirement for age verification to create an account. This only limits usage on the few platforms that force an account to do anything.
2. The technical controls platforms implement are, unsurprisingly, generally quite weak. Kids are crafty enough to circumvent them, and share how freely.
3. Wannabe-influencer parents just create accounts for their kids, making the circumvention trivial.
4. There are no consequences for using a social media account while under 16.
I think the final point is the main one, though. By design there's no mechanism in place for the government to take any action if a kid gets onto social media, only if a platform fails to implement age checks that satisfy the legislation's criteria. So platforms all implemented tokenistic age checks. Platforms don't care, or need to care, if they get bypassed. The government doesn't care.
If I were a more suspicious man I'd say that either the point was never to reduce the use of social media by kids in the first place, or it was well intentioned but railroaded into toothlessness by lobbyists.
The big issue that media and the like are careful not to mention lately were the algorithms social media refused to do anything about when asked to by the govt when the public complained -too hard or whatever- back 7 or 8 years ago. At the time parents were discovering some social media [1] was funnelling children into darker areas [focus teenage anxiety] for profit. Though bullying was one of the concerns for children, the under 16 ban means any smart social media company, with an understanding some kids will still use social media just like under age unlicensed driving still happens, the last thing the company needs is ending up in the courts due to the bad algorithms or piss poor moderation. With the ban it should be assumed, for they (social media and their friends) seem to be claiming their pii scraping and analysis is near hopeless, they will have preemptively removed the troubling algorithms at the very least - less they find themselves in the courts due to use by an under 16 child that was groomed to a dark place, without a leg to stand on.
The ban also means parents and teachers alike have the means to make children put their phone down or away and pay more attention to real life things.
I pay for my tokens for my own projects, at least when the ones Google seems willing to keep throwing at me for free don't cut it. I'd think that's not too uncommon, especially here where there's likely a high ratio of hobby coders (whether also professionals or otherwise).
Free tier Gemini is good enough for my personal projects and hopefully a local model can replace it before i ever personally pay for a single token from anyone.
local models are getting pretty close. they still require some serious hardware to run at a reasonable rate but they're about smart enough to be useful.
Yeah i just don't have the hardware to run them at a reasonable rate and am not ready to invest that much at today's prices. My tinkering with DeepSeek last year was promising but the minutes-per-response made it unusable.
If the phone support issued the decrypt code, you could just replay that same code for every CD stamped from the same master.
If phone support issued an encrypted decrypt code that could only be used with your challenge code to decrypt the decrypt code, replay wouldn't be as trivial.
Every CD is identical, so no matter how iD went about this there's only ever one decryption key (per title, I assume) and those keys must either have been encoded in iD support's response, or already stored on the CD. TestDrive sold iD on the notion that the process was too hard for hacker groups to reverse engineer, and it wasn't.
Maybe. There's less wiggle room though. You can't make a clone of a WCH, ESP32, GD32V, or RP2040 at a low enough price point to really profit from the gap.
If Quintauris successfully makes a RISC-V range for automotive use, there'd probably be margin to clone those and sell at a profit, but skirting automotive certification regulations is a high-risk game that (hopefully!) doesn't have many buyers.
If they make an IoT line, again, there might be margin in it, but you'd be trying to fit in between buyers willing and able to engage with Chinese sellers but for some reason unwilling or unable to engage with existing Chinese sellers of existing IoT RISC-V parts. Quintauris is a very, very long way away from being a "household name" along the lines of STM32 or FTDI.
I think the parent's point is, cheap MCU will have quirk no matter it's ARM clone mcu or RISC V MCU. Most of the time, the quirk exists in peripheral, not cpu core
You used to be able to do surprising things with those old speakers using a timer interrupt: on an IBM XT it was possible to get 8kHz quality out of it, enough to make 4-channel MOD playback sound about as good as hearing it over a phone.
But your more typical use case was to play a single tone for some significant fraction of a second.
Nice, there’s also a great in-depth article about an album driven entirely using the primitive PC speaker. The whole COM file comes in at around 40 KB, so you can copy it onto an old machine and run it. Some of it you'd swear you're listening to a SID chip~
I remember an old company called "Access software" that had something called "Realsound" with which they played really high quality audio on the PC speaker. Their games were things like Countdown, Martian Memorandum etc.
Codebases written by native English speakers are almost exclusively ASCII, but codebases written by speakers of languages other than English frequently have non-ASCII content, even if only in the comments, but languages which support it often wind up with non-ASCII identifiers, too.
I do not believe that emoji like crosses and ticks are particularly common at all, for any language, but LLMs seem to have picked up heavy use of them from somewhere and inserted them into code (and everything else) they generate.
LLM training sets will very likely include the massive corpos of non-English open source code from sites like Gitee, but would be unlikely to generate responses heavily influenced by them unless you've done specific things to make that happen - prompt in Chinese, try to make use of a library only available with Chinese source and/or documentation, perhaps. I've not seen it happen, but I am a light user of LLMs.
CP/M-86 was definitely a thing, but CP/M-386 was not. By the time the 386 existed, DRI had dropped the CP/M name in favour of Concurrent DOS - though they had MS-DOS compatibility in Concurrent CP/M - and, as you say, eventually renamed it to DR-DOS.
Much as I loved DR-DOS, it did have occasional compatibility hiccups.
Also, it was super common practice to just go direct to undocumented internals. You didn't have a clean API to duplicate, you had all the untamed glory of a CPU with no MMU to deal with, and all the programs that did shonky things because they worked.
Can you expand on your understanding of GRIN doing parts of supercompilation? As I understand it, GRIN doesn't do any supercompilation; it's a structural transformation optimiser built for functional languages, analyzing program flow across function calls for the whole program at once.
As I understand supercompilation, it's an extension of partial evaluation - optimisation is done on a graph of possible execution traces. The downsides should be obvious: execution traces rapidly grow massive, compilation resources grow superlinearly, and there are many cases in which the result is worse than the original.
What value would Fuse get from equivalence of terms, do you think?
> Can you expand on your understanding of GRIN doing parts of supercompilation?
GRIN, if I am not mistaken, performs partial evaluation. For example, it constrains, for each eval site, a set of tags and set of heaps allocations an eval site can receive. This is close to a partial evaluation step of a supercompilation. GRIN does not perform unification, though, it is not described in the original thesis, but data flow graph matching would be close to unification, reducing code size.
> The downsides should be obvious: execution traces rapidly grow massive, compilation resources grow superlinearly, and there are many cases in which the result is worse than the original.
This can be constrained. Supercompilation usually gets ran to a fixed point, where no partial evaluation steps can be performed that are not unifiable with previously encountered evaluation steps. But supercompilation can be stopped at any point.
I believe you can read on that in Simon Peyton-Jones works, I am unable to find a link to that paper right now, I have troubles with the internet connection.
EDIT: Note "tag-bags," it rhymes with the tag sets of GRIN.
> What value would Fuse get from equivalence of terms, do you think?
I think that equivalence of terms is an efficient way to verify properties of programs. Myself, I am looking at consensus protocol implementation verification.
It looks like a tidy little functional language - a small, easily grasped syntax surface and generally clear semantics. That you've got it to the point that it can compile and run proper programs is a great achievement for a solo dev project!
The string type in the standard library isn't Unicode-aware, might be worth just noting that. Unicode support can be a big undertaking, but considering whether you'll add it later or not might affect your library design now.
I don't really understand why you have an IO monad. The language isn't pure - `.exec()` means any function can perform IO actions no matter its type signature - so what's IO really for?
Do `impl` additions export? What happens when two libraries add the same function name with different signatures (or just bodies!) to a type's `impl` ?
Is currying automatic? It doesn't seem to be, but, eg, the `sum(x: i32, y: i32)` function theoretically could be called as `sum(5)` to create a closure, but this isn't a documented feature if so.
The website's font is using ligatures, not unicode operator symbols - I'd personally find it much clearer to use a non-ligature font to show what's really there, but that's immaterial to the language.
First of all thanks for all the feedback and looking into it, appreciate it!
Yeah GRIN is a great project, it took a lot of debugging and analysis to make it compile 100% especially with monomorphization involved.
I'll look into Unicode support, makes total sense. Didn't scope it in initially. I can fix the site ligatures too, that's a fair remark.
> I don't really understand why you have an IO monad. The language isn't pure - `.exec()` means any function can perform IO actions no matter its type signature - so what's IO really for?
That's a fair point, I still left a place for `.exec()` to happen as un-handled side-effect. But the preference is with using the IO monad as the stdlib is built around it, with `main() -> IO[i32]` as a type signature. As languages evolves I'm planning to build a runtime around IO execution, and build more constraints for handling strict side-effects. However for this initial stage of the language, I left it as a really simple solution.
> Do `impl` additions export? What happens when two libraries add the same function name with different signatures (or just bodies!) to a type's `impl` ?
For now the language doesn't support modules (libraries), I'm planning on adding it. At the moment it's a bit of undefined behavior, as overloading would occur with latest `impl` definition.
> Is currying automatic? It doesn't seem to be, but, eg, the `sum(x: i32, y: i32)` function theoretically could be called as `sum(5)` to create a closure, but this isn't a documented feature if so.
In the type-system it is automatic, and it successfully passes type checker as it's entirely built on top of lambda calculus. But there's an issue with codegen right now. I can def look into it and document it.
I’d really encourage you with Unicode support, as frustrating as of a side track it may be - I’ve had fun dogfooding my hobby languages by writing small web servers and CLI utilities. Even if it just generates part of your shell prompt!
1. It's not a ban on using social media, it's a requirement for age verification to create an account. This only limits usage on the few platforms that force an account to do anything.
2. The technical controls platforms implement are, unsurprisingly, generally quite weak. Kids are crafty enough to circumvent them, and share how freely.
3. Wannabe-influencer parents just create accounts for their kids, making the circumvention trivial.
4. There are no consequences for using a social media account while under 16.
I think the final point is the main one, though. By design there's no mechanism in place for the government to take any action if a kid gets onto social media, only if a platform fails to implement age checks that satisfy the legislation's criteria. So platforms all implemented tokenistic age checks. Platforms don't care, or need to care, if they get bypassed. The government doesn't care.
If I were a more suspicious man I'd say that either the point was never to reduce the use of social media by kids in the first place, or it was well intentioned but railroaded into toothlessness by lobbyists.