I had a discussion with one of my teachers the other day.

We debated the impact that simpler scripting languages (like Python or Ruby) have on junior programmers.

He argued that scripting languages engender sloppy coding techniques because beginners don't understand what is going on "under the hood". He also cited other examples of how scripting languages often cause the programmer to neglect concerns about efficiency, memory management, operational complexity, etc.

I argued that lower level languages might be too much for some people and they might give up before they develop a passion for programming. When I started learning my first programming language (C), I got to pointers and gave up because the concepts were too hard (in my defense, I was only 14 years old). If it wasn't for Java, I might not have become a programmer! If I had started with a simpler language and then dug deep, I feel I wouldn't have given up and I would have learned just as much as I have starting with C.

The class ended before either side was fully explored.

To this point, I have been preaching that beginners should start with scripting languages and then dig deep; but after that discussion, I began wondering if this was erroneous thinking.

So, what impact do scripting languages have on junior programmers?

closed as primarily opinion-based by user40980, GlenH7, Dan Pichelman, Kilian Foth, gnat Jan 1 '15 at 20:36


  • 8
    I don't mean to be an arse but grammar.quickanddirtytips.com/affect-versus-effect.aspx – Singletoned Apr 20 '11 at 21:52
  • 4
    I learned to drive on a car with an automatic transmission. Later, I got one with a manual transmission. It took some time to learn, and I felt lucky that I hadn't had to learn the clutch and shifting along with everything else. – David Thornley Apr 20 '11 at 22:02
  • 2
    @Singletoned: True. Somehow I had to think of xkcd.com/326 though... – user7043 Apr 20 '11 at 22:31
  • 2
    Made me think of this joelonsoftware.com/articles/ThePerilsofJavaSchools.html – P.Brian.Mackey Apr 21 '11 at 1:15
  • 4
    Personally I think its unnatural to learn to program low then high. We learn to crawl then walk then run, talk then write. Not sure what the logic is for the reversal of natural order in college. I usually just hear people conclude "because if it was hard for me to learn then it needs to stay hard for you". Even Joel said this. I guess the cycle will never end. – P.Brian.Mackey Apr 21 '11 at 2:32

14 Answers 14


I disagree. First, scripting languages are at a higher level of abstraction, and there is nothing wrong with this. At the beginning one is just trying to learn the principles. Actually I would say that choosing a lower level language may encourage bad coding, since one has to deal with some details before being able to understand them. Instead with a simpler language one can start writing clean and concise code from the start.

Second, there is much to learn in these languages. As far as learning the language, I would say that C is easier than Python. One has to deal with pointers or take care of strings, but there are many more concepts to learn in Python. Comprehensions, object orientation, reflection, magic methods, first-class functions, lambdas, iterators and generators, metaclasses: all of this is part of the language.

I think that starting with Python allows to learn much more about programming and with a gentler learning curve. A lower level language may have less abstractions - so less general concepts to learn - and overwhelm the beginner with details he may want to do without.

  • 1
    +1, though I don't think C is easier to learn than Python in any sense. Maybe there are fewer concepts to learn overall, but you'll learn more in the same amount of time with Python. And of course, if C's too easy, there's always C++, teaching you the complexities of both high- and low-level languages. ;) – Martin Apr 21 '11 at 11:18
  • +1, this was my thinking! I wish I would have read this before class :) – joe_coolish Apr 21 '11 at 14:14

It doesn't matter where you start. It matters where you go after you start.

BASIC may not be the most elegant language on the planet, but it encompasses the fundamentals of procedural programming, and that's enough to get started.

I started with BASIC. I didn't stay there.

  • +1 for the perfect answer - showing concisely how misplaced the original question is! (As utter coincidence, I started with BASIC too ;-) – Péter Török Apr 21 '11 at 8:41
  • 5
    It amazes me how many people DO stay there.. :o/ – Gary Willoughby Apr 21 '11 at 11:22
  • 1
    Excellect answer. Brief, accurate and to the point. I started with BASIC as well. – Michael Riley - AKA Gunny Apr 21 '11 at 13:27

Your teacher is correct, except that he assumes that his consequences are bad things.

