As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
What languages and tools do you consider a youngster starting out in programming should use in the modern era?
Lots of us started with proprietary Basics and they didn't do all of us long term harm :) but given the experiences you have had since then and your knowledge of the domain now are there better options?
There are related queries to this one such as "Best ways to teach a beginner to program?" and "One piece of advice" about starting adults programming both of which I submitted answers to but children might require a different tool.
Disclosure: it's bloody hard choosing a 'correct' answer to a question like this so who ever has the best score in a few days will get the 'best answer' mark from me based on the communities choice.
I would suggest LEGO Mindstorm, it provides an intuitive drag and drop interface for programming and because it comes with hardware it provides something tangible for a child to grasp. Also, because it is "LEGO" they might think of it as more of a game then a programming exercise.
My day job is in a school, and over the past few years I've seen or taught (or attempted to teach) various children, in various numbers, programming lessons.
Children are all different - some are quick learners, some aren't. In particular, some have better literacy skills than others, and that definitely makes a difference to the speed at which they'll pick up programming. I bet that most of us here, as professional computer programmers and the kind of people who read and post to forums for fun, learnt to read at a pretty young age. For those kinds of children, and if it's your own child who you can teach one-on-one, you could do worse than JavaScript - it has the advantage that you can do real stuff with it right away, and the edit-test cycle is simply hitting "refresh" in the browser. It gets confusing when you start to run in to how JavaScript does everything asynchronously, and is tricky to debug, but for a bright child under close tuition these problems can be overcome.
LEGO Mindstorms is definitely up there at the top of the list. Most schools now super-glue the bricks together to create pre-made models that can't have bits nicked off of them, but this shouldn't be a problem at home. Over on the Times Educational Supplement site (website forum for the UK's weekly teaching newspaper), the "what programming language is best for children?" topic comes up pretty regularly. Lots of recommendations over there for Scratch as an alternative to Mindstorms - bit more freedom than Mindstorms, again probably better for the brighter student who could also be given a soldering iron.
I've found that slower pupils can still have problems with Mindstorms, even though the programming environment is "graphical" - there's still a lot going on on screen, and there's a fair bit to remember (this was an older version, mind - haven't tried the snazzy new one yet). In my experience, the best all-round introduction to programming is probably still LOGO - actually a considerably more powerful language than most people give it credit for. The original Mindstorms book by Seymour Papert (nothing to do with LEGO - they nicked the title of the book for their product), one of the originators of LOGO, is the canonical reference for teaching programming to children as a "thinking skill" and for the concept of Constructionism in learning.
We've had classes of 7 or 8 year-olds programming LOGO. Note that we aren't aiming to make them "software developers", that's a career path they can decide on at some point post-16. At a young age we're trying to get them to think of "computer programming" as just another tool - how to set out a problem to be solved by a computer, in the same way they might use a mind map to help them organise and remember stuff for an exam. No poor child should be sat down and drilled in the minutia and use of a particular language, they should be left to explore and figure stuff out as they like.
I'll second Geoff's suggestions of Phrogram (used to be KPL), and Alice.
My only other suggestion is Lego Mindstorms NXT. The NXT's programming language is drag-and-drop, is very easy to use, and can do some very complicated tasks once you learn it. Also young boys usually like seeing things move. :)
I've used Alice and NXTs with some young kids, and they've taken to it very well.
Two possibilities are:
Scratch - developed at MIT - http://scratch.mit.edu/
and
EToys from the One Laptop per Child fame - http://wiki.laptop.org/go/Squeak
Full disclosure: I'm one of the guys who invented Kid's Programming Language, which is now http://www.Phrogram.com, which others have recommended here. Let me add some programmer-oriented info about it.
It's a code IDE, rather than drag-and-drop, or designer-based. This was intentional on our part - we wanted to make it easy and fun to do real text-based programming, particularly programming games and graphics. This is a fundamental difference between us and Alice and Scratch. Which you pick is a matter of the kid, their age and aptitudes, your goals. Using them serially with the same beginner might be a great way to go - if you do that, I would recommend Scratch, Alice, Phrogram as the order. Phrogram has worked best for 12 years and up, but I know dads with 6 year olds who have taught their kids with it, and I know 10 year olds who have taught themselves with it.
The language is as much like English as we could make it, and is as minimal as we could make it. The secret sauce is in the class-based object heirarchy, which is again as simple, intuitive and English-like as we could make it. The object heirarchy is optimized for games and graphics. 3D models are available, and 2D sprites. Absolute movement using screen coordinates is supported, or relative movement ala LOGO turtles - Forward(x), TurnLeft(y).
The IDE comes with over 100 examples, some language examples (loops), some learning examples (arrays), some fully-functional games and sims (Pong, Missile Command, Game of Life).
To give you a sense of how highly leveraged we made the language and the IDE: with 27 instructions you can fly a 3D spaceship model around a 3D skybox, using your keyboard. The same with a 2D sprite is 12 to 15 instructions.
We are working on a Blade-compatible release of Phrogram that will allow programs to run on the XBox 360. Yeah, the XBox, on your big TV. Nice motivator for getting a kid started? :)
Phrogram includes support for class-based programming, with methods and properties - but that's only encapsulation, not inheritance or polymorphism.
A tutorial and user guide is available,
My own ebook is available at Amazon and other places online, "Learn to Program with Phrogram!," and gets a beginner started by programming the classic Pong.
Phrogram Programming for the Absolute Beginner, by Jerry Lee Ford, Jr., is also available, as a paperback, at Amazon and elsewhere.
For a child, I would go with Alice. Any kid is going to like the drag-and-drop interaction that Alice uses better than trying to remember how to spell and punctuate any programming language. He/She will learn the basic programming structures (conditionals, loops, etc.) and will experience the fun of building an animated program they can show off to other family or friends.
A beginner CS class at the local community college actually uses Alice to teach programming in a language-independent way. It provides a good foundation for moving into programming in a particular language (or a few languages) down the road.
I recently saw a presentation about GreenFoot (a java based learning environment for children). It looked awesome. If I would have kids, I would give it a try
Link to the presentation
It is a very playful environment, where you could start with very basic methods. The kids learn thinking in an object oriented way (you cannot instantiate an animal, but you can instantiate a cat). And the better they get, the more of Java you can uncover for/with them.
I'd go with Scratch, some points regarding it.
It's a graphical programming language. It isn't text based (this might be
positive or negative). It does make it more intuitive and easy for kids (7 and
up).
It's actually highly object. The objects you write these graphical scripts have the code attached to them and can be reused and moved around.
Very Important: quick and impressive results. Kids need to get going fast and get results in order to get hooked.
I'd like to note that although many of us started programing at a young age in basic or logo and because programmer later in life doesn't mean those are good languages to start with. I think that kids today have much better options, like scratch or Alice.
Text based languages (python, ruby, basic, c# or even c) are dependent on external libraries and tools (editors, compilers) while something like Alice or scratch is all inclusive and will teach kids (not aimed at teens) programming concepts. Later they can move on and expand their learning.
Check out Phrogram (formerly KPL) and Alice
I'd say: give the kid a real C64, because that's how I got started. But, today... I'd say Ruby, but Ruby is a bit too chaotic. BASIC would be better in the long run. Processing is easy to learn, and it's basically Java.
The reason I recommend a C64 is because it's BASIC, but you still have to learn certain computer-related things, like the memory model, pixels, characters, character maps, newlines, etc. etc, if you want to do more advanced stuff. Also, if your kid finds it boring, you know his heart really isn't into coding.
I would pitch LOGO. It was something that was taught in my elementary school. It gives nearly immediate feedback, and will teach really basic programming concepts. Moving that little turtle around can be a lot of fun.
For a child, I would go with Alice.
Here is another vote for Alice. My 4 kids have had a ton of fun working with it and learning the basic concepts of programming. Of course to them it's all about socializing with fairies and ogres, but heck the darn legacy system I work on could use some faries and ogres too.
I'd recommend python, because it's so terse and expressive. Seems less likely to frustrate when getting started, but offers plenty of room to learn more advanced concepts as well.
Game Maker might be another approach. You can start simple with easy drag and drop development, and then introduce more advanced programming as you go. The book The Game Maker's Apprentice: Game Development for Beginners has a number of sample games and takes you through the steps required to make them.
I think python is a good alternative; it is a very powerful language also you can easily do a lot of things (not boring at all).
Checkout Squeak developed by Alan Kay who think programming should be taught at early ages.
How old? Lots of us stared with BASIC at some point, but before then, I learned the concepts of stringing commands together, variables, and looping with LOGO. Figuring out how to draw a circle with a triangle that can only go in a straight line and turn was my very first programming accomplishment.
Edit: This question & its answers make me feel old.
Though _why hasn't given it much love in the past year or so, for a while I was really excited about Hackety Hack. I think the key for most new programmers, especially children who are more than apt to losing interest in things, is instantaneous feedback. That was the really wonderful thing about Hackety Hack: a few lines of code, and suddenly you have something in front of you that does something. There are a few similar applications aimed at things like drawing graphics (one of which, I briefly assisted Nathan Weizenbaum on, Scribble!). Kids simply need positive feedback that they're doing something correct on a regular basis, else there's nothing to keep them interested in the task at hand. What I think the future is for teaching children to program is some sort of DSL built on top of a language with friendly syntax (these would include, arguably, Ruby, Python, and Scheme) whose purpose is to provide an intuitive environment for constructing simple games (say, Tic-Tac Toe, or Hangman).
I think you should start them off in C. The sooner they can get the hang of pointers the better.
See Understanding Pointers and Should I learn C.
I think the first question is: what sort of program would it be interesting to create? One of the things that got me started with programming as a kid (in BBC basic and then QBasic) was the ease of writing graphical programs. I could write a couple of lines of code and see my program draw a line on the screen straight away.
The closest I've seen to that sort of simplicity recently are the pygame library for python and Processing, a set of java libraries with an IDE.
I imagine that hacking on web pages would be another good way to get started: that would entail HTML, Javascript (using a library like jQuery), perhaps PHP or something along those lines.
Whatever tools you provide, the crucial thing is for it to be easy to get started straight away. If you have to write twenty lines of correct code and figure out how to invoke the compiler before you see any tangible results, progress is going to be slow.
There are many good suggestions here already. I really agree with Kronikarz. Get a retro computer (or emulator) that you are interested in and teach with that. Why a retro computer? Basic is built in. Making sounds and primitive graphics is a trivial task. The real deal might be better than an emulator because it will be a bit more fascinating to a child who is used to seeing only modern devices.
As I said here, I'd go for Squeakland and the famous Drive a Car example (powered by Squeak).
Smalltalk syntax is simple, which is great for children.
And later as the child evolves, he can learn more complex and even very advanced concepts that are also in Squeak (eg. programing statefull webapps with automated refactoring and automated unit tests!).
And like #cpuguru and #Rotem said, Scratch (also Squeak based) is great too.
I think Java might be a good choice simply because you can make GUIs easily, and see "cool things" happening. For the same reason, maybe any of the .NET languages. I've also heard good things about scripting languages (Ruby and Python, especially) for getting kids to learn how to program.
Well, if they're young and haven't learnt their ABC's you could try them on BF - non of those pesky letters and numbers to deal with.
I'll get me' coat.
Skizz
I would go with what I wish I had known first: a simple MS-DOS box and the integrated assembler (debug). It is great to really learn and understand the basics of talking to a computer.
If that does not scare away a child, then I would go the "next level up" and introduce C. This shouldn't be hard given that the basic concept of pointers, registers and instructions in general are well-understood by then.
However, I am not entirely sure, where to go next. Take the big jump to Lisp, Haskell or similarly abstracted languages or should there be some simple object oriented languages (maybe even C++) be thrown in or would that more hurt than help?
Looking at Alice, I see it is "designed for high school and college students". There appears to be another language/version called Story Telling Alice that is "designed for middle-school students"
Alice Download Page
I think Context Free Art might be a good choice, with output of graphics, it makes it a lot of fun learning about context-free grammar.
Try [Guido van Robot][1]. It's an excellent introduction to robotics, and it's a great way to introduce kids to the programming side of things (vs the "building the robots" side).
Wasn't Smalltalk designed for such a purpose? I think Ruby would be a good choice, as a descendant of Smalltalk.
I know in the first few years of high school we were 'taught' Logo, and strangely, HTML. After that, the progression went to macros in MS Office, followed by basic VBA, followed by Visual Basic.
Related
This Question about how do i learn from basic As3 to advanced as3 , as i want to become professional in as3.And work as freelancer.
can anybody guide me how to reach to the peak of Action-Script-3.
This question seems to be really funny to many but this is the most basic question in my mind
1) which way to go.
2) what steps i should follow.
3) how should i do my first project professionally.
4) how do i become excellent in as3
I believe actionscript 3.0 and Flash in general allows you work on a wide variety of projects:
from interactive rich media web interfaces, to interactive video, animation, games, desktop applications, rich internet applications, physical installations, creative and abstract pieces, etc.
It's up to you what you want to do, but I'm guessing if you start with something that motivates you, something that you enjoy working on and learning, it's a sure way forward
and it will make the boring bits more fun, and that's what it should be about: FUN!
It doesn't matter if it's actionscript or something else you want to learn, enjoy learning/challenging yourself and you'll get there faster than you think.
Answer 1.):
With regards to actionscript, based on what you want to do with it, there are a couple of good starts. Let's say you're interested in just the code, not planning to use the Flash IDE much or at all, and your aim to develop great applications. as #David Morrow said, Colin Moock's Essential Actionscript 3.0 is great. Also his guide From the Ground Up is a compressed version of the book.
An easier lecture, but packed with hands-on tips to getting things done in actionscript 3.0 is Rich Shupe's Learning Actionscript 3.0, also from O'Reilly. This might help you get up to speed with project you might have in mind.
Answer 2.) and 3.):
In short you have at least two routes:
easy/practical start where you learn
by doing small mini projects, but
keep in mind there are gaps to fill
in order to move on to complex
projects
a 'harder'/more theory based start,
that will cover advanced topics, so
you will ready to take most projects
out there, simple or complex.
Answer 4.):
It also important to keep in mind that there is no substitute for experience! Learn how ever it feels comfortable, but plan time for practicing/writing a lot of code/failing/fixing/repeating. Don't worry about getting things wrong! I don't know any programmer that can write a complex project perfectly from start to finish. Basically all projects out there are the result of this loops of failing/fixing/learning/ if you want to put it this way.
Never be afraid of getting things wrong ! You learn more this way, than getting things right, but not fully understanding why, also, you can discover something new. You can't run
into happy accidents if you don't have accidents at all.
As you progress you will like some things more than others. It is important to try everything when you learn. Knowing what you don't like is just as important as knowing what you like. Don't take everything for granted and form your opinions while learning.
You mentioned peaks. It's great to aim high. As I mentioned earlier, actionscript can be used for so many things, that it's hard to be the best in all areas. Andre Michelle and Joa Ebert for example are very talented developers and have a lot of experience with sound. Chris Georgenes on the other hand is a very talented animator. I wouldn't expect roles to swap anytime soon. If it helps, choose people that are actionscript virtuosos, get inspired by their works, there are plenty of them out there.
HTH,
George
understand OOP classes and packages.
Inheritance and polymorphism
keep all content in external xml files
dont ever put any code in your fla
start building a library of reusable classes for common tasks ( a util library )
start working with the Essential Actionscript 3.0 and you are on your way...
read and understand this entire book and you will be rolling
The simplest, yet probably most important answer is: Use it.
The only way you'll become advanced in AS3 (or any language) is to just start using it. Do some experiments, maybe create some small tools for yourself, or find an open source app and start contributing to it.
Books will help, but they're no substitute for actual experience using the language.
As they say, you need to learn to crawl before you can walk.
You need a solid understanding of programming. See David Morrow's answer for things you should know. Also add to the list a knowledge of datastructures.
Start programming. As George Profenza said, start with a simple project first and something that you will enjoy doing. If you undertake something too big you may end up disillusioned. The best thing about working on little things often is that you will encounter certain problems, and you will learn through experience on how to tackle them.
Once you have the basic hang of things start looking at other people's source code. Visit blogs of various well known flash developers and go through their code. Learn from the best. My blogrole is a list of such people.
After a while, maybe a year or so you will be a decent AS3 programmer. Remember AS3 is just a tool. What seperates the men from the boys is being able to solve problems. Start tackling more complex problems, for example, develop a voxel engine or something along those lines. The best programmers tend to experiment with problems in the field of computer science. In doing so, they become knowledgable on various things like 3D rendering, Audio etc and develop unique skills placing them on the cutting edge.
Well I'm a visual programmer, i only learn as a means to an end - I want to make things.
If you are as i am - then here's what I recommend to go from basic AS3 to advanced AS3.
Make a game. OR, and this might be an even better route.
Clone a game that you like - e.g. tetris, bomberman, pacman
I know it a single statement answer.... not fancy, but - you will HAVE to learn so much in the process of creating it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've been coding since my early teenager years. I started out with HTML, went on to PHP/MySQL (created my own forums, social networking sites, etc..) and then branched out into more traditional languages such as Java and C++ (also picked up a little VB .NET in high school). I'm most familiar now with C++ as that is the language of choice taught to us in Computer Science II (skipped Comp Sci I) at RPI. I now feel like I have a very good knowledge of how to program from this class (the homework assignments were brutal).
It is now summer and I am interning at a company that is providing me some level of new experiences with programming, but I want more. I want to feel the incredible satisfaction that I got out of my computer classes at RPI whenever I finished a long assignment (generating every possible wordsearch from a set of words to include and exclude comes to mind).
My question is, where do I go from here? I tried following a tutorials online, but they were all too simple. I then tried heading over to sourceforge and helping out with various projects. But, as soon as I downloaded the code I got lost in its complexity. I have never created actual software of a real life applicapable scale. And I don't know where to get started. How do you transition from programming knowledge to actuall creation of software?
I'm also open to learning new languages (javascript/jQuery, ASP .NET, C#, Python), or using new libraries and/or frameworks with c++ (we only used the STL in Comp Sci II) and other languages. Again my question is, where do I go from here? And I am welcome to all possible answers.
Thanks Much,
Michael
You could join a big open source project, you'll learn a lot and accomplish something cool.
EDIT after comment: If this is too complicated for you, try starting a "real" project. I say "real" because it should be something that you want to do, not a "create a blog" or "how to do a loop". For instance last year I created a fully functional project management system that I now use for some of my projects. If this is real, you will be more motivated and you will want to get this done.
Pick the technology you want for it. I'd recommend Ruby on Rails because it's awesome and full of interesting concepts that will improve the way you code overtime (DRY, RESTful, MVC...)... but you can pick whatever you want.
Try to create your project using what you know and basic tutorials. You will get stuck and have to learn some more in order to get the features you want going. To me that's the best way to improve the way you code and general programming knowledge.
Since you'll start the project from scratch, you'll see where to start and how this will evolve. I'll take the project management tool. We started with "A project has todos" and we ended up with all kind of other features such as a complex calendar, a full ajax interface, a embedded chat...
Once you see how you did this, try doing the same with a friend of yours to get a fealing of teamwork in development. Learn how to use SVN, basecamp... learn about software development processes (Agile!), peer programming..
There's a lot to experience! Then you could give open source another try.
Hope that helps
I'd recommend trying a pure functional language, such as Haskell. It's a completely different way of looking at programming, and I found it very satisfying.
I recommend the book Real World Haskell for learning it.
Edit: In response to comments, my interpretation of the question is where can he go from here as a programmer. Functional programming is a logical direction. For someone learning functional programming for the first time, Haskell is nice because it doesn't really allow for imperative programming practices. Furthermore, it has basically all features you will find in other functional languages, which means it will be easy to pick up other functional languages.
I would suggest looking at Project Euler. It's a great and fun way to learn a new language, and it does provide that level of satisfaction when you solve the problems. They offer a huge range of problems at all levels of difficulty.
I think the best way to improve your skills as a programmer is to do what programming was intended for: solve problems. I'm sure you've been playing around on your machine and at one time thought to yourself "I wish there was a program that did this..." or "I wonder if there are any programs that do X..." Instead of just googling to see if someone else wrote it, write it yourself. Start with something small, and gradually make it more complex. Add features. Allow yourself to fail, and when you do, ask yourself (or us at stackoverflow) how to overcome that obstacle. Once you have the basics of programming, everything else is just making big things out of littler things, and the little things are usually pretty easy.
When you are making something you know you will actually use, it's more fun and more gratifying when you finish.
Do you understand all of the following and how they work?
Linked lists (single and double)
Sequential vs. binary search
Binary trees
Stacks
Red-black trees
Algorithmic complexity and big O notation
Recursion
Hash tables and hashing algorithms
If you don't feel completely conversant in any of these, take a class in data structures and algorithms.
It seems like you've experienced many languages, but have not created a real-world application. Creating software in any of those languages will bring you to a new level.
PS: Creating software is much more than just knowing how to mess around with a language.
Check out Design Patterns.
I believe that's beyond mere simple coding.
You could offer your abilities to a non profit or a friend or someone who needs a website or program built.
Tell them you can do it for free and then just go for it. As you start to make it you'll start to see what you need to learn.
For example I bit ago I had the program Peel www.getpeel.com on my Mac. But sold my Mac for Wind as I am traveling.
Seeing that there was nothing for Windows (or nothing I could find) like Peel. I build my own in PHP and am up to a 4th rebuilding of it as I learn betters ways to do each new thing I am learning.
You've got to find a particular type of functionality that interests you. For me it's been basic socket programming and making my own protocols. I got that feeling when I was able to create a functional file uploading control that worked in conjunction with a file upload service on the server which I had created. The protocol handles authentication, chunking and hash comparison. Sometime soon I plan on incorporating file-resume functionality as well.
Well my advice will be to find a problem/project you are interested in and try to code it. Trying a real problem is something that drives you. Find something not to complex but not too simple. Something to try when starting a new language is to write some tools. You can for example program a python script that print metrics on a C++ project. You can write a tool that extract some statistics from a website you use, etc. When I learn programming game programming was quite fun (I was young :-) ). You can try to program some simple game using a 3D engine like Ogre3D for example. Participate in an opensource project is great too but as you stated perhaps a bit overwhelming for now ;-)
Find something you like and that has a REAL useful goal for you. You will thrive to solve the problem and learn a lot along the way !
I think the transition from the kind of finite tractable problems that are part of class projects (and some internships) to "real world" projects is quite tough. Sounds like language syntax, getting bugs out of code etc. is something you are comforatble with.
When we come to larger projects, probably with many release cycles, with developers working together, different kinds of problems emerge. I remember being shocked when I saw my first big project plan - what a small propertion of the time was actually writing code!
The thing I found helpful as a junior was "Sitting By Nelly", I was lucky enough to work for enlighted employers who put me with very experienced and helpful developers. Sometimes to work with, sometime to work alongside. I reckon that helped me get over the hurdles you describe.
So, I reckon you need to find employment of this kind. Be less concerned about specific technologies, salary etc. Look instead for the culture and level of responsibility you would have.
I think you should really start a "real world application" as suggested here. You will see that a real project requires a bit more than just knowing the language.
I suggest you find some simple problem you had issue with, and make a software that solves that issue.
For example, if you want some kind of software that checks RSS feeds every 5 minutes and makes a little pop-up as soon as a new one comes along. Or you want a program that will let you do simple presentations by just dragging a few pictures in.
Then whatever you choose, start by making the simple solution to the problem and extend from there (like do different settings, extra features etc.)
I've looked for the answer to this question for a while now. Most all of the suggestions are usually either help an open source project or build something that interests you. I'm starting to realize that those answers are vague because what's 'interesting' or 'valuable' experience and how to get started doing it is completely subjective. Also, there's only one way to get real experience, which is to work on real projects. It's difficult but find a project, personal, open source, or otherwise that will increase your knowledge in a technology or platform that you think will hold your interest. Then just dig in. It doesn't have to be of earth shattering importance, just valuable in relation to your own goals.
There is no magic bullet transition from academic puzzle solving programs to real world applications. The best way to learn is just to jump in head first. It will take you a very long time to learn what you need to if you only ever look at your own code. You need to be looking at code written by professionals and struggling to understand why it works the way it does until you do understand it.
It seems overwhelming at first, but you will quickly start to see patterns if the application is at all logical. Well written code will be separated in logical ways, so you should be able to pick it apart one layer at a time.
For example, you could try a bottom up approach where you try to understand how the database interactions are handled before looking at the code that uses the database layer. You keep going upward until you get to the GUI event handlers.
Large enterprise applications can be even harder to understand because there might be a lot more than one executable, or component. Try to stay focused and learn what the component is responsible for doing, and then pick it apart a piece at a time.
You will see that there are not just patterns at the function and class level, but at higher levels as well. This makes it simpler to understand what is going on when you understand those patterns.
Try to find an internship or co-op position. I was in a similar situation after my first few courses. I took a co-op position sophomore year and I learned so much more on the job than I did in class. Class is great for teaching you theory and the basics. I learned C# on my first project on my co-op and that got me my second co-op position at another employer (wanted to see how it was working at a small company).
This past spring, I accepted a position at my first co-op employer, reworking my first major project I had started on my co-op. I have a list of side projects I also want to complete, which will help round out my skills, as well as learn some other languages.
So my suggestion is try finding a job where you can have a great mentor. On my second co-op, I learned alot of the coding standards that I code against from my supervisor. He was a great teacher, and really had some great input, and explained why things should be done certain ways.
You will almost certainly go nowhere unless you find something that interests you. Figure out what is interesting, and then how to write software involving it.
The only way to begin is to begin! There is really no other way... The best answers you get would always tell you this. You have the knowledge, now put it to work!
What are your criteria or things that you consider when you are an early adopter of a programming language or technology?
Two of the most common explanations I've heard are:
It should be "fun" (what I've heard from technical people).
It should be capable of solving our problem (what I've heard from business people).
So what's yours?
I've made this change several times over my career spanning various companies, moving from C to Java to Ruby to Haskell for the majority of my software development.
In all cases, I've been looking for more expressive power and better abstractions. This is always driven by business needs: how can I develop better software more cheaply? To me, the challenge of this problem is "fun," so fun rather automatically comes along with it. Justifying the business value to managers can be difficult, however; they often don't have the technical skills to understand why one programming language can be better than another, and are worried about moving to technology that they understand even less than the current one. (I solved this problem by taking over the manager's job as well: I started a company.)
It's hard to say what exactly to look for in a new language. You obviously don't have a detailed grasp of the language, or you would already be using it or know why you're not. Vast experience will bring an instinct that will make certain languages "smell" better than others, but—and this can make it especially hard to convince others to look at a new language—you won't know precisely what features give you big advantages. An example would be pattern matching: it's a feature found in relatively few languages, and though I knew about it, I had no idea when I started in with Haskell that this would be a key contributor to productivity improvement.
While it's negative ("avoid this") advice rather than positive ("do this") advice, one fairly easy rule is to avoid spending a lot of time on languages very similar to ones you already know well. If you already know Ruby, learning Python is not likely to teach you much in the way of big new things; C# and Java would be another example. (Although C# is starting to get a few interesting features that Java doesn't have.)
Looking at what the academic community is doing with a language may be helpful. If it's a fertile area of research for academics, there's almost certainly going to be interesting stuff in there, whereas if it's not it's quite possible that there's nothing interesting there to learn.
My criteria is simple:
wow factor
simple
gets things done
quick
I want it to do something easily that is hard to do with the tools I'm used to. So I moved to Python, and then Ruby, over Java because I could build a program incrementally, add functions easily, and express programs more concisely (esp. with Ruby, where I can pass blocks/Procs and have clean closures, plus the ability to define nice DSLs making use of blocks and yield.)
I took up Erlang because it expresses Actor-based concurrency well; this makes for easier network programs.
I took up Haskell because it fit with a number of formal methods tools I wanted to experiment with.
Open source.
Active developer community
Active user community, with a friendly mailing list or forum.
Some examples and documentation, preferably a tutorial
Desirable features (solves problems).
If it's for my personal fun, I need very little excuse, as I do love learning new things, and the best way of learning is by doing. If it's for an employer, customer, or client, the bar is MUCH higher -- I must be convinced that the "new stuff", even after accounting for ramp-up effects and the costs that come with being at the bleeding edge, will do a substantially better job at delivering value to the client (or customer or employer). It's a matter of professional attitude: my job's to deliver top value to the client -- having fun while so doing is auxiliary and secondary. So, in practice, "new" technologies (including languages) that I introduce in a professional setting will generally be ones I've previously grown comfortable and confident with in my own spare time.
Someone has once said something to the effect of:
"If learning a programming language doesn't change the way you think about programming, it's not worth learning."
That's one metric (out of many) to judge the value of learning new languages (or other technology) by. Using this, one might suggest learning the following languages:
C, because it makes you understand the Von Neumann architecture better than any other language (and it's sort-of random-access Turing Machine like, sorta'...).
LaTeX (as a programming language, not only as a typesetting system) because it makes you learn about string rewriting systems as a model of computation. Here, sed is similar; learn both, because they're also both useful tools :-)
Haskell, because it teaches you about functional programming, lambda calculus (yet another model of computation), lazy evaluation, type inference, algebraic datatypes (done with ease), decidability of type systems (i.e. learn to fear C++)
Scheme `(or (another) ,Lisp) for its macro system, and dynamic typing, and functional programming done somewhat differently.
SmallTalk, to learn Object-orientation (so I hear)
Java, to learn what earning money feels like :D
Forth, because wisdom bestowed forth learned implies.
... that doesn't explain why I learn python or shell scripting, though. I think you should take enlightenment with a grain of salt and a shovelful of pragmatism :)
Should be capable of solving the problem
Should be more adequate to solve the problem than other alternatives
Should be fun
Should have prompt support, either from a community or the company promoting it
A language should be:
Easy to use, to learn and to code in.
Consistent. Many languages have 50 legacy ways of doing things, this increases the learning curve and turns quite annoying. C# for me is one of those languages.
It should provide the most useful solution with the least amount of code. On the other hand sometimes you do need a bit of expressiveness to make sure you're not making a huge mistake.
The right tool for the right job and maybe the right tool for any job
My criteria that the language should have:
1. New ideas - If the language is just another Scheme variant, if you know one than I don't feel the need to learn this new one. I will learn it if I think I will learn something new.
2. Similar to another language, but better. For example, while Java and C++ have many of the same ideas, Java's automatic garbage collection makes it a better choice in many cases.
Gets the most done with the least amount of effort
Extremely interoperable with different protocols, out of the box
Fast
Has lots of libraries built in for stuff 99% of web developers do (PDF's, emailing, reporting, etc..)
It depends on why I'm learning the new language. If I'm learning it for fun, then it has to meet these criteria:
Is well it supported on my platform?
Something that runs only on Linux
isn't interesting to a Windows
programmer.
Will I learn something new? In
other words, does it come up with a
new way of doing things?
Does it look fun? I don't want to learn Ada even if it has new ways of doing things.
If I'm learning it for work, the criteria are different:
How mature is it? Has it been
proven to work in the real world?
How big is the community?
Will it make my job easier? I.e. is
it worth the time investment versus
just doing the task with a language
I already know.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I guess, the following is a standard problem on every school or university:
It is Your job to teach programming. Unfortunately, some of the students
are semi-professionals and have years of experience while others do not even know the basic concepts, e.g. the concept "typed variable".
As far as I know, this leads to one of the following situations:
Programming is tought from its very basics. The experienced students get bored and discontinue to visit the lectures. As a consequence, they will miss even the stuff they do not already know.
Teachers and professors claim that they require basic knowledge (whatever that means). Inexperienced students cannot follow the lectures and a lot of them will focus on unimportant stuff (e.g. understanding every detail of a complex example while not getting the concept behind the example). Some of them will give up.
Universities invent an artificial programming language to give experienced programmers and newbies "equal chances". Most students will get frustrated about the "useless language".
Is there a fourth solution, which is better than those above?
IMO this is a problem based on the placement of the students, not something you should be too interested in dealing with on your end as a teacher.
If the course is an introduction to programming a computer, then you really need to start with the basics. If you have a classroom full of professionals who know how to program and they don't show, it was either a problem with your course description, or the school forcing them to take the class as a pre-req without allowing them to test out.
Your job should be to describe what you want to teach in the course description, and teach it. If students enroll who are overqualified, that's their problem. I think the only thing you really need to avoid is trying to make the course too advanced for beginners if your course really is for beginners.
I think the best way to keep it interesting is to bring up practical and interesting exercises along the theory. Taking a problem-solution approach is great (with interesting, funny, exciting, real-world problems). This requires the professor himself to have hands-on experience, work with new technologies and know them pretty well and not just teach what he had learned a couple decades ago.
The thing is, programming should be learned by practice. The instructor should focus on motivating students to code and try to solve problems themselves. This can be done by assigning a complete life-like project at the beginning of the course and working through the subproblems that occur in the project in the class. This way, students will have an idea why some specific feature in the programming language exists and where it might be useful.
Just a thought though. Not tried it! ;)
I recently attended a course in which there was a very wide spectrum of experience in programming among the students. They still managed to keep the experienced programmers in the class interested by having an exercise program in which they timed the practical parts of the exercises (the programming part), and posted the results in a high score chart. At the end of each lecture, the professor gave some pointers as to how we could improve our times even more. As we all know, all engineers love competing for topping such lists, so we kept showing up, and even learned a new thing or two.
The inexperienced students managed to complete the exercises too, even if they didn't care too much about their times.
Don't know if your course is one that can implement this solution, but if it is, you should really consider it.
I think there are a couple if things you can do to help bridge the gap between advanced and beginner students and to keep everyone interested and involved in the course.
Advanced Workshops
If it can be arranged (using PHD students etc.) run an optional weekly workshop which anyone can attend, but which is aimed at the more experianced students. Set a code task / challange each week and then at the workshop go through various solutions to the problem and discuss the implications and the theory behind the different choices.
This provides an interesting challange for the more experianced coders as they have something to get thier teeth into. It opens some debate and can help intermediate people grasp interesting concetps and if you get people to present thier solutions, it introduces an open reviewing style which is beneficial. It also helps the beginners in that you don't have to present them with really advanced concepts in the main lecture series just to keep the experienced people interested.
Student Involvement
Experienced people generally are experienced because they enjoy coding etc. and a lot of people love to share their knowledge. A really good way to use this, and to help both beginners and advanced students is to get the more advanced students involved in the teaching. If you run classes/labs where students complete exercises, try getting volunteers from the more experienced students to act as mentors/ supervisors for the labs. When the beginners struggle they can help out by explaining fine details or subtleties etc.
This can really help the beginners, as there are never usually enough staff available for everyone to be able to ask individual questions. It can also really benefit the more advanced people, as having to explain concept which you "know" is a great way to reinforce them in your own mind, and even to discover that you have subtle misunderstandings in your own knowledge.
Don't assume more than you need to; try to select programming environments which don't have too much intellectual baggage. You may think a C "Hello world" program is simple, but that requires understanding source files, compilation, static typing and block structuring. There are not easy concepts for a beginner. In comparison, typing "print 'hello world'" into a Python shell avoids them. Declarations, compound types, object orientation, pointers, floating point, recursion, modularity, threads, callbacks, modularity, networking, databases and so on are all major concepts which require effort to learn. And, there are plenty of fun things to be done without them. Your goal should be to get everyone in the group doing programming exercises as soon as possible.
Mixed ability teaching is hard; stream it by splitting the group up if you can. Maybe publish a quiz of basic concepts, and have an optional basic concepts section for those who didn't get 100%. Some people think they are experienced programmers but have misunderstood basic ideas.
If the course time available is too short to let people try lots of exercises, then I'd drop the more advanced material before I dropped practical work.
In one course I took, a large part of the course grade was derived from a end-of-term project which was announced in advance with extra credit available for assorted add-ons and frills. Sufficiently experienced student could start working on it while their less prepraed brethren were being taught the basics.
But as Dave Markle says, part of this is a matter of getting the right students into your class: you really want a cohort that is fiarly well matched at the start.
If you have many experienced students or this is an upperclassmen/graduate level-course, you should focus on integration into existing ecosystem. Being able to understand and integrate into an existing project rather than to always work from scratch is the most important skills you can give to give to those students.
Thus, programming assignments should come from real world scenarios. E.g., assign them tasks in an open source project. This can also make it more interesting, especially as their work may become part of a real world project.
If it's really beginners, tough luck, you will have to stick to the basics though if the students are non-CS majors, you can create problems from their own domains (e.g., engineering, chemistry, etc.)
I think your could be toast.
After some point, the difference is just to wide. It will take the whole year to get the beginners to the point that they can even understand stuff that wont bore the more advanced people.
However this clearly depends on the topic and setting. For some combinations of those the solution is teach to the level that the class is billed for. Those that are to advance will get board and quit, those that are to inexperienced with fall behind and quit. Don't worry about it to much as neither should have taken the class anyway. If on the other hand they need to take the class then some one further up the ladder messed up.
Sitting in your chair watching someone talk is boring (even if you talk well).
Things are interesting if you can achieve something, when you can manipulate the world and have a moment of success. So add as many practical exercises as you can and make really sure that they can do them in time and that they can do them successfully in time.
Nothing is more frustrating than to hear: "Well, I'm sorry that you couldn't complete it. You can find a solution here. Let's copy that and pretend it did work and move on." Examples during a course are simple and the people in front of you know that. So if they can't even solve the simple examples you bring along for them, what are they going to think?
I always think it is best to learn through practice. At the beginning of the course especially it is incredibly boring to teach language syntax in a lecture. It is far better to require your students to complete some work on their own or in a lab with assistants. This allows the more experienced students to get through the work quickly.
Once this is done you can have a lecture where you discuss some of the solutions to problems. Why they are good and why they are bad.
This works especially well if you also structure your course in such a way that students are always building on their rpevious work. The first week can be something simple like calculate how many days old I am from my birthday. A problem that is relatively simple mathematically but has a few weird cases. This might take several hours for someone inexperienced. Especially if they are learning syntax at the same time. But it gives them a simple goal to work toward.
After this you can expend on it. eg: take lasts weeks program and add functionality that allows it to batch process a file. This teaches people the importance of restructuring and refactoring, and can be expanded week after week. You may even want to distribute a good piece of work from the previous week for those that are falling behind to use. Obviously you will need to make sure people don't get too far behind, but this is a nice way to make sure that everyone feels that they have a fair shot at it even if their previous week's work wasn't too good. Those who are doing well will end
The key is to keep your lecture sessions relatively high level, and have people learn the syntax on their own, or with lab assistants. You can teach them different ways of thinking about a problem but the actual act of writing code is much easier to learn by doing it.
I once through a scheduling nightmare ended up teaching a beginner class and an advanced class in the same classroom at the same time. What I did was divide my time between the two levels by starting out giving the advanced group an assignment to do in class while I worked with the beginners and then giving the beginners an assignment while I worked with the advanced. You could do something similar (only having the groups self-select into the group they wanted to be in). Prepare some extra material for the more advanced ones and you are off to the races.
Another strategy is to keep everything at the beginner level, but offer the more advanced students some other material to do for extra credit (or even as substitution for some of the simpler tasks you require of the beginners). Discuss the more advanced assignments with them outside of class or individually while the class is working on practical work in the lab.
Keeping the lectures interesting with plenty of real world examples is helpful too. I tended to lecture as little as possible though and present the material more through class discussion and practical exercises and through asking leading questions. Making them find the information to answer your questions (and class participation was part of the grade) will make them pay more attention.
I also ended each semester with a course project that I only described what they had to do in order to get a B. An A would involve doing work beyond that including work in an area not covered in class. The more advanced students can then really shine by looking for really cool new things to do and even the beginners usually find a way to do something not covered by the course. It's amazing how much extra effort they will go to when they don't know how much more they have to do to get an A. Other instructors would be amazed at the quality of the end of the course projects I got and several of them started using the same method.
It may be better to break up a few areas of concern with what some would call, "Introductory Programming":
1) Introduction to personal computers and modern computing. Assuming that the course's software runs on windows, there may be some that need to cover the basics of a computer, e.g. what is a hard drive, keyboard, mouse, monitor, CPU, motherboard, etc. Note that this has nothing to do with even one line of code other than naming operating systems potentially. For some people this may be new to them and thus having a course that covers the basics, may well be worth it. Also in this course would be ways to use a mouse and all its various buttons, what are the various kinds of cables and connections people have, what are drivers, what are patches, what are parts of a network, e.g. firewall, router, load balancers, etc. The idea here isn't to get into how to configure a firewall perfectly, but rather that the person understands what various hardware components are for and possibly how to configure a home wireless network as the most complicated concepts taught.
2) Principles of programming. This would start with the idea of what are the steps are there to execute a sequence of commands. Things like printing and performing Mathematical operations, e.g. converting from Imperial to metric,would be covered with possibly sorting being the most complicated example, viewed from a variety of different algorithms and an understanding at a basic level of big-O notation.
3) Introduction to Data Structures and Advanced Programming. Now, let's introduce the concept of a relational database and how databases work in general and have projects with real world application, e.g. have each student take a list of something they have like DVDs or CDs and put these into a database schema to efficiently store all this data. Also, the idea of floating point arithmetic and its limitations, e.g. that a computer doesn't store the whole value of pi but rather an approximation that should be good enough in most cases.
4) Introduction to Parallel Programming and Operating Systems. Here you would have some in depth work in building an Operating System and handling how to write code that can run concurrently or in Parallel and how efficient are various programs under different circumstances.
That is how I could see someone breaking up programming so that it isn't where someone can learn in a week enough to pass the final without looking at anything else.
I have frequently been in this situation, first on the student side of things, and then on the teaching side.
Most schools force those sort of courses and their curriculum. This is silly, but such is life. If your school does allow it, I would suggest offering students attendance waiver if they pass an early screening test. It is in your interest and the interest of the freshmen to not sit in a class where a significant portion of the population is bored. Even being in a room with tons of people starting at their laptops harms discourse. Everyone is required to attend tests and submit assignments, but they at least don't have to show up.
Once you work with the novices, figure out if they're majors or nonmajors. Nonmajors will resent being in a CS course, you have to try and make it approachable for them. E.g., use examples from physics or chemistry or math rather than from building an interactive gui system.
If they're CS majors, they'd better damned be interested :)
My opinion is that teaching sample programs is dead-boring for most people. Searching, sorting, classification of 7-bit ascii input, using unix & make, opening a file, writing a file...
These are boring problems. Regardless of their importance/usefulness, these are tools. Unfortunately, tools are what's taught in intro courses, not problems.
But you need tools to be able to solve a problem. So it's a kind of chicken-egg problem.
Real world examples of code the student can imagine themselves doing out of their free time.
I remember a teacher telling me to use const values it was the tax of something. I only had to use the value in two places. She asked what if i need to change it i said its only in two places and i'll change it by hand also i couldnt imagine the gov ever changing the tax %.
I cant think of an non complex example where i would use a const so i wouldnt try teaching them to use that but for arrays i would simply write a guessing game then when the player wins the game, it plays back all the guesses in the same order to them. There is no easy way to do that w/o arrays and i could see how keeping track of someones steps/guesses would be useful (bragging rights to how quickly a person guessed it).
On the first day give the syllabus (what they will learn) and required basic knowlege (things you must know or else not take this class) and stick with it. After these all you can do is teach well (explain things well, answer questions, give a joke or two now and then etc). Caring who attends class, whether or not the field is boring, whether student lied about pre-requisites or not, who listens and the other yada yada is beyond your controls. Besides, you should expect adults to be adults. If students skip class and ace test, maybe that is best for them. If they skip class and bomb tests, well maybe they are in the wrong place.
I hated when professors had this mentality when I was in college. Now as a working professional I understand it.
Center the programming exercises around either sports or movies.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Courses for people who are being introduced to programming very often include a code project, which I think is a nice way to learn. However, such projects often feel too artificial, and are thus not very rewarding to work on.
What are your ideas of rewarding code projects? (Preferably easy to begin, and extendable at will for the more advanced!).
Edit:
#Mark: thanks for the link, though I'm more interested in projects for people who are completely new to programming (the link seems to refer more to people who are already proficient in at least one language, and trying to learn a new one -the typical SO audience I'd say :) -).
#Kevin, Vaibhav, gary: I was thinking of people who are learning programming through one language, so at the beginning of the course some don't know anything about control structures (and even less about any kind of syntax). However, I was thinking in quite a large project (typically in the 1k-10k lines of code range, possibly in groups of 2 or 3 students). This is what was done at my school for the complete beginners, and it sure seemed to work for them... except that most of them found their projects quite boring to work on!
As has been stated a few times, what you are trying to teach the beginner is very important to the project.
My advice to you for planning something like this:
1) Avoid making a computer game
A computer game, while fun to build, doesn't reward the programmer with results early on (it's very complex). You want to concentrate on small but useful application programs, such as a Port Scanner. The example there is a little complex, but it's one of the best learning projects I've seen on the web.
2) Teach graphics early
It's rewarding to see the fruits of your labors early on, and it motivates you to go further. Whether you're using WinForms, MFC or the Win32 API, OpenGL or DirectX, teach it early.
3) Many small lessons with in depth information
This principle is followed by the above linked Port Scanner project, and it works well. Teach each part thoroughly, and give time for the beginner to absorb the lesson. I think that ZophusX had a good format for giving the information. It's too bad he's mostly abandoned his site.
4) It takes time
Don't rush things. Nobody becomes a stellar programmer in a few weeks. Try and make the lessons simple, but engaging, and keep building from your previous lessons.
5) Get feedback early and often
You might think a project is incredibly interesting, or a particular lesson or such, but you aren't the one learning. Your student(s) will greatly appreciate it when you ask them early on how things are going, and what they'd like to know more about. Be flexible enough that you can accomodate some of those requests.
6) Have fun teaching
Have fun. Passion is contagious, and if your student(s) see how much you enjoy the subject matter, some of that enthusiasm will rub off on them as well.
I hope that helps!
Some good rewarding projects, in terms of what you can learn and which are quite scalable in terms of complexity, features are:
Games
A travel and transportation reservation/booking system
Encyclopedia or a Dictionary of terms, articles
Conversion Calculators (Currency, Units, etc.)
The key is to pick a project simple enough, so that some of its features are immediately apparent, when you look at the project title. And when really given a thought, will reveal more features that you can add to it.
The project should have enough difficulty to so that its features seem just beyond the beginner's reach, thereby motivating him to learn something new all the time.
If you are training new people in your company, then attaching them as intern resources on a live project is very rewarding.
This increases the work load of the main developers a little (because they have to review all the work that the intern does), but goes a long way in terms of training and development of the person.
I do think that games and puzzles are a good place to start as they can give great scope for developing more complex versions. For example a tic-tac-toe program can be built as a simple command line program initially that lets two players play the game.
This step can be used to show how a simple data structure or array can represent the game board, simple input to get user commands/moves, simple output to display the game board and prompts etc. Then you can start showing how an algorithm can be used to allow player vs computer mode. I like the simple magic square math algorithm for tic-tac-toe as it's based on very simple math. After this the sky's the limit, UI improvements, using file I/O to load and save games, more advanced algorithms to get the computer to play better etc. More complex and satisfying games can still be produced using text mode or simple graphics.
I've used the Sokoban game as a means of showing lots of techniques over the years.
The simplest game I've used is a number list reversing game. This involves a mixed up list of numbers from 1-9. The player can specify a number of digits to reverse on the left of the list. The aim is to get the list sorted. This is great for absolute beginners. Each little part of the game can be written and tested separately.
It really depends on what you're trying to teach the beginner. If you're trying to teach syntax, then simple "Hello World" programs and ones that spit out every odd number between 1 and 100 are fine to get them started. If you're trying to teach data structures, then maybe something like a 20 questions game or some simple sorting program. If you're trying to teach recursion, then maybe a breadth first search program. If you're trying to teach database manipulation, then something like a order tracking system would be appropriate.
Take a look at code examples in the book Python Programming for the Absolute Beginner
Text Adventure.
It's a console app
You'll need to do some useful things, hold inventory, map and room state and parse input
It's fun and you can give it to others to play! :D