19

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?

Jim G.
  • 8,006
  • 3
  • 35
  • 66
joe_coolish
  • 446
  • 3
  • 9
  • 8
    I don't mean to be an arse but http://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 http://xkcd.com/326/ though... –  Apr 20 '11 at 22:31
  • 2
    Made me think of this http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html – P.Brian.Mackey Apr 21 '11 at 01:15
  • @David: I've always liked the altitude training approach - if you learn to do the hard stuff first, everything is easy by comparison. – user21007 Apr 21 '11 at 02:22
  • 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 02:32
  • @user21007: I've always had trouble with learning too many things at once. This doesn't necessarily learning the easy stuff first, but that's how I usually learn languages. First the easy stuff, and then get into the concepts. – David Thornley Apr 21 '11 at 02:38
  • See [this SO question](http://stackoverflow.com/questions/644099/what-programming-languages-do-the-top-tier-universities-teach). – Eelvex Apr 21 '11 at 03:54
  • 1
    @P.Brian.Mackey: But you didn't try to learn the manual in terms of the automatic. The biggest problem I see is that people try to use the high level programming language concepts to understand the low level ones. But that's not possible, because the higher level ones are at a higher level of abstraction, and can't do everything the lower level constructs can. For example, I see people trying to learn pointers in terms of Java/C#-style references, or C++ templates in terms of Java/C# generics, and it doesn't work, because pointers and templates are more powerful than references and generics. – Billy ONeal Apr 21 '11 at 18:30

14 Answers14

26

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.

Andrea
  • 5,355
  • 4
  • 31
  • 36
  • 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
22

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.

Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
11

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.

Singletoned
  • 259
  • 1
  • 5
  • 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 01: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 02: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 06: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.](http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html) 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
  • 1
    @Mason If you're not the CS Master or PHD, and you're trying to make business-useful apps, and your background is in finance or statistics, and you never got to the pointers class, then are you suupposed to say "Screw it" and go bake bread? No, because the CS guys seldom know anything about anything outside CS that's very useful for the business world. So the CS types end up making tools like MS Excel that the finance wiz can use. I say c# falls in there, as it's meant to shield the .NET code from the machine/network, etc. It's about managing expectations, really. – Christopher Mahan Apr 21 '11 at 16:24
  • @ChristopherMahan And when that business programmer's finance or statistics application [starts returning the wrong results](http://floating-point-gui.de/), because he didn't know about the low-level details? Oops! – Izkata Mar 16 '14 at 19:27
  • @Izkata then that's the problem of leaky abstraction, and it's the fault of the abstraction. – Christopher Mahan Mar 17 '14 at 18:44
  • @ChristopherMahan Problem is, it's not feasible to fix all of them. Python 2.x has that problem, for example. Teaching the programmers about the problem is. – Izkata Mar 17 '14 at 18:50
  • @Izkata there are abstraction layers all the way down to the metals, silicone, plastics. One would need several Ph. D. in physics, mechanical and electrical engineering if programmers had to be able to fix all abstraction leaks. (flaky RAM? Replace and move on.) – Christopher Mahan Mar 17 '14 at 23:43
5

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).

back2dos
  • 29,980
  • 3
  • 73
  • 114
3

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

Darknight
  • 12,209
  • 1
  • 38
  • 58
Christopher Mahan
  • 3,404
  • 19
  • 22
  • 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. –  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 06:38
3

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.

