if you weren’t open to argument, I wouldn’t be wasting my time
Things to consider:
“Those games require a server” - so does http. If you aren’t concerned about providing a webserver (and you shouldn’t be) - you shouldn’t worry about it for sockets either. One of the things I was considering using redis for was matchmaking, because there’s no good way (yet) to say “please type the IP of the person you want to connect to”. If you want to add zeroconf/Bonjour (which is probably already there, somewhere, you’d just need to expose it) that’d be cool.
“8 large files to interpret each time your project runs” - until they take a measurable amount of time, that’s premature optimization. I push play on an empty project, boom it goes - so that burden isn’t something to worry about IMHO. If the situation changes, deal with it then. Frankly - most of my startup time, demonstrably, is doing things like building images; the way to make that faster is to give us real access to new spritepacks and binary storage. Besides - to provde http, you’re going to have to interpret and load the socket layer underneath it anyway - closing off access to the API won’t speed anything up.
“they add to autocomplete and documentation” - the API isn’t that expansive for autocomplete. As for docs - you don’t document the vast majority of the Lua language, nor should you be expected to (I was surprised to find strings there). I’m very comfortable with the in-program documentation covering only Codea-Specific things - by definition, everyone using Codea has a really nice web browser and can go look at the Lua docs, including docs on Sockets and the higher level APIs dependent on them. “Sockets are an advanced topic for advanced users - documentation is available here” with a link to the luasockets page is plenty good.
“They are large and complex” - granted - “very few users will want to use them” - I’m not sure about that. I see quite a few people asking for them (or more generally, for connectivity) on the forum (that and text), and I suspect there are more lurking.
As for exposing low level drawing functions as an analogy - consider it! So long as you aren’t preventing use of the high level ones, I see little harm in it.
I see your userbase, especially your early adopters, as “tinkerers”, and educators, and learners, and indeed players. We all, to a greater or lesser extent, don’t mind diving in a bit and getting our hands dirty, or we’d not have bought the app - people who aren’t interested in this are playing Angry Birds. Indeed - a lot of the really new users are using it as an opportunity to learn how to code; I wouldn’t underestimate what they will want to do, or what they can eventually understand. I can see a reasonable concern about newbies getting confused - but frankly, that’s what newbies do, get confused; if they don’t get confused about sockets, they’ll never learn about them, and that’s not desirable either (knowing how things work is powerful juju).
I’ve said it before, it bears repeating: Codea is my favorite meta-game. It’s cool worrying about making sure the early levels are easy enough for beginners - but there has to be lots of depth for the more advanced players to be kept occupied.
This wondermark comic is very relevant (and hanging on my wall): http://wondermark.com/tink8/ - The insides of things (including code!) are beautiful - let’s see what they look like.