If you look at learning languages as purely an academic activity to learn how computers work, then he is correct. If you look at them as a way to get things done then you are correct.

  • 6
    Gotta disagree with you. The consequences are bad things, because the consequence is ignorance. This means that eventually, something will break and the problem will be at a lower level of abstraction than you understand, and so you'll have no idea how to fix it. That's always a bad thing. – Mason Wheeler Apr 21 '11 at 1:05
  • 6
    Gotta agree with you. The consequences of not knowing what goes on under the hood is a profound simplicity and directness of expression with no worries about hardware nuance. Lower levels of abstraction are for language designers not application developers. – S.Lott Apr 21 '11 at 2:38
  • 1
    @Mason: Absolutely. I once made a very substantial amount of money saving the asses of a team of programmers who had no conception of what was really going on under the hood, and so couldn't make their production system perform well, or work reliably. (Once because that kind of work sucks. Life's too short!) – William Pietri Apr 21 '11 at 6:21
  • 1
    @Mason - I agree with what you said, that it is important to have that knowledge if you are going to program professionally. I've found my knowledge of pointers, discrete structures, and lambda calculus extremely valuable. I've been stuck in teams where my team members didn't have these skills and they ended up making overly complicated or very buggy code. only because they didn't know better. It just seems like sometimes colleges feeds CS students too much milk and not enough meat, but on the flip side, if they feed the beginning programmers meat they run the risk of them dropping out. – joe_coolish Apr 21 '11 at 14:31
  • 1
    @Joe: According to Joel, making the ones who can't handle it drop out is the entire point. And as not only a computer programmer but a computer user as well, one who regularly has to work with horrible programs that I can only assume were created by incompetent coders, I really wish the "making them drop out" bit was more successful! – Mason Wheeler Apr 21 '11 at 15:25

I think "scripting language" is an awful word, that is extremely outdated or at best suits a class of domain specific languages. Your teacher is just aligning everything he clearly doesn't have enough understanding about into an axis of evil.

A sensible distinction to make is that between high level languages and low level languages, or between statically and dynamically typed ones, which are truly orthogonal.

Assembler is low level dynamically typed (if speaking of types makes any sense at all), C is low level statically typed, Ruby is high level dynamically typed, Haskell is high level statically typed. Java is neither high nor low level statically typed, C++ is both high and low level statically typed. And so on.

The discussion can only be, which paradigms are more suitable for an entry level programmer.
I am quite convinced low level programming probably isn't one. It might have been, some time back in the early 90s, when you could actually produce interesting results in reasonable time with it.
But programming is fueled by passion. Passion is nourished by rewards. Therefore, entry level programmers should start with rewarding tools. Low level tools are no longer rewarding, because there's a vast sea of high level tools that get you the same result in a fraction of the time.

Human thinking is abstract. As we learn to understand the world, we do so by very coarse grained abstractions and we go into detail as needed.
For a child to understand its environment, you're not going to teach it mathematics, then physics, then chemistry, then biology, then history, sociology and philosophy. You give it a very simple model of the world to cope with and will, by itself long to reach past it, endlessly firing questions at you when young and completely negating your authority later.

That is how we think. The human brain can only process limited amounts of information "units", but the degree of abstractness matters little in the quantization of information. For example: reading the expression '34*75' to us is simpler to us than calculating it, whereas for computers it's the other way around. To recognize (and thereby abstract) a bunch of black pixels into a squiggly line, which can then be recognized (and thereby yet again abstracted) to be an individual digit is a tremendous amount of work.
My grandmother understands the idea of opening a file. However she has no understanding beneath that level. And frankly, if she had had to learn this by first studying the internal workings of the hardware and the operation system and what not, she never would have gotten there.

There's a lot of people out there, who overcomplicate things, because they were never taught to think in terms of clear, concise and thereby elegant solutions, but spent too much time bothering with exchangeable low level details and solving problems against those. Teaching people to think like computers is the worst possible approach to programming.
The value of programming lies in finding a solution to a problem. Expressing it as code is really more of a dull, mechanical task and should simply be done with whatever tools are fit.