Ingo
  • 3,903
  • 18
  • 23
  • 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 00:04
  • Neither python nor ruby are unityped and I don't think that term has any meaning. All languages have types, even assembly has types so none of what you've said makes any sense. –  Apr 21 '11 at 00:34
  • 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 08:55
  • @davidk01: Some languages really don't have types. They have data that you apply various operations to (see Forth for an example). Nothing will stop you from multiplying a pointer by a four-character string. – David Thornley Apr 21 '11 at 15:12
  • 1
    @Ingo: So? There's nothing wrong with dynamic typing. Many very useful programs have been written in dynamically typed languages. You're just convincing me more that static typing is dangerous, in that it becomes an obsession. – David Thornley Apr 21 '11 at 15:14
  • @David - you don't have to teach an ole perl hacker about the pros and cons. Nevertheless, your argument is invalid. Compare: Many miles have been driven extremely speedingly without airbags and safety belts and half drunk, hence there's nothing wrong with driving unsafe. (I am exaggerating to make the fallacy clear.) – Ingo Apr 21 '11 at 16:55
  • @Ingo: Thing is, if I wanted to look that up, I'd find good evidence that safety belts and sober drivers save lives (I hope I'd find evidence in favor of air bags also, because they're expensive and mandatory). Can you provide similar evidence about static vs. dynamic? Anecdotally, I've heard people on either side say favorable things about their particular favorite kind of typing, and I know some very good software has been written both in statically typed and dynamically typed languages. – David Thornley Apr 21 '11 at 17:01
  • @David, I have only anectodical evidence, of course, through my own experiences. Admittedly, it is **not** true that well typed programs can't go wrong - nevertheless, they go wrong in a different, so to speak higher level, manner by eliminating whole classes of stupid errors. Again, what software was written in this or that language is irrelevant. Perhaps the software that manages your bank account has been written in COBOL (or even, good lord, have mercy!, ABAP) and it is doing well for decades - but that is in no way an argument pro COBOL or ABAP. – Ingo Apr 21 '11 at 17:11
  • 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
  • @David, sure, but that is not a question for empirical studys. It is clear from the outset that dynamic typing can only be safe in the sense that it tells you at runtime what's wrong. The bigger the software systems one builds, the greater the complexity, and thus I prefer languages where I can change something in source file Foo, recompile and the type checker tells me all lines in all files where this change has an impact. – Ingo Apr 22 '11 at 09:12
  • 1
    @Ingo: It can only be a question for empirical studies. People who use dynamic languages for big and complicated systems report that they don't have difficulties because of dynamic typing. Your argument is plausible, but it makes assumptions that are not necessarily true. – David Thornley Apr 22 '11 at 13:59
  • @David - but then you should also ask users and convertites, like me. The convertites will probably tell you (like I do), that the compiler reminds them every day of errors that would probably have gone unnoticed earlier. Regarding the users: isn't it a shame that in software sold by Oracle or SAP, everyday critical bugs are found? To be sure, they make big money with maintenance contracts .... – Ingo Apr 22 '11 at 14:09
  • 1
    Perl, PHP and JavaScript lacks strong typing so they really don't force to pay attention to types. But Python and Ruby have strong typing, they don't allow e.g. string to be silently converted to int. I'm a convertie from C/C++ to dynamic world and for me JavaScript and PHP type system causes problems but not the Python's. And finally, C typing is worse than Python's in my experience because C have static typing without strong typing (void * anyone?) and this causes much more bugs than Python's dynamic typing. – Mike Korobov May 08 '11 at 11:52
  • 1
    I don't have problems with types in JavaScript, BECAUSE I think more carefully about the flow of data than you might in a strictly typed paradigm. – Erik Reppen Dec 06 '12 at 07:46
2

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
2

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.

Carra
  • 4,261
  • 24
  • 28
1

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.

Farley Knight
  • 121
  • 4
  • 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. –  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 04: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. –  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 09 '11 at 02: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. –  May 09 '11 at 06:31
1

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.

Billy ONeal
  • 8,073
  • 6
  • 43
  • 57
0

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.

JohnL4
  • 634
  • 4
  • 12
  • 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. –  Apr 21 '11 at 00: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 01:22
0

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.

Gaurav Sehgal
  • 47
  • 3
0

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.

William Pietri
  • 3,060
  • 1
  • 17
  • 20
0

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.