Good god, nothing brings out the elitist trolls better than trying to make technology accessible to plebeians!
The nerve of Apple! The priesthood must be preserved!
Trolls aside, I'm excited for this - looks like it could be the spiritual successor to HyperCard - it's too bad Apple pissed that lead away. If HyperCard had supported AppleTalk I wonder if the web would have even happened. Bill Atkinson has acknowledged he dramaticly underestimated the importance of networking, which always amazed me given the Mac had AppleTalk pretty much from day one. Oh well, I guess you can't hit everys single one out of the park every time. A lot of his other work was amazingly ground breaking. Good thing he didn't know that overlapping windows were supposedly impossible to do
Apple has to lock down the development for now because someone could develop a program that would damage the system, maybe even jailbreak it and they wouldn't have a way to fix it. If they figure out a permissions model that lets them run code without the possibility of damaging anything, they'll be able to let the iPad do more. Apple's new filesystem might be a part of that as it can create expandable filesystem containers.
Good points, all!
I've heard rumors about a new filesystem -- didn't know it used containers. IBM is using Docker Containers for its implementations, including Swift.
Do you have any link about Apple's new filesystem?
The developer documentation for the Apple filesystem notes some interesting features:
The container part mentions multiple filesystems. It says that each container reports the total free space on the volume. If that worked for Bootcamp, it would be good as any unused space on the Windows side would be available to the Mac and vice versa. For apps, it might mean a completely isolated file space similar to running an app inside a read/write disk image and only having permissions for that filesystem. Cloning will help with auto-save versions making them faster and use less space.
Having more control over permissions would help with development because Apple can put metadata into their own filesystem that prevents apps overwriting, moving or deleting files they shouldn't. By default apps can have no write permissions, just read and create. Perhaps each file inode would get a permission set of application binary inodes. There can be a central system to allow filetypes.
Say a file has inode 7798 and an application binary has inode 12290. When the application runs, the filesystem doesn't allow write permissions to the app for that file by default. When the app tries to write, the system would intervene and ask the user if the app can modify the file. On approval by the user, inode 7798 then stores metadata saying 12290 has write permission. Every file created by 12290 would automatically have write permission. The approval would just be a system call like a save dialog.
This means apps developed on iPads can be less restricted because they wouldn't have write permissions for anything and couldn't get permissions as it's limited at a filesystem level.
Apple can always keep iPhones and standard iPads more restricted and just have iPad Pros unrestricted, which limits any potential damage. It's not like anyone is going to develop an app using an iPhone.
mdriftmeyer said: Becoming multi-lingual is an invaluable tool, throughout life. Force feeding programming has nowhere near the long term value and rationale of traditional educational building blocks.
Force feeding?
Once I used to wonder what the colors of the sky the planet you are on could be. Now I just want to find out how to put you on ignore again
It is fun. This is complex stuff that being trivialized only adds frustration to the kid [who Tim thinks every kid should become a programmer: an absolutely terrible fantasy] when they discover they cannot master it.
You are telling it like it is and getting a stupid number of down votes for it, which is a shame.
As you say, fooling kids into thinking a real world enterprise is easy and trivial is doing them a disservice and will likely lead to discouragement.
It is fun. This is complex stuff that being trivialized only adds frustration to the kid [who Tim thinks every kid should become a programmer: an absolutely terrible fantasy] when they discover they cannot master it.
You could say the same things about music lessons and basic programs that teach kids to play "Happy Birthday". This is not to teach kids programming. It's to teach kids logical skills and concepts that programming requires. It's like pre-reading skills. For kids to be able to learn to read, they first have to know how to put pen to paper, draw with crayons, scan from left to right, learn the alphabet, etc.
Except you you don't introduce children to the idea of playing a musical instrument by having them press a few keys on a keyboard and have Beethoven's Moonlight Sonata result.
I think that the plan is that Swift will [eventually] replace client-side programming languages such as JavaScript.
Good luck convincing W3C to standardize on Swift to replace CSSx, HTMLx, and Javascript, at least not any time soon. It has only taken them 20+ years to get all the browser apps sort of compliant. Swift might potentially become a new server side language such as dotNet, but it will have a long way to go before it will be client side, if ever, with the possible exception of Mac nerds running Xcode. I expect it will be at least another 20 years before it becomes a go-to language across the mainstream platforms. Likely, it will remain just like it is now, programmers will select whatever language they prefer. If anything, Swift will just join the others like Java, PHP, ASP.Net, Ruby, Python, etc. It is not likely to replace anything except maybe Obj-C, at least in my opinion, especially not universally across all web browsers.
youre speaking out of ignorance. swift could not replace CSS or HTML anymore than javascript could. it's impossible because the first two are layout & styling technologies, while swift/javascript are programming languages. theyre entirely different types of tools.
swift could, however, replace javascript if it became popular enough to be included in the browsers and people wanted to switch to it. theoretically possible. and it is open source, so Xcode would have nothing at all to do with that.
My original assertion was that: "I think that the plan is that Swift will [eventually] replace client-side programming languages such as JavaScript."
I made no mention of CSS or HTML -- they're not programming languages.
It is fun. This is complex stuff that being trivialized only adds frustration to the kid [who Tim thinks every kid should become a programmer: an absolutely terrible fantasy] when they discover they cannot master it.
You could say the same things about music lessons and basic programs that teach kids to play "Happy Birthday". This is not to teach kids programming. It's to teach kids logical skills and concepts that programming requires. It's like pre-reading skills. For kids to be able to learn to read, they first have to know how to put pen to paper, draw with crayons, scan from left to right, learn the alphabet, etc.
Except you you don't introduce children to the idea of playing a musical instrument by having them press a few keys on a keyboard and have Beethoven's Moonlight Sonata result.
You also don't introduce children [or anyone] to the idea of playing a musical instrument by having them deconstructing the keyboard into its component parts, explaining what each one does and how it works overloading them with mind-numbing amounts of music theory.
Rather, you try to interest them by showing cause and effect at some level of abstraction -- when they are interested enough to want to know how and why, providing the details and reinforcement will be a natural part of the learning process.
The Playgrounds app starts the user with an analogy that a program can be a s simple as planting rows of seeds in a garden
Then creates a canvass which includes:
An animated character
A small 3D world - a grid divided into squares
A jewel in one of the squares
Two commands *
moveForward() collectGem()
It is noteworthy that they are called commands -- because you are telling the animated character what to do ... Calling by its real name func, at this stage would be confusing ... But why do they call it a function??? What does a function mean, anyway???
Also they point out that the words in commands are mashed together (that's just the way they are) and that commands are always followed by parenthesis -- You'll see why later!
And when the student enters (taps) the right sequence of commands, the Animated character bounces around and the student is given a message reinforcing his effort.
For the next problem the user is given a new command turnLeft() and a harder grid.
Later problems require the student figure out a way to command the character to turn to the right and turn around -- with only those 3 commands ...
Then, the need to repeat commands (collect more gems) teaches the student how to write loops.
Before long the problem becomes more complex and the need arises to combine several commands together -- and the app helps the student write a func and shows him why it is necessary. No explanation of why the parenthesis, yet -- but that comes when the student needs to pass parameters to his func.
The student has a set of tools that he can drag into his program: loops, structures, func, if, switch, logic, etc. ... This is a shortcut to quickly get the needed constructs into his code without a lot of typing and typos.
But, surprisingly soon, the student is just typing code -- writing funcs that invoke other funcs he has written, debugging, exploring better ways to do things, refactoring his code -- receiving reinforcement when he gets it right ..
I suspect that if a few of you detractors actually tried the Playgrounds app -- that you'd be amazed how well it teaches problem analysis, prototyping and, yes, coding -- not bad for a beta version and only the first lesson.
Apple has to lock down the development for now because someone could develop a program that would damage the system, maybe even jailbreak it and they wouldn't have a way to fix it. If they figure out a permissions model that lets them run code without the possibility of damaging anything, they'll be able to let the iPad do more. Apple's new filesystem might be a part of that as it can create expandable filesystem containers.
Good points, all!
I've heard rumors about a new filesystem -- didn't know it used containers. IBM is using Docker Containers for its implementations, including Swift.
Do you have any link about Apple's new filesystem?
The developer documentation for the Apple filesystem notes some interesting features:
The container part mentions multiple filesystems. It says that each container reports the total free space on the volume. If that worked for Bootcamp, it would be good as any unused space on the Windows side would be available to the Mac and vice versa. For apps, it might mean a completely isolated file space similar to running an app inside a read/write disk image and only having permissions for that filesystem. Cloning will help with auto-save versions making them faster and use less space.
Having more control over permissions would help with development because Apple can put metadata into their own filesystem that prevents apps overwriting, moving or deleting files they shouldn't. By default apps can have no write permissions, just read and create. Perhaps each file inode would get a permission set of application binary inodes. There can be a central system to allow filetypes.
Say a file has inode 7798 and an application binary has inode 12290. When the application runs, the filesystem doesn't allow write permissions to the app for that file by default. When the app tries to write, the system would intervene and ask the user if the app can modify the file. On approval by the user, inode 7798 then stores metadata saying 12290 has write permission. Every file created by 12290 would automatically have write permission. The approval would just be a system call like a save dialog.
This means apps developed on iPads can be less restricted because they wouldn't have write permissions for anything and couldn't get permissions as it's limited at a filesystem level.
Apple can always keep iPhones and standard iPads more restricted and just have iPad Pros unrestricted, which limits any potential damage. It's not like anyone is going to develop an app using an iPhone.
Thanks for the link.-- seems like the Apple filesystem didn't make prime time but there was some info out there.
Interesting idea to open the file system to the iPad Pros (prolly requested by IBM, too). The iPad Playgrounds app seems to have its own container -- you can export a file from Xcode and AirDrop it to the iPad where it is automatically opened as a new document in the Playground App -- a little less straight forward going the other way. You can also use iCloud Drive or just copy copy/paste to from web sites.
It is fun. This is complex stuff that being trivialized only adds frustration to the kid [who Tim thinks every kid should become a programmer: an absolutely terrible fantasy] when they discover they cannot master it.
You are telling it like it is and getting a stupid number of down votes for it, which is a shame.
As you say, fooling kids into thinking a real world enterprise is easy and trivial is doing them a disservice and will likely lead to discouragement.
I have no idea why the two of you look at the equivalent of "Hello World!" program and claim that it is pointless to teach programming graphically. This is like looking at Lego Mindstorm coding and claiming that because it's not embedded C it is pointless.
That said, while Swift Playground is cool, Code.org runs on the iPad and is very very very very similar. My kids do the Hour of Code stuff from Code.org and some Scratch and like it and will progress to Khan Academy and other more advanced languages later after they learn conditionals, loops, functions, eventing, etc from Code.org.
Code Studio scales into AppLab which takes you closer to traditional coding with a text editor mode.
In the AppLab intro video it shows that AppLab allows you to write apps that can persist to the database, use typed variables, do eventing, define functions and lay out UIs. If you skip to 3:50 you see that you can lay down UI elements in Design mode an then fill in onEvent () handlers for button presses, etc. At 6:24 they go into teaching how to use the debugger. Students can use a graphical drag and drop programming like they learn in Code Studio or move to developing in the text editor.
Given that Swift scales from the same exercises you see in Hour of Code on Code.org all the way to Xcode I would assume that the lessons will similarly transition elementary and middle school students to full scale programming in high school.
They aren't fooling kids into thinking that coding is easy any more than 1st grade math is fooling kids that non-linear differential equations is easy.
At about 16:26 in, Siri introduces Chris Lattner who tells you what's happening in Swift ... This is immediately followed by an more in-depth demo of the Apple Playgrounds app on the iPad. You will realize that damn near anything you can do in Xcode you will be able to do in iPad Playgrounds -- no small feat!
Comments
Well, I've been through most of the Lesson 1 (I skim read the last half of it).
It is quite comprehensive, though the animation gets a little tedious. I suspect there will be less (or optional) animation in future lessons.
I'm Impressed -- let's see if I can get my grandson interested.
The nerve of Apple! The priesthood must be preserved!
Trolls aside, I'm excited for this - looks like it could be the spiritual successor to HyperCard - it's too bad Apple pissed that lead away. If HyperCard had supported AppleTalk I wonder if the web would have even happened. Bill Atkinson has acknowledged he dramaticly underestimated the importance of networking, which always amazed me given the Mac had AppleTalk pretty much from day one. Oh well, I guess you can't hit everys single one out of the park every time. A lot of his other work was amazingly ground breaking. Good thing he didn't know that overlapping windows were supposedly impossible to do
https://developer.apple.com/library/prerelease/content/documentation/FileManagement/Conceptual/APFS_Guide/NewFeatures/NewFeatures.html
The container part mentions multiple filesystems. It says that each container reports the total free space on the volume. If that worked for Bootcamp, it would be good as any unused space on the Windows side would be available to the Mac and vice versa. For apps, it might mean a completely isolated file space similar to running an app inside a read/write disk image and only having permissions for that filesystem. Cloning will help with auto-save versions making them faster and use less space.
Having more control over permissions would help with development because Apple can put metadata into their own filesystem that prevents apps overwriting, moving or deleting files they shouldn't. By default apps can have no write permissions, just read and create. Perhaps each file inode would get a permission set of application binary inodes. There can be a central system to allow filetypes.
Say a file has inode 7798 and an application binary has inode 12290. When the application runs, the filesystem doesn't allow write permissions to the app for that file by default. When the app tries to write, the system would intervene and ask the user if the app can modify the file. On approval by the user, inode 7798 then stores metadata saying 12290 has write permission. Every file created by 12290 would automatically have write permission. The approval would just be a system call like a save dialog.
This means apps developed on iPads can be less restricted because they wouldn't have write permissions for anything and couldn't get permissions as it's limited at a filesystem level.
Apple can always keep iPhones and standard iPads more restricted and just have iPad Pros unrestricted, which limits any potential damage. It's not like anyone is going to develop an app using an iPhone.
Once I used to wonder what the colors of the sky the planet you are on could be. Now I just want to find out how to put you on ignore again
As you say, fooling kids into thinking a real world enterprise is easy and trivial is doing them a disservice and will likely lead to discouragement.
We're you born writing enterprise apps? The concept of starting on the path is really completely foreign to you?
I could understand people dismissing this as not useful to them - big whoop. But to actually casting it in a negative light? I weep for our future...
My original assertion was that: "I think that the plan is that Swift will [eventually] replace client-side programming languages such as JavaScript."
I made no mention of CSS or HTML -- they're not programming languages.
You also don't introduce children [or anyone] to the idea of playing a musical instrument by having them deconstructing the keyboard into its component parts, explaining what each one does and how it works overloading them with mind-numbing amounts of music theory.
Rather, you try to interest them by showing cause and effect at some level of abstraction -- when they are interested enough to want to know how and why, providing the details and reinforcement will be a natural part of the learning process.
The Playgrounds app starts the user with an analogy that a program can be a s simple as planting rows of seeds in a garden
Then creates a canvass which includes:
Also they point out that the words in commands are mashed together (that's just the way they are) and that commands are always followed by parenthesis -- You'll see why later!
The solution to the first problem is:
And when the student enters (taps) the right sequence of commands, the Animated character bounces around and the student is given a message reinforcing his effort.
For the next problem the user is given a new command turnLeft() and a harder grid.
Later problems require the student figure out a way to command the character to turn to the right and turn around -- with only those 3 commands ...
Then, the need to repeat commands (collect more gems) teaches the student how to write loops.
Before long the problem becomes more complex and the need arises to combine several commands together -- and the app helps the student write a func and shows him why it is necessary. No explanation of why the parenthesis, yet -- but that comes when the student needs to pass parameters to his func.
The student has a set of tools that he can drag into his program: loops, structures, func, if, switch, logic, etc. ... This is a shortcut to quickly get the needed constructs into his code without a lot of typing and typos.
But, surprisingly soon, the student is just typing code -- writing funcs that invoke other funcs he has written, debugging, exploring better ways to do things, refactoring his code -- receiving reinforcement when he gets it right ..
I suspect that if a few of you detractors actually tried the Playgrounds app -- that you'd be amazed how well it teaches problem analysis, prototyping and, yes, coding -- not bad for a beta version and only the first lesson.
Thanks for the link.-- seems like the Apple filesystem didn't make prime time but there was some info out there.
Interesting idea to open the file system to the iPad Pros (prolly requested by IBM, too). The iPad Playgrounds app seems to have its own container -- you can export a file from Xcode and AirDrop it to the iPad where it is automatically opened as a new document in the Playground App -- a little less straight forward going the other way. You can also use iCloud Drive or just copy copy/paste to from web sites.
That said, while Swift Playground is cool, Code.org runs on the iPad and is very very very very similar. My kids do the Hour of Code stuff from Code.org and some Scratch and like it and will progress to Khan Academy and other more advanced languages later after they learn conditionals, loops, functions, eventing, etc from Code.org.
Code Studio scales into AppLab which takes you closer to traditional coding with a text editor mode.
https://code.org/educate/applab
In the AppLab intro video it shows that AppLab allows you to write apps that can persist to the database, use typed variables, do eventing, define functions and lay out UIs. If you skip to 3:50 you see that you can lay down UI elements in Design mode an then fill in onEvent () handlers for button presses, etc. At 6:24 they go into teaching how to use the debugger. Students can use a graphical drag and drop programming like they learn in Code Studio or move to developing in the text editor.
Given that Swift scales from the same exercises you see in Hour of Code on Code.org all the way to Xcode I would assume that the lessons will similarly transition elementary and middle school students to full scale programming in high school.
They aren't fooling kids into thinking that coding is easy any more than 1st grade math is fooling kids that non-linear differential equations is easy.
Have a look at Apple's State of the Platform video;
https://developer.apple.com/videos/play/wwdc2016/102/
At about 16:26 in, Siri introduces Chris Lattner who tells you what's happening in Swift ... This is immediately followed by an more in-depth demo of the Apple Playgrounds app on the iPad. You will realize that damn near anything you can do in Xcode you will be able to do in iPad Playgrounds -- no small feat!