About 2 weeks ago i made a discussions about sockets ( http://twolivesleft.com/Codea/Talk/discussion/3184/well-sockets-ever-be-a-reality/p1 )
But it just got forgotten like all the other discussions about sockets, i would like a straight answer to this question. Will sockets be implemented again in the (near) future?
I don’t know the rules as they stand but making two threads for one question is asking for clutter, its best to keep it refined to one thread. Anyway I think the main reason you haven’t been answered yet is because Simeon and the other(s) are busy working on a decently sized update for codea so I doubt they will be planning for future releases just yet. It has been talked about by Simeon himself and may be implemented in the future, that’s how it stands for now, anyone else correct me if I’m wrong.
Let’s see… A new asset manager with sounds, new implementation or SFXR, etc. I think that’s a big enough update. Not to mention the other features they didn’t list. That’s long enough.
I doubt very very much that it’s forgotten or ignored. TLL has been reluctant, in the past, to speculate too much in public about upcoming features, because it’s all too common for them to have to change, delay, or even cancel them - and having people wondering about what’s coming is a lot better than having them disappointed. One thing to keep in mind is that whatever features they add, they have to be approved in the end by Apple - and general-purpose sockets have been forbidden in the past. It’s an open question as to if they’re still forbidden - I want to say they’re in pythonista (I should double-check).
Point being - not forgotten, not ignored - and don’t expect an “official” answer, in large part because they probably don’t have anything official to say right now. They know sockets are desired, there are implementation issues along with possible apple approval issues, and there are other features they may be implementing first.
I can say this with some assurance - because I’ve hounded them for sockets in the past, and this was the basic response. And - they’ve never disappointed with what they eventually do get up, so I’m not going to second-guess their decisions again…
@Bortels - Simeon did mention earlier that he would look into it again now that there and many, many other apps that use sockets now. He also said that if he was going to include them again, he’d probably redesign the API, so I think that they may include then again.
I am really glad for these long responses, this has gotten my hopes up again! Thank you very much!
Just follow twitter account @CodeaCommits to know what is currently being cooked on TLL kitchen. They seem to be making something called Asset Manager which is cool. If what you want has nothing to do with what currently being coded, just be patient. Keep asking.
Though somehow I wonder… TLL seems to be more likely to provide game-related features than other things. Some kind of got higher priority. Some non-game-related requested features seem to get delayed for uncertain time (so one may felt being ignored). For example, my request for more basic shapes API (triangle, poligon, roundrect, etc), gesture detection API, arbitrary fill function, sound generation by notation (using C1, D1, C1#, etc instead of using SFXR), etc seem to get little to no attention, though I’ve asked for them since the beginning days of Codea (formerly Codify).
So, just ask, be patient, and keep your fingers crossed. Good luck! 
@Bee - you could use ABCMusic.lua to get notation based sounds.
@aciolino: You know what… I already can do all that using custom code/class, some are made by the people of this great community. But that’s not the way I want. I want them to be simple and ready to use functions just like any other built-in functions in Codea. Why is that? Because I need those not for me but for my kids. I got 4 and 6 y.o kids that I like to teach them basic programming. They already know how to read and write, and some basic english. They’re very excited when they could make a circle on the screen using a single simple command. But then got demotivated when they couldn’t make a star. Using custom class is too complicated for them and they wonder why it’s not as easy as circle to draw a star.
@Bee, make a star class for them, and have them add a dependency. Lots of real-world code works that way - someone else writes the hard stuff and you hand it down to the others.
I think there are a few basic geometric shape apps somewhere on this board - stick’em into a project and have your kids use the dependency.
It’ll be more fun when they try to do a simple game.
@aciolino: I did. And they didn’t like it. They asked, why do we need to do it differently? This Codea thing is stupid, they said. These are kids. Their mind work in a simple way, yet elegant. If you want to know the beauty of simplicity, ask some kids. That’s what I learned from them.
Even when I taught them how to detect touch, they didn’t like the way we do it with touch began, moving, and ended. They said, I don’t care when the touch began or ended, why can’t we just know that a thing (a circle, star, or any objects on the screen) is being tapped. That’s what matters right? That’s why I asked for gesture detection API.
Now, they don’t use Codea anymore. They don’t like the inconsistency. Instead I gave them some games that could lead the way to programmatical thinking without doing real programming. CargoBot is one of them. And they like them more than Codea. But I still wish @simeon or someone else in TLL would provide the features I have asked above. I believe some of them aren’t too difficult to implement, they just need higher priority. Then I would teach my kids programming using Codea again.
Hold on while I get up from my rocker and wave my cane: “Kids today are spoiled!”
Heh - no, but really. I honestly believe that way back when, we learned to program (well, I did) to make games, because we otherwise didn’t have any (or many).
But - that’s not why I was responding; “basic shapes” reminds me - I know that I wrote a set of polygon primitives way back in the day for Codea, or Codify at the time. Hold on… it was in a thread…
Aw. So - here’s the thread: http://twolivesleft.com/Codea/Talk/discussion/312/pic-v3-december-14-2011-flood-fill-added#Item_28
But the code isn’t there; at the time, we could share .codea files, and the common thing to do was post them to a service called “posterous” - that’s apparently dead. Fun to look at the old threads, though. You can see my k-rad state of the art (including a nice hexagon) here: https://twitter.com/bortels/status/146358741888024578/photo/1
(Hmm - apparently twitter acquired all of the posterous guys, then killed the service. BAD TWITTER. NO COOKIE.) W00t, It’s left a niche for… uh… whatever it is they did. (As I recall, you could post a blog via email? it’s been so long…)
Let me see - ok, regular polygons is easy; for an N-sided regular polygon, divide 2*pi into N equal portions, and use sin/cos to compute their locations on a circle - then connect the points. Filled polys was a lot harder back then, but you could do it (filled and unfilled, actually) with a mesh today pretty easily. Rounded rects are easy too - 4 circles in the corners, then two overlapping rectangles to fill it in.
I think/hope that TLL is working on things we can’t easily do for ourselves - like poly drawing - in favor of things we can’t do (editor changes, import/export/utility, and new language features).
@bortels: You don’t get my point. Yes, kids today are spoiled. Guess what… because we spoil them. When we were kids, computer is a big machine sits on a desktop with very limited capability. It’s hard to make them to do something complicated. Some computers today can fit in our kid’s pocket with much more capability than computers on our age. And you expect them to treat the computer like the way we used to? These kids live on different age and they interact with computers differently too. Let go the memory of stupid and slow machine. We live on 21st century now.
I did too make some games myself. I remember using gw-basic to make some simple games and animation. Then I moved to Turbo Pascal and made some more complicated games with it. But that was about 20 years ago. Now, even myself curse some IDEs that unable to do some functions easily or automatically. There are things that we should do ourselves, but there are also other things that should be done for us automatically or easily. After all, computers are made to serve us. Not the other way around. No?
IMHO, the features I’ve been asking should be provided built-in. Heck, @simeon made us tween library to ease us with animation. Then why basic shapes, gesture library, notation music, etc seem so hard to give?
Hey! O’pa Bortels is back! I love your reactionnary comments. Lol!
@Bee - I don’t expect them to do it like we did - but I want to encourage them to learn to look at things at a low level, and how you put that together to make higher level behaviors, or they’ll be users instead of makers.
As you say (and I agree) - “There are things that we should do ourselves” - and I’d say learning an API, at whatever level, is that. No matter what level of functionality TLL provides, you could always say “but why didn’t you provide this as well”. Fact is, at some point you have to call it 1.0 and ship.
If they expect to be able to flail themselves at a computer and say “just do what I want” - they’re in for a rude surprise. Never been that way, and I suspect never will be. As capabilities grow, so do expectations.
This may be a bias on my part - I don’t see Codea as a graphics tool; I see it as a game, that fools you into learning how to program. I honestly think learning to program is best done early, and without real intent - you need to fall into it accidentally (I did, by typing in games from magazines, and then having to find and troubleshoot my inevitable typos). So - not having everything handed to you on a platter is a feature, not necessarily a gap. It’s not meant to be easy - just fun.
@jmv38 - I calls em as I sees em, don’t expect everyone (anyone, sometimes!) to agree. I’ve been NUTTY busy at work, so I haven’t been able to spend as much time puttering around with Codea as I’d like recently, but I try to at least skim the forums, and the sockets topic is near and dear to my heart (and, secretly, I keep hoping Simeon and the guys will say “Dammit, he’s on about sockets again - maybe we should add UDP just to shut him up”. Won’t work - but it’s a fun dream).
Ok, I give up. What’s “O’pa”? Closest I got googling is “Hooray” in Greek, but generally nobody shouts “Hooray” when I show up.
@bortels: Looking at low level isn’t the mainstream for today programmers. Most programmers today are just another level of computer users. They’re highly dependent on high level tools (IDE, frameworks, versioning, etc) to create programs. Almost similar to music makers, film makers, or other creative makers. They’re more on the creative side rather than on the (low) technical side. Yet, they still programmers, just not like the way we used to on our age. Just look at the young programmers today. They’re hardly able to write a simple program without an IDE.
If you’re focus on the “there are things that we should do ourselves” you would say that (learning API). Let’s flip the coin, look at the “there are things that should be done for us” side. I would say, why the API is still incomplete? Where are the other functions? Where is the progress for better and more complete API? Ok, these features might be enough to ship as v1.0, but why is it still the same for v1.5?
As I said, it just a matter of priority. The features I’ve been requesting are not on TLL priority list. Ok, maybe they’re on the list but they’re on the very bottom part.
I am a very happy and satisfied user of Codea. What Codea provided are more than enough for me, even too much (I don’t need the 3D things but I’m glad to know it’s there). But that’s not the case for my kids.
@Bortels O’pa is a shortcut for ‘grand-father’ , if my english is correct, and if not, this what meant. It is supposed to be affectuous.
@bee - I think you have a fairly narrow view of the programming community. There’s a ton of people who program assembly, even today - embedded controllers are showing up in everything, and you don’t (generally) code those in java (but Lua may be reasonable in some cases!). If speed is an issue, you also end up bailing to a lower level as a common solution. Yes - more capable processors are becoming available, but they’re more expensive; in the real world, manufacturers save money by buying minimal hardware, and the people writing code for it have to adapt.
The young programmers today who “are hardly able to write a simple program without an IDE” are going to have a hard time getting a job. I know - they do exist, and they interview with us, usually for Java positions, and they lose out every time to people who are more well-rounded. The good ones can and do work at a lower level. I’d add that I know of no professional musician who can’t play a real, traditional instrument (and a lot of them play many); I think a broad knowledge of your craft is vital for real success (barring luck or nepotism).
When I was in grade school - we weren’t allowed to use a calculator, because they wanted to make sure we knew how to do the math - not how to work a calculator. Later on, when things got more complex, we were allowed to use calculators as a tool - not a crutch. Someone who wants to program - especially well enough to consider it as a job - needs to use an IDE as a tool - not a crutch - or they’re handicapping themselves in the long run.
@jmv38 - I’m ok with grandfather. I’m old enough. But - it’s not English that I’ve ever heard of, and I’m a native speaker (American English). If you aren’t, that’s a surprise to me - your English is at least good enough that I never suspected it might not be your native language.
@bortels: Well, I’d like to continue our discussion. But as it’s getting irrelevant to the topic of this thread, I think we should stop it. I doubt other people would get anything useful from our discussion anyway. Thank you. It’s nice to have discussion with you.
Oh, btw… maybe some of you might intested to this GamePress app. 
Holy moly - yes, that’s awesome. I want to say I saw a very very preliminary version of it a long time ago, and thought that’s what turned into Codify originally. I’m glad to see it’s out - I missed any sort of announcement. Grabbing it now.
We may be talking past each other. Programming is one way to make a game - a construction kit like this is another. If the goal is to make a game - this will do the job (assuming the game you want to make fits the template). If the goal is to learn something useful for the real world… I’d say this is marginal? Dunno, maybe not - I spent hours and hours with “Adventure Construction Set” on my Atari as a teen, and it must have helped somewhat with the mental constructs necessary to write software (breaking down a big thing into smaller parts, etc).
Either way - good spot on GamePress. Free, too, which is surprising. And - I don’t see any IAP either. I wonder what the deal is (if any).