My bet would be on a version of xCode for iPad being released at WWDC 2017.
This seems like a perfect way to get some wide testing of the compiler, coding keyboard, etc. I wonder what IDE enhancements we can expect from a touch interface.
> Are there any good development options for the iPad today...
Yes, there are.
> ...that aren't excruciating to use?
Oh. No, not really. Pythonista is the closest I've seen to an non-excruciating IDE on the iPad, but that's Python only. Link: http://omz-software.com/pythonista/
Before Swift Playgrounds launches to the general public, Hopscotch and ScratchJr are still two of the best apps for children to explore learning to code on the iPad.
In addition to the the ones mentioned above, my 7 year old enjoys codecombat on the PC (or Chromebook which a lot of elementary schools use these days):
I think it makes for a cute demo but misses the mark - what's desperately needed are better developer tools - not another 'how to become a programmer in 30 days'.
There's enough beginner material - the stumbling block is the reality programmers are living in.
I've lamented in the past (here even, maybe) that the first computing devices many people get are primarily designed around consumption. Some types of content creation (particularly visual and audio, more limited textual), are very well enabled by these tablet interfaces, but that's not been the primary focus.
But programming them has long been difficult and required an external device. Many of my peers' young children are first given an iPad or similar device, not access to a Tandy 1000, Apple II, Commodore or similar computer that had a BASIC interpreter baked in. To an extent the fault (on iOS) is squarely on Apple's shoulders, as for a long time they explicitly made interpreters and such verboten on iOS. This is a nice turnaround on their part, and a potentially good tool to get programming into the hands of kids.
I thought Apple had allowed interpreters etc. for some time, pythonista looks quite nice for example (it even has numpy and somebody ported some sort of pip to it so you can even install modules)
As a first introduction to programming python might be a bit too complicated, but there do seem to be some BASIC interpreter on the app store it seems
How is it that we can teach chemistry and physics - but when it comes to 'when this, do that', we throw our hands in the air and claim it is too difficult?
I'm pretty sure calculus is more difficult than intro to python :)
Give kids the tools to program their own games and they will be plenty motivated to learn the skills.
That's how I got started, was having a TI calculator with a full TI-BASIC programming language in it. I was sitting in my classes and programming games while listening to the teacher at the same time.
I wish there was something equivalent in modern devices, but devices in general are too sandboxed, and pretty much all require programming from the computer, which interferes with kids being able to code from wherever they're at, because they have to go and do what their parents/teachers/etc tell them to do.
Back then I could access the graphing calculator, from code, and draw my own graphics directly to it, or create native menus (great for choose your own adventure games), check key input realtime, all sorts of fun things. I don't know an existing mobile device that allows native access to things from code on the device, and that sucks.
> I wish there was something equivalent in modern devices, but devices in general are too sandboxed, and pretty much all require programming from the computer, which interferes with kids being able to code from wherever they're at, because they have to go and do what their parents/teachers/etc tell them to do.
On Android (without rooting or any other "magic") there are plenty of fairly complete programming environments with comprehensive access to device features (including at least one dialect of BASIC with fairly comprehensive access to sensors, etc.), and there are even dev environments where you can build Android apps on device.
iOS may be "too sandboxed" to allow as much freedom (back when I was using iOS, I remember some similar things, but they were much more restricted than what was on Android at the time, don't know how that has changed since), but if so that's an iOS thing, not a "modern devices" thing.
That's cool. Which apps? I do have an Android phone myself. I only use iOS for tablets nowadays.
And that being said, really there should (also) be something built into every device, so everyone has it and can be curious what it is and can look it up and tinker with it. Having to download apps requires them to be actively looking for it, and every IDE is competing with each other and fracturing the community and support behind it. (They should exist as alternatives, I just want something built in also).
Modifying colours, sprites and sounds with the inline picker directly from code was my own design. And first appeared in Codea, as far as I'm aware.
I was definitely aware of, and inspired by Bret Victor's presentations (and certainly took some of his ideas for Codea). But those particular features were first in Codea before being replicated elsewhere.
Inspiring the next generation of college students to sign up for freshmen CS classes and shockingly realize that programming is only a small component in the field.
Perhaps, but while programming may be only 20% of CS, learning it probably takes up 80% of a student's time. Reducing that additional cognitive load during the first couple semesters could allow them to focus on other CS fundamentals and improve overall comprehension over the course of their degree.
And I honestly can't recall a single CS course where I didn't write an executable program after my first (CS 1301 at GT circa 2000, done using a pseudo-code language based on Pascal). Even my theory classes, I used programming to express/analyze the material discussed in class.
This is what I'm hoping for. I want my kids to learn how to program, not so that they can become a programmer like me, but so that they can use programming to inform and enhance whatever they choose to do.
Yeah, I'm using my programming skills to write scripts to assist me in making/designing/balancing physical board games. Probably no one would assume that programming would assist in the hobby in any way, but I'm finding it quite useful.
And have more horrible software that breaks once you look at it , causes billions in damages, wastes millions of live hours, and endangers lives (shitty medical software cough)?
Presumably, the more coders there are, the smart thing to do is to hire some of them for reviewing pull requests. Perhaps professional code-copyeditor will become a thing.
Every organisation already does code review. Why would you want to have code review done by subpar people?
All this will do is push down wages.
We don't need more programmers, we need a higher percentage with a strong background in math, and with a thorough understanding of the infrastructure underpinning ever application (operating systems, hardware, networking).
But what we instead get is another post every week of somebody complaining that reversing a binary tree is too hard, and not relevant to our profession.
I think it is a safe bet that the fraction of users of this program that will end up going for a CS degree will be so tiny that 'zero' is a good enough approximation.
Reason? That's true for the general population, too. This IMO isn't even targeted at people who will go into software engineering or even science degrees. Instead, I think the target audience is anybody who might benefit from occasional scripting, 'down' to for those who will not program at all, but may benefit from knowing a bit more about what programming entails.
If successful, it will allow those people to, for example, write better spreadsheets, for some of them to write the occasional script, and for those ending up as managers to be a bit better at managing the software side of their projects.
Basically, I think this aims at the rest of the world, like logo and smalltalk do/did. Of course, the open question is whether it will succed at that.
I like Swift as a language, but I have my doubts as to its suitability as a first-time programming language for children. It contains a whole lot of industry-standard jargon that we as practiced software developers don't think twice about, and will have to be explained. Like, what the heck is a "string", and why is it called that? What is this weird vertical character that I've never seen before (and how do I even begin to type it? is it an emoji?) and why do two of them next to each other mean "or"?
I don't doubt that kids are smart enough to wade through it all, but if you put enough obstacles in their path then they're going to wander off and do something more interesting. It also raises the question of whether you're teaching kids programming for the sake of programming (in which case you'd rather use any of the myriad languages that have been designed for young children), or if you're teaching kids programming for the sake of helping them solve some problem or achieve some task (in which case you'd probably pick a language with a more specific focus), or whether you're just teaching them programming just for the sake of adding to the ranks of the software industry ten years from now.
It seems to do a lot of holding your hand through all those things, but I've always been very skeptical of the idea that the things you listed are real barriers to understanding.
The fact is that those are surface details that are far less likely to tank your understanding of what's going on than basic problems understanding logic and execution flow. When I see beginners struggle, it's not because they've been given sigils they don't understand (it'd be almost impossible not to: even using words like 'or' and 'and' carry various secondary meanings unique to programming and/or formal logic), but because they're having trouble building a meaningful mental model of the execution of the program.
Live visualizations help a lot with that fundamental problem. From there you can learn the details. I think this way around is far more successful.
Fundamentally, this argument's been had over and over and over again, and in the end the languages people learn are the languages people use. BASIC is probably the most successful 'learning language' ever, but it became successful in environments where people were using it for productive work (as the boot rom environment on older computers and with visual basic). Likewise, Pascal only became popular when it became possible to use it for productive work (thanks to Borland Pascal and later Delphi).
Otherwise, allegedly 'easier to learn' languages lose every time to the ones people can move from success to success all the way from learning to productive work.
> basic problems understanding logic and execution flow
I don't disagree with this. My point is that layers of obfuscation on top of the really difficult bits only make it harder to devote attention to the difficult bits. Beyond a certain threshold, beginners throw up their hands and walk away, especially if they're motivated only by curiosity (which seems to be the target audience of this app).
I know I reached this stage as a teenager when trying to learn C++ (because I wanted to make video games, you see, and everyone told me this was the only language to use), and trying to perform even the simplest operations was piled under layers and layers of seemingly-arbitrary nonsense. I gave up and didn't touch C++ again until after college.
In all, I think there's survivorship bias at work here. We say that these things aren't a problem, that they aren't barriers to understanding, but the only people here in this discussion are the ones who haven't already become discouraged. It's no wonder when things are seen as not-a-problem by people who didn't have a problem with them.
I'm not sure appealing to survivorship bias is useful here, since presumably you are also a survivor and just as subject to it.
But my argument was based on my observations of other people trying to learn. My experience learning was quite different from most that I've observed, and my observation has actually been that the way I learned is the one that works for fewer people. This is an area of interest for me, so I take opportunities to see how people learn as much as I can. If anything, the better argument against what I'm saying is that it's just anecdata, which is true. I'd welcome research to prove this one way or another, though.
Tools like this are quite unlike what I had available to me, and I think they are a much bigger step to creating learning environments for real computing than trying to shoehorn natural language into a box it just doesn't fit. We have been down that road so many times and it never works out the way proponents suggest it should.
I think you are grossly underestimating young people. Learning || to mean OR or String to mean "a series of characters" is by no means beyond the capability of kids.
I explicitly said in my comment that I am confident that kids are capable of learning these concepts.
You seem to be asserting that an abundance of jargon, unfamiliar symbols, and unintuitive names are no obstacle to people learning to program, but sit a first-timer down with Befunge or Malebolge and we'll see how far they get. :) User interface matters, and it especially matters to people who have not yet internalized all the latent, lingering idiosyncrasies of programming in general.
I think the first programming I did was Turtle Logo, or Apple Logo or whatever it was called.
Traditionally it's been Pascal and Basic, but I think those aren't used much anymore. I learned Commodore Basic first then Pascal in High School and CS1 in college.
Kids need to start with small, quick successes before they are willing to invest more time. The Playground weighs in Swift's favor because they can get immediate feedback.
As for the language itself, it seems to have decent type-inferencing. So, kids won't get bogged down on a compiler not liking "String" vs. "string".
To really capture kids' imaginations, Apple needs to visual and auditory libraries loaded and ready to go in the Playground. Kids will immediate want to build something graphical or auditory.
> B) Why teach them one way to do things and force them
> to relearn it a few years later?
Who says anyone's being forced to relearn anything? My initial progression of languages went QuickBASIC -> Visual Basic -> Java, and despite the fact that Java is nothing like QuickBASIC the concepts helped me immensely in powering through Java's intimidating learning curve (i.e. "just type `public static class Hello { public static void main(String[] args) { system.out.println("Hello"); } }` for now (and for god's sake, make sure the file name is Hello.java), you'll understand what all that means in about six months or so").
It's easy to forget that our first exposure to programming involves a lot of fundamental concepts that are wholly incidental to the semantics of whatever language we're using. Trivial stuff like case sensitivity of identifiers (quite surprising to an enormous number of first-time programmers) as well as highly non-trivial stuff like setting up your programming environment and teaching people how to invoke the compiler/interpreter. Making the language itself small and intuitive, even if limited, goes a long way towards giving students a stone to cling to in the rushing river of unfamiliar concepts that they're being exposed to.
I've taught programming to thousands of children, teenagers, and adults for a bit over a decade now (not exagerating, I've been through the exercise of estimating, for each of my gigs, how many students I've interacted with directly), in a wide variety of contexts (summer camps, bootcamps, middle schools, undergraduate classes, etc.), using a wide variety of languages (C, Python, Scratch, Ruby, PHP,...).
The things you quote are typically not much of an issue. Once you tell students what a string is, or you show them how to type | or ^ or & or whatever weird symbol, they typically remember it (of course, you'll get some "oh yeah I need to use that weird squiggly thing here, how do I type that again?" - and as a fun tidbit, students in 2016 have no problem remembering and typing the # symbol (aka a "hashtag") ).
The bigger issues come from more macro level things, like understanding that the code gets executed on a line by line basis and can't "read the future" (i.e. you can't use a variable if it's only declared 10 lines later), what scoping is, how to combine conditions together to make a loop that does what you want it to do, and so on.
Here's an attempt at defining a simple, minimal programming language, which would be useful to kids and adults choosing to learn programming and people looking for something simpler than the popular languages today: http://kartickv.tumblr.com/post/142934120532/why-arent-there...
I think it's a shame to teach kids to program on a platform as closed as iOS.
A 12 year old I know wrote an app as a birthday gift for his grandfather who lived overseas. The app was simple and displayed the grandfather's age with various different effects. Unfortunately, he wrote the app for iOS and so there was no easy way to deliver the app to grandfather (the family tried to submit it to the app store but it was rejected).
At least Swift Playgrounds allows kids to share with one another. Just don't try to leave the playground.
48 comments
[ 2.6 ms ] story [ 118 ms ] threadAlso the new coding keyboard looks interesting. A nice surprise from Apple.
This seems like a perfect way to get some wide testing of the compiler, coding keyboard, etc. I wonder what IDE enhancements we can expect from a touch interface.
Yes, there are.
> ...that aren't excruciating to use?
Oh. No, not really. Pythonista is the closest I've seen to an non-excruciating IDE on the iPad, but that's Python only. Link: http://omz-software.com/pythonista/
https://www.gethopscotch.com/
https://itunes.apple.com/us/app/scratchjr/id895485086?mt=8
For children who are older or more advanced:
Codea https://itunes.apple.com/us/app/codify/id439571171
For more of a game-like environment:
Lightbot
https://itunes.apple.com/us/app/lightbot-programming-puzzles...
https://codecombat.com/
It's a bit more visual programming rather than actual code, but programming concepts still apply.
We're being used by hundreds of schools around the world teaching kids to code :).
There's enough beginner material - the stumbling block is the reality programmers are living in.
Cute demos aren't changing that.
I've lamented in the past (here even, maybe) that the first computing devices many people get are primarily designed around consumption. Some types of content creation (particularly visual and audio, more limited textual), are very well enabled by these tablet interfaces, but that's not been the primary focus.
But programming them has long been difficult and required an external device. Many of my peers' young children are first given an iPad or similar device, not access to a Tandy 1000, Apple II, Commodore or similar computer that had a BASIC interpreter baked in. To an extent the fault (on iOS) is squarely on Apple's shoulders, as for a long time they explicitly made interpreters and such verboten on iOS. This is a nice turnaround on their part, and a potentially good tool to get programming into the hands of kids.
As a first introduction to programming python might be a bit too complicated, but there do seem to be some BASIC interpreter on the app store it seems
I'm pretty sure calculus is more difficult than intro to python :)
That's how I got started, was having a TI calculator with a full TI-BASIC programming language in it. I was sitting in my classes and programming games while listening to the teacher at the same time.
I wish there was something equivalent in modern devices, but devices in general are too sandboxed, and pretty much all require programming from the computer, which interferes with kids being able to code from wherever they're at, because they have to go and do what their parents/teachers/etc tell them to do.
Back then I could access the graphing calculator, from code, and draw my own graphics directly to it, or create native menus (great for choose your own adventure games), check key input realtime, all sorts of fun things. I don't know an existing mobile device that allows native access to things from code on the device, and that sucks.
On Android (without rooting or any other "magic") there are plenty of fairly complete programming environments with comprehensive access to device features (including at least one dialect of BASIC with fairly comprehensive access to sensors, etc.), and there are even dev environments where you can build Android apps on device.
iOS may be "too sandboxed" to allow as much freedom (back when I was using iOS, I remember some similar things, but they were much more restricted than what was on Android at the time, don't know how that has changed since), but if so that's an iOS thing, not a "modern devices" thing.
And that being said, really there should (also) be something built into every device, so everyone has it and can be curious what it is and can look it up and tinker with it. Having to download apps requires them to be actively looking for it, and every IDE is competing with each other and fracturing the community and support behind it. (They should exist as alternatives, I just want something built in also).
Swift Playground: http://www.apple.com/swift/playgrounds/
Codea: https://codea.io
I was definitely aware of, and inspired by Bret Victor's presentations (and certainly took some of his ideas for Codea). But those particular features were first in Codea before being replicated elsewhere.
All this will do is push down wages.
We don't need more programmers, we need a higher percentage with a strong background in math, and with a thorough understanding of the infrastructure underpinning ever application (operating systems, hardware, networking).
But what we instead get is another post every week of somebody complaining that reversing a binary tree is too hard, and not relevant to our profession.
Reason? That's true for the general population, too. This IMO isn't even targeted at people who will go into software engineering or even science degrees. Instead, I think the target audience is anybody who might benefit from occasional scripting, 'down' to for those who will not program at all, but may benefit from knowing a bit more about what programming entails.
If successful, it will allow those people to, for example, write better spreadsheets, for some of them to write the occasional script, and for those ending up as managers to be a bit better at managing the software side of their projects.
Basically, I think this aims at the rest of the world, like logo and smalltalk do/did. Of course, the open question is whether it will succed at that.
I don't doubt that kids are smart enough to wade through it all, but if you put enough obstacles in their path then they're going to wander off and do something more interesting. It also raises the question of whether you're teaching kids programming for the sake of programming (in which case you'd rather use any of the myriad languages that have been designed for young children), or if you're teaching kids programming for the sake of helping them solve some problem or achieve some task (in which case you'd probably pick a language with a more specific focus), or whether you're just teaching them programming just for the sake of adding to the ranks of the software industry ten years from now.
The fact is that those are surface details that are far less likely to tank your understanding of what's going on than basic problems understanding logic and execution flow. When I see beginners struggle, it's not because they've been given sigils they don't understand (it'd be almost impossible not to: even using words like 'or' and 'and' carry various secondary meanings unique to programming and/or formal logic), but because they're having trouble building a meaningful mental model of the execution of the program.
Live visualizations help a lot with that fundamental problem. From there you can learn the details. I think this way around is far more successful.
Fundamentally, this argument's been had over and over and over again, and in the end the languages people learn are the languages people use. BASIC is probably the most successful 'learning language' ever, but it became successful in environments where people were using it for productive work (as the boot rom environment on older computers and with visual basic). Likewise, Pascal only became popular when it became possible to use it for productive work (thanks to Borland Pascal and later Delphi).
Otherwise, allegedly 'easier to learn' languages lose every time to the ones people can move from success to success all the way from learning to productive work.
I know I reached this stage as a teenager when trying to learn C++ (because I wanted to make video games, you see, and everyone told me this was the only language to use), and trying to perform even the simplest operations was piled under layers and layers of seemingly-arbitrary nonsense. I gave up and didn't touch C++ again until after college.
In all, I think there's survivorship bias at work here. We say that these things aren't a problem, that they aren't barriers to understanding, but the only people here in this discussion are the ones who haven't already become discouraged. It's no wonder when things are seen as not-a-problem by people who didn't have a problem with them.
But my argument was based on my observations of other people trying to learn. My experience learning was quite different from most that I've observed, and my observation has actually been that the way I learned is the one that works for fewer people. This is an area of interest for me, so I take opportunities to see how people learn as much as I can. If anything, the better argument against what I'm saying is that it's just anecdata, which is true. I'd welcome research to prove this one way or another, though.
Tools like this are quite unlike what I had available to me, and I think they are a much bigger step to creating learning environments for real computing than trying to shoehorn natural language into a box it just doesn't fit. We have been down that road so many times and it never works out the way proponents suggest it should.
You seem to be asserting that an abundance of jargon, unfamiliar symbols, and unintuitive names are no obstacle to people learning to program, but sit a first-timer down with Befunge or Malebolge and we'll see how far they get. :) User interface matters, and it especially matters to people who have not yet internalized all the latent, lingering idiosyncrasies of programming in general.
Traditionally it's been Pascal and Basic, but I think those aren't used much anymore. I learned Commodore Basic first then Pascal in High School and CS1 in college.
As for the language itself, it seems to have decent type-inferencing. So, kids won't get bogged down on a compiler not liking "String" vs. "string".
To really capture kids' imaginations, Apple needs to visual and auditory libraries loaded and ready to go in the Playground. Kids will immediate want to build something graphical or auditory.
It's an interesting experiment.
A) Literally everything is new to a kid, and if they can figure out how to play pokemon and minecraft, they can figure out what '||' means.
B) Why teach them one way to do things and force them to relearn it a few years later?
It's easy to forget that our first exposure to programming involves a lot of fundamental concepts that are wholly incidental to the semantics of whatever language we're using. Trivial stuff like case sensitivity of identifiers (quite surprising to an enormous number of first-time programmers) as well as highly non-trivial stuff like setting up your programming environment and teaching people how to invoke the compiler/interpreter. Making the language itself small and intuitive, even if limited, goes a long way towards giving students a stone to cling to in the rushing river of unfamiliar concepts that they're being exposed to.
The things you quote are typically not much of an issue. Once you tell students what a string is, or you show them how to type | or ^ or & or whatever weird symbol, they typically remember it (of course, you'll get some "oh yeah I need to use that weird squiggly thing here, how do I type that again?" - and as a fun tidbit, students in 2016 have no problem remembering and typing the # symbol (aka a "hashtag") ).
The bigger issues come from more macro level things, like understanding that the code gets executed on a line by line basis and can't "read the future" (i.e. you can't use a variable if it's only declared 10 lines later), what scoping is, how to combine conditions together to make a loop that does what you want it to do, and so on.
A 12 year old I know wrote an app as a birthday gift for his grandfather who lived overseas. The app was simple and displayed the grandfather's age with various different effects. Unfortunately, he wrote the app for iOS and so there was no easy way to deliver the app to grandfather (the family tried to submit it to the app store but it was rejected).
At least Swift Playgrounds allows kids to share with one another. Just don't try to leave the playground.