Principles of Programming Languagesit is an introduction to the principles of programming languages. It focuses on:

identifying the conceptual building blocks from which lanugages are assembled and
Specifying the semantics, including common type systems, of programming languages.

In the lecture materials, interpreters are written in concise functional notation using Scheme. In some cases, supplementary material showing how the same interpreters can be written in OCaml (using explicit typing) are provided. While Java is a very good vehicle for implementing these interpreters, it is not a good conceptual representation because it is much too wordy and the OO structure obscures the simple algebraic structure of abstract syntax and structural recursion used to define interpretation.

A secondary theme is software engineering. All of the programming assignments in this course are conducted in Java using test-driven development and pair-programming, two of the major tenets of Extreme Programming.

it consists of three parts:

The first part focuses on specifying the syntax and the semantics of programming languages. The former is introduced via simple parsing (translations) of program text into abstract syntax. More detailed aspects of parsing (such as lexical analysis and advanced parsing methods) are left to a course on compilers. The semantics of a comprehensive collection of programming language constructs is specified using interpreters and reduction (textual rewriting) systems. The constructs include arithmetical and conditional expressions, lexical binding of variables, blocks, first-class functions, assignment and mutuation, simple control constructs (loop exits, first-class continuations, simple threads), and dynamic dispatch.
The second part illustrates how interpreters and reduction semantics can be used to analyze important behavioral properties of programming languages. Two examples are covered: type safety and memory safety. Type safety guarantees that programs respect syntactically defined type abstraction boundaries and never raise certain classes of error signals. Memory safety guarantees that programs release memory if it is provably useless for the remainder of the evaluation. Type safety typically depends on memory safety.
The third part shows how interpreters can systematically be transformed so that they use fewer and fewer language facilities. The key transformations are the explicit representation of closures as records and the conversion of program control flow to continuation-passing style. Using these transformations, a recursive interpreter can readily be be re-written in a low-level language like C/C++ or even assembly language. These transformations can be applied both to interpreters and to arbitrary programs. if we apply these transformations to an interpreter, the result is a low-level interpreter that is easily implemented in machine code. The process of applying these transformations to arbitrary input programs yields a high-level description of program compilation, a process which is explored in more detail.

