Mmm ... I am amazed at how much I misjudge someone by a series of web posts spanning years!
I have many other skilsets… just not programming, which I contend hasn't clicked because of the language aspect of it.
Why is that an issue -- any more than when you insert a DVD the player app pops up (with appropriate drivers) to play your DVD?
Seriously, that's an unnecessary distraction/crutch -- it just works! After you learn to program, you can address compilers and the mechanics of the language, if that still is of interest ... But, I'd bet it won't be!
It's a crutch to not understand why code needs to be written in a certain way. I know what the code is supposed to do and I can write out how the logic will flow, but what I can't competently do is write out the code from scratch correctly. At best, it looks like some spam email where you can make out what they are trying to say, but it's written in broken English that much have gone though several languages translators before they hit send. Compilers are finicky.
For example, let x: Int = 0 is correct, but let x = Int: 0 and let x = 0: Int, are not. Why can't I declare the value as an Integer on the other side of equals sign? Why does it have to be after x: and before the equals sign? That isn't stuff I've ever read about. It's like trying to figure out how an internal combustion engine works by only driving the car.
My personal lesson plan is now to repeat the most basic aspects of the language by trying slight variations (all run in the CLI) so I can see how the compiler treats it. I keep doing this until 1) I feel I get an understand of what's going on in the background, and 2) I feel the wrong code will stick out to me like a sore thumb.
I am a firm believer in "Learn by doing".
There is only one thing worse than doing something badly -- not doing it all!
And I do learn by doing, but the books that have you create your first iPhone app in Ch 1 by following their steps and then conclude you know that material because you followed along in their book is not the same as understanding.
I agree! But I don't think those instructions are meant to be a means to understanding -- rather they are a starting point, a working example if you will -- which through research and experimentation provide the understanding you seek.
Ray Wunderlich has some pretty good tutorials in Obj-C and Swift. Some of the older tuts, like RWMapping, have not, yet, been updated to Swift. IMHO, it is a worthwhile exercise to follow the tut, but implement the code in Swift -- you will learn, discover and gain understanding!
For example, let x: Int = 0 is correct, but let x = Int: 0 and let x = 0: Int, are not. Why can't I declare the value as an Integer on the other side of equals sign? Why does it have to be after x: and before the equals sign? That isn't stuff I've ever read about. It's like trying to figure out how an internal combustion engine works by only driving the car.
It's because of the way your program is turned in to assembly language. The compiler doesn't understand it line by line as such, rather it has something called a "grammar" which describes what is and is not a syntactically valid program as a whole. The grammar describes a tree structure, and the parser needs to be able to map what you wrote on to this tree, and then the tree is passed to another program for conversion in to assembly language.
So if you ever want to know why something you wrote isn't parsing just Google for the "grammar" of that particular language, e.g. Swift:
There do appear to be a preponderance of programming nerds commenting on this article. I started off with BASIC over a quarter of a century ago. The logic of 'if X = Y go to line 5, otherwise go to line 7', etc., led me into the later forms of programming languages. Swift is incredibly useful, provided that you have that basic understanding, as far as I am concerned. I am more concerned with what it is used for. It is just another form of communication with a machine.
It's a crutch to not understand why code needs to be written in a certain way. I know what the code is supposed to do and I can write out how the logic will flow, but what I can't competently do is write out the code from scratch correctly. At best, it looks like some spam email where you can make out what they are trying to say, but it's written in broken English that much have gone though several languages translators before they hit send. Compilers are finicky.
For example, let x: Int = 0 is correct, but let x = Int: 0 and let x = 0: Int, are not. Why can't I declare the value as an Integer on the other side of equals sign? Why does it have to be after x: and before the equals sign? That isn't stuff I've ever read about. It's like trying to figure out how an internal combustion engine works by only driving the car.
My personal lesson plan is now to repeat the most basic aspects of the language by trying slight variations (all run in the CLI) so I can see how the compiler treats it. I keep doing this until 1) I feel I get an understand of what's going on in the background, and 2) I feel the wrong code will stick out to me like a sore thumb.
.
Do you know any non-English languages ... Spanish, French, Croatian, German, Urdu? You will find that the construct of most languages is backwards (to us) from English and quite well defined:
la rosa amarillo * vs the yellow rose ...
That's the structure of the language -- and we learn to deal with it to accomplish the job to be done ... rather than fretting over why they are different or which is right.
in your example, above, let x = 0 is the preferred construct because:
Swift is a typed language
the type can be inferred by the value of the assignment
let y = ["a","b", "c"] is also correct
as is:
let z: [Int] // defined as an array of integers that must be initialized before use
z = [9,8,7] // initialization of let statement
My personal lesson plan is now to repeat the most basic aspects of the language by trying slight variations (all run in the CLI) so I can see how the compiler treats it.
if you are comfortable with the CLI, fine ... but you can do the same thing in a Playground -- a little easier and more flexible, IMO.
My only recommendation here, is that it might be more meaningful if you try to write some code that accomplishes something -- rather than experimenting with the compiler and language syntax ... Parsing the Spanish verb ir is nice but yields little ...
* FWIW, The French call Coca-Cola: Le Beaujolais de Texas
[quote name="Dick Applebaum" url="/t/186949/apples-itunes-u-course-on-swift-is-watershed-in-high-school-computer-science-education/40#post_2741736"]Do you know any non-English languages ... Spanish, French, Croatian, German, Urdu? You will find that the construct of most languages is backwards (to us) from English and quite well defined:[/QUOTE]
No, but I've tried to an extreme extent with little progress. The problem is that I am adult who only has English as a foundation and my brain isn't still malleable like a child's. Language learning is considerably more difficult for humans for reasons not worth getting into here.
[QUOTE]if you are comfortable with the CLI, fine ... but you can do the same thing in a Playground -- a little easier and more flexible, IMO.[/QUOTE]
Not a fan. It doesn't update as quickly as I'd like and the sidebar doesn't usually show the results I'm looking for.
[QUOTE]My only recommendation here, is that it might be more meaningful if you try to write some code that accomplishes something -- rather than experimenting with the compiler and language syntax.[/QUOTE]
I do, I'm just going back to the basics so I ca get a better foundation of the language that I never got when I tried to learn to write iPhone apps as my first attempt at learning a programming language.
If you followed Apples WWDC videos you will learn that object oriented programming is an old mans approach. Maybe not punch card old but it is a technology that isn't always the best choice. Try out the protocol oriented programming video. There are other efforts afoot to displace object oriented programming too.
That video and associated documentation shows how programming can be so alien to newcomers:
It also leads people to the wrong impressions. There are only two types of programming: procedural and object-oriented. People like to split variations in how these two things are implemented into different groups:
but there's only two main ideas - actions and objects. If you drive a car, that's an action or function and the car is an object. That covers everything in the real-world that needs to be modelled in software.
Protocols don't replace objects, they are just templates for inheritance like in other languages (with some differences), where they are called interfaces (different from Objective-C interfaces but the same as Objective-C protocols):
The intricacies of these concepts would normally only matter for scenarios with multiple programmers but they'll apply to use of core frameworks.
These concepts and all the verbiage that goes along with it just confuses what are very simple ideas. When people hear the word polymorphism, it's *click* and they just stop listening and it's for good reason. Most programmers want to use code to solve a high-level problem, they don't need to understand how a computer works down to the processor registers or how to coalesce fragmented memory, that's someone else's job and that understanding doesn't make their problem solving more effective.
Languages like assembler, C, C++ and so on are old languages for when memory had to be managed manually because there wasn't enough. Memory still has to be managed but not to the point that most developers have to track every variable to see if any kilobytes are being wasted, so the compiler and runtime can take care of it. Assembler helps get rid of overhead in very performance-intensive code, same as with Metal and OpenCL but that's not for most developers so it shouldn't be taught to everyone. Programming in older languages slows people down because they have to always code by their conventions and they make mistakes as a result.
Apple wants to make these kind of jobs accessible to non-nerds and the way to do that is not to teach low-level concepts that they'll never use. They need to consider commercial application, which is where teaching institutions fall short. Institutions have to pick a language to use and the best language is the one that gets the best results for the most people. This isn't C, C++, Objective-C, Assembler or outdated languages like Ada, LISP, Cobol, Fortran. Swift isn't the ideal choice just now because it's so new but it's a good option to go with. Java is a decent language to use too but the UI features with Swift are better.
The only things that newcomers need to be be taught about are objects, functions, data structures and variables and how to solve a problem with those. Inheritance matters for when they use core frameworks but they don't need to be taught the complexity of it, just how to use it.
The Xcode environment with Swift is a great place to learn code. They start with variables and data types and they can just print code. Then they start to build functions/actions. Then they build objects/classes that actually store attributes. Then they attach those to graphics and core frameworks and they are able to build apps. Put that on an iPad with a keyboard addition and it'll be a better environment than they could get on a Windows or Chromebook laptop. Kids could code their own apps and run their own apps for free on the same device, fully hardware-accelerated with multi-touch - split screen allows them to interact with an app on one side and debug it on the other. Add in iCloud version control that has a simple 'save snapshot' and it'll store major milestones without worrying about setting up version control repositories with complicated UIs. They could browse code versions like how Time Machine works. Teachers can browse snapshots to see how a student is approaching the problem and train them to solve problems in the most effective way.
This thread just goes to show that there is no "silver bullet" when it comes to education (in any field). No one-size-fits-all way to teach and inspire someone.
For myself, I'm definitely an applied learner: give me a goal/task and I will go to the ends of the earth to make it happen. I may not do it in the most succinct way, and it may require multiple iterations, but I will end up with the solution. And I will learn a lot about how to solve it better in the process. After which, if you give me the theory behind it, I will much better understand the abstraction. However, if you give me the theory first with no direct application, I won't learn it. Or I'll simply memorize it for a few days, and then forget it because I have no reason to remember it. No application for it.
As for learning object-oriented or procedural programming, both of those are simply architectural decisions -- something which someone just starting out in the field won't really comprehend since they're very focused on the exact steps needed to get a working program. For myself, software architecture was something I learned after I had written a number of programs and started to see common patterns and mistakes I had made. I learned that organizing my data and functions in certain ways made things much easier and made my programs more flexible in what they could do and easier to maintain.
Now, one can argue that establishing good habits from the start is important. But I think it's overwhelming at first to have someone who can barely get a program to run thinking about what objects and interfaces they need to create (they likely don't even understand that level of abstraction). At that point, I think it's best for them to simply see a program like a recipe -- a series of instructions that gives a certain outcome. Once they get that outcome, then you can get them to try and modify their program to do something else (which would be more easily accomplished with good structure). At which point, they may start to see the need for that structure. But I think they need the space to do things sloppily, make mistakes and see what happens. That's an essential part of the learning process.
As for learning how things work at a low level (CPU instructions operating on chunks of data, copying data around, etc). Again, I see that as likely too abstract for most people. They'll see what they want to do (say, draw something) but have no idea how to do that using such basic instructions. Because it takes hundreds or thousands of such simple instructions to do it. So I believe that having very plainly named, high-level APIs (like Java, Obj-C, Python, or Swift have) is the way to go. Keep things as close to the spoken language they already have experience with as possible.
If I was going to teach an absolute beginner how to code, I would start them out on Javascript. It has immediate gratification for small animations and transformations and also teaches them to code by hand. Javascript has very nice standardized implementations and is surprisingly similar to Swift.
If I was going to teach an absolute beginner how to code, I would start them out on Javascript. It has immediate gratification for small animations and transformations and also teaches them to code by hand. Javascript has very nice standardized implementations and is surprisingly similar to Swift.
Except for weirdness like whether to use "==" or "===" to compare things. Or how to check if something is uninitialized/null/empty. Given both options, I'd choose Swift personally -- less baggage and complication.
If I was going to teach an absolute beginner how to code, I would start them out on Javascript. It has immediate gratification for small animations and transformations and also teaches them to code by hand. Javascript has very nice standardized implementations and is surprisingly similar to Swift.
Except for weirdness like whether to use "==" or "===" to compare things. Or how to check if something is uninitialized/null/empty. Given both options, I'd choose Swift personally -- less baggage and complication.
My initial foray into web development (1997) was with JavaScript -- the first time I had done any programming in years.
JavaScript was simple, easy to learn -- though a little slow in those days. I was able to write a shopping cart with JavaScript.
So yes, it is an excellent starting point, IMO.
However, I think that Swift offers several advantages over JavaScript:
fast
safe
strongly typed
concise syntax
forced initialization of variables
writing time validation of code as opposed to compile/execution time failures
interactive code execution with Playgrounds
Some of the above advantages of Swift are not, yet, fully realized -- in a language implementation a little over a year old ... Obtuse error messages, syntax changes with each version, incorrect or missing documentation, etc.
But, you can envision what it will be with a little history under its belt.
The fact that Swift 2.0 will be released as open-source later this year is very significant! It will encourage all levels of programmers to use Swift regardless of platform.
My initial foray into web development (1997) was with JavaScript -- the first time I had done any programming in years.
JavaScript was simple, easy to learn -- though a little slow in those days. I was able to write a shopping cart with JavaScript.
So yes, it is an excellent starting point, IMO.
Very similar to my experience with Java around that same time. I had been learning OO programming with C++, and Java was such a breath of fresh air:
No weird template syntax to figure out: everything is an object that can be put into a container
APIs with names that read like natural language (prose) instead of something a machine would generate. For example, a container class has a function like "container.contains(item)" rather than C++'s equivalent: std::find(container.beginIterator, container.endIterator, item) != container.endIterator
An overall simplicity because there is one clear/concise way to do things rather than a half dozen slightly different ways for different situations
Fast forward to today where Java's API set and syntax has become far more powerful, but also more convoluted and difficult to find things (with many ways to do the same thing -- just like C++ had 20 years earlier).
Same goes with JavaScript -- it has been around so long and developed so many warts that while it certainly is simpler than languages like C++, it's definitely not as easy/straightforward as it once was. Especially now that everyone has extended it in custom ways with development frameworks. See programs which use Ember, Angular, and Backbone for examples of JavaScript that you probably wouldn't recognize anymore.
This tends to be what happens with languages over time: they are extended in ways that make them more powerful, but more complex. Which is why I'd have beginners learn with a younger, less complicated programming language like Swift.
If I was going to teach an absolute beginner how to code, I would start them out on Javascript. It has immediate gratification for small animations and transformations and also teaches them to code by hand. Javascript has very nice standardized implementations and is surprisingly similar to Swift.
For me, that instant gratification used in most books and lessons doesn't work well. I don't need a token achievement to get me enthused about the language. I'm already learning because I'm interested. What I want is is a solid foundation of each component and how they works so I can learn how the pieces fit together. The books I've bough for learning to write iPhone apps have mostly jumped around which has made me unsure of how a complex engine I can't see working is being able to run. That isn't to say I haven't learned anything but I can definitely say that creating my own lesson plan with my own puzzles in which I step up each week and repeat in various forms each week has helped me much more than any of those books, videos and classes. I have literally more in the last 2 months on my own than all my attempts since trying in 2008, although that's not completely fair because I'm excluding Xcode in that assessment. In and of itself, the IDE was a difficult challenge, and even though I'm very comfortable with major aspects of Xcode I wouldn't be surprised to find out I only understand about 5% of what it's capable of.
However, I think that Swift offers several advantages over JavaScript:
strongly typed
I completed the first two courses on Swift on Lynda.com but I still haven't had time to write any apps. I'm so busy with web development where I'm using Javascript, SQL and PHP that I've probably already forgotten most of what I learn regarding Swift. In terms of "strongly typed" Swift is pretty much statically typed. Although it can use weak ownership and explicit overrides it is for all intents and purposes statically typed. I came to programming through Perl which although it is dynamically typed, it is can be considered strongly typed, as can Javascript and php.
I was considering the attention span of a high school student not a mature adult.
Mature? I have more a few ex-girlfriends that would beg to differ.
But, yes, I do think that these small victories can help build interest with young minds, especially when there is so much too pull one's attention in the modern age.
Mature? I have more a few ex-girlfriends that would beg to differ.
But, yes, I do think that these small victories can help build interest with young minds, especially when there is so much too pull one's attention in the modern age.
The ultimate test of maturity is see whether you can don a fake mustache without laughing. Can you do that?
Comments
I agree! But I don't think those instructions are meant to be a means to understanding -- rather they are a starting point, a working example if you will -- which through research and experimentation provide the understanding you seek.
Ray Wunderlich has some pretty good tutorials in Obj-C and Swift. Some of the older tuts, like RWMapping, have not, yet, been updated to Swift. IMHO, it is a worthwhile exercise to follow the tut, but implement the code in Swift -- you will learn, discover and gain understanding!
I much prefer to say I Borg other people's code, but Cargo Culting seems to the accepted term.[/quote]
When searching for Cargo Cutting, I did run across that Wiki page.
I would suggest that 75% of the apps on the App Store are cargo culting as the Wiki describes ... And I don't believe that is a bad thing.
For example, let x: Int = 0 is correct, but let x = Int: 0 and let x = 0: Int, are not. Why can't I declare the value as an Integer on the other side of equals sign? Why does it have to be after x: and before the equals sign? That isn't stuff I've ever read about. It's like trying to figure out how an internal combustion engine works by only driving the car.
It's because of the way your program is turned in to assembly language. The compiler doesn't understand it line by line as such, rather it has something called a "grammar" which describes what is and is not a syntactically valid program as a whole. The grammar describes a tree structure, and the parser needs to be able to map what you wrote on to this tree, and then the tree is passed to another program for conversion in to assembly language.
So if you ever want to know why something you wrote isn't parsing just Google for the "grammar" of that particular language, e.g. Swift:
https://developer.apple.com/library/mac/documentation/Swift/Conceptual/Swift_Programming_Language/zzSummaryOfTheGrammar.html
No, but I've tried to an extreme extent with little progress. The problem is that I am adult who only has English as a foundation and my brain isn't still malleable like a child's. Language learning is considerably more difficult for humans for reasons not worth getting into here.
[QUOTE]if you are comfortable with the CLI, fine ... but you can do the same thing in a Playground -- a little easier and more flexible, IMO.[/QUOTE]
Not a fan. It doesn't update as quickly as I'd like and the sidebar doesn't usually show the results I'm looking for.
[QUOTE]My only recommendation here, is that it might be more meaningful if you try to write some code that accomplishes something -- rather than experimenting with the compiler and language syntax.[/QUOTE]
I do, I'm just going back to the basics so I ca get a better foundation of the language that I never got when I tried to learn to write iPhone apps as my first attempt at learning a programming language.
That video and associated documentation shows how programming can be so alien to newcomers:
https://developer.apple.com/videos/wwdc/2015/?id=408
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html
It also leads people to the wrong impressions. There are only two types of programming: procedural and object-oriented. People like to split variations in how these two things are implemented into different groups:
https://en.wikipedia.org/wiki/Comparison_of_programming_paradigms
but there's only two main ideas - actions and objects. If you drive a car, that's an action or function and the car is an object. That covers everything in the real-world that needs to be modelled in software.
Protocols don't replace objects, they are just templates for inheritance like in other languages (with some differences), where they are called interfaces (different from Objective-C interfaces but the same as Objective-C protocols):
http://docs.oracle.com/javase/tutorial/java/concepts/interface.html
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/WritingSwiftClassesWithObjective-CBehavior.html
The intricacies of these concepts would normally only matter for scenarios with multiple programmers but they'll apply to use of core frameworks.
These concepts and all the verbiage that goes along with it just confuses what are very simple ideas. When people hear the word polymorphism, it's *click* and they just stop listening and it's for good reason. Most programmers want to use code to solve a high-level problem, they don't need to understand how a computer works down to the processor registers or how to coalesce fragmented memory, that's someone else's job and that understanding doesn't make their problem solving more effective.
Languages like assembler, C, C++ and so on are old languages for when memory had to be managed manually because there wasn't enough. Memory still has to be managed but not to the point that most developers have to track every variable to see if any kilobytes are being wasted, so the compiler and runtime can take care of it. Assembler helps get rid of overhead in very performance-intensive code, same as with Metal and OpenCL but that's not for most developers so it shouldn't be taught to everyone. Programming in older languages slows people down because they have to always code by their conventions and they make mistakes as a result.
Apple wants to make these kind of jobs accessible to non-nerds and the way to do that is not to teach low-level concepts that they'll never use. They need to consider commercial application, which is where teaching institutions fall short. Institutions have to pick a language to use and the best language is the one that gets the best results for the most people. This isn't C, C++, Objective-C, Assembler or outdated languages like Ada, LISP, Cobol, Fortran. Swift isn't the ideal choice just now because it's so new but it's a good option to go with. Java is a decent language to use too but the UI features with Swift are better.
The only things that newcomers need to be be taught about are objects, functions, data structures and variables and how to solve a problem with those. Inheritance matters for when they use core frameworks but they don't need to be taught the complexity of it, just how to use it.
The Xcode environment with Swift is a great place to learn code. They start with variables and data types and they can just print code. Then they start to build functions/actions. Then they build objects/classes that actually store attributes. Then they attach those to graphics and core frameworks and they are able to build apps. Put that on an iPad with a keyboard addition and it'll be a better environment than they could get on a Windows or Chromebook laptop. Kids could code their own apps and run their own apps for free on the same device, fully hardware-accelerated with multi-touch - split screen allows them to interact with an app on one side and debug it on the other. Add in iCloud version control that has a simple 'save snapshot' and it'll store major milestones without worrying about setting up version control repositories with complicated UIs. They could browse code versions like how Time Machine works. Teachers can browse snapshots to see how a student is approaching the problem and train them to solve problems in the most effective way.
A little off-topic -but can anyone recommend a solid "getting started" tutorial for experienced C++11 / Java / Objective-C programmers?
This thread just goes to show that there is no "silver bullet" when it comes to education (in any field). No one-size-fits-all way to teach and inspire someone.
For myself, I'm definitely an applied learner: give me a goal/task and I will go to the ends of the earth to make it happen. I may not do it in the most succinct way, and it may require multiple iterations, but I will end up with the solution. And I will learn a lot about how to solve it better in the process. After which, if you give me the theory behind it, I will much better understand the abstraction. However, if you give me the theory first with no direct application, I won't learn it. Or I'll simply memorize it for a few days, and then forget it because I have no reason to remember it. No application for it.
As for learning object-oriented or procedural programming, both of those are simply architectural decisions -- something which someone just starting out in the field won't really comprehend since they're very focused on the exact steps needed to get a working program. For myself, software architecture was something I learned after I had written a number of programs and started to see common patterns and mistakes I had made. I learned that organizing my data and functions in certain ways made things much easier and made my programs more flexible in what they could do and easier to maintain.
Now, one can argue that establishing good habits from the start is important. But I think it's overwhelming at first to have someone who can barely get a program to run thinking about what objects and interfaces they need to create (they likely don't even understand that level of abstraction). At that point, I think it's best for them to simply see a program like a recipe -- a series of instructions that gives a certain outcome. Once they get that outcome, then you can get them to try and modify their program to do something else (which would be more easily accomplished with good structure). At which point, they may start to see the need for that structure. But I think they need the space to do things sloppily, make mistakes and see what happens. That's an essential part of the learning process.
As for learning how things work at a low level (CPU instructions operating on chunks of data, copying data around, etc). Again, I see that as likely too abstract for most people. They'll see what they want to do (say, draw something) but have no idea how to do that using such basic instructions. Because it takes hundreds or thousands of such simple instructions to do it. So I believe that having very plainly named, high-level APIs (like Java, Obj-C, Python, or Swift have) is the way to go. Keep things as close to the spoken language they already have experience with as possible.
If I was going to teach an absolute beginner how to code, I would start them out on Javascript. It has immediate gratification for small animations and transformations and also teaches them to code by hand. Javascript has very nice standardized implementations and is surprisingly similar to Swift.
If I was going to teach an absolute beginner how to code, I would start them out on Javascript. It has immediate gratification for small animations and transformations and also teaches them to code by hand. Javascript has very nice standardized implementations and is surprisingly similar to Swift.
Except for weirdness like whether to use "==" or "===" to compare things. Or how to check if something is uninitialized/null/empty. Given both options, I'd choose Swift personally -- less baggage and complication.
My initial foray into web development (1997) was with JavaScript -- the first time I had done any programming in years.
JavaScript was simple, easy to learn -- though a little slow in those days. I was able to write a shopping cart with JavaScript.
So yes, it is an excellent starting point, IMO.
However, I think that Swift offers several advantages over JavaScript:
Some of the above advantages of Swift are not, yet, fully realized -- in a language implementation a little over a year old ... Obtuse error messages, syntax changes with each version, incorrect or missing documentation, etc.
But, you can envision what it will be with a little history under its belt.
The fact that Swift 2.0 will be released as open-source later this year is very significant! It will encourage all levels of programmers to use Swift regardless of platform.
My initial foray into web development (1997) was with JavaScript -- the first time I had done any programming in years.
JavaScript was simple, easy to learn -- though a little slow in those days. I was able to write a shopping cart with JavaScript.
So yes, it is an excellent starting point, IMO.
Very similar to my experience with Java around that same time. I had been learning OO programming with C++, and Java was such a breath of fresh air:
Fast forward to today where Java's API set and syntax has become far more powerful, but also more convoluted and difficult to find things (with many ways to do the same thing -- just like C++ had 20 years earlier).
Same goes with JavaScript -- it has been around so long and developed so many warts that while it certainly is simpler than languages like C++, it's definitely not as easy/straightforward as it once was. Especially now that everyone has extended it in custom ways with development frameworks. See programs which use Ember, Angular, and Backbone for examples of JavaScript that you probably wouldn't recognize anymore.
This tends to be what happens with languages over time: they are extended in ways that make them more powerful, but more complex. Which is why I'd have beginners learn with a younger, less complicated programming language like Swift.
For me, that instant gratification used in most books and lessons doesn't work well. I don't need a token achievement to get me enthused about the language. I'm already learning because I'm interested. What I want is is a solid foundation of each component and how they works so I can learn how the pieces fit together. The books I've bough for learning to write iPhone apps have mostly jumped around which has made me unsure of how a complex engine I can't see working is being able to run. That isn't to say I haven't learned anything but I can definitely say that creating my own lesson plan with my own puzzles in which I step up each week and repeat in various forms each week has helped me much more than any of those books, videos and classes. I have literally more in the last 2 months on my own than all my attempts since trying in 2008, although that's not completely fair because I'm excluding Xcode in that assessment. In and of itself, the IDE was a difficult challenge, and even though I'm very comfortable with major aspects of Xcode I wouldn't be surprised to find out I only understand about 5% of what it's capable of.
However, I think that Swift offers several advantages over JavaScript:
I completed the first two courses on Swift on Lynda.com but I still haven't had time to write any apps. I'm so busy with web development where I'm using Javascript, SQL and PHP that I've probably already forgotten most of what I learn regarding Swift. In terms of "strongly typed" Swift is pretty much statically typed. Although it can use weak ownership and explicit overrides it is for all intents and purposes statically typed. I came to programming through Perl which although it is dynamically typed, it is can be considered strongly typed, as can Javascript and php.
For me, that instant gratification used in most books and lessons doesn't work well.
I was considering the attention span of a high school student not a mature adult.
Mature? I have more a few ex-girlfriends that would beg to differ.
But, yes, I do think that these small victories can help build interest with young minds, especially when there is so much too pull one's attention in the modern age.
Mature? I have more a few ex-girlfriends that would beg to differ.
Maybe they were looking for instant gratification.
Well, then -- he certainly wouldn't want to be considered swift
To be clear, they said I had an issue with being mature, not premature.
Mature? I have more a few ex-girlfriends that would beg to differ.
But, yes, I do think that these small victories can help build interest with young minds, especially when there is so much too pull one's attention in the modern age.
The ultimate test of maturity is see whether you can don a fake mustache without laughing. Can you do that?