Raylib is definitely a pretty fun and simple library. I used it with OCaml (which has bindings to it already) before.
One thing I like about the Functional Core, Imperative Shell architecture is that, if you gather input into an immutable record before sending it to your update function, then your handling of input becomes independent of the windowing/control library you use.
That would make it easier to switch to SDL or GLFW if you later want to since you only need to rewrite a minimal amount of code which converts the windowing library's inputs to your own record type. (Although it's not easy to abstract over drawing operations that way.)
If you'd like any help, I'm happy for you to shoot me an email (my email is in the repository's LICENSE file). Although there's still a lot I could learn more about too.
Cheers - I may email once I get into it. The (disclaimer'd) MacOS build actually segfaults on startup but I'll probably be able to work out what's happening there :)
Talking of Raylib, from the fooling around I've done so far, it's actually a very awkward library to use with MLton. Because many of its functions take C structs by-value and that isn't something the FFI supports, a lot of shim C code needs to be written/generated.
Is the "no JIT' policy somehow baked into the hardware/software of iOS devices, instead of something Apple finds by doing an app review?
I thought it was the latter (that running a JIT on iOS would be possible but not accepted on the app store), but then I'm left wondering why they seem to have submitted a JIT-less version on a third party app store.
Maybe the intent was ease development by having only one version to support for the first-party and also third-party app stores.
IIRC it's part of the sandbox apps run in, which, in turn, makes use of the hardware memory protection. To do JIT, you need to first write your dynamically generated code into the memory, and then execute it. The memory you obtain via e.g. malloc() doesn't allow execution, only reading and writing (this is controlled by permission flags, in the page table, on the memory pages your app is given by the kernel). To obtain memory that is both writable and executable, you call mmap() specifying corresponding flags. The kernel just refuses to allocate such memory for your app because it doesn't have necessary permissions, or "entitlements" in Apple speak.
I prefer to build result-passing, no-exception-throwing systems out of an exception-throwing core where the language itself may throw exceptions but the thing I build from the language always returns result.
Elm is an extreme case where indexing into an array returns a result type instead of an exception when the index is out of bounds, unlike most languages including Haskell.
Maybe my program logic is intended to always access only valid indices in an array, but here I'm given a result type where I have nothing to do in the error case since my code is never intended to reach that case. I would rather let the language throw an out-of-bounds exception here to tell me that my implementation is incorrect while I'm testing.
Same with libraries in a language. It really depends on the use cases of the library you're writing whether results or exceptions are better. The most convenient thing for the user of a library would be to provide both exception-throwing and result-passing alternatives. This is what the OCaml standard library does as well.
Stack Overflow is a community with an answer-rating system and there is often some level of review from other people commenting on the answer's advantages and shortcomings. You often have multiple answers to choose from too. Those features build trust in an answer or prompt you to look elsewhere.
The UI for an LLM answer would have difficulty replicating the same thing since every answer is (probably) a new one and you have no input from other people about this answer too.
Edit: After writing my reply, I saw that roughly four other people (so far) made the exact same point and posted it a couple of minutes before. I think your question is a good one (made me think a little) and apologies it feels like you're being piled on.
I've never been that fond of SO, but I find chatgpt very useful. SO tends to be simpler one time questions. My interactions with gpt are conversations working towards a solution.
LLMs totally have a beginner problem. It's much like the problem where a beginner knows they need to look something up but can't figure out the right keywords to search for.
Also chatgpt has never called me an idiot for asking a stupid question, having not read the question properly, and making the assumption it was the same as an existing question after skimming it. I wouldn't ask SO a question these days, the response is more likely to be toxic than helpful.
Standard ML is pretty simple and easy to pick up, but a weak point is the lack of { record with updatedValue } syntax to create a new record which is the same as an existing one but with some value changed. You have to specify every field in the record which can be a pain depending on how large your record is.
Standard ML has some nice features though and I think what I mentioned is the only serious shortcoming (except for ecosystem if that's important to you).
Standard ML is also structurally (but strongly) typed, unlike F# and the vast majority of nominally typed languages, which is rare but nice.
type person = { age : int, name : string }
is the same as the type
type animal = { age : int, name = string }
but this hasn't been an issue foe me, and structural typing means you can avoid defining the type at all which is convenient for small records.
For example, a function to increment age has no need for you to define the type.
fun grow { name, age } = { name = name, age = age + 1 }
I think Standard ML helps you understand the origin of some common FP idioms. Like tuples are really just records and SML treats them as such. The empty record {} is the same as the empty tuple (): both are the unit type. And a record like { 1 : "a", 2 : "b" } is exactly the same as the tuple ("a", "b").
Which in turn compiles itself into Javascript, such that you can run the SMLtoJS compiler in the browser, e.g. it should be possible to make it accept <script> tags with SML code.
B+ Trees (which store data at leaves) rather than B-Trees are what you want for good iteration performance usually.
An ordered B-Tree iteration would jump between different arrays in the tree often, but a B+ Tree would only have you jump to another array once you’re done iterating over all the elements in the current array.
I don't think you need to infer that Apple believes they own every device.
You don't need to infer anything, really. You just need to observe that every corporation will engage in rent-seeking behavior whenever they're in a position to get away with it.
Apple is far from the first mobile device maker to try to make it difficult or impossible to install software through alternative channels. That practice has been in place since before the invention of the smartphone. Google likely would have done the same thing with Android, had it not been far more profitable for them to take a different tactic. Heck, in the USA, back in the analog landline phone era, the Bell system famously did functionally the same thing until regulators stepped in.
On that note, I'm annoyed that Apple does it, but I'm even more annoyed that, in the USA, we are absolutely toothless about regulation because we can't shake the pollyannaish belief that we should be able to expect corporations to play nice purely out of the goodness of their nonexistent hearts.
> Google likely would have done the same thing with Android, had it not been far more profitable for them to take a different tactic.
I don't think that's fair. You have to consider the culture at Google and pre-Google Android. It might be the case, but at the time it felt like a very natural way for them to go.
> On that note, I'm annoyed that Apple does it, but I'm even more annoyed that, in the USA, we are absolutely toothless about regulation because we can't shake the pollyannaish belief that we should be able to expect corporations to play nice purely out of the goodness of their nonexistent hearts.
Agreed, though I think this is a cultural problem more than a regulatory problem. We humans are suckers for good marketing, as Apple has masterfully demonstrated over the years. Some of their real life PR/marketing lines are indistinguishable from parody, yet people's faith and trust in Apple is at or near a religious level of devotion. They love the products and they desperately want to believe in the goodness of the creator.
Unless/until we figure out how to pull the curtain back so people see through the spin, they will stay powerful. Once we do that, the regulation will follow naturally.
I've used to excuse such behaviors, saying that Apple has better integration between their products, cares about UI design more than anybody else, or that such integrations are new and don't have proper APIs yet.
However, years have passed, and Apple has been systematically giving preferential treatment to their apps and services, while dragging their feet on APIs for 3rd parties.
They keep using genuinely useful aspects of the App Store as a shield for anti-competitive abuse and petty rules (only in Apple's imagination allowing apps to mention other platforms is the same thing as allowing malware).
They've been spreading FUD and presenting false dichotomies that it's either exactly Apple's way, or chaos and malware. Instead of creating safe and efficient APIs for 3rd party browser engines, they chose not to have competition for Safari instead. Instead of creating APIs for easy centralized subscription management, they conveniently kept it exclusive to their own subscriptions, with pricing that can only be sustained in a duopoly.
Apple had plenty of time, and lots of chances to ease off their worst anti-competitive behaviors to keep regulators away, but instead they've doubled down on owning the platform and their users, and are now throwing tamper tantrums and malicious compliance.
I appreciate the more thoughtful comment! I agree with some of it, and disagree with some of it -- which isn't possible when you try and boil it down into a one-liner.
There are literally thousands upon thousands of comments debating both topics ("owning" an apple device & app store stuff) on HN alone. Let alone everywhere else from reddit to governments.
If it was so simply one-sided, there wouldn't be such lively debate.
I don't think we need to rehash those thousands of comments to agree that the debate can't be settled in a single blanket statement?
I don't really have the same impression that you have had when it comes to discussions about Apple's approach to HN.
This linked comment (which I randomly found on HN's search) summarises what I've seen here:
"The way these discussions usually go is that a bunch of Apple users complain about the restrictions, a bunch of Apple users say they like them, and a few Android users like myself remind the complainers that there are, in fact, other options that don't involve forcing Apple to take away the rules that most iOS users appreciate having."
I do recall a few users opposing allowing alternative app stores (which is the debate that is freshest in my mind) because they prefer to stick to Apple's, and the common rejoinder from the community that nothing is being taken away from those who prefer to stick to Apple's store but that other users who want something different have more choice.
I'm still curious about what additional nuance you have in mind, since I honestly can't remember seeing it.
You cannot summarize thousands of comments (there's nearly 4000 comments between [1] and [2] alone) in sentence or two and pretend like it is representative of the entire debate and everyone's opinion.
Even so, your quote and further commentary proves there is more nuance to be had -- some Apple users are complaining, some Apple users are defending, others are suggesting compromise! The nuance can be found when you examine how those separate groups of people came to their opposing opinions. To say there is no nuance, yet give an example of a more nuanced argument is almost funny.
While I have absolutely no interest in debating it, the example that first came to my mind regarding the "Apple thinks they own every device" comment was the nuanced debate around security, especially in relation to the target market of the devices.
Thanks; I didn't see that debate on security and I can see it being a valid point, especially with the burden of a technically-inclined person having to fix others' (family/friends) devices.
I was trying to point to the opinion of the majority that I've seen and what I have seen from most of the community when security is mentioned is that Apple needs stronger security from a technical standpoint rather than controlling what and what is allowed on users' devices. I think both opinions hold validity, and you may be right that there is more nuance.
VS Code is known to use a Piece Tree (Piece Table represented as a balanced binary tree) and I thought AbiWord (which this article also mentions) was the first to use the data structure. This article points out that the Tweak editor and the MText interface in the Modula-3 programming language uses the same approach, meaning this variant of the data structure goes back even further than I knew.
I thought to myself a rename to FACT Prover (Formerly known As Coq Theorem Prover) would be nice when seeing they wanted to rename the project and it's a bit of a disappointment that didn't quite pan out.
Rocq is similar to the Roc programming language which is confusing naming (and they sound identical as far as I know).
One thing I like about the Functional Core, Imperative Shell architecture is that, if you gather input into an immutable record before sending it to your update function, then your handling of input becomes independent of the windowing/control library you use.
That would make it easier to switch to SDL or GLFW if you later want to since you only need to rewrite a minimal amount of code which converts the windowing library's inputs to your own record type. (Although it's not easy to abstract over drawing operations that way.)
If you'd like any help, I'm happy for you to shoot me an email (my email is in the repository's LICENSE file). Although there's still a lot I could learn more about too.