This online tutorial grossly overestimates how much the layperson understands about computer languages. For the complete beginner, far too much is left unexplained.
No one actually codes using a REPL in a browser. Yet the site makes no attempt to explain why or how this REPL exists, or how it works.
It doesn't explain why I can only type in certain places on the screen.
It doesn't explain how to try again, or undo mistakes.
It doesn't explain why a string must be surrounded by quotes, but numbers must not be.
It doesn't explain why suffixing `.length` to a string (but not a number) does anything, versus any of 50,000 other English words I might have put in its place.
It's confusing that there are three sources of errors: those from the language, those from the tutorial, and those from the browser/internet. Where is this program running? Where does the code live? How does this code turn into action? How does the tutorial know what I'm doing?
Codeacademy doesn't explain how any of this magic happens. It just plops you down in front of a REPL and tells you to echo specific things.
Coding is not about learning the syntax that lets you type "Ryan".length. It's about learning the underlying concepts: the "why", not the "what".
Funny. There is a series of books by Zed shaw called "Learn 'x' the Hard Way". The books tells you to type things first; the explanation comes later.
In my experience, the most important part of learning to program is that you can do something fun, quickly. If you enjoy the programming, you will continue with it, and then bother to learn the "why"'s. If you don't find it fun, why would you bother learning "why"?
The Code Academy tutorial isn't perfect, but I do think it's a fun introduction. Importantly, it's a fun introduction that require almost no set up. I know it has limitations, but it is pretty awesome, and a much better path into Ruby than a lecture on object oriented programming.
Not to knock the lecture. It's very important, in fact. I just think the lecture should wait until lesson 2 or 3.
I agree. The vast majority of what I've read regarding teaching, and my personal experiments tutoring, have shown that alternating between different layers of abstraction is a far better approach than going purely bottom-up.
One example is the popularity of Stanford Professor Andrew Ng's Machine Learning class. The course is almost entirely top-down, with concepts, then trying out basic code, then finally learning some of the Math behind the algorithms. But people have definitely been able to learn from the course-I remember seeing an HN post about a guy who built a self-driving RC car using the algorithms in the ML course.
Thanks for the comments. I'm the cofounder of Codecademy - we're working to alleviate all of these issues. We do lots of user testing and have surfaced many of these problems on our own. Additionally, we make an effort to simplify a lot of concepts and ease users into them instead of explaining them immediately. We've noticed lots of users actually struggle when deciding what IDE or text editor to download. The REPL makes it easier for them. We'd love to hear more of your comments - shoot me an email at contact (at) codecademy (dot) com.
I agree with the overestimation of what the layperson understands.
The idea of adding buckets of complexity by beginning with questions like "what is a REPL", "how does the code turn into action?", "how is my message getting to this site?" kind of takes all the fun and exploration out of the experience.
As a programmer I dislike magic, I have to know what's happening under the hood. But had I kept asking why, I'd be studying electronics and electricity at the moment.
The trust in the existing infrastructure has to begin somewhere, and I think the quick feedback from a REPL is a great learning tool. It whets the appetite, and students can then expand their circle of knowledge over time.
Imagine if you had to understand E=mc^2 before being allowed to appreciate the night sky ;)
Agree with you about Codecademy's assumption/expectation of a layperson's understanding is ambitious but your expectation of what needs to be explained kinda deviates from their aim. Yes, they should've expanded on some concepts but Codecademy should really concentrate on the 'what' and not the 'why' as that can be developed afterwards. Spending most teaching on the 'why' (like most adult learners would do) early on will put off some users off as they do not feel they are 'doing' much and quit/move onto something else.
It is obvious the users' background covers a wide spectrum so Codecademy would have to draw a line somewhere and say here's the pre-requisites prior to starting the intro coding course. They may need to provide this background knowledge via a pre-sessional/foundation/principles course (or pintpoint users where to go if they don't) covering the barebone basics of computer science and computing as a task.
Whether 'the hard way' is the best is really up to the learner - people learn in different styles so whatever gets their attention really. As a suggestion , Codecademy should provide a list of additional resources for eager learners who wants to understand the underlying concepts and/or provide links to other courses if this particular course is not useful for them.
It's also constant. Every single time someone tweets/blogs/talks about Codecademy they say Code Academy. It's inevitably followed by "actually it's Codecademy".
It's a distraction from what otherwise seems to be a great idea.
I seem to remember codeacademy being owned by someone else, a squatter or an entrepreneur who hadn't got around to doing tomething with it. If I do in fact remember this correctly, one explanation would be that they bought that ___domain after they'd received more investment money than they started out with.
"squatter" - although the term is commonly used in the way you used it (and always has been) the usage is an invention of the 90's media. Squatting actually involves occupying property of someone else that you don't have right to in any way (and you don't have permission) that isn't being used. The person who takes a chance and buys a name pays for it and at the time it wasn't in use by anyone else. The practice of using the derogatory word "squatting" to describe legitimate buying of a ___domain name with the hopes of reselling is something that should end.
Maybe you're right about learning 'the hard way'. I too strongly believe in learning with rigorous practice. But, one has to understand that people take various approaches to learning and teaching.
There cannot be a right way to teach given the multitude of learners now online.
I was a complete beginner at coding a few months ago. I really really wanted to learn, so I've tried going to local meetups designed to teach newbies to code and I've tried Codecademy.
The problem I found was this tendency to start with the terminal as the teaching tool. The terminal is a black and intimidating hole to a beginner. Sure, I happily typed in 2+2 and got 4 as a result, and I understood how to store variables and even if statements and while loops, but honestly, I found this to be too abstract. I didn't understand what the terminal was and how typing in 2+2 was supposed to help me build a website, which is why I wanted to learn to code to begin with. I got frustrated and quit learning to code for a while as a result.
But then I decided to try out the free Stanford CS106A course. I was hooked from the very first lecture. Instead of starting at the terminal, Stanford had me download Eclipse (which is less intimidating than the terminal) and they started with a fun "Karel the Robot" language. In the first assignment, my goal was to make Karel the Robot run around the grid and drop / pick up diamond 'beepers'. I LOVED it. The excitement I got from actually getting Karel to do what I wanted was exhilarating and far more rewarding than getting a pretty badge from Codecademy. I completed the course in about a month and am now learning Ruby, which I absolutely love.
My point is, people want to learn to program so they can build something, so starting off with concrete and fun projects (versus typing random stuff into a Terminal) is the way to go.
Is there a link to this Karel the Robot exercise or is it a hand out?
We're in the amidst of creating something complimentary (different too) to Codecademy called http://CodePupil.com. We're eager to see different styles of teaching; especially examples where gaming is used!
As noted in the OP's article creating a new experience and especially one that teaches all the Elizabeth's how to code is a big challenge. We've been asking our friends like Elizabeths to test and then we reiterate. Also we've found Mechanical Turk to be helpful in re: to user testing feedback. There seems to be a lot of Liz's there.
I highly recommend you check out all the exercise for the Stanford course: http://see.stanford.edu/see/materials/icspmcs106a/assignment... (the ones at the bottom, not the top). The reason the class was so much fun was because we got to make Breakout, Hangman, Yahtzee, and ended by creating a simple version of Facebook.
The application would have access to see your email address i.e. <paul's-id>@gmail.com
The app uses it to send a welcome message to users.
Unfortunately that's the default minimum permission set granted by App Engine Users API. Further, I promise not to be evil:
iheartpy.com/privacy.txt
Feel free to write to me for any feedback and/ or help.
I would argue just the opposite actually. Eclipse has a very intimidating interface intended for experienced developers -- I remember when I was learning Java I used Eclipse and it was not user friendly at all.
Also, my first intro CS course also used Karel the Robot, and while it was cool that I could see this guy run around on the screen, I kept wondering "what is the point of this"? It didn't seem useful or related to writing actual programs at all. While it is less abstract than typing commands in a a prompt, it still felt very contrived.
But I guess that depends entirely on the student's motivation for learning to code -- are they looking to build a website? To understand how computers work? Because they like solving puzzles? Just to "try it out"? Teaching through a robot game like Karel probably would not be a good approach for those who want to get their hands dirty and build actual stuff (and Java is probably not the best first language). But for those who are more interested in understanding computer science / puzzles, those who value the problem solving aspect of programming, a tangible game like Karel might be better.
However, I'd still say CodeAcademy's approach with browser based lessons is much better -- there's a much lower barrier to getting started than downloading and setting up an IDE. Furthermore, they have complete control of their site design. I don't think introducing REPL at the beginning is the best idea, but it's better than hitting the student with a sledgehammer like Eclipse.
Perhaps a compromise would be a very simple game in Ruby/Python? There was a web based Ruby game on HN recently, intended for experienced programmers, in which you wrote the AI for a bot navigating through a map. Obviously that is too complicated for a beginner, but I imagine something simpler could be both appealing, engaging, and accessible.
It is interesting to see how much
has changed in the past 20 years or so.
It used to be that terminal was the standard when it came to learning ones first language (think BASIC in most of computers in 80s).
EDIT: I wanted to criticize the choice of learning programming by starting with something as unwieldy and bloated as Eclipse and Java.
My mind changed, as I read about Karel language. Starting with a simple language that can actually do something then gradually building up is great for learning.
However, one point still stands, BASIC was basically one level down the abstraction from machine code, while Karel is now four levels down. This is the inevitable price of progress just like we can't build a toaster completely from scratch(http://www.ted.com/talks/thomas_thwaites_how_i_built_a_toast...).
I made my (non-programming) girlfriend try codecademy and she had the same kind of troubles. I had to go at lengths to explain to her what a console was.
She also told me that codecademy assumes too much stuff is known, like booleans or whatever. All the things that we take for granted and innate are extremely complicated to teach through a human-computer interaction.
In the end she went and googled "javascript tutorial", clicked one of the results and told me "this is much clearer". The tutorial was in classic textual form. I think codecademy looks very appealing for developers because it looks like it's easy to learn on it, but that's because we are developers, not laypeople.
Slightly offtopic: I also have a non-programming girlfriend and she recently expressed an interest in learning what programming is all about. This is because she often sees me coding, knows that I like it and that it's a big part of my life, and feels bad when I start talking about how I started some new project and she knows that I cannot tell her in detail what it's about because she wouldn't understand me (I ususally like to make stuff for developers, like libraries, tools and so on, not stuff for general public).
So I've been pondering what would be the best way to teach her a bit about programming, just to give her some general idea on what programming is. Should I just make a simple website with her and show her how to do basic stuff using javascript, or should I start with some theory first (I'm not thinking here about teaching her theoretical CS, just some basic OO principles). Anybody has any advice?
"Should I just make a simple website with her and show her how to do basic stuff using javascript"
I think the easiest way to learn is to take a simple page or script that already does something and change it. With that you get a little excitement that motivates you to learn further.
The classical computer learning books normally start with a "hello world" program and then move on from there.
I'd like to see someone build a learn-to-code site around Yahoo Pipes; where you'd learn about each module by making something cool and useful. Later, once you have a basic understanding of what can be done, you'd work backwards to do the same by coding. The problem I've had with most of the online tutorials is that at the end of the day I don't have anything I can actually use.
I can't imagine this would be productive. What's the point of learning OO stuff if you aren't actually going to be writing programs big enough to warrant it right away? Get started with the smallest part of of the joy of programming: write some code and see it do something, even "10 print hi goto 10" is going to be a lot more exciting than OO, I would think.
A large part of learning to program is testing, then debugging. If 2+3 didn't work, my natural course of action would be to read the instructions again, and then try 2+2.
CodeAcademy is trying to teach people to code, and I think a big part of that, is learning to navigate small problems, debug, and follow instructions. If they just gave instructions that said "type the following", that would take away these problems - but what would that achieve? That would be like a professor not giving repeat questions on an exam, and a student complaining he wasn't clear enough.
I very much agree with this. But I still think that if someone types in 2+3 at that second exercise, the program should compute it properly and not error out :)
Glad someone pointed this out. Several of us are doing this at the office and I've watched our design team struggle in similar ways. If you're not used to the the kind of errors you'll see in coding or javascript, it can be incredibly confusing. Luckily for me, a reference error can be meaningful but to someone who has no idea about scripting, it's utterly worthless (sure you could argue this person should go to google and learn it but I'd say that this is the learning tool they've settled on and it should provide that instruction).
I've found myself struggling with their less-than-clear directions. I'm even convinced that there is at least one problem set so far with no solution (Functions in Javascript Optional Course » Lesson 2, part 3).
I have high hopes for Codeyear. After toying with it for a bit during the first week though, I'm hoping the usability and directions are cleaned up otherwise this will be more of an exercise in patience than in learning programming or javascript.
All this said, I've at least gotten some totally sweet badges.
I did the same thing with my sister(who doesn't know any code) and the same issues came up with her as well. This is definitely a design issue. How to make the UI better?
In the initial stages of learning of learning a concept, have a dialogue appear for each error saying something like:
When you're coding in the real world no one is going to tell you this, but we've got your back! You forgot the quotes around your name. This problem occurs because some programming languages are case-sensitive, meaning that you have to type it in exactly the way Javascript wants you to. We'll give you a heads up about using quotes 4 more times and after that you're on your own.
To fix this error type in: "Janet".length instead of Janet.length
Just in case any non-programmers are reading this, the quotes around a string (like your name in the Codecademy example in question), have nothing to do with case, or being case-sensitive. Programming languages have basic building blocks called primitive data types, and for many programming languages, strings represent one type of those building blocks. Traditionally, strings are indicated by putting double- or single-quotes around the letters of the strings, but they just as easily could be indicated by two parentheses, or dollar signs. It's a convention for denoting a string, no more, just like quotes in English and certain other natural languages represent certain features of the language, often direct speech.
As it stands, I only see codeacademy being useful for programmers who are new to Javascript. If you're completely new to programming, there are too many problems, like the article mentions, that are difficult to get past without knowing... programming!
Even then it is frustrating. I know basic to medium level Java and Python. I wanted to learn Javascript and decided to take codeacademy for a spin. The experience was so frustrating, I gave up after the first few exercises (after shouting at my computer a few times). There was no useful feedback - just an error message like 'Oops. Try again'.
I prefer Zed Shaw's style of teaching. Guess, I will wait until he publishes LearnJavaScriptTheHardWay.
Agreed 110%. given that up and down arrows scroll up and down, having left/right arrow keys ties to history fwd/back would make a heck of a lot more sense.
Left/right - yeah, I see your point. I was testing it on a page that didn't need to scroll left/right when I tried it, so that didn't occur to me. I probably always mouse or trackpad for scrolling anyway, so my key-fu is a bit rusty.
Still... 'delete/backspace' going back in a browser never made sense to me.
I work for a small start-up in a completely non-technical role. I have no programming ability and previously had no desire, but since I've started working here I've had the desire to learn some.
Until Codecamedy came along it was probably just going to be a project I continuously put off until something else changed to make it happen. But now I'm signed up to get the Code Year emails, it's something I'll probably remember to do from week to week.
Anyway, back to the usability. I agree with the author that it's easy to make mistakes and feel confused with learning to code on Codecademy. But from what I've gathered so far it's easy to make mistakes and feel confused with learning to code, period.
Programming involves a lot of testing, of trial and error, to come to the right answer, or more relevantly; a better answer. Codeademy is giving people the opportunity to ease into that sense of trial and error, but it needs to be there nonetheless, because that is the reality of programming.
If you make a mistake, such as typing with a close bracket quote, and then you get an error message, what you do from there is probably a good signal of whether you should continue learning to code. If that happens to you five times, and you keep thinking "huh, why did that happen?" and then continue working on it until you figure it out, there's a good chance you have the sort of insatiable quest for understanding that you probably need to be a programmer. On the other hand, if you give up after a few tries, then it's likely that you don't have that same need to understand the logic behind it.
Codecademy is obviously trying to bring programming to a wider audience, but it shouldn't simplify it to the point where it's not giving a realistic picture of the very nature of programming. You can choose to take the stairs over diving in; but you still gotta get in the pool.
People have been taught by their IT dept., their family members, friends, store clerks, etc., to not mess with a computer. This also applies to their automobiles, appliances, etc.
In short, a lot of people out there have been hit with a newspaper on the nose (various times) for trying something new.
So, they decide to learn a new hobby (or craft), and they spend (waste) a lot of time fighting the fear of breaking things.
Yet, we (as in hackers) all know that one can't really do much harm to a computer with a simple approach such as the one used by CodeCademy. But non-hackers do not know that. They fear the machine (or the result of making a mistake with it (their files will be deleted! - plays in their mind)).
So, CodeCademy, I suggest you help people overcome such fear by showing them what they can do before showing them how to do it.
The terminal is fine, actually, I find that it was a genius idea. But, learning how to code is not bound to a terminal. It is bound to thinking, problem solving, abstractions. A learner cannot be afraid to break things, otherwise, they will not learn.
Challenge their fear (and ignorance) from the start. Instead of throwing them crumbs in the form of a simple string.length exercise, show them that they:
- cannot mess their computer up by playing with your website
- will not get a virus
- should try again if they fail at something
- programming (not coding) takes time to learn
How will you do that?
I can point north, and tell you that Nirvana is that way, but I cannot walk the roads for you.
Sit back, and think about what I'm saying.
Help people learn how to code by helping them get over themselves.
I thought my 10y.o. daughter might want to learn programming. So I pointed her to codecademy and said if she got stuck, to call me over.
She was excited to try, but ran into the exact same problems this article surfaced. She was being a real trouper about it, but it was plain that her patience and temper were running short. That said, once we got past the first steps and I taught her how the website was supposed to work, she breezed through the next handful of exercises before calling it a night.
All that said, I was definitely left with the impression that codecademy was not well designed for complete beginners. Yet.
For now I had a brief look at Scratch (http://scratch.mit.edu/) and I'm tempted to turn her loose on that. It seems to have a nicer effort/reward slope, and will help her understand enough of the core ideas behind programming that I could then turn her loose on other languages.
I highly recommend Scratch. I teach 8 - 12 year olds using scratch. It teaches computational concepts in a fun (certainly not intimidating way). I am now planning to experiment using Scratch for adults as well as a starting point before introducing any of the common programming languages.
I love codecademy, but I always wondered if it would be better to ease a newbie into programming with a 'childrens' UI like Scratch or Alice. It wouldn't build up any coding muscle memory, but it might help them get use to the general look and feel of code before asking them to type it out themselves.
I'm really curious to know if anyone has experience with this. On the one hand, kids like building games, so Scratch and Alice seem like a good idea. On the other hand, those aren't "real" languages, so I think...why not just teach kids how to actually write code? I'm suspicious of how we dumb things down for kids. Anyone have experience teaching kids to code, either with Scratch/Alice, or another language?
Codecademy have done a great job at reducing something that can be very difficult down to laymans terms but its difficult deciding just how far down the rabbit go they need to go.
While the problems with the REPL and trying to delete text are obviously a problem (and a hard one to solve), I'm not sure the issue with leaving out the quotes is. Obviously if the text was replaced with "I don't know anything called liz" instead of "liz is not defined" would be a minor improvement -- but at the same time anyone should be able to sit back, look at what they were asked to code ("Ryan".length) and notice the difference to what they typed (liz.length). The "Oops, try again" might be enough of a message there.
For some of these early lessons at least, could they not have 'curated' error tests?
ie. for this one, since missing the quote is an obvious error, why not match the string entered with a regex (or your parsing tool of choice) and look for the presence of exactly 2 quotes, with at least one character in between. If it's not there, print "That didn't work. Did you miss out a quote?"
In fact, if they log all the things people type in, they could analyse it for all the most common errors and then start attacking each of those.
As Codecademy is targeting a large demographic with varying ability of coding (i.e. from basic MS Office users because it's part of their day job to people who are more switched on with tech stuff but never bothered to learn coding), they need to work out how to cater them all. I'm personally in the 'I use Office in my day job and have some interest in the latest tech trends but no knowledge of how things work' segment.
Adding more expansive instructions should help as their current one/two-liner approach doesn't really explain anything for the absolute beginners. However, this can put some slightly more knowledgeable learners off by being too pedantic so Codecademy needs to find the right balance. Within their existing UI, they can probably do this via offering more 'Show Hints' per task like certain computer games where Hint 1 is the cryptic-ish hint, Hint 2 gives slightly more context and Hint 3 for really struggling learners. Users can then self-select how much help they need and don't feel like they are being spoonfed. If Codecademy is really targeting the absolute (but willing) beginners, they need to realise these users are unlikely to google for help as they are used to self-contained courses a la CBT courses in their day jobs.
Agree with imjared about the sweet badges - if they want to get the crowd (or maybe just me) going, they should start offering the options for users to buy some embroidered patches or 3D printed versions of the achievements!
I apologize in advance if what I'm about to say may sound harsh, mean or elitist, but the truth is programming isn't for everyone.
While the intent of the article is very noble ("improving the usability of Codecademy"), it also raises very important questions about programming tutorials in general. How much "holding by the hand" should a tutor do, really?
The examples the author gives are very relevant to my point. The behaviour of a web browser when pressing "BackSpace" or of an interpreter when leaving an opening quote unmatched ... Those are perfect examples of the kind of things that a future programmer must learn to figure out by themselves. While I don't argue that the pupil has to necessarily find that out from the first time, I strongly believe it is not up to the tutor to point it out.
To a certain extent, the role of "introductory" tutorials aiming at teaching programming, should be a way to filter potential programmers and select the best from the ones who won't make it. Teaching programming is similar to Martial Arts in the sense that the best teachers are the ones who let their students struggle before earning an achievement.
I can safely assume most of us here found out the "backspace in browser" issue (as well as "unmatched quote" one) without having the solution pointed out to us. We played, tinkered and experimented. This is how we got where we are today.
Holding a student by the hand is not doing him a favor. Often, it's simply delaying his giving up. And I think that the worst thing Codecademy could do is presenting their student with a modified interface for the JS (or whatever language) interpreter, just to make things "nicer".
It's not hand holding when you're trying to introduce someone to programming. Learning to use a REPL isn't a test to separate good programmers from bad. It's something that has to be learned first.
I think babarock phrased it poorly but he's not entirely wrong. I learned to program (like many others of my generation) by futzing around on my C=64's repl. It wasn't a great system by any stretch of the imagination, but actually playing with it (and failing) got me to learn it so well. I think the C=64's repl was simpler for users than Javascript's, which certainly helped. The goal should be to get people to play with it, not to get them to type "Ken".length and press return.
The things we know best are the things we play around with. The things I know the least well are those where I only learned the happy-path through some training procedure. I learned to read and speak and cook breakfast and ride a bike and program and everything else mainly by trying and failing.
(The bicycle is actually an interesting case, because we try to teach the happy-path with training wheels, though this essentially inverts the controls we're trying to learn. It's a confidence-builder, not a skill-builder.)
Last year I took a class to learn a new skill. The teacher was great: he was enthusiastic, and after each teaching point he got us to try it by saying "Now let's go screw it up and learn!" We spent a lot more time screwing it up than being lectured, thankfully.
I don't know much about "Codecademy", but based on this I would say it's not really going to help most people, but not because of these minor usability gripes. The goal shouldn't be to create an 'intuitive tutorial'. You're trying to teach people a new way of thinking. The goal should be to provide an environment where the essence (type something, get result) is completely obvious, and where more information is always available upon request, and where they are encouraged to play around. What I'm seeing is an environment where there's a right and a wrong. It makes programming look like a 1980's MS-DOS adventure game but harder.
What you call "holding a student by the hand" I call "teaching." It's not legitimate to assume that some subject should only be reserved for an elite group just because it is difficult to teach and learn; the failure in this case is in a lack of good teachers.
They need to capture the common interpreter errors in the earlier lessons. So that if you try and do liz.length it doesn't come back with a reference error, but with an explanation of why that doesn't work.
Making friendly error messages in the general case is a hard problem, but doing so in a restricted environment where you know the most likely errors that beginners will make (which you can data mine over the long term) is not.
I went through the Codeacademy exercises even though I can program reasonably well (i.e. I can do everything I need to, but I would never call myself a software engineer). I did this partially because I do not know js and partially because I wanted to see how the systems work. The “Oops, try again.” message can be very frustrating because, as the author points out, often the output they want is opaque. They have a great idea, but it seems that they sometimes prefer brevity in their instructions over specificity.
She might have learned more if she didn't have somebody telling here the answers each time. Instead of a teachable moment, her friend tried to fix the experience to match HIS expectations.
I remember fooling with tiny BASIC etc as a young man. It was weird and wonderful. Nothing worked right; everything was a maze and a puzzle. I wouldn't have missed that for the world.
I dunno. She didn't really follow the instructions. Maybe the error messages should be more helpful. But part of being a programmer is being very precise and having to deal with initially obscure and unexpected errors like that. Its frustrating yes, but if a person's reaction to that tutorial is to give up rather than be intrigued and push harder, I can't imagine them ever having the patience or drive to debug way more complicated systems.
Semi tangentially, the 'backspace = go back' shortcut has accidentally deleted countless posts and emails of mine (and I'm sure many other people's). I really think that shortcut needs to go away.
Not sure about the other browsers, but this is mostly a solved issue in Firefox: it has grown clever enough to remember the contents of a text box even after going back, closing the tab (reopen it with ctrl+maj+t), or even quitting Firefox.
I think I fixed this problem in my app (iheartpy.com) using AIML. Caution: Still a work in progress.
The whoe thing -
I am a self-taught programmer. And I had been an extensive user of codeacademy myself. I realized this rather serious design flaw early on and tried to do something about it.
Initially, I tried to right my own engine based on JSON but midway I discovered AIML. It suited the task perfectly. So I downloaded pyAIML library [1]. It is surprisingly simple to get started with. I hacked around a bit and got a workable python app.
Finally using pyAIML + regexp, I ended up with a crude engine that takes something like this (in Python):
def foo(param1, param2)
and spits out:
FUNCTION foo PARAMS param1 param2
which can be easily manipulated and replied to by the pyAIML parser. It worked flawlessly. And moreover, designing lessons is as simple as creating an XML file.
Then I threw together a minimal UI and got it up and running on App Engine here:
iheartpy.com
I used CodeMirror [2] for the editor. The focus of the UI was to be extremely minimal ( = blazing fast) and delightfully non-distracting ( = no post-to-facebook rubbish). This being a side-project, I thought I could easily get away with that. :)
Honestly, this is my first project and looks more like the work of a script-junkie at this point of time. The lessons are not done yet. I wasted a lot of time in trying to optimize my app for App Engine. And now I'm an 18 year-old who has a LOT of exams on his head and this unfinished project. It is kinda disheartening.
Anyway here's the github repo [3]. It is not very neat. Psst.. I added some LOLPython magic as well [4]!
Finally, I made something that is essentially an MVP. I'm new to both design and coding. Plus, I don't think I'm proficient enough in Python to teach people.
In short, I need help. Would be happy enough with some feedback, though. ;)
Looks interesting, good design, didn't try it because it requires a login that gives a scary "THIS APPLICATION WANTS TO READ YOUR EMAIL ON GMAIL OH NOOOEESSSSS" login.
Huh?
I actually use the App Engine Users API and zed I'm truly sorry for the crappy message that put you off.
What it meant was that the application would have access to see your email address i.e. google will disclose the address zed'[email protected]
Unfortunately that's the default minimum permission set granted. I use it to send people a welcome message. Further, I promise not to be evil here:
iheartpy.com/privacy.txt
It looks like you have the same problems with incorrect input. I tried typing Hello without the '#' and the error was much more confusing than "Oops. Try again"
It doesn't go back, it actually deletes the page from the internet. Since the page has been trashed, the only logical result is to take you back one history state.
No one actually codes using a REPL in a browser. Yet the site makes no attempt to explain why or how this REPL exists, or how it works.
It doesn't explain why I can only type in certain places on the screen.
It doesn't explain how to try again, or undo mistakes.
It doesn't explain why a string must be surrounded by quotes, but numbers must not be.
It doesn't explain why suffixing `.length` to a string (but not a number) does anything, versus any of 50,000 other English words I might have put in its place.
It's confusing that there are three sources of errors: those from the language, those from the tutorial, and those from the browser/internet. Where is this program running? Where does the code live? How does this code turn into action? How does the tutorial know what I'm doing?
Codeacademy doesn't explain how any of this magic happens. It just plops you down in front of a REPL and tells you to echo specific things.
Coding is not about learning the syntax that lets you type "Ryan".length. It's about learning the underlying concepts: the "why", not the "what".
Coding is best learned "the hard way".