Americans have a bad, though deserved, reputation for only speaking one language. Small surprise, then, that the same is often true for American programmers. Today's computer science graduate often leaves school with a strong knowledge of only one programming language -- typically a major systems language, such as Java or C++ -- and goes on to a career based almost exclusively on that language.
On the surface, this makes sense. C++ and Java are both highly versatile, complex tools. Just learning the syntax of either one is nothing compared to the amount of study it takes to become familiar with the whole ecosystem of associated libraries and frameworks. Not to mention that both languages are widely used; if you don't know either one, you cut your chances of getting a coding job dramatically.
[ The now-ubiquitous multicore chips pose new challenges to developers using traditional languages. ]
But a software development field that's based almost exclusively on two languages -- languages that are very similar, for that matter -- is also in danger of stagnating. The Sapir-Whorf hypothesis holds that the patterns of human thought are profoundly influenced by the patterns of the language in which the thought is expressed. Linguists disagree as to how strictly this is true of human languages, but for computer programming languages -- which are themselves but restricted subsets of human language -- it seems particularly apt. And yet, while the study of software development has marched forward with concepts such as functional and aspect-oriented programming, mainstream languages have remained tied to the same object-oriented paradigm introduced decades ago.
Outside the mainstream, however, the field is exploding. New programming languages are introduced every year, and many of them could make valuable contributions to real-world software projects -- if only they would get used. What will it take for enterprise software developers to start thinking outside the twin boxes of Java and C++?
A cornucopia of new languages
What's good for computer scientists isn't always good for working programmers. But surprisingly, perhaps, not all of the work in the area of programming languages has been strictly academic. Microsoft's .Net platform, with its CLI (Common Language Infrastructure), has been a particularly prolific source of new languages. Wikipedia currently lists no fewer than 55 languages that run on the platform, all of them fully interoperable.
This whitepaper explains the terminology and concepts behind Data Replication technologies and establishes some sizing rules through worked examples. Learn the new paradigm in disaster tolerance—protect data anywhere.
Download now »Download a free 30day trial and experience how XenDesktop delivers a pristine, ondemand desktop experience to users on whatever device they choose, while cutting IT complexity and costs.
Download now »
The emergence of WLANs has created a new breed of security threats to enterprise networks.
Included in HP ProCurve WLAN solutions is security technology that alleviates threats from WLANs through:
* Monitoring wireless activity inside and out of the enterprise
* Classifying WLAN transmissions into harmful and harmless
* Preventing transmissions that pose a security threat to the enterprise network
* Locating participating devices for physical remediation
It's about design, not languages
Knowing multiple languages is not a key to good programming. It is simple, old fashioned design that separates good programmers from bad programmers. Good design principles can be applied to any language, and a good designer will quickly figure out how to apply the necessary priniciples in the current language he is faced with. He may be banging his head against the wall over missing capabilities, but he will know enough to find an alternative approach
I've known good and bad programmers through out the years and either could be a language specialist or a "polyglot" programmer. Good designers succeed with either approach
Cheez, I really did not want to get sucked in here, but your mention of the Sapir-Whorf hypothesis in the opening, kinda set me off. Point; the hypothesis posits a deterministic relationship between language and thought, whereas BY DEFINITION there is a deterministic relationship between a computer and languages it can support, and similarly a deterministic relationship between that computer and the problem domains it can address. Which, again by definition, constrains the solution space for the DESIGNER (see WayneM above).
But the real issue is bigger than simply the concept of language, whether you slavishly cling to one or proudly master many. The issue is tools. Language can be a big part of that, but the issue goes way beyond syntactic detail. Many, if not most, of the popular languages to day are derivatives of C. C syntax proved to be such a strong base, that numerous language designers followed suite. Many of the above posts, touting their polyglot experience, list few if any languages, syntacticly rooted in anything other than C! Sorry guys that is not polyglot. On the other side of that coin, if you are serious about the code that actually runs, you have multiple options for x86 code-gen in an amazing array of compilers, COBOL, Fortran, several variations of the C family (not to mention their + and ++ libraries), x86 assembly, Lisp, Forth, and Ada.
The issue is tools, and programing environment, code management tools, project management tools, debug tools, make tools, cleanup tools, publish and install tools, ALL have this Sapir-Whorf like impact on the practitioners of the software arts. The more tools in your tool bag the closer you come to being a craftsman. Or as my graduate instructor in compiler theory loved to say,"When you are holding a hammer, it is amazing the number of problems that begin to look like a nail."

Sign up to receive InfoWorld Resource Alerts