Oh, and don't worry about not having understood pointers. I had about the same problem at the same age. The problem here is also the lack of abstraction. Classically you learn about pointers from some C book and while you're struggling to understand them, this goes hand in hand with memory allocation and thus with stack and heap memory and so on. The abstract concept behind pointers is indirection. A variable, that holds an index into a specific array is just that (actually it's really the same in C, where the specific array is your address space), and you do not need pointer arithmetics for this.
This is just meant to illustrate, that choosing high level of abstractions makes things a lot easier to grasp.

EDIT: and when it comes to typing, I prefer statically typed languages. And I think entry level programmers should clearly understand the concept of types (which is an abstract one).


There's nothing simple about Python. Take a look at Unicode and meta-programming.

  • I agree that Python can be very complex and VERY powerful. But the basics (string manipulation, array manipulation, etc) are much easier in Python than in C. – joe_coolish Apr 20 '11 at 21:40
  • 1
    Python is very simple to start with and many everyday tasks are an order of magnitude simpler than e.g. in systems languages. No, the language as a whole, its gory details and the advanced features aren't simple (this holds for all non-toy language). But that wasn't the question. – user7043 Apr 20 '11 at 22:32
  • 1
    Then why was my if searchstring.lower() in filecontent.lower(): not working? because of the bom in UTF-16LE sql file in tfs on windows with Python2.7. Was not fun. got it working. took a few hours. string.find() was not working either... Argghhh! – Christopher Mahan Apr 20 '11 at 22:55
  • 1
    How is Unicode simpler to handle in C? – dan04 Apr 22 '11 at 6:38

I see another, much deeper problem.

Unityped languages don't force one to pay attention to types, to think in types. This is well and good as long as I have small scripts with some strings and numbers which are converted to each other without noticing. But the day will come when this will break. Suddenly, the program will break, and every quick fix will cause it to break again.

Or, the novice wannabe programmer figures out that he will need a tupe of lists instead of a list of tuples, but will not have the slightest idea "how to do this", and he will ask questions on stackoverflow that show is absolute helplessness.

  • 6
    But Python and Ruby are strongly typed. This is orthogonal to being dynamically typed. Strings and numbers don't implicitly convert to each other. – dsimcha Apr 20 '11 at 23:20
  • 3
    @dsimcha: Yes - And how does that refute what @Ingo said? – Jim G. Apr 20 '11 at 23:43
  • 1
    Because this question is mostly about Ruby and Python. I thought he was implying that he thinks Ruby and Python are weakly typed, which is a common misunderstanding. – dsimcha Apr 21 '11 at 0:04
  • 1
    @davidk01 - that's my point: values have types whether we want it or not. But in dynamically typed (if that term pleases you more) languages, variables have not. Instead, type checking is done at runtime to distinguish between the many variants of the Unitype. – Ingo Apr 21 '11 at 8:55
  • 2
    @Ingo: I at least used to be able to find Common Lisp users who thought the lack of static typing was a benefit (actually, optional static typing, usable either for error checking or performance purposes), in that it sped up development and that the errors static typing would have avoided didn't turn out to be difficult to find and fix in practice. I haven't seen anything more than opinion one way or the other. – David Thornley Apr 21 '11 at 18:05

I still maintain that formal instruction and mentoring is a much bigger factor than language choice in beginner code quality. However, if I had to pick a first language for beginners, I would choose python for self-taught programmers and C++ for college instruction.

The reason is with formal instruction you can start with small, trivial programs to lay a strong theoretical foundation years before you need to do anything useful. I think that order is ideal if you can afford the time, and C++ gives you a lot of help with compiler errors and segmentation faults between lectures to let you know if you're not grasping the fundamentals.

Some of those fundamentals are just plain really hard to learn if you're self-taught, until you get some experience under your belt. Also, you usually need to be making something useful as soon as possible, and can gain the theoretical underpinnings as needed, although you risk never learning more than the bare minimum with this approach. That's why I recommend a language like python in that case.


We saw it the other way around in college and I think it's useful. *We started on the low leve. Pointers, memory management, character arrays... So yes, we started with C. The same with algorithms: first implement a linked list, a hashtable, a tree... And only then use the standard libraries.

After that we went up to more powerful languages such as Java, C# or perl. But with the advantage of knowing what's going on under the belt.

While this works, I believe that going from scripting languages to a lower level language is fine too. Knowing both a high and low level language makes sure you have the ease of use of a high level language while still understanding what's going on. The order in which you learn them is less important.


Scripting languages don't make programmers sloppy. Lack of clarity of understanding the problem domain (e.g. the business the program serves) is what causes sloppiness.

As the old saying goes, "You can write COBOL in any language.", although I suspect that when every data type looks the same, then it becomes harder to see what are the essential aspects of your program, a major feature of COBOL-ization.

  • 1
    Try it before suspecting. The main difference is that you don't give a damn about where it's a Foo or Bar or something completely different as long as you can .frobnicate() it either way. Without explicit interfaces. – user7043 Apr 20 '11 at 22:45
  • I am pretty familiar with dynamic languages, as my day job is with Ruby on Rails. And yes, that is a major convention within the dynamic language community. In general, this is called 'duck typing'. In the research literature, they are called structural types, and there are some syntax conventions that can show you what a 'quackable type' looks like. Not only that, there are type systems which can recognize them, and verify that your program is treating the ducks with kindness. – Farley Knight Apr 21 '11 at 4:58
  • I know about structural types and consider them a pretty neat idea. But as there's not a single mature, remotely widely-used (O'Caml-level user base would be a good start) language that uses them, I don't consider them a practical alternative to dynamic typing. Sad, but fact. – user7043 Apr 21 '11 at 15:57
  • Widely used languages don't, but that's not stopping you from boot-strapping your own type system onto a widely used one. I'm sure you've seen papers on things like type inference for dynamic languages. – Farley Knight May 9 '11 at 2:13
  • Again, I don't consider something used by me and the guy next door a practical alternative. A programmer needs things like libraries, stable syntax, tooling, etc. – user7043 May 9 '11 at 6:31

