51–60 of 138 posts
A bit of a tangent, but I tried F# recently to make a small gamedev framework. I absolutely adored the language at first. Loved the syntax. loved the type definitions and domain modeling. I felt maybe, this is it, this is the language for me. Never felt that way about a language since the last time I wrote something in Crystal. Then came the part where I needed to work with list of records and realized that something…
Earlier quoted context omitted.
Could you go into a little more detail what task you were trying to solve?
Its been a while, so I might be saying it wrong but, I was trying to create an entity collection. Essentially, a super basic scene graph. on every tick in my update call, i would update something about a specific entity in that collection (maybe position, transform etc). And then in my draw call I would render the entire updated collection. Just getting a specific entity from the list was a huge issue and then updati…
I must be missing something, but this sounds like a pretty straightforward List.map
A bit of a tangent, but I tried F# recently to make a small gamedev framework. I absolutely adored the language at first. Loved the syntax. loved the type definitions and domain modeling. I felt maybe, this is it, this is the language for me. Never felt that way about a language since the last time I wrote something in Crystal. Then came the part where I needed to work with list of records and realized that something…
There are also some libraries out there that make this easier.
I'd say it's an annoyance and should be improved, but it's nowhere near a blocker for us.
"Objects containing the same values should be equal by default." No. This breaks down as soon as you have references to other objects in your objects. If you compare by reference, you probably don't get what you want. If you compare by value, you need to go arbitrarily deep, which is not a sane default, because of possible reference cycles. You need a distinction between objects and value types. C# has that (record t…
> The real world is all about mutable state. At some point, you need to take the training wheels off. Funny enough, I think the opposite is true. For example, if you have a moving point in the real world, there is never a point where only the x coordinate is mutated, yet you have that in your mutating code.
Yet, this is how immutable datastructures often work in practice. That may or may not be a worthy tradeoff, but please do not act like it is the right way to do things by default.
The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects containing the same values should be equal by default. 3. Comparing objects of different types is a compile-time error. 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. 5. Once created, objects and collections must be immu…
So this language would not be general purpose, as it would not be suitable for high-performance computing.
Large scale simulations almost always involve arrays that are modified in place. Being able to somehow declare a collection to be immutable would be highly useful, but not having the option of mutable collections limits the kinds of problems that can be approached with the language.
> I don’t care what my language will let me do, I care more about what my language won’t let me do. I think this is the best summary of the article. In short, please protect me from my own stupidity and/or laziness.
Alan Kay referred to this as the "Wirth school of non-programming". It obviously has some merit, but I'd rather have a language be an enabler rather than a disabler. And again, not having to worry about messing up is or at least can be a kind of enabler, but I prefer a more positive approach, with good defaults encouraging me to do the good and simple, but the language getting out of my way for things it might not kn…
IMO, the current zeitgeist seems to be a knee-jerk reaction to a prior idea: "everyone can program (e.g. previous zeitgeist)...but, we need guard rails in tools! Put as many guard rails as we can into tools!" Thus, you have languages prescribing architecture (Elm), web frameworks imposing naming conventions (Rails), etc. At least Rust's limitations help with reasoning, vs seeming capricious.
I'm preaching to the choir here (parent), but Obj-C remains the most interesting language I've seen in a long while: dynamic runtime with a static type-checking for a great majority of code, along with very good performance.
The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects containing the same values should be equal by default. 3. Comparing objects of different types is a compile-time error. 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. 5. Once created, objects and collections must be immu…
5. Once created, objects and collections must be immutable. So this language would not be general purpose, as it would not be suitable for high-performance computing. Large scale simulations almost always involve arrays that are modified in place. Being able to somehow declare a collection to be immutable would be highly useful, but not having the option of mutable collections limits the kinds of problems that can be…
The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects containing the same values should be equal by default. 3. Comparing objects of different types is a compile-time error. 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. 5. Once created, objects and collections must be immu…
5. Once created, objects and collections must be immutable. So this language would not be general purpose, as it would not be suitable for high-performance computing. Large scale simulations almost always involve arrays that are modified in place. Being able to somehow declare a collection to be immutable would be highly useful, but not having the option of mutable collections limits the kinds of problems that can be…
I strongly disagree with this. I’d take it one step further and say that there should be no equality operator or default equals function for non-primitive data types. Some specific type of records/tuples could use a default equality, but it should be opt-in or follow from using metadata like an attribute (e.g Rust derive) or only for those specific types (e.g C# ValueTuple) . Not even strings should have a default equality (ie it shouldn’t be possible to create a map/dictionary with string keys without explicitly also saying how keys are compared. That’s right: It shouldn’t even be an optional argument so the default string equality/hash is used unless specified. It should be explicitly passed. This isn’t “boilerplate” it’s avoiding subtle bugs.
As for the rest of the arguments, some are downright crazy. You cannot program without mutation in the general case. You simply don’t always have the performance/power budget for it. Obviously mutation should be avoided, but dogmatically using all-immutable data is just not possible.
No automatic casts would be high on my list too. I don’t ever want to accidentally treat things like “falsy” or convert between types based on usage. I’d rather litter my programs with type names and explicit conversions.