mleku on Nostr: Move is actually quite an interesting language... for a database scripting system... ...
Move is actually quite an interesting language... for a database scripting system...
i think that its semantics could definitely be more concisely expressed in a syntax more like #golang but there is a lot of things in it that it deliberately makes explicit whereas in Go they are implied... like, the `interface{}` implicitly can be nil, and that is a different nil to the nil of a specific type...
in static typed languages in fact all variables are two-fold values, there is the type indentifier, and the value... and the value can be a type of pointer, as you see with slices and maps
dynamic typed languages also maintain this but they basically hide the type handling part in the syntax, which is why it is a Bad Thing ™️ - and very often reflection is left out or hard to use and ugly in dynamically typed languages, and at the best of times reflection is nasty, this is why a language tends to select a set of essential aspects of types being exposed to built in functions
i'm probably going to have a low key small bit of fun figuring out how to do useful things in this language, there are two tasks that are on the table for me, one is maintaining a port that uses a different framework, and i've now got a basic run over both but i won't be able to really fully absorb it until i see it in action and get to understand the differences in how to do the same thing in each framework
the other task will be building a middleware that acts like a cache/protocol translator enabling users to transparently use identities from different database systems (*cough* blockchains) and access data that may be on other databases, seamlessly to the user
well, i am getting paid to learn, in a big part of it at the beginning, that's fine, i appreciate what the designers of this language have set out to achieve and it's very interesting, definitely one of the better systems for managing a collection of users and attached data (aka "assets") and our project is for a game collaboration system, ie, chat and matchmaking, but it seems to me like this language would be also quite well suited in general to creating full blown simulations, like my favourite game Kingdom Two Crowns, and the old Settlers and Populous games also would be fitting use cases for this kind of hard ownership protection based language constructs
for sure it is going to feed into my growing and improving understanding of how to design programming languages, and contrasting it with the design of Go is quite interesting... like, i can kinda see some sense in certain aspects of it, especially the notion of scope of ownership of a piece of memory, this is really intensively micromanaged in Rust and they have loosened it a little in Move by dramatically simplifying what you can actually store (which is, not that many things actually) but the idea of capabilities, as it is in Move there is "key", "copy", "drop" and "store"... this extra attribute of a type has quite some interesting possibilities for ensuring that memory does not get stuck in a limbo where it's allocated but no threads are anymore owning it, which means the GC can then delete it and reuse the memory
but on the other hand, why it's a bit complicated is that if data is on the stack, it is implicitly in scope when being used, and dropped when you return, all that is required is to pop the stack to the point where the return address is stored... but if it has to get allocated on the heap... this breaks the model because the heap is a kind of background process (garbage collector/memory allocator) owned part and this is where you then would need to automatically track its scoping and thus the garbage collection mark/sweep process
anyway... time to play some games for a bit and probably actually start to try and apply what i've learned
i think that its semantics could definitely be more concisely expressed in a syntax more like #golang but there is a lot of things in it that it deliberately makes explicit whereas in Go they are implied... like, the `interface{}` implicitly can be nil, and that is a different nil to the nil of a specific type...
in static typed languages in fact all variables are two-fold values, there is the type indentifier, and the value... and the value can be a type of pointer, as you see with slices and maps
dynamic typed languages also maintain this but they basically hide the type handling part in the syntax, which is why it is a Bad Thing ™️ - and very often reflection is left out or hard to use and ugly in dynamically typed languages, and at the best of times reflection is nasty, this is why a language tends to select a set of essential aspects of types being exposed to built in functions
i'm probably going to have a low key small bit of fun figuring out how to do useful things in this language, there are two tasks that are on the table for me, one is maintaining a port that uses a different framework, and i've now got a basic run over both but i won't be able to really fully absorb it until i see it in action and get to understand the differences in how to do the same thing in each framework
the other task will be building a middleware that acts like a cache/protocol translator enabling users to transparently use identities from different database systems (*cough* blockchains) and access data that may be on other databases, seamlessly to the user
well, i am getting paid to learn, in a big part of it at the beginning, that's fine, i appreciate what the designers of this language have set out to achieve and it's very interesting, definitely one of the better systems for managing a collection of users and attached data (aka "assets") and our project is for a game collaboration system, ie, chat and matchmaking, but it seems to me like this language would be also quite well suited in general to creating full blown simulations, like my favourite game Kingdom Two Crowns, and the old Settlers and Populous games also would be fitting use cases for this kind of hard ownership protection based language constructs
for sure it is going to feed into my growing and improving understanding of how to design programming languages, and contrasting it with the design of Go is quite interesting... like, i can kinda see some sense in certain aspects of it, especially the notion of scope of ownership of a piece of memory, this is really intensively micromanaged in Rust and they have loosened it a little in Move by dramatically simplifying what you can actually store (which is, not that many things actually) but the idea of capabilities, as it is in Move there is "key", "copy", "drop" and "store"... this extra attribute of a type has quite some interesting possibilities for ensuring that memory does not get stuck in a limbo where it's allocated but no threads are anymore owning it, which means the GC can then delete it and reuse the memory
but on the other hand, why it's a bit complicated is that if data is on the stack, it is implicitly in scope when being used, and dropped when you return, all that is required is to pop the stack to the point where the return address is stored... but if it has to get allocated on the heap... this breaks the model because the heap is a kind of background process (garbage collector/memory allocator) owned part and this is where you then would need to automatically track its scoping and thus the garbage collection mark/sweep process
anyway... time to play some games for a bit and probably actually start to try and apply what i've learned