I would argue that scripting languages do encourage sloppy techniques. (Note that this is not saying the languages are bad, just that it is hard to maintain large codebases in said languages) However, I think that for different reasons than the other answers here.

I think to use any language a programmer needs to have some basic understanding of programming as a whole. They're not going to be effective anywhere if they don't understand concepts like vectors, trees, and hash tables. They don't necessarily need to be able to implement these things, but they need to know their characteristics.

Where I think the sloppyness comes into play is not programming skill, but when one needs to create reuseable components. These languages do not require you to define good interfaces between code units or the mechanisms to have libraries enforce constraints on their clients. It's not impossible to make good reuseable components in such languages, it's just much more difficult.

The scripting languages have the appeal to the newbie programmer because it allows them to get more "one-off" things done in less time, but when those same programmers start doing maintenance programming they often quickly have problems with these languages.

I'm not saying scripting languages are bad -- far from it. But they do make it difficult to maintain enormous (several million line) codebases (which is one of the reasons why you don't see any such codebases done in scripting languages). When you need relatively small or one-off solutions, they allow you to accomplish far more in less time, and less code (and less code is almost always better).

Just keep in mind that no tool is best for every job. Choose the tool most appropriate for the situation. That goes for programming languages just as it does for any tool.


I'm with your teacher, but also with @Singletoned when he says your teacher is assuming the consequences (e.g., no knowledge of performance) are bad.

I think starting with C is better than starting with scripting languages. As a teacher, I would concentrate on that whole von Neumann architecture thing (ALU, registers, memory, i/o ports, ...), move straight on to pointers (I'm sorry, it's really a key concept [not releasing references (i.e., pointers) in VM languages is a prime source of memory leaks]), hit some data structures (tree, linked list, hashtable1), and then... kick it up an abstraction level into something else (OO, functional programming, something -- strong static typing rules, yo \m/, so no "scripting languages" >:( ).

1Hmm, maybe I agree w/your teacher on performance considerations, after all.

  • Sloppy programming is a source of memory leaks and it doesn't take much to teach people to keep track of resources like file handles. There are countless C programs with memory leaks so I'm not sure what you're getting at with teaching people about pointers as soon as possible. – davidk01 Apr 21 '11 at 0:38
  • That is true, but... (a) not understanding the basics leads to some bad code (via hacking-til-it's-right or sloppy programming), and (b) I was trying to motivate why pointers are still relevant, not asserting that C is better than garbage-collected languages in terms of memory leaks. The objective of getting to pointers asap is so we can then get the heck out of C. – JohnL4 Apr 21 '11 at 1:22

I think the best is to start with a modular language and then go on to more complicated stuff, in my days we started with Pascal and COBOL and tried to understand what subroutines,control flow variables etc mean. Only after being comfortable with Pascal did I even have the desire to switch to languages like C/C++ and learn all the other techniques which are more of an add on to the junior programmer.


You're both right.

Scripting languages definitely make it harder for novice developers to understand what is really going on. (So do databases, frameworks, and libraries. Oh, and browsers, servers, networks, and filesystems.) When I interview younger developers, I am often dumbfounded how little they know about how computers actually work, and how prone they are to cargo-cult programming.

On the other hand, the number one thing I look for in interviews isn't perfect understanding, it's that they love making things. Back when I got started, a computer doing anything was pretty impressive, so my little Apple Basic and 6502 assembler things seemed really awesome to me. But these days computers do a lot of amazing stuff, so I think it's fine for people to start out at a pretty high level if that's what it takes for them to get hooked.

Basically, I think it's ok to start in the shallow end of the pool just as long as you eventually strike out for deeper waters.


Firstly, I woud difinitely start with a language of higher abstraction level. Currently I would recommend Python. The most important reason for choosing a scripting language as the first language is that you can easily put together something that works. As Joe mentions in his question, the number one thing while becoming a programmer is that you have the motivation to go on and dig deeper. This motivation is gained when you are able to create working and useful software.

Besides of the points with understanding abstraction (high level) and understanding underlying implementation (low level) there is a third point that is missed. In order to be a good programmer nowadays you must certainly master both of the two above points. Additionally, it is critical for your competence that you constantly look at new technologies and points of view. No matter from which abstraction level you start from, you must improve constantly, and question your current methods.

It should be made clear right from the start that programming languages are merely tools for getting the job done. It is very important to choose the correct tool for a particular task. I think that for a beginner programmer a high level scripting language will help in emphasizing this point. A higher level language will give a broader perspective and motivate the programmer to dig in deeper.