The students to analyze the semantics and pragmatics of the old, new, and future programming languages that they are likely to encounter in the workplace (e.g., Fortran, C, C++, Java, Visual Basic, C#, Perl). They will also be able to build efficient interpreters for new languages or for "special-purpose" languages embedded in software applications. Finally, they will be much be equipped as software developers because they will understand how to define and implement whatever linguistic extensions are appropriate for simplifying the construction a particular software system.

The development of programming languages has profoundly impacted our relationship with language, complexity and machines. By introducing the principles of programming languages, using the Java language as a support, Gilles Dowek provides the necessary fundamentals of this language as a first objective.

It is important to realise that knowledge of a single programming language is not really enough. To be a good programmer, you should be familiar with several languages and be able to learn new ones. In order to do this, you'll need to understand universal concepts, such as functions or cells, which exist in one form or another in all programming languages. The most effective way to understand these universal concepts is to compare two or more languages. In this book, the author has chosen Caml and C.

To understand the principles of programming languages, it is also important to learn how to precisely define the meaning of a program, and tools for doing so are discussed. Finally, there is coverage of basic algorithms for lists and trees

Essentials of Programming LanguagesBeyond the use of Scheme, we use four major strategies:

The first strategy is the use of {interpreters} to explain the run-time behavior of programs in a given language. Interpreters express language design decisions in a manner that is both formal (unambiguous and complete) and executable. Furthermore, our interpreters are generally expressed in a fashion consistent with the principles of denotational semantics; they express key ideas of denotational semantics in a concrete way.
Instead of relying on mere descriptions, using English, diagrams, or some abstract notation, we present each principle using Scheme programs that implement it. The use of Scheme enables the student to understand these programs without drowning in a sea of irrelevant detail. The exercises allow the student to experiment with alternatives in design and implementation.
We emphasize the systematic derivation of low-level implementations from their high-level abstractions. We show how simple algebraic manipulation can be used to derive program properties and correctness-preserving program transformations. In particular, we use these techniques to derive stack-management protocols and to transform an interpreter into a compiler.
Finally, we use data abstraction, expressed as a modular coding style, to separate algorithms from the representation of the underlying quantities. In this way, we can change data representation without changing programs. In the case of interpreters, we use this technique to investigate different implementation strategies.

Through the use of these strategies, we are able to give students several working models, ranging from very high-level (almost formal semantics) to very low-level (almost assembly language), and to demonstrate a clear connection between these models.

Such depth must come at the expense of breadth. We make no attempt to survey existing languages; though we occasionally point out the design choices used in common languages. Although our approach is largely motivated by the developments in programming language semantics over the last 20 years, we do not address a number of important research areas, such as type checking and inference, logic programming, parallelism, and verification. We believe, however, that a command of the essentials will allow the student to study these topics. For example, an understanding of the mechanics of logic programming certainly requires understanding of continuations, dynamic binding, and the distinction between a variable's name, its binding, and the value of its binding.

Choosing a Programming Language

A language that doesn't have everything is actually easier to program in than some that do.

Hard choicesOften a single one of these factors is decisive and leaves little room for choice. If you have to squeeze your interrupt-driven code in a microcontroller's 1024 bytes of memory assembly language or maybe C is the only game in town. If you're going to interface with a Java-based application server then you write in Java. Sometimes tradition plays an important role. Systems code, like operating systems, device drivers, and utility programs, is typically written in C. Following this tradition means that the code will mesh well with its surrounding environment and won't impose on it onerous requirements for libraries and runtime environments.

At other times the choice of the programming language is a fine balancing act. I find the power of C++ and its standard template library amazing: the combination provides me with extreme efficiency and expressiveness. At a price. The language is large and complex; after 15 years of programming in C++ I'm still often puzzled by the compiler's error messages and I routinely program with a couple of reference books on my side. Time I spend looking up an incantation is time not spent programming. Modern object-oriented languages like Java and C# are more orthogonal and hide fewer surprises for the programmer, although the inevitable accumulation of features makes this statement less true with each new version of each language. It looks like Lehman's laws of software evolution ("as a program is evolved its complexity increases") haunt us on every front. On the other hand, sometimes you just can't afford Java's space overhead. I recently wrote a program that manipulated half a billion objects. Its C++ implementation required 3GB of real memory to run; a Java implementation would easily need that amount of memory just for storing the objects' housekeeping data. I could not afford the additional memory space, and I'm sure even our more generously funded colleagues at CERN facing a one petabyte per second data stream in their large hadron collider experiment feel the same way.

The situations however I described are outliers. In many more cases I find myself choosing a programming language based on its surrounding ecosystem. If I'm targeting a Windows audience, the default availability of the .NET framework on all modern Windows systems makes the platform an attractive choice. Conversely, if the application will ever be required to run on any other system, then using the .NET framework will make porting it a nightmare. Third party libraries also play here an important role. Nowadays many applications are built by gluing together many other libraries. I recently calculated that each of the 20 thousand applications that have been ported to the FreeBSD system depends on average on 1.7 third party libraries that are not available on the system's default installation; one application depends on 38 different libraries. Thus for example if your application requires support for 3D rendering, Bluetooth communications, the creation of PDF documents, an interface to a particular RDBMS, and public key cryptography you may find that these facilities are only available for a particular language.

Soft choicesWhen efficiency, portability, and library availability don't force a language on me the next decisive factor is programmer productivity.

Interestingly here, I've found that the same language features can promote or reduce productivity depending on the work's scope. For small tool-type programs I write in the course of my work I prefer a language that sustains programmer abuse without complaint. When I want to put together a program or a one-line command in a hurry, I appreciate that Perl and the Unix shell scripting facilities don't require me to declare types and split my code into functions and modules. Other programmers use Python and Ruby in the same way.

However, when the program is going to grow large, will be maintained by a team, or be used in a context where errors matter a lot, I want a language that enforces programming discipline. One feature I particularly appreciate is strict static typing. Type errors that the compiler catches are bugs my users won't face. Language support for splitting programs into modules and hiding implementation details is also important. If the language (or the culture of developing in that language) enforces these development traits, so much the better. Thus, although I realize one can write well structured hundred thousand line programs in both Perl and in Java, I feel that the discipline required to get this right in Perl is an order of magnitude higher than that required for Java, where even rookie programmers routinely split their code into classes and packages.

A language's supporting environment is also important here. Nowadays, a programmer's productivity in a given language is often coupled with the use of an IDE. Some tasks, like developing a program's GUI layout, are painful without an appropriate IDE, and some colleagues have become attached to a particular IDE in the same way I'm clinically dependant on the vi editor. Thus choosing a language often involves selecting one of those a particular IDE supports.

Declarative choicesThere are also cases where a program's application domain will favor the expressive style of a specific language. The three approaches here involve using an existing domain-specific language, building a new one, or adopting a general-purpose declarative language.

If you want to get some figures from a database you might write SQL queries; if you want to convert an XML document into a report you should try out XSLT. Building a special-purpose language may sound daunting, but is actually not that difficult if one takes the appropriate shortcuts. Such an approach can be a tremendous productivity booster. Fifteen years ago I designed a simple line-oriented DSL to specify the parameters of CAD system's objects. Instead of designing an input window layout for each input group one simply specifies declaratively what the user should see and manipulate. Thus, the system's initial 150 parameters have effortlessly swelled over the years to 2400 surviving intact a port to a different GUI platform.

When I recently set out to design a way for specifying complex financial instruments my first attempt was to design a DSL. However, the more I worked on the problem the more I realized that many of the features I wanted, like the manipulation of lists and trees, were already available on declarative languages like Prolog, Lisp, ML, and Haskell. After expressing a small subset of the problem in a number of these languages I singled out Haskell, a language I had to learn when writing a compiler for it as an undergraduate student. It seemed to offer a concise way to express everything I wanted and a no-frills but remarkably effective development environment.

My biggest surprise came when I started testing the code I wrote. Most programs worked correctly the first time on. I can attribute this to three factors. Haskell's strong typing filtered out most errors when I compiled my code. Furthermore the language's powerful abstractions allowed me to concisely express what I wanted, limiting the scope for errors (research has shown that the errors in a program are roughly proportional to its size). Finally, Haskell as a pure functional language doesn't allow expressions to have side effects and thus forced me to split my program into many simple, easy to verify functions. Over the years many friends and books have prompted me to evaluate the use of a functional language for implementing domain-specific functionality; as I continue to add Haskell functions to my program I can see that the choice of the appropriate programming language can make or break a project.

Technical Characteristics

There are plenty of technical characteristics with which to compare programming languages: how many key words, maximum length of identifier, type-checking facilities, polymorphism, overriding, and so on. It is almost infinitely perplexing. Instead, I suggest that you focus on the following comparison criteria, which are centered on outcomes:

Ã‚Â· Ease of learning

Ã‚Â· Ease of understanding

Ã‚Â· Speed of development

Ã‚Â· Help with enforcement of correct code

Ã‚Â· Performance of compiled code

Ã‚Â· Supported platform environments

Ã‚Â· Portability

Ã‚Â· Fit-for-purpose

Ease of LearningClearly, the easier that the programming language is to learn, the quicker that programmers become productive. Java is a lot easier to learn than C++; C is probably even easier. But you learn once and program for a long time, so that ease of learning is of only limited value.

About the most difficult language to learn that I know is C++. One of the weird things about C++ is that the language is so complex and flexible that you develop your own style and work mostly within a subset of the language. This is strikingly illustrated by the two Microsoft object libraries: MFC (Microsoft Foundation Classes) and ATL (Active Template Library), which have a large overlap in functionality, but look completely different. Learning to be proficient in C++ is best seen as a three-step process: basic understanding, developing your own style, and learning to read someone elseÃ¢â‚¬â„¢s style. Classes and books teach you only step one; but it is only when you have passed step two that you are useful. You will be of more help to others when you have completed step three. It is probably the same for all languages; but the time that is taken in steps two and three is much shorter in languages that are not as profuse in features as C++.

Ease of UnderstandingMost code is written once and read many timesÃ¢â‚¬"usually, to focus on a particular point (for instance, to fix a bug). Thus, it is important that the reader quickly grasp the essence of whatÃ¢â‚¬â„¢s happening. COBOL can usually be read easily; but, because it is verbose, you have to read many lines of code to get anywhere. Old-fashioned COBOL (in contrast to OO COBOL) tended to use PERFORMs, instead of procedure calls, and that means that the logic and the data are miles apart. C does not have this problem; but C can still be hard to understand. This is partly the fault of the language. For instance, I always have to think twice to remember that:

In theory, object-oriented (OO) languages allow you to write more compact code (because of code reuse), and the structure of the objects can allow you to mirror more closely the structure of the problem; thus, in theory, they should be easier to understand. In practice, you might find many abstract classes; and you have to spend time trying to figure out what they are all for, before you can identify all of the parts of the program that are relevant to the topic that you are investigating.

Programmers can make any program hard to understand. Unfortunately, there is a breed of programmers who think that cryptic code is good codeÃ¢â‚¬"especially, C and C++ programmers. It used to be the case that cryptic code produced fast, compact applications; but compiler optimizers are so good these days that this is no longer an excuse.

Speed of DevelopmentIf you look at speed of development in the round, you must consider not only how long it takes you to write code, but also how long it takes you to find a solution to the problem at hand and find the bugs. Factors other than the programming languageÃ¢â‚¬"for instance, platform facilities, development tools, experience and skill of the programmers, and testing regimeÃ¢â‚¬"are so significant that it is hard to pin down any difference in development speed that is actually due to use of different programming languages. For instance, a quick calculation will show you that the physical act of typing code makes practically no difference to the speed of development. Verbose, therefore, does not mean unproductive.

There is a programming language called APL (initialism for A Programming Language) that takes compactness to the extreme by using a host of additional graphic symbols, and was best used if you had a specialized keyboard. It was described to me once as a Ã¢â‚¬Å“write-only programming languageÃ¢â‚¬Â; having been written, the code is immediately incomprehensible. Not surprisingly, the language has fallen out of fashion.

Object orientation has probably made good programmers better and bad programmers worse. Usually, with OO programming, there are more ways of tackling a problem than in conventional languagesÃ¢â‚¬"or, at least, there seems to be. This means more time up front thinking about the design. Once that is done, however, development speed should be fasterÃ¢â‚¬"mainly, because of the reuse opportunities.

The dream of reusable class libraries from which classes can be extracted and glued together by non-experts never materialized. Creating the classes was no problem. Finding and reusing the classes was the hard part, because you had to find a class that was both a solution to the problem and did not have unwanted side effects, such as using other classes, databases, or system facilities that you did not have or did not want. One of the messages from the agile community is: Only program for reuse, when a reuse opportunity arises. In other words, do not develop classes that you think will be suitable for reuse. Instead, refactor the code to create a reusable class only when you want to reuse it. I find this to be good advice.

One of the simplest forms of reuse is to copy code from one place and paste it in another. The benefits of OO reuse kick in when you want to modify the code; now, you modify it only in one place. In a poorly designed OO program, you find that it is hard to modify the code for one subclass without having to break the functionality of another subclass. In a well-designed OO program, each piece of shared code has a clear task, and making it better benefits all subclasses. Finding the right solution can be hard and is often an iterative process, which is why refactoring is so important.

Help with Enforcement of Correct CodeThe ideal programming language should turn logic errors into syntax errors. A powerful means to this end is type checking. Most standard languages, such as Java and COBOL, have good type checking. But some languages have an escape clause. An example is C++, in which you can change the type of a pointer. Figure 1 shows an example.

Changing the type of a pointer

This example creates a pointer to an object of type C, but points it 50 characters into array a. Clearly, this feature completely circumvents type checking, and it is considered dangerous. But I have had hardly any trouble by using this featureÃ¢â‚¬"possibly, because I know itÃ¢â‚¬â„¢s dangerous and, so, tread carefully.

Most languages have pitfalls of their own. These are caused by being able to write two expressions that look similar on paper, but have very different effects. For instance, in C and C++:

if (A = B) X ();

Means that A is assigned the value of B, and X is called if A is not equal to zero; while:

if (A == B) X ();

means to call X if A equals B.

Java is safer, because the first expression gives a syntax error.

Performance of Compiled CodeThese days, performance is as much an architectural issue as a programming issue. Thinking of performance problems about which I have heard over the last five years, there was one that used a workflow tool for all of its application logic. It used far too many I/Os. There was another that did not upgrade its network when it moved from old-fashioned terminals to a Web interface. And there was another that had a program that would cache hits to searches, but, every now and then, clear its cache and grind to a halt rebuilding it. I cannot remember a recent case in which bad performance came down to inefficient code production by the compiler. Even with a games program that is processor-bound, the chances are that a large percentage of the processing is going toward drawing the screen. That, in turn, means that performance comes down as much to how you use the graphics card as how the compiler generates code. Of course, huge, number-crunching programs will be an exception; but, even there, only a small part of a large program is performance-critical.
Supported Platform EnvironmentsBy platform environment, I mean not only the operating-system facilities, but also the middleware facilities, database facilities, and system-management facilities. Clearly, the more facilities that you have, the more work that has already been done for you. However, there is a downside. Understanding the platform facilities to the level that you can use them wisely is more difficult, in my opinion, and takes longer than understanding the programming language. Furthermore, I find that I use a facility, make it work, and move on. I do not revisit the subject for months or years. The effect of this is that I am much more dependent on documentation, examples, and research by using the Web than I am with normal programming. PortabilityMost popular languages have been standardized by a nonvendor organization. The aim is twofold: to reduce retraining needs and enhance portability. However, portability has been found to be very difficult. The standards bodies have succeeded in making differences of syntax a relatively minor problem, but that only covers the part of the language that is standardized. Most languages are dependent on hardware constraints in some form, such as defining the maximum value that an integer can take. If code is used such as seen in Figure 1, the dependency between code and platform can be tight and hard to unravel. Probably, however, the most serious problem with portability is the platform environment. For instance, the problems of moving a mainframe COBOL program to a .NET environment will almost certainly be in the area of changing fromÃ¢â‚¬"say, a CICS interface to a .NET interface. By far, the most successful example of a popular language that has good portability is Java, which was deliberately designed for portability. It has achieved this by standardizing not only the language, but also the platform environment (J2EE and J2SE).
Fit-for-PurposeWhile Java is a good language and is highly portable, it is unsuitable for some purposes, such as some game programming and system programming. Game programming often requires fast access to the screen-display hardware. This can be done by using DirectX, which is available only in C++ or C. The kind of code that Figure 1 illustrates might not be portable, but it is highly useful if you must take a buffer of information and unpick the data from it. You need this if you are writing your own database or network software. However, the majority of programmers are writing business applications in which neither of these issues applies, and Java (or C# or Microsoft Visual Basic) is just fine. Historically, there have been many good programming languages that got nowhere in the market, simply because they did not have good interfaces to the platform environment. This was probably true of Pascal, for instance, and it helps explain why that never became a popular commercial language.
Decisions, DecisionsSo, how do you decide which programming language to use? The first overriding factor is the last one in the preceding list: fit-for-purpose. For most business operational systems, you need a language that has good middleware and database facilities. For specialized workÃ¢â‚¬"for instance, writing a hardware driverÃ¢â‚¬"you might be forced to use C or C++. For some AI work, perhaps, a language such as Lisp or Prolog might be the only one that gives you access to the facilities that you need. The second factor is platform choice. If your application must integrate with other applications, you will often find it easier to implement if it is written in the same language as those other applications. For instance, calling a Java method by using Java RMI is easier from another Java program. Calling a .NET application method is easier from another .NET application. Also, if your program must create a batch file for an existing COBOL program, it will be easier and quicker to write the new application in COBOLÃ¢â‚¬"especially, if you can use existing COBOL copy libraries.
The third major factor is the existing skills base of your programmers. Training an existing Java programmer to write in C# would probably take a few days, because the languages are similar. What would take much longer would be training your programmers in the .NET environment. For the first few months of their new life as C# programmers, they will be looking things up in the reference manual, asking each other how such-and-such worked, and spending time pondering (and, we hope, properly investigating) the best way to perform a new task. As time progresses, much of this additional effort disappears, and both productivity and quality creep up.
The net result of the last two factors is that choosing a programming language becomes a strategic skills issue for the IT department. You want to concentrate your resources on a few languages. You want to grow skills in languages that you think will have long-term benefits for your organization. However, you do not want to do it so fast that you are left with all of the programmers struggling with a new language.
ConclusionThe three major factors that influence the choice of programming language are the following: Ã‚Â· The language must be fit-for-purpose. Normal business-application development can be done in Java or COBOL, but specialist applications might need C++ or some other language.
Ã‚Â· The choice of platform is critical. ItÃ¢â‚¬â„¢s better to let the platform dictate the programming language, instead of letting the programming language dictate the platform.
Ã‚Â· The skills of the programmers. Programmers are much more productive when they are working in a language that they know well, instead of working in a new language or on a new platform.

Selecting A Primary Programming LanguageA question that I frequently see in technical forums and other places that programmers congregate asks for guidance regarding which programming language that someone just starting out in software development should learn first, or specialize in. Although it is asked in earnest by novice programmers hoping to mine the collective experience of the veterans, such subjective questions on religious issues are not likely to garner useful or consistent answers. It's like asking a group of people about their opinions on abortion. The issue is so polarized that you are likely to get a fairly dogmatic answer that refl in technical forums and other places that programmers congregate asks for guidance regarding which programming language that someone just starting out in software development should learn first, or specialize in. Although it is asked in earnest by novice programmers hoping to mine the collective experience of the veterans, such subjective questions on religious issues are not likely to garner useful or consistent answers.
It's like asking a group of people about their opinions on abortion. The issue is so polarized that you are likely to get a fairly dogmatic answer that reflects the worldview of the person answering without much context, at least not any context that integrates more than one ideological view.
How NOT to select a programming languageFirst, let's get some of the WRONG reasons out of the way for choosing a language to specialize in. Almost every time this question comes up, the person asking either implies or explicitly specifies that the criteria they are most interested in are (A) earning potential; and (B) employment trends that indicate the marketability of the skill. Don't select a language based on earning potentialIt is true there exists disparity in the average salaries of programmers based on the language they use. Aside from the ~$20K disparity for VB.NET, that I think has more to do with the baggage of the Visual Basic name than the real comparative value of those programmers, most of the popular languages are averaging within $5K/year of each other according to the numbers I found on It is also important to consider that salaries tend to spike for technologies as they near obsolescence because it gets harder to find candidates with experience in those technologies and are willing to risk sitting in the COBOL chair when the music stops. I think the next major victim of this will be C++, but not for at least another decade or two.
A more important consideration is that these salary numbers are just averages and should only be used to get a general picture of the market for various skills. In my experience, the level of experience and competence in a particular language is more deterministic on salary than the choice of language itself.
The premium for a programmer in their first job out of college in C++ might be tempting, but I have observed that discrepancies based on specific languages tend to converge over the course of a career and are much less pronounced for veteran developers. As such, it is probably more useful to focus on mastering a language than picking the right one.
Don't select a language based on marketabilityLooking at the number of available jobs is perhaps the worst way to pick a programming language. This field changes too quickly for it to be wise to make long term decisions on short term trends. There are numerous examples of labor markets glutted with people who embarked on a career path because of a shortage was that drove up salaries when they started college. By the time those people graduate along with the 75% of their class who got the same diploma, the market once strapped for talent became excedingly competitive and consequently less desirable. How to select a programming languageThis is the easy part. Pick the one you like best! You are far more likely to invest the effort required to master a language that you pick by preference than one selected for purely monetary or competitive reasons. That said, the language you select shouldn't win by default, but rather should be selected from a pool of at least 3 languages for which you have had some exposure: Still in school? Try to select courses that give you exposure to several programming languages and at least two platforms (Windows, Apple, Unix, etc.) You can hedge your bet by learning C++ which is extremely similar several other languages and will reduce your learning curve, but don't use that as an excuse to learn just one language.
There's an oversimplification in the title. Your choice is not really about choosing a scripting language. You'll go much farther when you understand that you're after a scripting framework. The best way to understand this is through a real life example:
You start learning the scripting language of your choice. In a short time, you've written a five- or fifteen-line script that does something you've always wanted to do, although you never had the time, confidence, or knowledge to tackle it. "Five (or fifteen) lines," you think. "This isn't bad at all."
You show it to a few friends who ignore you because they have more important matters on their minds. Then a few days later, someone comes up to you, and asks, "Know that little gadget you built? That was slick; in fact, I could use something like that, if only I could:
Â· Interface to our FORTRAN-coded thermodynamics library
Â· Pull out current figures from the department database
Â· Look on a Web site I know for all the names
Â· Sort the results by time zone and state"
You nod and answer, "no problem." You're now going to extend the language; that is, bind it together with external functionality that's not part of the core language.
In fact, this is how many scripters spend their time. While modern scripting languages are remarkably expressive and capable, one characteristic that almost all share is that they're written to be extended. The big returns on your investment come when you wed the strength of the language itself to the legacy algorithms, components, and objects already in use in your organization.
It gets better. After a couple of months of demonstrating that your chosen scripting technology easily absorbs the quirky interfaces they've tried to fold into it, your colleagues worry less about where the pound signs and backslashes go; now, they just want to get jobs done, and the particular syntax of the language you choose doesn't seem like such a problem. A manager asks, "Can we do this under VMS/MacOS?" "Sure," you say, because you know that modern scripting languages have been coded with great care given to portability. "What will it take to put a copy of this stuff inside our existing product, so that users can write their own macros?" "Not a lot," you answer with confidence. "Can we Web-enable it, communicate through SNMP, administer it remotely, perform calculations with arbitrary-precision integers, and cryptographically secure the transactions?" "Well," you think, "other developers have already written packages to support precisely those operations, so it will only take a bit of reconnaissance to pull it all together."
Then one day, you're at the water cooler, and you hear yourself proclaim, "If I had to give up X (your chosen scripting language), golly, I think I'd just resign first." You've surprised yourself -- yet it sounds right to say it.
This is what has happened: When you think of your language, it's not just grammatical structure with peculiar rules for writing array elements. For you, the language opens up an entire framework which gives you extensibility, embeddability, and portability.
That's what happens with scripting languages. As languages they diverge dramatically in appearance, philosophy and style; but, as frameworks almost all have the features that make their use and reuse compelling.

Tips on choosing a programming language to learnI'm often asked: How do you pick which programming language to use in your development work? It's a fair question, particularly for people with little or no experience in the development field. The great temptation is for me to just say, "use XYZ language." Instead, I think it is better to explain how to think about choosing the language with which to work.
When you're thinking about which programming language to learn, you need to ask yourself the following five questions in order to come up with the right decision for your needs.
Why am I learning a programming language?If your goal is to learn to program, look for languages that teach basic principles such as Lisp (or Scheme) or possibly Ruby or Smalltalk. There are a number of excellent languages that are specifically designed to teach programming at a fundamental language. You'll want to bypass most of the mainstream development languages in favor of one of these educational languages, and look for one with an associated workbook, textbook, or other training materials that will effectively tutor you.If you're trying to become a better programmer, one of these educational languages will greatly benefit you as well. Alternatively, you can try one of the nonmainstream languages, especially if it uses a different paradigm than what you're using now.
If you're building a career, then you need to base your decision on market forces. Look at job ads that appeal to you (the type of work, the location, the pay, the experience level needed, etc.). Keep track of what languages (and other skills) those ads mention as the primary skill(s) and that is what you need to learn. If you think that you'll be miserable in that language or environment, then you might need to reevaluate your career goals.
If you just want to have fun or build personal apps, then learn whatever you want!
How do I plan to learn the programming language?Your plan of attack and style of learning will affect your programming language choices. For instance, if you learn best in a face-to-face classroom setting, you need to make sure that classes exist for what you want to learn. For many nonmainstream languages, even the book choices are poor.No matter what, you'll want to make sure that you feel comfortable in the online communities for that language. Consider these questions: How do they treat newcomers? Do a lot of questions go unanswered? Is there a good mechanism for turning questions into better documentation?
On that note, is the documentation any good? A poorly documented programming language will force you to count on the community, and an unhelpful community can sink you pretty quickly.
What toolset, libraries, and frameworks support the programming language?Some people really like working in a specialized IDE; others are perfectly happy in a basic text editor. Whatever your style is, make sure that the tools are available to support it. Even if you like a plain text editor, for example, you'll probably want to make sure that it supports formatting and coloring for your language. Along the same lines, you'll want to make sure that the language's libraries and frameworks support your intended applications. As an example, if you plan on working on scientific applications, you'll want to check out the math libraries to ensure that you won't spend a lot of time implementing the basics of your math routines.What do I plan on building?If you have a particular kind of application in mind, it will influence what kind of programming language you choose to learn. Some programming languages are better suited for some applications than others. For example, if you're working on a Web application, you'll want to make sure that your language of choice has the capability to be used in those applications and is designed for that scenario. On a server using the CGI model, virtually any language can be used for development, but you'll quickly discover that some languages are better than others.Part of this comes down to toolsets, frameworks, and libraries (having to handle HTTP connections by hand is a chore regardless of the language you're using), but the programming language plays a large role in things as well; many development languages have succeeded because of one small feature or a few features that made a particular type of development much easier.
Look at applications that are similar to what you're building, and try to find out what language those developers are using and why they chose those languages. This will give you insight into what programming languages you should learn.
Am I willing to take the road less travelled?There is the possibility of using a less mainstream programming language. For personal development, this is not a problem, but many development environments view nonmainstream languages as a risk; specializing in one of these languages can restrict your job choices, or your boss may not be willing to allow you to work on a project in that language.All the same, there is a great deal of value in learning programming languages that aren't as popular. For one thing, you may find yourself on the path to becoming a highly paid specialist consultant. In addition, every language you learn will teach you new things about programming, even if you don't use the language in your day-to-day work. ConclusionLearning a new programming language can be a very rewarding experience, but it is important to not waste your time, either. Picking the right programming language for your needs is not always easy, and chances are, any language you learn will have some things that you dislike about it. But with these tips, you should make better decisions about which programming lang

Resources

Top Categories

Product

Company