Oh, okay, Apple... because soooooo many high school kids have prior experience with Java, Python, or C . SMH.
The first part that had me laughing was the bit about "High School iOS instructors". What are we going to see next high school courses for banking, mortuary services, bridge engineering, or some other occupation normally requiring extensive post secondary education. The whole article is a bit surreal.
As for your comment, most high schools don't have a computer science program worth a damn. Even the ones that do try would hardly prepare a student for Swift and iOS. In the end this will end up being a self directed educational opportunity for highly motivated students. The same students that would go out and buy a book on iOS programming on their own.
I think it's important to first teach the concepts of computer science apart from any toolset. Then the student will have a clear separation in their mind between the science, and any particular vendor tools. If I was teaching high school CS I probably wouldn't use Apple tools, I would use a plain open-source text editor, and a teaching-oriented procedural programming language.
Those are the last things I'd ever do. You might as well start them with keypunch cards.
Object oriented programming is the first thing any new programmer should learn. Why start them with bad habits (procedural programming) that the next class has to break.
And what is the point in using less than state of the art tools. Xcode shows errors as you type them, playground lets you execute the code as you type it.
Here are a couple of examples of how Playgrounds can be used in interactive Swift Programming / Computer Science education: These Playgrounds illustrate:
interactive code entry, compilation and execution (REPL)
included narrative (written markdown) presenting the theory behind the code
interactive display of the code execution results in a assistant editor
This shows what could be done -- it is not perfect -- far from it.
For one, It is a resource hog.
Secondly, the narrative is just "there" -- it would be better to let the user interactively show/hide a popup of the narrative and scroll with the code ... maybe a second assistant editor to handle the narrative (and even a best boy to include some video )
This is the second attempt but to make it short and sweet I have to say I agree.
Beyond that the indications are that this course requires that the student have a background in object oriented programming. I take this to mean a prior comp-sci type class. The people at Apple must be grossly out of touch if they think that the majority of high schools have the resources to pull this off.
In the end I suspect this course will be used in a self directed manner by the same sorts of students that would go out and buy themselves a iOS programming manual. In the end it's availability will have a minor impact on drawing new students into comp-sci.
I think it's important to first teach the concepts of computer science apart from any toolset. Then the student will have a clear separation in their mind between the science, and any particular vendor tools. If I was teaching high school CS I probably wouldn't use Apple tools, I would use a plain open-source text editor, and a teaching-oriented procedural programming language.
I've made numerous attempts over the years to learn Objective-C, but keep bumping up against unfamiliar terminology and the distinct lack of "action" definitions of such. Sure, there are verbose descriptions of parameters and properties, etc., but few or no clear explanations of what the hell you do with these damn "things." I'd like to see simple code examples with extensive annotations explaining exactly why and how you create a delegate, for example.
Objective C is fairly easy to understand as it is a minor extension of C. It is how they use it in the SDK that I find problematic. The only thing you can do is find a good book and try to ignore the practices seen on other systems.
Swift seems tantalizing, but if I still need to know Objective-C, then I'm still stuck there.
Swift can be useful to an extent without a strong background in Objective C. With each revision it has become more independent than previous version. However it really sounds like your issue isn't the language but rather the SDK. Frankly I find Cocoa to be very frustrating myself especially if you have lots of exposure to other systems.
The only suggestion I can make is to sign up as a developer and download all of the resources and example code Apple has. They do have many examples available to work with and excellent documentation.
I attempted for several years to learn Objective-C and just couldn't grasp the concepts. I've determined that programming is just too abstract for me.
I was fine with Visual Basic. C++ was absolutely awful and I dropped out of the course (it didn't help I would get the programs right and their stupid "autograder" software would mark it wrong because it didn't fit "the right way") and really don't have a desire to continue.
Maybe the problem is not too much abstraction -- but, too little abstraction!
For my own education, I recently proved that you could write a usable, multiple-column table (think spreadsheet) app without writing a line of code. * The columns were searchable, resizable, rearrangeable, [un]hideable, sortable, accumulatable and modifiable. Additional rows could be added, in place with optional default values for the various columns. You could select multiple (adjacent or non-adjacent) rows and delete them.
This was done using Storyboards and Bindings on an NSTableview (multiple-column table). iOS does not support multiple-column tables, yet. (However I was able to create a Watch app with a 2-column table).
This leads me to believe that you could make a construct, like a table even easier to use and more accessible (to programmers) by more abstraction.
Consider:
What if you could encapsulate this table and its relationships to its data and the user into a simple fill-out-a-form and voila you display a table -- no need to code: views, tableViews, datasources, delegates, sort descriptors, bindings, etc. -- just an encapsulated table, that includes everything it needs within (efficient, maintainable best-practices code)! on iOS, a list (single-column table) be even easier to encapsulate!
Certainly, there are places in apps where thoughtful, careful coding is required ... rewriting table code is like reinventing the wheel (often badly)!
Those are the last things I'd ever do. You might as well start them with keypunch cards.
One of the most useful classes I took was an assembly language course. Not that I ever programmed in assembly again but it really helps you understand what is going on in the processor.
Object oriented programming is the first thing any new programmer should learn. Why start them with bad habits (procedural programming) that the next class has to break.
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.
Beyond all of that you really do need to understand procedural programming to some extent as you never get completely away from that. I'm not saying I expect that object oriented programming will disappear 100%, what I'm trying to say is that a programmers tool box is getting bigger. A developer will simply have more modern techniques to choose from when programming in Swift.
And what is the point in using less than state of the art tools. Xcode shows errors as you type them, playground lets you execute the code as you type it.
The point is to develop a deeper understanding of what is going on when a piece of software is being developed. The last thing you want in a developer is to have his eye glass over with that deer stuck in headlights look when you tell them you have a embedded system you need them to work on. IDEs are a crutch that distracts from learning the basics.
Now having said that I wouldn't waste a lot of time on compiling, linking and otherwise building an app from the command line. However a comp-sci student that can't do this and understand what is going on is worthless in my mind. I suppose that if you hire somebody to work strictly in Swift for iOS apps you might be OK but the last thing I want is a narrowed minded developer.
One of the most useful classes I took was an assembly language course. Not that I ever programmed in assembly again but it really helps you understand what is going on in the processor.
That's what I've been wanting to do for a couple years now — perhaps because of something you stated previously — but the opportunity hasn't yet presented itself. Programming has been very tough because the books I read seem to focus on what I'd call generic logic and gloss over the syntax, which is where I tend to have the problem with these languages, but there is still a lot of the mechanics of what happens with the code that I'm simply not aware of at this point.
I think there needs to be a distinction between what is high-level app development, and what is real computing science. Universities should refrain from teaching anything vendor specific, but many times lack of funding causes them to sell out, which is unfortunately understandable.
At a high school level, we do not teach science as a single subject, it is meaningless without a focus on biology, physics, chemistry. If CS isn't a requirement to get into post-secondary education, it doesn't need to be standardized to teach core concepts, it only needs to spark interest and give a sampling of what it has to offer. However, if the app development is only as complex as creating a fancy power point presentation using templates, they are only doing a diservice to their students. There are many extremely simple yet powerful examples of computing science that do not require purchasing a roomful of Apple products. It's too bad that computer literacy is not as good as it could be for teachers to teach and create programs themselves and need to rely on this.
The last thing you want in a developer is to have his eye glass over with that deer stuck in headlights look when you tell them you have a embedded system you need them to work on. IDEs are a crutch that distracts from learning the basics.
Now having said that I wouldn't waste a lot of time on compiling, linking and otherwise building an app from the command line. However a comp-sci student that can't do this and understand what is going on is worthless in my mind. I suppose that if you hire somebody to work strictly in Swift for iOS apps you might be OK but the last thing I want is a narrowed minded developer.
I think IDEs just make it more complicated. A text editor + basic make file is arguably simpler to use than an IDE with many buttons, often incorrect error messages coupled with red squiggly lines, and auto-suggest mechanics. Things like auto-suggestions actually make it take longer to memorize very basic command syntax. In that sense the IDE doesn't make it easier at all. The exception might be in debugging in a language like C++, where it's easy to accidentally "step into" something that was included as part of a library if stepping through code.
One of the most useful classes I took was an assembly language course. Not that I ever programmed in assembly again but it really helps you understand what is going on in the processor.
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.
Beyond all of that you really do need to understand procedural programming to some extent as you never get completely away from that. I'm not saying I expect that object oriented programming will disappear 100%, what I'm trying to say is that a programmers tool box is getting bigger. A developer will simply have more modern techniques to choose from when programming in Swift.
The point is to develop a deeper understanding of what is going on when a piece of software is being developed. The last thing you want in a developer is to have his eye glass over with that deer stuck in headlights look when you tell them you have a embedded system you need them to work on. IDEs are a crutch that distracts from learning the basics.
Now having said that I wouldn't waste a lot of time on compiling, linking and otherwise building an app from the command line. However a comp-sci student that can't do this and understand what is going on is worthless in my mind. I suppose that if you hire somebody to work strictly in Swift for iOS apps you might be OK but the last thing I want is a narrowed minded developer.
assembly language at some point to understand what's going on in the processor is fine. Certainly professional programmers/computer scientists should have some understanding of what the compiler/cpu is doing with their code. But not at the high school intro to programming level.
And I disagree on procedural programming. You can build entire apps without ever writing any procedural based code. I will have to watch the video, but protocols aren't a replacement for object oriented programming, they are an enhancement to it.
Embedded systems also aren't a high school level intro programming topic. And they certainly have their own IDEs.
4 years of college for a cs major can get into all of these issues.
Start kids off with something like Scratch so they start thinking about programming objects, then have them move on to swift/xcode/playgrounds to build on what they have already learned. The ones who move on from there will have the right foundation to build off of and they will be learning techniques that they will continue to use.
One of the most useful classes I took was an assembly language course. Not that I ever programmed in assembly again but it really helps you understand what is going on in the processor.
That's what I've been wanting to do for a couple years now — perhaps because of something you stated previously — but the opportunity hasn't yet presented itself. Programming has been very tough because the books I read seem to focus on what I'd call generic logic and gloss over the syntax, which is where I tend to have the problem with these languages, but there is still a lot of the mechanics of what happens with the code that I'm simply not aware of at this point.
Interesting ...
I think it was 1958 when I took my first assembler course at IBM. Prior to that we wrote code in octal absolute. The assembler was called IBM 650 SOAP for System Optimal Assembly Program. The Optimal was related to the fact that the 650 used a drum memory to store the program and the data. The assembler would distribute instructions and data across the drum to compensate for drum rotation latency.
Not very assemblerish or CSIish ... But the programs ran a lot faster when the instructions and data were stored just ahead of where the read/write head was -- when the app needed them.
The point is to develop a deeper understanding of what is going on when a piece of software is being developed. The last thing you want in a developer is to have his eye glass over with that deer stuck in headlights look when you tell them you have a embedded system you need them to work on. IDEs are a crutch that distracts from learning the basics.
Now having said that I wouldn't waste a lot of time on compiling, linking and otherwise building an app from the command line. However a comp-sci student that can't do this and understand what is going on is worthless in my mind. I suppose that if you hire somebody to work strictly in Swift for iOS apps you might be OK but the last thing I want is a narrowed minded developer.
assembly language at some point to understand what's going on in the processor is fine. Certainly professional programmers/computer scientists should have some understanding of what the compiler/cpu is doing with their code. But not at the high school intro to programming level.
And I disagree on procedural programming. You can build entire apps without ever writing any procedural based code. I will have to watch the video, but protocols aren't a replacement for object oriented programming, they are an enhancement to it.
Embedded systems also aren't a high school level intro programming topic. And they certainly have their own IDEs.
4 years of college for a cs major can get into all of these issues.
Start kids off with something like Scratch so they start thinking about programming objects, then have them move on to swift/xcode/playgrounds to build on what they have already learned. The ones who move on from there will have the right foundation to build off of and they will be learning techniques that they will continue to use.
I think that technically you are correct!
But, practically, you have about 10 minutes to grab the kids' interest ... and thinking about programming objects -- ain't gonna' get the job done!
One of the most useful classes I took was an assembly language course. Not that I ever programmed in assembly again but it really helps you understand what is going on in the processor.
They still teach assembly language in a lot of programs. It's just never the first course. A few still use C or C++ as a first language, specifically for manual resource allocation and a rather direct way to write unix system calls. Typically if it's C++, they still treat it more like C, with a few quirks such as the use of std::cout over some variant of printf or occasionally putc (just to demonstrate the concept). Reading assembly is quite annoying, but I'm curious what you find valuable about it. I mean you see that things are explicitly placed in registers and that certain operations such as division take up more register space. I don't know that it offers that much of educational value over C though, especially if only examined at a rudimentary level. Depending on the school, if it's only used in one course, that's 10 or 16 weeks depending on the system (semester or quarter).
But, practically, you have about 10 minutes to grab the kids' interest ... and thinking about programming objects -- ain't gonna' get the job done!
if they are taking a class in high school, you generally have at least 18 weeks and perhaps a full year. Even the very first 10 minute example in a playground is going to be calling objects.
My son is a CS major. His intro class was C++. They did exactly what hmm said above, they used it as C, only had him call std::cin/cout without bothering to first explain they were classes/objects and what a class/object is. Objects were the last thing scheduled for the class, they ran out of time before they got to it.
But, practically, you have about 10 minutes to grab the kids' interest ... and thinking about programming objects -- ain't gonna' get the job done!
if they are taking a class in high school, you generally have at least 18 weeks and perhaps a full year. Even the very first 10 minute example in a playground is going to be calling objects.
My son is a CS major. His intro class was C++. They did exactly what hmm said above, they used it as C, only had him call std::cin/cout without bothering to first explain they were classes/objects and what a class/object is. Objects were the last thing scheduled for the class, they ran out of time before they got to it.
Again, I can't disagree! I re-reviewed the first 10 minutes of Paul Hegarty's Stanford Swift course. He is very firm that you need an understanding of OOP or you will suffer in his course ... then goes ahead and teaches it as if you don't understand OOP -- and provides OOP explanations as needed.
I never attended a a CSI course nor one in OOP -- when I learned to program, those didn't exist (I'll be 76 in August).
Still, from reading, videos, and Obj-C programming tutorials and sample code -- I have a pretty good understanding of OOP.
In Paul's course, for me -- my lack of OOP training was no problem.
If you were taking a class in high school using Swift Playgrounds -- yes they will be calling objects ... but I don't think that the student needs to know or care at that point. Just here's something you need to use, and how, to accomplish the task at hand ... I'll 'splain it later!
Your son is a good example -- how long was he successfully using classes/objects before the Aha moment -- when he realized that he was doing OOP, and needed to flesh out his knowledge of same?
Again, I can't disagree! I re-reviewed the first 10 minutes of Paul Hegarty's Stanford Swift course. He is very firm that you need an understanding of OOP or you will suffer in his course.
And I suffered. I got through several lessons and did all the homework but it was mostly following along and then mostly cargo cutting the rest.
Again, I can't disagree! I re-reviewed the first 10 minutes of Paul Hegarty's Stanford Swift course. He is very firm that you need an understanding of OOP or you will suffer in his course.
And I suffered. I got through several lessons and did all the homework but it was mostly following along and then mostly cargo cutting the rest.
I don't know what cargo cutting means!
Really? From our prior exchanges, I assumed that you had a much broader traditional CSI/OOP background than I.
I am more anal-retentive than most, and want to understand everything about something before I use it. But, had I done that, I'd be the best damn assembly programmer around -- let's talk assembler macro pre-processors ... yes, did that on the Apple ][ ...
BASIC was/is a disaster ... Not until UCSD Pascal was an Apple computer a viable programming platform.
Obj-C on the Mac was very difficult for me -- not the OOP, but the syntax and the multiple, conflicting "best Practices" ...
Just what the hell does a _variableName signify?
To me, Swift is clean and concise (and, apparently, ever-changing )
Really? From our prior exchanges, I assumed that you had a much broader traditional CSI/OOP background than I.
Not at all. I never had the opportunity to learn a computer or any other language as a kid which may be an issue now when trying to learn to code. I also never had access to a computer growing up. I was in my mid-20s when I owned my first computer, which means actually getting to sit down to try to use one.
I got myself into computer networks and security, which i can design and configure, but actual programming is still very much beyond my ken. I am working on it and I am learning, but it's a rate much slower than a child, which is probably because of how children can assimilate languages better than adults. My problem squarely lies with the syntax, not with the logic, but not having a good foundation of the mechanics of how the code and compiler work to create the program is certainly an issue. I have a well establish plan for tackling this and I hope that one day the dozens of app ideas I've written down I'll finally be able to build.
To me, Swift is clean and concise (and, apparently, ever-changing)
It would seem a natural for you???
Swift certainly has made learning to programming much better than attempting Obj-C.
Really? From our prior exchanges, I assumed that you had a much broader traditional CSI/OOP background than I.
Not at all. I never had the opportunity to learn a computer or any other language as a kid which may be an issue now when trying to learn to code. I also never had access to a computer growing up. I was in my mid-20s when I owned my first computer, which means actually getting to sit down to try to use one.
I got myself into computer networks and security, which i can design and configure, but actual programming is still very much beyond my ken. I am working on it and I am learning, but it's a rate much slower than a child, which is probably because of how children can assimilate languages better than adults. My problem squarely lies with the syntax, not with the logic, but not having a good foundation of the mechanics of how the code and compiler work to create the program is certainly an issue. I have a well establish plan for tackling this and I hope that one day the dozens of app ideas I've written down I'll finally be able to build.
To me, Swift is clean and concise (and, apparently, ever-changing)
It would seem a natural for you???
Swift certainly has made learning to programming much better than attempting Obj-C.
Mmm ... I am amazed at how much I misjudge someone by a series of web posts spanning years!
My problem squarely lies with the syntax, not with the logic, but not having a good foundation of the mechanics of how the code and compiler work to create the program is certainly an issue
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!
I am a firm believer in "Learn by doing".
There is only one thing worse than doing something badly -- not doing it all!
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.
Comments
The first part that had me laughing was the bit about "High School iOS instructors". What are we going to see next high school courses for banking, mortuary services, bridge engineering, or some other occupation normally requiring extensive post secondary education. The whole article is a bit surreal.
As for your comment, most high schools don't have a computer science program worth a damn. Even the ones that do try would hardly prepare a student for Swift and iOS. In the end this will end up being a self directed educational opportunity for highly motivated students. The same students that would go out and buy a book on iOS programming on their own.
Here are a couple of examples of how Playgrounds can be used in interactive Swift Programming / Computer Science education: These Playgrounds illustrate:
This shows what could be done -- it is not perfect -- far from it.
For one, It is a resource hog.
Secondly, the narrative is just "there" -- it would be better to let the user interactively show/hide a popup of the narrative and scroll with the code ... maybe a second assistant editor to handle the narrative (and even a best boy to include some video
It's pretty damn good though!
This is the second attempt but to make it short and sweet I have to say I agree.
Beyond that the indications are that this course requires that the student have a background in object oriented programming. I take this to mean a prior comp-sci type class. The people at Apple must be grossly out of touch if they think that the majority of high schools have the resources to pull this off.
In the end I suspect this course will be used in a self directed manner by the same sorts of students that would go out and buy themselves a iOS programming manual. In the end it's availability will have a minor impact on drawing new students into comp-sci.
Objective C is fairly easy to understand as it is a minor extension of C. It is how they use it in the SDK that I find problematic. The only thing you can do is find a good book and try to ignore the practices seen on other systems.
Swift can be useful to an extent without a strong background in Objective C. With each revision it has become more independent than previous version. However it really sounds like your issue isn't the language but rather the SDK. Frankly I find Cocoa to be very frustrating myself especially if you have lots of exposure to other systems.
The only suggestion I can make is to sign up as a developer and download all of the resources and example code Apple has. They do have many examples available to work with and excellent documentation.
Maybe the problem is not too much abstraction -- but, too little abstraction!
For my own education, I recently proved that you could write a usable, multiple-column table (think spreadsheet) app without writing a line of code. * The columns were searchable, resizable, rearrangeable, [un]hideable, sortable, accumulatable and modifiable. Additional rows could be added, in place with optional default values for the various columns. You could select multiple (adjacent or non-adjacent) rows and delete them.
This was done using Storyboards and Bindings on an NSTableview (multiple-column table). iOS does not support multiple-column tables, yet. (However I was able to create a Watch app with a 2-column table).
This leads me to believe that you could make a construct, like a table even easier to use and more accessible (to programmers) by more abstraction.
Consider:
What if you could encapsulate this table and its relationships to its data and the user into a simple fill-out-a-form and voila you display a table -- no need to code: views, tableViews, datasources, delegates, sort descriptors, bindings, etc. -- just an encapsulated table, that includes everything it needs within (efficient, maintainable best-practices code)! on iOS, a list (single-column table) be even easier to encapsulate!
Certainly, there are places in apps where thoughtful, careful coding is required ... rewriting table code is like reinventing the wheel (often badly)!
Beyond all of that you really do need to understand procedural programming to some extent as you never get completely away from that. I'm not saying I expect that object oriented programming will disappear 100%, what I'm trying to say is that a programmers tool box is getting bigger. A developer will simply have more modern techniques to choose from when programming in Swift.
The point is to develop a deeper understanding of what is going on when a piece of software is being developed. The last thing you want in a developer is to have his eye glass over with that deer stuck in headlights look when you tell them you have a embedded system you need them to work on. IDEs are a crutch that distracts from learning the basics.
Now having said that I wouldn't waste a lot of time on compiling, linking and otherwise building an app from the command line. However a comp-sci student that can't do this and understand what is going on is worthless in my mind. I suppose that if you hire somebody to work strictly in Swift for iOS apps you might be OK but the last thing I want is a narrowed minded developer.
That's what I've been wanting to do for a couple years now — perhaps because of something you stated previously — but the opportunity hasn't yet presented itself. Programming has been very tough because the books I read seem to focus on what I'd call generic logic and gloss over the syntax, which is where I tend to have the problem with these languages, but there is still a lot of the mechanics of what happens with the code that I'm simply not aware of at this point.
At a high school level, we do not teach science as a single subject, it is meaningless without a focus on biology, physics, chemistry. If CS isn't a requirement to get into post-secondary education, it doesn't need to be standardized to teach core concepts, it only needs to spark interest and give a sampling of what it has to offer. However, if the app development is only as complex as creating a fancy power point presentation using templates, they are only doing a diservice to their students. There are many extremely simple yet powerful examples of computing science that do not require purchasing a roomful of Apple products. It's too bad that computer literacy is not as good as it could be for teachers to teach and create programs themselves and need to rely on this.
The last thing you want in a developer is to have his eye glass over with that deer stuck in headlights look when you tell them you have a embedded system you need them to work on. IDEs are a crutch that distracts from learning the basics.
Now having said that I wouldn't waste a lot of time on compiling, linking and otherwise building an app from the command line. However a comp-sci student that can't do this and understand what is going on is worthless in my mind. I suppose that if you hire somebody to work strictly in Swift for iOS apps you might be OK but the last thing I want is a narrowed minded developer.
I think IDEs just make it more complicated. A text editor + basic make file is arguably simpler to use than an IDE with many buttons, often incorrect error messages coupled with red squiggly lines, and auto-suggest mechanics. Things like auto-suggestions actually make it take longer to memorize very basic command syntax. In that sense the IDE doesn't make it easier at all. The exception might be in debugging in a language like C++, where it's easy to accidentally "step into" something that was included as part of a library if stepping through code.
One of the most useful classes I took was an assembly language course. Not that I ever programmed in assembly again but it really helps you understand what is going on in the processor.
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.
Beyond all of that you really do need to understand procedural programming to some extent as you never get completely away from that. I'm not saying I expect that object oriented programming will disappear 100%, what I'm trying to say is that a programmers tool box is getting bigger. A developer will simply have more modern techniques to choose from when programming in Swift.
The point is to develop a deeper understanding of what is going on when a piece of software is being developed. The last thing you want in a developer is to have his eye glass over with that deer stuck in headlights look when you tell them you have a embedded system you need them to work on. IDEs are a crutch that distracts from learning the basics.
Now having said that I wouldn't waste a lot of time on compiling, linking and otherwise building an app from the command line. However a comp-sci student that can't do this and understand what is going on is worthless in my mind. I suppose that if you hire somebody to work strictly in Swift for iOS apps you might be OK but the last thing I want is a narrowed minded developer.
assembly language at some point to understand what's going on in the processor is fine. Certainly professional programmers/computer scientists should have some understanding of what the compiler/cpu is doing with their code. But not at the high school intro to programming level.
And I disagree on procedural programming. You can build entire apps without ever writing any procedural based code. I will have to watch the video, but protocols aren't a replacement for object oriented programming, they are an enhancement to it.
Embedded systems also aren't a high school level intro programming topic. And they certainly have their own IDEs.
4 years of college for a cs major can get into all of these issues.
Start kids off with something like Scratch so they start thinking about programming objects, then have them move on to swift/xcode/playgrounds to build on what they have already learned. The ones who move on from there will have the right foundation to build off of and they will be learning techniques that they will continue to use.
Interesting ...
I think it was 1958 when I took my first assembler course at IBM. Prior to that we wrote code in octal absolute. The assembler was called IBM 650 SOAP for System Optimal Assembly Program. The Optimal was related to the fact that the 650 used a drum memory to store the program and the data. The assembler would distribute instructions and data across the drum to compensate for drum rotation latency.
Not very assemblerish or CSIish ... But the programs ran a lot faster when the instructions and data were stored just ahead of where the read/write head was -- when the app needed them.
I think that technically you are correct!
But, practically, you have about 10 minutes to grab the kids' interest ... and thinking about programming objects -- ain't gonna' get the job done!
One of the most useful classes I took was an assembly language course. Not that I ever programmed in assembly again but it really helps you understand what is going on in the processor.
They still teach assembly language in a lot of programs. It's just never the first course. A few still use C or C++ as a first language, specifically for manual resource allocation and a rather direct way to write unix system calls. Typically if it's C++, they still treat it more like C, with a few quirks such as the use of std::cout over some variant of printf or occasionally putc (just to demonstrate the concept). Reading assembly is quite annoying, but I'm curious what you find valuable about it. I mean you see that things are explicitly placed in registers and that certain operations such as division take up more register space. I don't know that it offers that much of educational value over C though, especially if only examined at a rudimentary level. Depending on the school, if it's only used in one course, that's 10 or 16 weeks depending on the system (semester or quarter).
I think that technically you are correct!
But, practically, you have about 10 minutes to grab the kids' interest ... and thinking about programming objects -- ain't gonna' get the job done!
if they are taking a class in high school, you generally have at least 18 weeks and perhaps a full year. Even the very first 10 minute example in a playground is going to be calling objects.
My son is a CS major. His intro class was C++. They did exactly what hmm said above, they used it as C, only had him call std::cin/cout without bothering to first explain they were classes/objects and what a class/object is. Objects were the last thing scheduled for the class, they ran out of time before they got to it.
Again, I can't disagree! I re-reviewed the first 10 minutes of Paul Hegarty's Stanford Swift course. He is very firm that you need an understanding of OOP or you will suffer in his course ... then goes ahead and teaches it as if you don't understand OOP -- and provides OOP explanations as needed.
I never attended a a CSI course nor one in OOP -- when I learned to program, those didn't exist (I'll be 76 in August).
Still, from reading, videos, and Obj-C programming tutorials and sample code -- I have a pretty good understanding of OOP.
In Paul's course, for me -- my lack of OOP training was no problem.
If you were taking a class in high school using Swift Playgrounds -- yes they will be calling objects ... but I don't think that the student needs to know or care at that point. Just here's something you need to use, and how, to accomplish the task at hand ... I'll 'splain it later!
Your son is a good example -- how long was he successfully using classes/objects before the Aha moment -- when he realized that he was doing OOP, and needed to flesh out his knowledge of same?
And I suffered. I got through several lessons and did all the homework but it was mostly following along and then mostly cargo cutting the rest.
I don't know what cargo cutting means!
Really? From our prior exchanges, I assumed that you had a much broader traditional CSI/OOP background than I.
I am more anal-retentive than most, and want to understand everything about something before I use it. But, had I done that, I'd be the best damn assembly programmer around -- let's talk assembler macro pre-processors ... yes, did that on the Apple ][ ...
BASIC was/is a disaster ... Not until UCSD Pascal was an Apple computer a viable programming platform.
Obj-C on the Mac was very difficult for me -- not the OOP, but the syntax and the multiple, conflicting "best Practices" ...
Just what the hell does a _variableName signify?
To me, Swift is clean and concise (and, apparently, ever-changing
It would seem a natural for you???
Not at all. I never had the opportunity to learn a computer or any other language as a kid which may be an issue now when trying to learn to code. I also never had access to a computer growing up. I was in my mid-20s when I owned my first computer, which means actually getting to sit down to try to use one.
I got myself into computer networks and security, which i can design and configure, but actual programming is still very much beyond my ken. I am working on it and I am learning, but it's a rate much slower than a child, which is probably because of how children can assimilate languages better than adults. My problem squarely lies with the syntax, not with the logic, but not having a good foundation of the mechanics of how the code and compiler work to create the program is certainly an issue. I have a well establish plan for tackling this and I hope that one day the dozens of app ideas I've written down I'll finally be able to build.
Swift certainly has made learning to programming much better than attempting Obj-C.
Mmm ... I am amazed at how much I misjudge someone by a series of web posts spanning years!
My problem squarely lies with the syntax, not with the logic, but not having a good foundation of the mechanics of how the code and compiler work to create the program is certainly an issue
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!
I am a firm believer in "Learn by doing".
There is only one thing worse than doing something badly -- not doing it all!
/sermon
Still don't know what cargo cutting means!
I have many other skilsets… just not programming, which I contend hasn't clicked because of the language aspect of it.
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.
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 much prefer to say I Borg other people's code, but Cargo Culting seems to the accepted term.