tinypy2 musings
So, my mind has been poking away at the idea of making a “tinypy2” that would be a bit less like python, so probably even more confusing for end users. Being only one sentence into my proposal here, and it already sounds bad. Well, here goes:
-1 All objects would be assigned and passed by value instead of by reference
=0 There would be a dictionary of global variables
+1 The VM state could be saved to readable JSON
+1 The VM state could be loaded from JSON
=0 The VM would be written in C++
+1 The VM would have super-easy interoperability with C++ code
-1 The VM would be on the slow side
Tallying up the pros and cons, we get to a +1 for this idea. I don’t suppose there’s much way for anyone to comment on if this sounds like a good idea or not, but thos are some of the thoughts going around in my head right now. It seems like it would be an interesting rudimentary scripting language. The load / save of VM state and C++ interoperability are the key points.
#badideas ??
-Phil
June 2nd, 2011 at 9:15 pm
Sounds interesting (especially the state saving). What are the potential applications of this you’ve thought of?
June 2nd, 2011 at 9:47 pm
I doubt you can get super-easy interoperability with C++. C is no problem. (Try using ctypes against C++ DLL to see the problem.)
You also haven’t stated why you picked a VM over compilation (LLVM lets you do that fairly easily).
But the biggest elephant in the room is the standard library. Where are you going to get the code from that knows how to do diverse things like file and network I/O, database, compression, logging, audio, package installation, multi-threading and multi-processes etc. Remember that approximately 0% of existing C++ (or Python) library code has been written to be state saved and loadable.
My suggestion is that you work backwards – work out what you want the language’s sweet spot to be and work on the standard library which will then get you the language you want (and a lot of work).
There was also a reddit discussion http://www.reddit.com/r/Python/comments/hms4z/ask_pyreddit_if_you_were_making_your_own/
June 3rd, 2011 at 4:45 am
You need think far more carefully about the way you score your pros and cons. Only having value types is more like ‘-100’ and not a mere ‘-1’. You’ve just said that all types must be either immutable, a primitive type, or able to be copied at will. This makes all I/O either very difficult or outright impossible. Even Haskell has monads after all, and Python has pointer semantics for all variables for a reason.
I’m not exactly sure what saving the VM state to JSON gains you other than a lot of wasted space on disk. It won’t make interpreting the data any easier.
June 3rd, 2011 at 6:33 am
The only thing missing from this proposal is “why”. This could be a most excellent idea, or utter folly, depending on what the point is. For writing games? Mobile devices? Learning language design? I guess “VM is slow” would eliminate “better performance” from the possible set of reasons…
June 3rd, 2011 at 9:01 am
-1, not Coffeescript 🙂
At this point I find it hard for any new mini or full bytecode VM to be more compelling that Javascript. Granted, Node isn’t all that portable at the moment, but it sounds like the next release will make Windows a viable option?
It’s worth considering before starting in a new direction.
June 3rd, 2011 at 9:53 am
Thanks everyone for the feedback on all this. I think blogging about it and getting some response really helps me process some ideas.
It’s hard to say for sure, but I have a feeling that this idea isn’t really the most practical. The main application would be to offer “scripting support” to games I write. For wide acceptance I really need to use a language that people know and is documented 🙂 So python / lua / javascript would really be the best answer.
On the other hand, I’ve had fun toying with these sorts of mini-scripting engine projects .. while amassing some enormous headaches trying to get things to work nicely! (I think that’s a +1 -1 = 0 😉
-Phil