Software Development

Strategies for learning programming languages - what works and what doesn't

Learning another programming language can be a great way to help take your development career to the next level. Justin James tells which techniques for learning programming languages have and have not worked for him.

In my recent post 10 tips to go from a beginner to intermediate developer, my #1 tip is to learn another language. Since I've had a lot of experience learning programming languages, I want to share what techniques have and have not worked for me.

For the record, we ran a poll in August 2008 asking how you learned to program. From the 4,716 readers who took the poll, 45% used a mix of various learning techniques; 35% were self taught; 20% learned in school; and only 1% were taught by a friend of family member.

Shoot from the hip

Sometimes you have no choice but to jump right in feet first into a new language with no preparation; sometimes we get so excited about a new language that we do the same thing -- even when it isn't necessary. In my experience, this is one of the worst ways to learn a language. You often end up with some bad habits that may take a long time to unlearn, and you actually spend more time learning like this than you would with a more disciplined approach.

The funny thing is the first time I tried this approach, it worked out fairly well. The HTML 2 spec had just come out, and I was learning HTML. It was a different world then; HTML could not do much, and it was fairly easy to deal with provided you had low expectations.

My next attempt with this technique did not work out as well. I was running an online store, and the software was written in Perl. I learned Perl's syntax in about 30 minutes, but it took approximately six months of intense work later on to feel like I had learned it well enough to live without having the documentation open in another window all day long. Luckily for me, I did not have to do much in the system.

This experience set the tone for years to come. I convinced myself that 30 minutes to learn syntax was "good enough," and any learning beyond that amount of time was just memorization that could be replaced by handy documentation. Later on, I discovered that what made me so successful in Perl (and unsuccessful in Java) was that I was doing enough work with it to learn the paradigm of the language -- its strengths, weaknesses, etc. I made a lot of messes until I gained that kind of knowledge.

Learn with human help

I learned my first programming languages -- BASIC, COBOL, Scheme, and Pascal -- in high school from an instructor. We were gently eased into a language, taking baby steps and doing projects of increasing complexity, until we had enough knowledge to write a full-fledged application from top to bottom.

This was a great way to learn, particularly for the first few languages because those languages shaped my thinking for a while. Unfortunately, there are three issues with it for a working developer:

  • It might take longer than you have to learn the language.
  • No school or facility offers a class to teach just one programming language.
  • It might be too expensive.

If you have a good instructor and a good workbook of appropriate exercises, this is the best way to learn your first few languages, but it is unrealistic to use it once your formal education is complete. (Maybe this is a possible business idea for a reader?)

Study the language before touching it

Another strategy I've used is to study a language in-depth before trying to write any code in it. You can watch online tutorials, read books, study source code, or whatever strikes your fancy, but no matter what, the learning should be at least partially structured (such as reading a quality book). The idea is to seed your mind with a lot of ideas so that when you start to write code (while you may not consciously remember everything you learned), the concepts are kicking around deep down and helping you out.

A technique I haven't tried but I know people who have is to essentially craft your own learning program. By putting together a disciplined program for yourself instead of doing research first and then trying to write code, you can create appropriate "assignments" for yourself during natural breakpoints in your study session.

I used this technique the first time I had to learn a language on my own. It was my college summer break, and I had the good sense to contact the CS department to find out what language the Data Structures class was in instead of assuming that it was in Pascal like the previous class. The Data Structures class used C, and students were responsible for learning C on their own. I bought a book that said it would walk me through learning C (I seem to recall the phrase "24 hours" in the title), and I read it about a month before classes began.

While the language is fairly simple, C requires a ton of work to use it safely and well. I didn't touch C until the second week of class, but when I did, I understood it enough to do everything necessary. I breezed through the class and watched most of my classmates struggle; their problems weren't with the concepts taught in class but rather with trying to learn C with the "shoot from the hip" strategy.

