Slashdot Mirror
Learning To Code: Are We Having Fun Yet?
theodp writes "Nate West has a nice essay on the importance of whimsy in learning to program. "It wasn't until I was writing Ruby that I found learning to program to be fun," recalls West. "What's funny is it really doesn't take much effort to be more enjoyable than the C++ examples from earlier...just getting to write gets.chomp and puts over cout > made all the difference. Ruby examples kept me engaged just long enough that I could find Why's Poignant Guide to Ruby." So, does the future of introductory computer programming books and MOOCs lie in professional, business-like presentations, or does a less-polished production with some genuine goofy enthusiasm help the programming medicine go down?"
The important thing about learning to code is keeping interest/motivation to do so.
I agree with the general approach that the essay espouses - whimsy is a great way to keep interest; but it's certainly not the only way. Different things work for different people. My daughter is two and a half years old, and so far has totally rejected learning that involves traditional 'reward' such as the way gCompris shows 'happy' images on completing tasks vs 'sad' images when failing. However, what seems to do it for her is being able to 'show off'. When she can make her grandmother surprised by being able to point out letters of the alphabet on things, she is much more motivated to learn and get it right.
I'm sure my daughter's learning style will develop and change as she grows; I just wanted to use an example that demonstrates not everyone is motivated to learn in the same way. I don't think coding is any different.
My book about LSD and Self-Discovery
Also on facebook as: DroppingAcidDaleBewan
I like to learn this way better than that way therefore this way is better.
Yes, for you. That way may better for others perhaps even most.
If you have to make learning to code 'fun', you're probably doing it wrong.
It shouldn't need to be made 'fun', as it's the intrinsic motivation of getting the computer to do something is its own reward.
Anyway, you don't go out of your way to make it _un-fun_, by forcing loads of sophisticated concepts and useless syntactic sugar on people right from the get-go, you start by, keeping things simple, doing the simplest thing that could possibly work, only introducing abstractions and concepts when they're absolutely needed, and by being powerful enough to let people 'scratch their own itch' to solve interesting and useful problems.
C++, C#, Java, Ada are terrible choices for a beginners language (yet the fucking idiots at my university changed to Java, because it was "practical", although it completely blew their pass rate.)
Python, Ruby, Scheme are far better choices.
My first class was in 1976 and our text was _Business Programming in Fortran IV_. Fun was not an option. However, the next year, I took a class in Basic on some of the first desktops, an IBM 5100 (Basic and APL in ROM) and an HP 9830 (full ASCII keyboard and 32-character LED display). Writing games was encouraged. Tic-Tac-Toe and Oware were serious challenges. Physics students wrote projectile motion target practice but without the benefit of Birds. Six months later, my new wife and I played Adventure on an IBM 370. She just earned her CISSP. A little whimsy goes a long way.
Hello! I see you are trying to create an array which is bigger than the RAM on your computer. Would you like me to order additional RAM on amazon.com for you at the cost of USD$5,452,981,583 or would you rather create a 1 petabyte swap file on your 3 terabyte hard drive? - Clippy
Get free satoshi (Bitcoin) and Dogecoins
This reminds me of those Head First books that were all the rage a while back. It is an interesting approach. And learning doesn't have to be painful. But there is a thick gray line between stoic and ADD. I think the trick is staying in that area. Also we have to consider that for a lot of programming -- the part that thinks it is more like engineering and less like painting - a certain degree of maturity is a prerequisite. So we shouldn't make programming childish thereby completely alienating the people who will design the important stuff like controlling the electric grid or Martian probes. It would suck to have a 20 hour blackout or lose a 5 billion dollar probe just because someone didn't feel like checking a return code. Still it takes all kinds. I suspect the guys who wrote the SCADA software would never have come up with Angry Birds. But I don't necessarily want the ROVIO guys controlling the nuclear power plant up the road. So once again, all things in moderation.
Seriously? I hated Why's Guide... it was stupid. I'm sorry. Just get to the point. I'd rather have a BNF with some sample code, without the fluff. Lua's documentation was the best I've seen (for introduction to a programming language). Go's is pretty good too.
The author has a point, maybe. I did notice that he was ten years old in the nineties and learned to program after college, meaning he has maybe five years of experience. He may be missing the REASON you name it "XMLReader", not "SusieQ" or whatever he said. If he ever has to grok a medium sized project full of classes with "whimsical" names he may wish for clear, intuitive names.
My predecessor at work was whimsical - every script or class has a variable named "bob", which sometimes is important, sometimes does nothing. Occasionally, he forgot what he was using bob for in a particular function and tried to have it represent two different things. One of our tasks is to slowly replace all of his whimsical code with proper code that is reliable and self documenting
I found learning and using Ruby to be decidedly "not fun". This stemmed more from the language itself than from the available materials. Why's guide was an irritating manifesto.
When I hire a programmer, my first goal is to find out how much fun they have coding. Without that, I don't hire them.
no, I don't have a sig
First of all, it should be like a dope that gets you hooked, not a bitter medicine to be swallowed.
Second, people aren't stupid. Don't try to be cute and make people throw up.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
A lecturer's enthousiasm is one of the things I keep see mentioned as plusses in any course. Merely stating the facts isn't enough. Enthousiasm does help. But that isn't enough either. I've skipped MOOCs because the lecturer tried too hard and became shouty and loud.
Some subjects are boring and dry and in fact go better when they're not too much "nicened up". In fact, there was a study where children couldn't do normal math because they'd been spoon-fed so much "story math" they weren't able to deal with stuff that wasn't "storified". Another case of trying too hard.
At the end of the day, it's about acquiring the skills, and learning where and when to apply them. But motivation certainly helps--though I for me need to be somewhat interested already, or be shown why the thing is worthwhile to put effort in. What also helps is a lecturer who knows how to pick apart your jumbled thoughts and show you what you've been missing, so you can assemble the final puzzle yourself. Because, you know, all the trappings are really just that, trappings. If you think they're the main thing, then you're losing track of what really matters: Acquiring the skills.
http://learnyouahaskell.com/
The most fun I've seen people have while learning to program was back in the 90s, when people
learned to program for LPMUDs.
It takes about half a second for someone to understand object oriented programming with inheritance
if they create a key, or a door, or a special sword, or...
And they had so much fun programming. They never wanted to stop.
I wish someone could create a similar 3d MMORPG (with physics) to keep up with the times...
Source code should not read like this:
if fucked(bob, saly) {
generate_legal_filing(divorce);
} else {
give_blowjob(bob);
}
Code should read like:
If Bob fucked Saly, sue for divorce. Otherwise, give him a blowjob.
It's easily-readable and self-documenting.
1. A toolset they can use to build useful projects
2. A language they can grasp easily
3. And a genuinely useful project they can achieve
Everyone's best coding experiences have come from a desire to do something, combined with the right tools to achieve it. In the early days of 8-bit computing and BASIC, this was about making a game where the computer said "I've thought of a number between 1 and 1,000", and then you guessed and it told you you were too high or too low.
When you got that going, that was an extraordinary sense of achievement. "Look ma! I've made a simple game, you can enjoy!"
And then came Windows and complex APIs, and languages like Visual Basic that abstracted too much from the users, such that much that happened was 'magic'. Who - given a computer these days - begins to think "how do I *make* something amazing?"
Fortunately, things are getting better. The right languages are now available - most notably Python, Lua and Ruby - all of which are proper programming languages, but which are also easy to learn.
And the Raspberry Pi project comes from the right place. The issue it has, perhaps, is that people don't want to produce Raspberry Pi apps - and that desktop apps for Linux, whether written in Ruby, Python or anything else, are hardly childs play.
A better option for deploying a *real* app, people want to use, a modern equivalent of the guess the numbers game, must be either an app for a smart phone, or it must be a web app which can be deployed (for free) in the cloud. In which case, I think there are two or three options. (There used to be more, but Heroku Garden is no more). For smartphone development, Corona SDK is fairly mature and works with both Android and iOS. For a web app, there are a few more options, of which PythonAnywhere is probably the best of the bunch.
I suspect a decade from now, the self-taught developers will have mostly learned their craft in one of these languages, building useful apps for smartphones or the web.
--- My dad's political betting
I agree that some languages make Programming a very heartless and painful experience, but then others are just fun to get working. It's how I fell about Perl. I love that I can get to a solution via an assortment of different ways and that there's not just one way to do everything. It allows me to express my individuality and creativity and helps me maintain a sense of ownership. Sure, that's not always a top priority to your boss, but as a programmer, it makes you feel more than you're just another project resource... probably vanity or hubris, but sometimes you need something to have a little pride in doing--code that isn't just generated by next-year's code generator.
http://www.beanleafpress.com
One small quote from SICP sums up all one needs to know about programming and the history of computers: "When it started out, it was an awful lot of fun." --Alan J. Perlis
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
I teach my nieces and nephews Perl. I love Perl. So many languages have fallen by the wayside but Perl is a masterpiece. I'm also a fan Python and Ruby which are also fun. Lite languages are generally fun. I detest Java since it is such a heavy language and heavy languages are NOT fun.
To much College mindset. Need more trade school / apprenticeship setting.
To have an AP that is Java based is good and bad (based on how much theory there is) It can be good for people doing Java work but may not so good for people doing other coding work. Also it may be a poor fit for people doing IT / network work.
But it can also be very Theory based that does not even tech you how to trun out workable java code.
IT / tech work needs to be less College and shorter class times / more skill based learning with some kind of badges systems or even certs that add up to some thing bigger.
2-4 years pure classroom is to long for tech work, leads to skill gaps and even being in class to learn a skill just to have be replaced by some other one when you get out.
If you want to get into programming then I suggest grabbing an embedded board and by using C and ASM make LED's blink, Make motors spin and make stuff just happen. Nothing will get you hooked faster then seeing your code do useful work. I think that is what is missing from most programming classes.
If you think C++ is bad, and Ruby is "enjoyable" you shouldn't be writing software.
But not anyone can write *Readable* code... which *others* can read. Coding is fun? No. Solving a problem, like solving a puzzle can be fun. Finding the best solution is fun, but just the typing for the computer to do something is actually boring, I don't know if this is because I wrote already a bunch of code myself that the nice part is actually the design of the solution. If the fun is to find more people to come to our field, just pay better and you get more people who find interesting to code.
Huh, I knew there was a reason all those old computers came with BASIC.
Guess it's because it's understandable and it's capable (and probably quite cheap). Vive la BASIC
"The author has a point, maybe. I did notice that he was ten years old in the nineties and learned to program after college, meaning he has maybe five years of experience. He may be missing the REASON you name it "XMLReader", not "SusieQ" or whatever he said. If he ever has to grok a medium sized project full of classes with "whimsical" names he may wish for clear, intuitive names."
This holds true in the sysadmin world too. If you have just a couple servers, it's fun to give them whimsical names but once you start getting into the dozens of servers, it becomes a huge pain in the ass to keep the names straight.
When I hire a programmer, my first goal is to find out how much fun they have coding. Without that, I don't hire them.
Translation: I want someone to work his ass of to the bone for shitty pay because he loves it.
I USED to love to code. Then after about 4 -5 years of the 55 -60 hour work weeks to meet the deadlines set by sales and having to keep up with technology at home (more coding), I just got to the point of disliking it. Burnt out.
BUT - I get the specs: I get the job done - on time. And then go home to the family and my tennis game. I work to live: NOT live to work. I have balance in my life and I'm MUCH happier.
Having someone "Love" it is like dating in high school - they're out of love at the end of the Summer.
I talked to career councilors, they told me to stay in development/computers; so it's not me, it's the screwed up industry and its idiotic notions of what makes a "good" programmer and employee.
Perhaps if folks promoted folks who actually have grown up and gotten beyond the adolescent idea of "you are what you do" and "you must have passion" that maybe there would be changes in the working conditions.
A good programming language is not one that is full of fucking "whimsy". A good programming language has a clear, concise set of commands which are self documenting. It should be difficult to write the same, simple function in multiple ways. Ruby fails on all accounts. The wording is inconsistent, there are about 45million different ways to write any given function which also means it is hardly self documenting.
I've rarely met a Ruby developer who was employable in another field because they simply don't know what constitutes good, clean, concise code.
I've got karma to burn...
Perhaps the most soul crushing phrase you will ever hear as a programmer is: "Don't re-invent the wheel."
Go ahead, re-invent that wheel every now and then. That's why you got into programming in the first place. You can do a better job.
With servers you can have your cake and eat it too (to some degree) with hostname aliasing, though. While some languages (eg JavaScript) have easy ways to alias functions and objects, it is often considered bad form to do so.
Dr. Donald Knuth has opined that Literate Programming is the most important computer science concept which he has created and that TeX and Metafont couldn't've been written w/o that technique:
http://www.literateprogramming.com/
I've found that using it for the TeX projects I do results in much more maintainable code which was also easier to write initially.
Sphinx of black quartz, judge my vow.
When I was an undergrad with a part time job helping out in a graduate chemistry lab, there was a suite of utilities written in FORTRAN. People depended heavily on this suite to calculate all manner of things related to their crystallography research.
The problem was, it was mostly written during one of those years where Lord of the Rings and the Hobbit were massively popular again, and people were learning to program with hunt-the-wumpus teletype programs. The original author "amused" himself by naming pretty much anything he could after some fantasy concept. CASTLE, FRODO, DRAGON, and so on. Okay, so to map out van der Waals surface strength, you ran CASTLE. Many things have quirky codenames, you get used to it. But all the variables followed suit. Now it was a bit more obscure to maintain the program or trace the logic.
Worst of all, the comments. In FORTRAN, columns 1 to 72 were for your program, and anything after 73 was a comment. The author wrote an "epic" of his own, all word-wrapped in the column space from 73 to 132 (the width of common teletype paper and long Hollerith punch cards). What a waste of his time, you might think. But it was also a huge impediment to maintenance; you see, people in the lab LIKED his story (for a while), so they had to figure out how to patch the logic without breaking the flow of the story. It took years before someone stripped all the prose and got the rest of the lab to follow the maintainable fork instead o the prosaic one.
[
One of the great things about Scratch is that you get instant feedback. Is it a robust programming language? Hell no. Does it frustrate routinely? Yes, just enough to keep my daughter interested.
My biggest frustration with trying to learn structured programming was that it took a week to get from "hello world" to anything else. When characters on the screen were the limit, BASIC was appropriate. Now, however, I've found nothing really between Scratch and Unity for a teaching language.
Modern life seems to cherish the idea of everything being fun and giving immediate reward, even in areas like technology which in general needs long-winded learning process to bear fruit and to master complex systems.
When I hire a programmer, my first goal is to find out how much fun they have coding. Without that, I don't hire them.
I see. The more they suffer, the more you have to pay them to stay, so obviously the goal is to hire someone who gets so much kicks from their work that they'll do it even if you punish them for doing it ...
I tried a number of languages and books before I got "comfortable" doing any kind of programming. Assembly, C++, Java, PHP, Javascript, Perl; I would check out books constantly from the library growing up and spend weeks trying out different things. Some of the books were in the "For Dummies" series, and no amount of humor or so-so comics made Java fun. Same for the rest. Programming didn't start being fun until I actually had something to achieve - once I had a project in mind, the programming became much easier to understand. A book's approach of "now we'll make an address book program" is so dull and boring, it's just not something I can get in to. Maybe that's why I still have a hard time reading through language books today - even Learn Programming the Hard Way has been difficult for me, because I don't feel like I'm going to apply any of it in a meaningful (to me) way.
These three are the key to motivation in many activities. Without fun it's hard to get started, without joy it's hard to keep going, and only later do you see the beauty, first hand, that you can achieve through really mastering a discipline.
John_Chalisque
All you really have to do is look.
What makes you think I haven't?
Also, I have HAD to change jobs because, well, employers moved development offshore. And I used to move to find interesting projects, and now it has hurt me because I am considered a "job hopper".
Yeah, you remember back in the 90s when if you stayed in a job more than 2 years, you were considered someone who didn't want new challenges or whatever the bullshit term the lemming managers and HR people had. I did that. 2 years I was gone - usually because the project was in maintenance mode anyway.
It's hurting me now.
Also, things are getting worse. Companies are canning people and putting more and more work on the existing people. Meaning, those 55 - 60 hour weeks are turning into 60 -70 weeks and longer. And here's the kicker - the pay is NOT going up and in some cases going down. Recently, a C++ guy I know took a job for $65K. I looked at the job posting and back in 98, I was getting $75K for that same type of work.
I want out.
After coding in numerous languages including FORTRAN, C, C++, Java, TCL, and
a bit of Python, Perl and Javascript, I find Ruby is the one I reach for when starting
a new project if I have a choice.
It achieves the perfect balance between concise syntax and readability, has OO
if you need it but you're not required to use it and has a pretty good standard
library -- though perhaps not as extensive as Java or Perl.
I had much the same reaction to perl. I love perl for many reasons. One is that even though the native language without any imports is more powerful than almost any other languange (without imports) the O'reily nut shell guide is the thinest one on my shelf. It really says something about incomprehensibility when even the C++ nutshell guide is thicker than perl. It means that even though perl might seem very ad hoc, in fact it's so self consistent that you can write it all up in a tiny guide.
What really sold me on perl was writing object oriented perl. I had been doing object oriented programming for some time in multiple languages including java and Objective C, but what really made me understand it was perl. In perl you actually see the underside magic of what an object actually is. It's remarkable that the language of perl could go from not having any objects to having objects just by adding one additional command ("bless"). Nothing else in the language had to be re-written. Internally one is storing all the instance variables in a single hash. What's interesting is that you don't have to choose that mode of data organization. you can instead bless a scalar. then you can have the class rather than the instance manage the instance variables. Effectively a hash is a row oriented data base and a scalar is a column oriented data base. When I realized this I was sort of staggered how many high concept ideas were rolled up into the perl method of objects.
I went back and implemented a hash in fortran 77. After that I could write Object oriented fortran 77. yep that's right fortran can also be an object oriented language just doing the same trick perl does. All you then are missing is dynamic memory allocation for it to be complete.
While may people curse perls prefix sigils I actually find them conceptually compact. In most languages the notion of a type, and the construction of a primitives data, get conflated. Really these are different things. Perl makes this explicit. A primitive in perl can have a data organization (list, hash, scalar, reference, dereference, glob) signified by a pand it can separately have a package inheritance (@ISA) that is analogous to a type. In languages like C++ or most everything those two concepts are not distinguised heavily. As a result I find it easier to read a perl program because of all the explicit data structure prefixes.
What kills perl in the end for complex programs is not these sigils looking like cursing on the page, but rather that everyones programming style is different, so it gets pretty crazy to read because it's so compact. It's perhaps a compliment how compact it is. It's interesting that the less compact and less versatile a languages native syntax is the easier it is to read.
But it's true. Try reading APL, the most dense language ever devised. then try reading Lua or (early) python. Both of those are a breeze to read other people's code.
When I read ruby what I see mainly is an extended perl syntax that can avoid using these despised prefix sigils. It gives the objects syntacic sugar, like python does, to hide the object mechanics from you. So it's a very clean looking upgrade to perl.
Some drink at the fountain of knowledge. Others just gargle.
Coding can't be fun in an environment that isn't fun. If you have an environment that frowns on fun, then everything is business and business isn't fun. Even programming itself, computer science, has decided that fun is no longer part of the equation. So many people embrace "agile" programming, however, my experience has been that management twists it to mean that we have two week sprints that literally are meant to burn out programmers as fast as possible. Even so-called scrum experts are guilty of this. Yeah, they're doing it wrong, but it's business.
I'm 50 and it's a common opinion amongst my peers that programming has changed for the worst. Yes, you can do many things but only if you're working on your own. In business, creativity is frowned upon unless it comes from marketing. Instead, programming (and IT) is purely about being "productive" which, to managers, means lines of code. You now use toolsets and frameworks over which you have little choice over and generally the analysis is done by someone who doesn't understand computing (so it lacks any logic). Deadlines are unreasonable.
Part of the problem is that we've been telling people that programming is easy for so long, they believe it. No matter how whimsical your learning is, business will fins a way to drain it of all passion and fun.
chomps get and puts over. Good grief, might as well ust go back to perl if you find that crap fun.
Anytime I see accidentally read any of his writings, the crazy hurts my head. I hope he's locked up in a padded room and injected with bear tranquilizers on an hourly basis.
makes a huge difference. My first comp sci teacher in high school was great. Even as he was teaching us the basics, he gave us very open-ended assignments that encouraged creativity. We were programming Pascal in DOS (and I've dated myself). The last topic he introduced in the first year was the Turbo Pascal graphics unit. Our last major project was to "write a program using the graphics unit." We could literally do anything. Some of the less advanced people just drew pictures on the screen. Others did a choose your adventure-style game. One other kid in the class and I had a friendly competition going to see who could make the better project and we were constantly eyeing the progress of the other and trying to one-up each other. I ended up making a game with some rudimentary physics where you could jump around and shoot at a bad guy. It was a blast, to say the least and I have been hooked on programming ever since.
Unfortunately, my teacher retired at the end of that year, and we brought in a new comp sci teacher. This new guy was very much into teaching to the AP test and took off points if our output deviated slightly from what each each assignment prescribed. I can't imagine that there were many enthusiastic programmers that came out of that environment.
The author wrote an "epic" of his own, all word-wrapped in the column space from 73 to 132 (the width of common teletype paper and long Hollerith punch cards). What a waste of his time, you might think. But it was also a huge impediment to maintenance; you see, people in the lab LIKED his story (for a while), so they had to figure out how to patch the logic without breaking the flow of the story.
I've been a professional software developer for nearly 25 years now, and did it for fun for about 10 years prior to that. I'm old and jaded, and before this morning I thought I had come across every way in which a well-meaning person can make a computer program difficult to maintain.
Thank you more than words can express for restoring my sense of wonder in the universe today.
Laughter is all fine and good, but the best way to learn to program is to have a specific goal in mind. Personally I'm learning to code apps right now because I want to try out a concept in the market and its prohibitively expensive to have it built.
These things help but, if you are into a good problem, even cout is a minor annoyance. I wonder if there isn't some self-selection bias going on here. There have always been terrible bores of teachers. Hell when I was in college I got sick with the chicken pox and, on my way home, realized I needed to talk to my calculous prof, but I couldn't remember his name. My roomate asked if it was Prof SoandSo, "Tall pale humerless pale guy, talks in a monotone voice?" "Yah that is him"...turns out it wasn't.
Perhaps its just that the more interesting teachers who come up with more interesting approaches, tend to select more interesting or fun languages to teach? Frankly, I don't think it matters much what language you learn in...they all have their idiosyncrocies, but, with few exceptions (looking at you LISP) they are mostly the same, I can usually pick up code in a language and read it without
too much trouble, especially if there is a language reference I can peek at when the syntax gets unusual.
I really don't think the language itself matters that much.
"I opened my eyes, and everything went dark again"
I think it is well documented that people learn better when they have fun - even to the extent that the fun doesn't have to be at all relevant to the subject. I recall an experiment where a comedy movie was shown on a screen while a teacher went through his lecture and his class remembered and understood the subject better than a class that didn't watch the movie.
The danger is that humour is sometimes difficult to get right; if you get it wrong, it prejudices the student against the subject. I've tried it myself - when I first encountered Perl, I was put off by things like "bless" and similar attempts at being funny (I assume?), and I'd still today rather shave with a cheese grater than use Perl. A shame, really, I've heard it is really useful, but there you are.
I find C++ much more fun, because it does exactly what I tell it to.
But you sometimes have to be a language lawyer to figure out exactly how templates, inheritance, the implicit conversion, and other C++ language features will interact in a given case. See C++ FQA Lite for a taste of the language lawyering that C++ programmers have to do in their heads to be competent in the language. In what way do you find this easier than figuring out the semantics of a particular dynamically typed language?
Python, PHP, Ruby
PHP is less strongly typed with its policy of playing loose with implicit conversions to and from numeric and string types. But Python is strongly (though dynamically) typed.
"What's funny is it really doesn't take much effort to be more enjoyable than the C++ examples from earlier...just getting to write gets.chomp and puts over cout > made all the difference. Ruby examples kept me engaged just long enough that I could find Why's Poignant Guide to Ruby.
To me, this just does not make any sense. The preference of gets.chomp over cout << (or viceversa) are so subjective that they borderline on the ridiculous. I don't think I will ever relate to such minutia. Even when I was in my formative years as a future programmer, such minutia seemed as irrelevant then as it does now.
At least for me my focus and motivation were always a) what can I create with this programming language, and b) how can I tame this beast. That's the approach I took with BASIC, with Pascal, with Delphi, with C and C++, with assembly, with Ada, with Lisp and Prolog, with Java, with C# and so on and so on.
The only thing out of this story that I could relate to is that indeed C++ (like Java and C#) is a horrible introductory language, and that something like Ruby (or Python or Lisp or BASIC or a Pascal variant) is a better prog-101 language. Heck, I would go as far as to claim that Assembly (a real one or a simulated one) is better to teach programming than C++.
But to suggest that such ridiculous minutia "engages" someone to learn, to me that's suggestive of prioritizing on the wrong things. Every person is different and unique and perhaps *THIS* works for them. To me OTH, it has always been about being able to create more and more powerful things with whatever language I had to learn (or work with.) Syntactical minutia is just not such a significant impediment unless you focus on them and give them greater power (positive or negative) than they actually have.
As for the value of goofing, of course that is important, but that is not a function of the language. It is a function of the professor, and the student. I know professors that will suck at it even if they use Ruby, and I've had wonderful professors that took me on great journeys with whatever language, low-level or high-level, that they were teaching at the time.
Ultimately, fun is subjective and it is just a function of what you make of the things you have at your disposal. Your learning potential will likely suffer if you take minutia as the focus of your likes or dislikes.
75 hours into a deadline week, coding is not fun. I could name every variable poop and fart, but that shit doesn't matter with your boss breathing down your neck (not to mention how pissed if I saw that during a code review). I'm not sure I'm sold on teaching through cuddly hand holding. That being said, technically I learned programming through logo writer and writing little games in basic when I was very young. Looking back, I do not think it was necessarily the content of the programming that kept me interested, but rather the self-competition of beating yourself at problem solving. Why can't kids be motivated by learning, rather than learning because they want to have fun?
Does anyone know of any material that follows that "fun" approach for Python? I am a pro web designer, but a non programmer, and would like to get a fully INTRODUCTORY course to Python but everything I've found so far makes me feel like I'm reading a manual to some complex electronic machinery.
Also regarding Tolkien, he was a linguist and invented many languages in his stories. The books inspired Larry Wall to become a linguist and work at a job processing electronic communications, and that's how Perl was born.
He talks about the Natural Languages Principles in Perl here: http://wall.org/~larry/natural.html
says that complex tasks demand 'low motivation" == "a relaxed mind".
This has been well-known since the 1930s, keeps getting rediscovered in different contexts.
...or at least more palatable. Using humor engages more of the brain and makes processing dry material more enjoyable. The only thing better is setting it to a goofy tune. I learned and retained more about James K. Polk from They Might Be Giants than I did from any other source.
What's the point in entertaining learning? It just means your soul will be crushed that much harder when you get out into industry and realize that 99% of your professional life will involve almost physically painful efforts to focus on unimaginably dull, repetitive, and restricted tasks.
I agree with your point about how these articles are a waste of time to read b/c they are essentially just one random person's diary of their tech travails in life....
The question of the post, about coding being 'fun' I think goes to something deeper though, something that TFA tries lamely to address:
Coding languages are non-sensical. That's what makes them so 'hard' to learn.
First, let me contrast between 'easy' and 'hard' & 'simple' and 'complex'....so, the task of 'dig a 5x5x5' hole in the ground' is a simple task, but it's not 'easy' with just a spade shovel...it's at least a day task for most /. readers
Coding is 'hard' AND 'complex'....contrast with the game of chess...a child can learn the basic rules of how the pieces move and interact, but the game itself is as complex as anything humans do..."easy to learn, difficult to master"
One reason coding is 'hard' is that so many abstraction layers add unnecessary complexity. People encounter choices and usage of language that is completely out of context of anything they experience and so far removed, in a systemic sense, from the 'user interaction layer'....So therefore, much of the work of coding is learning how to quickly teach yourself how to do a specific task.
The problem is, many professionals have built their workflow around dealing with coding's ridiculous abstractions. They establish a system of their own using heuristics.These tactics have become **standard operating proceedure**
Which alienates new coders.
The true difficulty in coding is the abstraction. Computers can do anything in 'cyberspace' in a sense...the only limits are our ability to describe commands with language!It's **contextuallizing** that total openness into a 'language' for human users to write commands for the computer to execute
So, to sum up, my theory is that writing code requires that the coder develop their own mental heuristic to overcome the natural limitations in the coding language in use.
"yes, duh" you might be saying...and that's why this matters in relation to TFA
Coding is not fucking 'fun' because new users expect coding languages to be intuitive instead of random and abstract. They *expect* to use their proven inteligence and methods that work for other endeavors to work with coding.It doesn't.
The answer to how to make coding "fun" and how to teach new coders so they retain interest is simple:
BE HONEST UP FRONT about what the real work is...
we need to stop pretending that us coders who have 'figured it out' have some magical intuition...it's all hammer-to-forehead slogging uphill...and finding cheats and shortcuts
Thank you Dave Raggett
If he ever has to grok a medium sized project full of classes with "whimsical" names he may wish for clear, intuitive names.
I read that part of the summary about "getting" to write whatever it was (get.chomped or something like that) and immediately yearned for a computer programming language where you could calculate pi to 300 places using the commands:
Wouldn't you?
The books inspired Larry Wall to become a linguist and work at a job processing electronic communications, and that's how Perl was born.
That almost sounds like the story of Morgoth.
Ezekiel 23:20
ok, I had a great teacher, so maybe thats part of it ;)
But generally, when I wrote my C work I quickly got into a quite deep flow. In the other languages I wrote/write stuff in (Java and Python at Uni, now C# at work) it is much less so because you generally do much less low-level tinkering -> the feel is much more upbeat and less relaxed.
On the other hand, the stuff that took me a weekend to write in C I could probably get done in an hour tops in any of those languages ;)
That would result in workplace violence.
For crying out loud, the best way to get people interested in programming is by using paper and pencil...http://en.wikipedia.org/wiki/Finite_state_machine
You don't have to deal with syntax errors, compilation, any of that pure BS. All you need is your imagination. If you told somebody to take two letters, and then draw a "game board" with circles and arrows so that you always ended on the "finish circle" whenever you have an even number of "letter 1", that would be all you needed to scratch the itch.
Whimsy is defiantly the way to go. Rename the variables into cute little things, make mini games, whatever you need to do to make it fun. Just because someone doesn't get it right away doesn't mean you should stop. Also, beginning by modifying small programs rather than programing from scratch can be a more fun and enjoyable way to learn. Once you know what you are doing, its much easier to do the boring stuff and the business problems, because you already know the basics of the syntax so you no longer get all hung up on that. It also helps a lot to have a nice text editor that highlights different code parts in different colors, and thus makes it much easier to find bugs. Now that I'm more advanced, I don't find myself relying on funny variable names or cute little programs to enjoy it anymore.
I am a starting Javascript developer. When I treat any task as an opportunity for self-development then the work becomes may be not very fun but at least meaningful.
I have found that the name of _everything_ is really crucially important, from variables to classes to programs to directories to servers.
Yes, it's cute when your servers are named "Kirk", "Spock", etc., but how much more self documenting when they are named "SQL1", "SYSLOGGER", or at least something remotely representative of what they actually do.
How does he require the gem if he can't even spell it?