I'm currently using this strategy to learn Ruby (I know... I've been saying this for nearly six months). I still have not touched any code, but I'm almost finished reading a book on the subject. And you know what? I feel like I already know Ruby better than C# and probably VB.NET. My knowledge of VB.NET and C# were learned without any discipline or rigor, and there are gaps in my knowledge. I see things all of the time that have me scratching my head because I know enough to do my daily work, but my knowledge probably only entails a small subset of the languages' capabilities. I know that I am not as good in those languages as I could be because of these gaps.

Though I don't think I'll get to use Ruby any time soon for actual work (.NET implementations do not seem ready for prime time yet, and we're a VB6 and .NET shop), I'm glad for this experience. From now on, I intend to use this strategy for any new language I learn -- except for something I just need to stumble through to make a few minor changes.

What are your experiences with learning new languages?

What methods have or have not worked for you? Like me, did certain strategies work in some situations but not in others? Share your experiences in the discussion -- you just might help a fellow developer.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

90 comments
matharuajay
matharuajay

I had pretty good experience in learning PHP although I work on .Net but learned PHP to manage my blog http://www.ajaymatharu.com It was fun learning PHP dint used any human help just saw some code analysed and got my hands on. Tried some simple apps and got into flow. I managed to write a plugin for wordpress if you are interested you can check that out it tweets about your old post to get more traffic to your site :) http://www.ajaymatharu.com/wordpress-plugin-tweet-old-posts/

dashasalo
dashasalo

I am trying this approach just now and I think it works pretty well for me. It is great to start 'heavy' coding when you already have an idea of the language but you should still try all examples in the book yourself while reading.

Dukhalion
Dukhalion

Most problems I have had with programming languages are when I have a specific idea and try to implement it but can't find a suitable command to use. After some struggle I contact some friend who is fluent in that language only to hear "No sorry, You can't do that in that language, try xxx language instead, I think it can be done there." I should have started and stuck with assembler, which is to my knowledge the only language that can achieve practically anything. Look at GRC's Spinrite for one good example. Small, fast and does wonders.

kevin.adams
kevin.adams

Well, im more of a programmer wanna be. At this point in my life i'll probably never make it to being a programmer anywhere. I mainly use what skill i have in crafting scripts and applications to help me in my email administration duties. Usually upon setting my sights on a new language to learn (i do it just for the fun usually), i'll hunt down a book that looks promising and work through each chapter, etc. I tend to try to stay away from the "24h" books. For what i use the languages for, if i even use it, this works out great for me.

yadav.lokesh
yadav.lokesh

i am a web designer who is willing to learn dot net for web development. Can anybody help me in getting the right path to learn this technology ? Regards Lokesh Yadav

hercules.gunter
hercules.gunter

The best technique I have ever used is to get the language reference manual and read it straight through. This gives you a grounding in all the capabilities. Then, once in a while when there was some spare time, I'd read it again, looking for things I didn't know - and always I'd learn something. The problem is that that was back in the days when there were paper manuals. You could read it while commuting, relaxing in the park, waiting in the dentist's office. You could put sticky labels in it to mark points of interest. Best of all, the batteries never wore out ... These days there just doesn't seem to be a way to get a coherent overview, and I just can't find any language reference manuals.

ggardei
ggardei

My method... Crash Course Boss : George will write the necessary scripts to get our elementary and high school course management, reports and transcripts to work on our college ERP System. Knowledge of the ERP system : I was a new hire; so not much. I knew the name of it... CAMS, does that help? Knowledge of SQL, TSQL and ASP : None Knowledge of Crystal Reports : Heard of it

alaniane
alaniane

I like to first read up on the language and get the basic syntax. Then I like to take code samples and play with them to see what happens when I changed a bit here or there. Also, running them through a debugger to see what is happenning with code helps. Then I try to think up of a simple project to do in the language. Sometimes, I even take a project from another language and translate it to see what nuances there are in the new language. Then when I've gotten comfortable with the language, I see if it's possible to write part of a project I'm currently working on in that language. I set specific goals for what needs to be accomplished and whether it suits the language or not. I also set failsafe points where I can bail out if I find out the language is not going to support what I'm trying to do or if time constraints won't allow me to complete it.

fewiii
fewiii

It's all about just jumping in and getting wet. You can't be afraid to mess up (or get stumped). It's like something I learned a few years ago: "Until you blue-screen your computer, you're not a device driver programmer!" Just make sure you make *regular* backups!!!

ron.connal
ron.connal

Everyone probably has slightly different ways of absorbing new material, your article points out the most common ways developers go about about acquiring new language skills. Doing team programming with a developer that knows the language would be at the top for me, followed by study as you indicated, intertwined with coding on a personal project. I have found the "Head First" series of books from O'Reilly publications real helpful - concepts are explained with a lot of graphics, some goofy but always to the point. It also contains reinforcement of concepts in different ways and questions about the material covered ... code snippets to complete ... Just well rounded as good starter material for learning a new computer language or concept.

dsaftler
dsaftler

I think it's important to understand the basic concepts of software development (logic, data integrity, validation). There are programmers out there that know the syntax of a language, but don't program logically. As for learning a new language, I study first and seed my brain. I can remember that there was 'a way to do that', then go back and look up the method. I found a series of books that's well suited to that method of learning - the Head First series. There are plenty of thought exercises, puzzles, and quizes along the way that 'cement' key concepts. Those tend to stick in my brain better than the 'just read through' type of book. I'm currently learning Java.

jhoward
jhoward

If you are learning your first programming/scripting language I believe it is important to do so in a school or online course environment where someone is there to guide you and correct you when something is not quite right. Like Justin I started with BASIC/QBASIC and Pascal in high school and luckily our teacher was a retired software engineer. We didn't really do much coding in the classes first semester - it was mostly concepts and theory. When we started doing actual assignments second semester it was much easier to visualize mentally what needed to be done before we started coding. The emphasis was on building a game plan with the skills we knew and implementing it. Once we got the basics down he would show us how to improve the efficiency of the programs we already did. I am still learning C# and I am doing so in the same manner I learned those first languages - reading up on concept and theory and then getting a basic implementation down. Once the implementation works as expected I go back and find ways to improve upon it. This has helped me progress pretty quickly with my first .NET language however in the work place I don't always have the time to go back and improve upon a working implementation. In most cases it is more about getting it right the first time on the next project and fixing an older project when there is more time (i.e. never). That old dichotomy will always be there in the work place however every time I boot Windows I am reminded of why it has become okay to release work that "could/should be better"...

wlportwashington
wlportwashington

In high school we learned (or dabbled for a better term) in BASIC, FORTRAN, COBOL and CML (a binary language - very painful). All were procedural languages. In later years I went on to take JAVA at a local college. The first professor did not know the language at all. We spent the best part of 6 weeks studying floppy drives. The second professor went so fast, he actually ran out of breath. No one was able to keep up. The books were horrible at best and you could never get any additional help from the labs. Next we went on to VB.Net. As luck would have it, I was stuck with the same professor who didn't know a thing about JAVA. He had the same level of knowledge of VB.Net as he had with JAVA. And again the books were horrible and so was the rest of the support. For me, I have not had luck in finding good documentation nor anyone (or place for that matter) that offers instruction.

CodeCurmudgeon
CodeCurmudgeon

I learned FORTRAN in a class, but COBOL, PL/1, and PL/SQL from the documentation and existing programs. Visual Basic was a trial: There was no documentation to speak of and the whole business of declaring one thing and having a whole array of properties and methods pop miraculously into existence was disorienting. Not to mention, the examples available to me were of poor quality or were not germain. Java is going better, the books are a great improvement over VB, but having well indexed documentation that you can open to the index and have the answer to your question in a couple of minutes would still be an improvement.

jwork
jwork

I find it helpful to learn a new language with a friend or coworker. I find that when I explain how a new language works to someone else it helps me retain and fully understand it. The advantage to this is having someone else to explain what you don't understand to you also.

dkidd23
dkidd23

I'm 48 and programming/computers were a hobby for me for years before they actually became my career. I started in 1979 with a ZX-80 Sinclair hooked to a TV and programming in BASIC A and then later Machine Language. It became a career for me in 1994 and techniques I learned from early on assisted with learning new languages and new paradigms. Like someone else has written already, I like to learn the why of a programming language before the how. I then get a good book or tutorial and read through it to get a grasp of the syntax. My next step is to write small programs in pseudo code or take the psuedo code that I always save from previous projects and program in the language. I must say, the jump to OOP gave me fits at first, especially the limitations. But once I grasped the concepts it became very easy. It was learning VBA after having learned the Excel Macro Language that helped me to understand OOP. I am currently learning .NET (VB, C, ADO) to stick my foot into web development mainly because my company is using an outside web developer and I have to check up on what he is doing and will have to modify once he is done.

ralphsabean
ralphsabean

I'm too old to start learing too many new programming languages and besides that it seems that as soon as you learn one three more crop up. Why can't we just stay with HTML and upgrade it so the codes stay similar enough and you don't have to keep learning new codes. You would just need to upgrade a little at a time. Front Page and sharepoint are examples of easier ways to program publish and upgrade at the same time. Everything is already there so you won't need so many codes drifting around in an already boggled mind. Thanks so much for the info just the same.

bhaskarr
bhaskarr

Study and practice is ultimate

ibrahim.it
ibrahim.it

I thing Microsoft should make something called mobile workshops to send outside (or inside) states to teach the languages and programming techniques , rather than making only references books !!

KSoniat
KSoniat

When I was in school we were taught PL/1. Even back then there were no jobs in it and some complained to the professors. The answer was "We are teaching you to program on the most robust language available. It should be a fairly simple exercise to learn a new language with the programming skills you already know." This may be somewhat less true today - but has held most of us in good stead. :) Edit: kan't spel

mikifinaz1
mikifinaz1

Go to school and learn programming academically or learn by doing. Learn by doing is better, usually, but takes way longer. On the Job Training (OJT) was fine for older people because, hey there wasn't any way to do it but OJT. Now younger people need to get up and running faster and school or mentoring works faster. The main issue is, learning by doing helps you find all the information written between the lines in books. A simple example. An end user wanted to keep his laser printer and use it with XP but only had Win 3.1 drivers. All the new guys said that's impossible based on all their training. Experience has taught me that by starting with Win3.1 and upgrading you can drag the drivers forward into XP and the laser printer will still work. Yes, a major pain, yes, it won't always work, yes, it isn't the best solution, BUT it works. The same is true of programming, there are some tips and tricks that the old guys learned hammering on COBOL and FORTRAN that still work today and you won't find in textbooks or classes.

Anita Y. Mathis
Anita Y. Mathis

I took my first programming course in the 12th grade. It was Pascal. I dropped the class after we did the calendar.(and thus began my career as a secretary..lol) I've taken C/Visual C++, VB and some stuff I don't remember. It's hard to actually develop code when you're first exposed to it, or at least it was for me. Reading about it and doing tutorials sounds like a very smart idea.

Osiyo53
Osiyo53

Generally speaking, I'll browse through the official docs, user manual, or a book written about the language. Lightly, quickly. I'm not really trying to learn details at this point. Just trying to get a feel for it. That is, for the basic ideas and goals behind the design of whatever particular programming language. After all, let's face it, you could program any app in straight machine language ... the original, mother of all programming languages. And what any system is actually running "under the hood", anyway. BTDT, it's the first programming language I was taught and learned. On a CDC 3109 mainframe. The idea of other programming languages is, of course, that they employ certain strategies in order to make certain programming tasks easier, more efficient, more easily maintainable and understandable, etc. Trust me, I proved that to myself once when I decided to reprogram an approximately 500 line FORTRAN app, a relatively simple one, using straight ML. Not assembly, straight ML. I did it successfully. This achieved a couple things. I learned a new appreciation for FORTRAN, and I learned the ML of that 3109 to a depth greater than I had previously. I also got stronger arms from hauling around the printed copies of my ML project. Anyway, after a quick browse through whatever literature is available in order to get a feel for the new programming language, I'll usually load up the IDE (if there is one available) and try a few simple test runs. Coding some simple and stupid little things. In short, I start to become at least a little familiar with the new tools. At least, what does what, where to find things, that sort of stuff. Then, I go back and start reading all over again. Skipping a lot of stuff. But reading in more detail and with more focused attention upon those parts of the new programming language I am most interested in and which I am most likely to use in the types of programming I actually do. My goal now is to learn more about those facets of this new programming language that I am most interested in and most likely to use. Some would disagree with me about this, but so be it. The point is that I am focusing upon those aspects and facets of the new language whose purpose and usage fits in with my needs and interests as a programmer. To, among other things, keep my interest up and my concentration focused. Bore me and I go to sleep, start thinking about other things, etc. As an example, with one new language I was trying to learn, someone recommended a particular book about it. However, the author of said book attempted to teach by offering examples focused on game development. First, I've never studied game programming theory, so a lot of the examples offered focused on accomplishing certain tasks that he assumed you'd understand the need for. I didn't. And second, computer games bore the crap out of me. That language, BTW, was Java. I dropped back and punted, did my own research and found a book and numerous web sites that offered tutoring and examples on the type of programming I might actually want to do using Java. This kept my attention focused and motivated me. Making my time and efforts to learn more productive. Keeping on with the Java example. After I'd learned the parts of it that benefited and interested me, from time to time I do drop back into learn mode and take a second look at facilities, features, functions, and libraries that are not directly related to my primary interests and purposes. Just dabble at it, try to learn something new. Based upon my thoughts that one never really knows where and when you might actually pick up something useful. But for initial learning, I focus on those aspects and features that directly relate to the type of apps I specialize in and have the most interest in. For myself, my expertise (and interests) are focused primarily upon specialized math routines and functions, text/string manipulation and parsing, database functions, data re-coding/reformatting, etc. It's the kind of programming I mostly do for a living (I'm an engineer by trade). As concerns things like GUI functions, advanced graphics and animations, fancy special visual effects, etc. I know the basics, but have neither the real need or interest in developing my skills in those tasks beyond where they are. Where I work, we have a specialist who codes that kind of stuff if there is a need. When I and my co-workers are done with the apps that actually do useful work/tasks, his job is to slap on a pretty front end, visually appealing screens, etc. That's a whole art and skill set in itself. OTOH, he is not nearly as good as we are at coding the apps which actually get things done. The fact is I don't know any programmers who are broadly skillful in their knowledge of and use of all aspects of any programming language. I know some who CLAIM they are ... but that's a whole different subject. For myself, I find that the quick scan through the docs to get an overview and feel for the new language. Followed by a few test runs, coding the type of small, simple routines one is most familiar with coding and using. Before delving in, in depth, is beneficial. Then, when I do dive in, I concentrate at least at first, on developing code fragments (mini-apps) of the type I'm most interested in and which I'll most likely use in real development. After mastering those, THEN I may attempt to broaden my skill set in that new language. OTOH, I might not. I have only so much time, and do have other uses for it. I've been promising myself for ages that in one particular language I program in that "someday" I'll make the effort to learn more about it's advanced graphic functions and libraries. Been telling myself that for years. Yeah, right. Of course I will, maybe next year. If I'm really bored to tears and can't find some other sort of task I'd rather do.

dkidd23
dkidd23

Never tell me you can't do that in this language because I will find a way. It may not be graceful, it may eat a lot of system resources but I will find it. I think it is because I never learned by going to school, just learning on my own. I've always believed that if I can imagine it, I can do it. Time and time again, I've proved it. A few years ago, someone told me that full text searching wasn't possible in Access 2003. Even the documentation for the program mentions it. It took me about 20 hours but I was able to create full text searching. Later we had an outside company working with ours to port the backend over to SQL Server 2005 and they were amazed by the Access database I had built. Don

Sterling chip Camden
Sterling chip Camden

... and a large part of my career has been spent finding it. But the question is always whether the cost of finding that way outweighs the cost of switching languages.

Tony Hopkinson
Tony Hopkinson

to side after being thrown in the deepend. Management have had several attempts at drowning me as well. I'm not sure it's becaue it's a successful learning strategy though, more like we'll get rid of the irritating tw@t, this time.

auogoke
auogoke

While in grad school we had a teacher who used card games to illustrate concepts in our simulation and modeling class. Everyone was nodding but I didn't have a clue about what he was saying because I simply do not know how to play cards! I could not write a program to simulate what I fundamentally did not understand. It was an eye-opener to say the least. I still don't get the Head First series. Although everyone seems to like and benefit from them, they seem to lack "structure" and appear "disorganized" to me. Perhaps I need to take another look.

auogoke
auogoke

To the parts about having, err, "challenging" teachers. I had the misfortune of dealing with 3 straight "challenged" teachers. Although I turned in better work than all but one student in my all these classes, I still ended up with "B" s. I stayed with programming because, done right, the results usually speaks for itself. I also wanted to "disappoint" some people. The "first" time I had fun learning a new programming language outside of class was with Pascal. I tinkered a friend's homework assignment in an "idle" moment and was hooked. I loved the clarity and structure of good Pascal code. Programming tools and access were much better than when I took my Cobol programming classes. There was no pressure or grades. I later took a class called programming languages. A classmate presented a research paper called "The winner is Green" -- describe the winning design of a new programming language. Green was the DoD code name for what became the ADA language. How cool is that... knowing what went into the design of a programming language and why?! I am learning Ruby -- I needed a "good" language to teach my daughter how to program. I have scoured the web for good books. I must still break it all down to something my daughter can relate to. She will need to know how to recognize and break down a problem and can use appropriate programming language constructs to create a solution. For me, programming is about selecting efficient constructs -- in whatever language you are using -- to solve problems that you have correctly parsed. I accept that there will be new programming languages offering new constructs for implementing problem solving logic.

guillegr123
guillegr123

The last year, I learned the basics of DrScheme in my Functional programming class in the University. I must accept that I had a good teacher. However, like all the other assignments relationed to my career (Computer Sciences degree), there was a final project, and I needed to learn how to use the graphic package, MrEd, by myself, in less than two months. It was an odyssey, because I speak spanish (I guess you had noticed about it a few lines back), but there is a minimal documentation in my native language, even searching in Google. After days trying to find something in Internet, I finally surrendered, and decided to use a very large manual (PLT MrEd: Graphical Toolbox Manual), which was in english. It took me about a month to discover that the graphical package applies the Object Oriented paradigm. However, because I have no idea about it at the beginning, I used the "Ranger Way" (as we call it), which consists in play with the code until the program do what I want (and hoping not to destroy the computer in every attempt, hahaha). After many trials, I learned the basics of the graphic package, and some curious advanced stuff, which resulted useful in my project. Those were the good news. The bad news: it takes a lot of time, effort, and a sad ration of frustration.

Justin James
Justin James

Some documentation is useless. Some, like the .Net stuff and the JavaDocs, are a good reference if you already know what you are doing, but not so helpful if you don't. And my favorite kind of documentation can replace a good book; the Perl documentation is like that. J.Ja

Tony Hopkinson
Tony Hopkinson

debate on whether HTML is a programming language. I doubt it was in the forefront of JJs mind when he wrote this article. HTML isn't exactly Turing complete.....

Justin James
Justin James

Microsoft already does it, but on a somewhat smaller scale than teaching entire languages or techniques. They have a lot of "developer evangelists" who regularly put on workshops and take them around the country to show people new technologies and such. I went to one a few months ago on ASP.Net MVC, for example. And if you have a local developer's group, they will gladly send someone to present there too. At the developer's group I go to, we had one of the Microsoft developer evangelists present (in fact, he's one of the guys who write the "MSDN Flash" newsletters that I get), and he did a great job, and really knew his stuff. J.Ja

Realvdude
Realvdude

One side being "learning to do", the other being "do by learning". Having done both, I didn't find one easier than the other. The "do by learning" usually involves being invested in process and outcome, where "learning to do" is more invested in the potential of what can be done. The great thing about the internet is that it provides resources for learning, mentoring and OJT.

dkidd23
dkidd23

I actually had a similar situation but I just got the driver specs and custom wrote the print driver myself for XP. No hiccups, prints great.

Tony Hopkinson
Tony Hopkinson

anymore than learning english, is learning to write a book. Or learning arithmetic is learning mathematics. Far too often academia and the certifiers, teach it as though it is. Quite a few of us feel that diving straight into a first language, actually obscures programming as a discipline. Forget VB, C++ etc. Write out the steps in 'english' to make a cup of coffee, then try to follow them. It might sound silly, and certainly you'll have a problem finding anything other than a tolerant human to run your program. But it's what you do when there's a power cut, or you forget to get more coffee from the shop, that fascinates programmers. The language you write it in, is a personal, a market, and or company preference, very rarely a technical one.

Chaz Chance#
Chaz Chance#

When I was an IT tutor, back in the Eighties, I used to help out the COBOL students. It started when I saw one of them peering at a printout and getting upset because he couldn't figure out where the bug in his code was. The COBOL tutor had suggested writing the code again because the bug wasn't obvious, and the code compiled (or whatever COBOL did). I offered to help, and the student was surprised because he didn't know that I knew COBOL. I was a tutor, so I made him talk me through what his code was doing, line by line. Soon we discovered that the code was clearing the screen after drawing the form, instead of before it, and this was why he was being left with a blank screen. I was called to account for why I was encroaching on the COBOL tutors territory by teaching COBOL. I replied that I didn't - couldn't, because I didn't know COBOL, but that what I was teaching was programming, which clearly the other tutor was not teaching. Knowing a language is not knowing how to program. Even knowing a language and knowing how to program is not knowing how to program in that language. Write out the steps to make a cup of coffee. Then ask someone to follow them, and point out if you missed anything. If that goes okay, do it again for another activity. And another. If after you have done ten you find that you enjoy doing it, consider becoming a programmer, because you have the right aptitude. (Other careers may include health and safety, project management, technical author.) If not, find something else because you will probably come to hate programming.

Sterling chip Camden
Sterling chip Camden

You can't tell someone how to make a pot of coffee in ancient Sumerian, because they didn't have words for coffee or any of the appliances you use in the process. Heck, they didn't even have vessels that would stand the heat required to boil water, so they wouldn't even know what that meant. OK, in theory you could build up a vocabulary in ancient Sumerian to explain and represent each of the components of the process, just as the Navajo tongue employed various metaphors for communicating wartime information in WWII. But it would be a far from efficient process. The same holds for programming languages. Any Turing-complete language can theoretically be used to program any solution, given enough time. And the programmer's ability to design and program is indeed a far more important factor than the language used. But I'm not planning to wait around for anyone to write a UI framework in Brainfuck.

jslarochelle
jslarochelle

That's not obvious for everyone though. JS

Tony Hopkinson
Tony Hopkinson

procedural, is a short one. Lest we forget now we are spoiled, doing large procedural applications that exhibited, encapsulation, loose coupling etc, required you to design and implement the scaffolding first. Which is why a lot of people didn't bother, which is why OO became so popular. I still like to dodge OO for some tasks and being forced in JJs pet hate of static class with static method on it is a pain. I'll live with that compared to getting no help dealing with all the other stuff though.

jslarochelle
jslarochelle

Learning to partition your design into high quality classes is just as important as correctly building the procedural part. However I agree that you have to start somewhere and that while you can write useful programs using purely procedural constructs and primitive you can't do anything useful (that will actully do something) with classes without the procedural part. In that sense I agree that it is useful for entry level programming to drop the OO scaffolding. That's one of the reasons why I agree with Tony that Pascal is a good entry level language (no OO scafolding, parameters per reference without using explicit pointers, bounds checked arrays, ...). JS

Sterling chip Camden
Sterling chip Camden

The programmer who is proficient in multiple languages will look at the problem and will think about what language features are best suited to it. If it's a feature that doesn't exist in the language he/she is forced to use (which happens to me a lot), he/she will look for the way that language wants to do it instead -- if that proves insufficient, he/she will perhaps invent the feature or something close enough.

Tony Hopkinson
Tony Hopkinson

There's a core skill to using any hammer. Hold the right end, hit the target at the required angle with not more than the required force. There's a big difference between hammering your thumb flat, and attempting to unseat the black knight from his destrier with a toffee hammer. Which was my initial point. One of the real advantages of learning a second language, is picking up the common factors, because then you have a good start on understanding a third, and becoming a craftsman. I'd like to say choice of language is a valuable skill, but 99% of the time developers don't get that choice, and have to face Sir Grimnuts of Grimswold with a 2 ounce piece of steel with TOFFEE stamped on it. :(

Osiyo53
Osiyo53

"You can teach someone to drive a nail with a rock, but they'll have a lot better luck with a hammer." And after they've mastered the use of a general purpose hammer, they will find that using the correct type of hammer matched to the specific type of task can make the getting the job done even easier and more efficient. The very reason that a good tool shop or hardware store carries a selection of a dozen or more various types of hammers. A reasonably proficient and experienced handyman can accomplish most hammering tasks using only a regular, curved claw hammer. A master craftsman, however, even tho he COULD make do without them, will want a wider selection. So as to do a better job of it, more efficiently, at each type of hammering task.

Tony Hopkinson
Tony Hopkinson

was considered by academia as a suitable first language , made what hair I have left stand on end. That's not a dig at Java per se, I would n't choose C#, VB, or Delphi either. To learn OO, you must learn procedural first.

Sterling chip Camden
Sterling chip Camden

I absolutely agree that learning the principles behind programming is far more important than learning a specific language. But I do take exception to the idea that language doesn't matter. You can teach someone to drive a nail with a rock, but they'll have a lot better luck with a hammer. Likewise, you can teach someone how to program in Java, but their first impression is going to be "this is hard" -- and not for the right reasons. All the required OOP scaffolding that they have to learn is just noise that hides the real principles that they should be learning instead.

alaniane
alaniane

that you need boiling water to brew coffee. The Japanese have a method of using cold water to brew coffee. Also, for some boiling water actually ruins the quality of the coffee produced. Too hot of water causes the coffee bean to release its bitterness. It's easier to learn a language, but it's more useful to learn the principles behind programming. If you start students out language-centric then everything becomes a nail. I like Tony's method because it's simple and language-agnostic.

Tony Hopkinson
Tony Hopkinson

Fighting a language/environment is one of the hardest things you can do, technically it's very rewarding, in terms of business it's butt stoopid. Picture multi-threaded VB6, someone actually tried it, put a lot of effort into finding out it couldn't be done. Bet he knows his VB6 now though. :p

Sterling chip Camden
Sterling chip Camden

... and the programming language is not programming. But some maps are better than others depending on what you're looking for, and some languages make certain kinds of programming practical.

Tony Hopkinson
Tony Hopkinson

it comes in various flavours but I've seen plenty of examples that f**ked with my brain. I don't agree with your reservation though, If I'd have swapped herbal tissane for coffee, and rain putting out fire for power cut, the point would have been the same. I don't get this fixation with language as programming, it isn't, it's an abstraction. Some are more convenient or offer more descriptive value than others. But a drawing of a boat and a scale model of the same boat, both describe a boat in a particular way. Neither one is the real thing, the fact the drawing something with a stanley knife is not ideal, is neither here nor there. In fact it's the confusion that you can or should that shows that people are taking the map for the territory.

Editor's Picks