Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

July 22 2011

Top stories: July 18-22, 2011

Here's a look at the top stories published across O'Reilly sites this week.


Google+ is the social backbone
Google+ is the rapidly growing seed of a web-wide social backbone, and the catalyst for the ultimate uniting of the social graph.
Intellectual property gone mad
Patent trolling could undermine app ecosystems, but who can mount a legitimate challenge? Here's four potential solutions.
Software engineering is a team sport: How programmers can deal with colleagues and non-programmers
Ben Collins-Sussman, tech lead and manager at Google, and Brian Fitzpatrick, engineering manager at Google, explain the "art of mass organizational manipulation."
FOSS isn't always the answer
James Turner says the notion that proprietary software is somehow dirty or a corruption of principles ignores the realities of competition, economics, and context.


Emerging languages show off programming's experimental side
Alex Payne, organizer of OSCON's Emerging Languages track, discusses language experimentation and whether these efforts are evolutionary or revolutionary.

Rugby photo: Scrum by MontyPython, on Flickr; Open sign photo: open by tinou bao, on Flickr




OSCON Java 2011, being held July 25-27 in Portland, Ore., is focused on open source technologies that make up the Java ecosystem. Save 20% on registration with the code OS11RAD



July 18 2011

Emerging languages show off programming's experimental side

The emerging languages space is programming's work bench. It's where novel theories are tested and new ideas are tweaked — and the underlying motivations are often less important than the work being done.

Characterized this way, it's easy to understand why last year's OSCON emerging languages camp proved to be popular. It offered an unusual opportunity to focus on the essence of the field rather than strict practical applications. This year, to meet the demand and amplify the work being done, emerging languages has been promoted to a full-fledged conference track at OSCON 2011.

I got in touch with the track's organizer, Alex Payne (@al3x), to discuss the particulars of this year's schedule as well as the broader state of emerging languages. Our interview follows.


Which languages in this year's emerging languages track intrigue you most?

Alex PayneAlex Payne: One of the things that's neat this year is that there's a couple of very experimental languages in the track. One of the most interesting to me is Wheeler, which describes itself as a language with no objects, functions or variables. It's difficult to describe how that works in practice.

Ola Bini, author of the Ioke language, has a new language called Seph, which is sort of an experiment in using Java 7 as a platform for building new languages. It builds on some of the ideas in Ioke and it borrows from Clojure a bit. Seph could be really interesting.

The FAUST language was a late entry. It's a programming language for real-time signal processing and synthesis. I like that it's so domain specific. That's nice to see because a lot of the languages we got last year were general purpose, but this one is very focused.

OSCON Emerging Languages Track — Learn and exchange ideas with the inventors of tomorrow’s computing future in OSCON's Emerging Languages track.

Save 20% on registration with the code OS11RAD

Do the languages you're seeing plug in to broader trends, like the popularity of Node.js?

Alex Payne: I'm not the biggest Node fan, and I kind of think it's the other way around. Node applies research and techniques that have been around for a long time. It's bringing those ideas to a broader group of programmers who know JavaScript as a common language.

The thing that Node, and Ruby before it, have done well is remind language developers that usability and community really matter. Node, in a very short period of time, has developed an enthusiastic community. They've developed good tools and tutorials around it. It's friendly, it's readable, and there's lots of examples. Developers working on the cutting edge can forget to do that stuff, and then they wonder a year or two down the line why no one is interested in their project.

A comment attached to our 2010 interview questioned the need for emerging languages — "evolution is better than revolution" was the exact phrase. What's your take on that?

Alex Payne: Most of these languages are evolutionary and not revolutionary. Clojure is a synthesis of stuff going on in concurrent programming, and it borrows heavily from Lisp. Go is certainly an evolutionary language, building on the enduring qualities of C and attempting to correct what some might see as the missteps of C++, Objective-C, and Java.

I don't think that a lot of these languages come along and say everything we're doing in the realm of programming is broken and we have to rethink it. The only person who came to last year's camp with that kind of agenda was Jonathan Edwards, who presented on his Coherence language. But he had a lot of push-back at the end of his presentation, and this was in a room full of people who were interested in emerging languages.

Your perspective on this depends on how close you are to these emerging language conversations. If you're the sort of programmer who only picks up a new language once or twice a decade, then yes, seeing people talk about the need for new languages is probably revolutionary and probably threatening. If you're involved in discussions about programming languages day-to-day on mailing lists or on sites like Lambda the Ultimate, Hacker News, or Reddit, then you can watch these new languages slowly take shape. With that social context and perspective, new languages look much more evolutionary.

Are there categories or problems this year's crop of languages are trying to address? I'm thinking of things like mobile or big data.

Alex Payne: Most of the languages are not going after the problems the industry as a whole is thinking about right now. The submissions that we got for this year's track are focused on experimenting with the fundamentals of the languages themselves. For example, we have a language called Plaid that's an experiment in a concept called typestate. We also have a talk that's about object-functional languages like Scala and how you resolve some of the problems in them. The group of people submitting talks for this track seem to be more interested in ironing out issues in the language world rather than addressing industrial problems.

Are you surprised at the popularity of any current languages?

Alex Payne: I'm constantly surprised at the popularity and success of Objective-C. Almost everyone I know tells the same story about Objective-C: they started learning it and they hated it. They thought it was the worst of C and the worst of dynamic languages. And then eventually, they learned to love it.

Most of the time, that software works pretty darn well, so who am I to judge? I'm pleasantly surprised by the continued success of Objective-C, and I think it should be taken as a lesson for the language designers out there.

This interview was edited and condensed.


Related:

June 07 2011

Why a JavaScript hater thinks everyone needs to learn JavaScript in the next year

I've long looked at JavaScript as a second-class citizen in the programming world. Early on, it was the source of numerous security problems; it was a nice bit of glue to patch together HTML applications with a bit of styling, but nobody would use it for serious code; and so forth. Java, Ruby, Python, they were the languages for doing real work.

But my attitude toward JavaScript has changed completely in the past few years. JavaScript has "grown up." I'm sure there are many JavaScript developers who would take issue with that judgement, and argue that JavaScript has been a capable, mature, and under-appreciated language all along. They may be right, though you can write any program in any complete programming language, including awful things like BASIC. What makes a language useful is some combination of the language's expressiveness and the libraries and tools available. JavaScript clearly passed the expressiveness barrier a long time ago, even if the ceremony required for creating objects is distasteful. But recently, we've seen some extremely important game-changers: jQuery, JSON, Node.js, and HTML5. JavaScript may have been a perfectly adequate language in the past, but these changes (and a few others that I'll point out) have made JavaScript a language that is essential for every developer to know. If there's one language you need to learn in the next year, it's JavaScript.

The potential of Node.js

Node.js logoNode.js has the potential to revolutionize web development. It is a framework for building high performance web applications: applications that can respond very quickly and efficiently to a high volume of incoming requests. Although Node is a low-level framework that can build any kind of application, it's particularly useful for building web servers. Its asynchronous event-driven paradigm is arguably more effective for web applications than the more familiar request-response paradigm.

Two things make Node particularly valuable, though. First, Google has started a revolution in JavaScript performance. This isn't to say that at any given moment they have the best JavaScript engine available (though that's a fairly good bet). But what's certain is that Google took JavaScript performance seriously when other players didn't, and in doing so drove Mozilla, Apple, Microsoft, Opera, and other vendors into a performance race. The result is that the JavaScript engines we have now are much, much faster than they were a few years ago, and are capable of running a serious web application.

Second, Node has benefitted from an enormous pool of JavaScript developers. Whatever language they use for the back end "server," few developers don't use JavaScript in the client. It may only be for bits and pieces of glue; it may be for sophisticated Ajaxian effects; it may even be to write full-fledged applications, such as Twitter or Gmail. But whatever the case, the number of JavaScript developers is huge. And authors like Doug Crockford have been pushing the idea that JavaScript, despite many warts, can and should be treated like a serious programming language.

At this point, writing Node applications is relatively crude: it's a low-level library, about as close to the metal as you can get with JavaScript. It is not a full-fledged web framework, like Rails or Django. But that is certain to change. Lightweight frameworks like Express are starting to appear, and I have no doubt that we'll see more full-featured frameworks built on top of Node.

I've mentioned the appearance of sophisticated web applications that
run almost entirely in the browser. Those are hardly new — how old is
Gmail
? How old is Google Maps? But writing the client side of an
application in JavaScript and running it on the browser is
increasingly attractive. HTML5 takes this trend a step further.

Save 50% - JavaScript Ebooks and Videos

JavaScript is everywhere: servers, rich web client libraries, HTML5, databases, even JavaScript-based languages. If you've avoided JavaScript, this is the year to learn it. And if you don't, you risk being left behind. Whatever your level, we have you covered:

Introductory  /  Intermediate  /  Advanced

One week only—offer expires 14 June. Use discount code HALFD in the shopping cart. Buy now and SAVE.

HTML5 is about JavaScript

I've said many times that HTML5 isn't really about HTML; it's about JavaScript. What changes in HTML itself? There are a few new tags, which in and of themselves aren't that difficult to understand. The power of HTML5 lies in what these tags allow you to create in JavaScript. A drawing canvas isn't very useful without the code that lies behind it and creates an animation, a game, or a visualization tool. As soon as browsers supporting Canvas appeared, we saw hundreds of implementations of Asteroids as developers started playing with the new features. Some were crude, some were surprisingly rich. That work is entirely in JavaScript.

HTML5HTML5, then, isn't really a major advance in angle-bracket-based tagging; it's about enabling JavaScript to do more powerful things. The WebGL library (which is still bleeding edge) allows real-time 3D graphics inside an HTML5 canvas. HTML5 geolocation allows you to write location-aware applications in the browser (a basic capability for mobile phones). Persistent storage and offline functionality have enabled developers to write full-fledged applications, with the same functionality you'd expect on a desktop, that run in the browser. There have also been experimental libraries for adding multitouch capabilities. These are all really features of JavaScript. HTML5 just provides a structure for giving them meaning.

Furthermore, there have been significant advances in browser libraries that don't require HTML5. JavaScript has long been the workhorse for implementing dynamic features in HTML. But there have always been two problems: browser incompatibilities, and the awkwardness of working directly with the DOM. The JQuery library has elegantly solved both problems, and is the basis for modern client-side browser development. But it's not just JQuery. The Protovis and D3 libraries allow you to create complex interactive visualizations that run directly in the browser — for the first time, making the browser an important tool for data exploration.

JavaScript and databases, compilers and languages

The use of JavaScript has also exploded in databases. Three of the leading databases in the NoSQL movement, CouchDB, MongoDB, and Riak, are "document databases." Rather than storing tables, they store documents. And for all three databases, a "document" means a JSON document, not a Word or Excel file. (Riak also supports XML documents and plain text.) While JSON has been widely adopted as a data exchange format (there are libraries for parsing JSON in almost all modern programming languages), it's important to realize that JSON is really just a format for serializing JavaScript objects. So while you can use JSON with any language, it's a natural fit for JavaScript development; and the fact that JSON has become a cross-language standard, rather than some Python, Ruby, or Java serialization format, says a lot about JavaScript's readiness to take a role on a larger stage. But even more than that, all three of these databases have facilities for executing JavaScript as part of queries. In the coming years, I would not be the least surprised to see JavaScript and JSON embedded within other kinds of applications.

We've only seen the beginning of JavaScript development. At this year's JSConf, javascript-to-javascript compilers were a big theme, and seen as a major trend for the future. Google has been the hotbed of compiled JavaScript. GWT is the first framework I'm aware of that used compiled JavaScript (compiled from Java). I have never taken GWT that seriously; a framework that exists just to save Java developers from having to use JavaScript just doesn't seem worthwhile. However, GWT does some amazing JavaScript optimization in the process. Closure is a JavaScript-to-JavaScript compiler that does the same kinds of optimization. Traceur, which first appeared a few weeks ago, was designed to allow experimentation with the language itself: it compiles JavaScript with experimental language features into JavaScript that can run on any modern platform.

Finally, we're starting to see some languages compile to JavaScript, much as we're seeing JVM languages in the Java space. Some of the more interesting languages, such as Coffeescript and Kaffeine, are similar to JavaScript in style, but focus on smoothing out JavaScript's rough edges. Do you find the JavaScript object model interesting, but awkward, and are you put off by the ritual you need to go through to create a working object from a prototype? You may find Coffeescript a significant improvement. In addition to smoothing out the object model, Coffeescript adds features like list comprehensions, and does away with most of the curly braces. As in Python, indentation serves to delimit blocks.

Web servers, rich web client libraries, HTML5, databases, even JavaScript-based languages: I see JavaScript everywhere. If you have avoided JavaScript, this is the year to learn it. There's no excuse — and if you don't, you risk being left behind.



Related:


August 06 2010

Poetry of code

In my last article, I wrote about safety in the emerging computer languages presented at OSCON — how some languages focus on reducing failures by tightening up a language, restricting or regulating how code interfaces with other code, with data, and with system and network resources.

On the other side of the spectrum, we have languages that still function as useful tools, but encourage programmer productivity and expression. Like beauty, expressiveness is in the eye of the beholder. Generally, the languages that call themselves ‘expressive’ place a value on simplicity and consistency, allowing programmers to translate high-level concepts into code without being distracted by syntax or convention. They let a programmer do bigger things with less effort. And they often encourage an openness, a sense of play, a pleasure of work, a poetry of code.

The formal influence of Lisp and Ruby (and Smalltalk and Python to a smaller degree) was clearly seen at the Emerging Languages Camp. Many of the languages do away with the excessive punctuation of languages like C++, Java, and Perl, opting instead for minimal syntax and keywords, valuing whitespace, and using punctuation only when needed. CoffeeScript was one of the more impressive examples, wrapping the often-verbose JavaScript in a simplified, terse yet understandable syntax.

In the expressive languages, the concept of a rigid syntax seems to be far less important than in conventional languages. Perhaps that’s the influx of metaprogramming in languages like Ruby that encourage domain-specific mini-languages, or a general rebellion against committee-driven over-specification. In several of the emerging languages, there was a willingness by the designer to let the language evolve. CoffeeScript, again, was an example of incrementally improving an otherwise static language. Unlike most languages that have a public external representation and a private internal parse tree, Ioke welcomes the utility of different representations. It supports a ‘sugared’, Ruby-like syntax, a canonical/‘desugared’ representation, as well as an internal syntax. All can be used by a programmer, depending on need — for example, the implementation of a DSL might return a tree of internal syntax.

Most designers of expressive languages seem to want people to not only understand how to use their language, but understand how the language itself works. Sometimes this is done by unifying and simplifying the architecture. Io and Ioke avoid built-in keywords in favor of implementing everything as objects communicating via messages. Other languages emphasize the openness of the implementation itself: the websites for both Finch and Fancy explicitly state that the underlying code is intended to be understood. (Although not presented at the conference, Rubinius, too, shares this goal by reimplementing most of Ruby’s core in Ruby itself.)

Instead of the strict tradition of object-oriented languages with their careful hierarchy of abstract classes, many expressive languages discussed at the camp adopted the model of prototypes, first developed in Self. Prototypes tend to lead to a flatter, almost peer-to-peer world of objects. CoffeeScript adds prototypes to JavaScript, while Finch, Io, Ioke, and Trylon are more general-purpose prototype-based languages.

Pushing the boundaries with visual languages

After so many decades of purely textual languages, you might think that new language attempts might seek to pull themselves up from the soup of words, and attempt to express themselves as pictures. But while IDEs and other development interfaces have made some progress, most languages are still inherently textual. Only two languages presented were primarily in the visual vein.

While the language base for Thyrd is a textual, stack-oriented, postfix notation like Forth, an integrated graphical runtime provides visualization of execution, as well as far more intuitive debugging. Thyrd emphasizes programming via direct manipulation. Its data lives in ‘Thyrdspace,’ a spreadsheet-like hierarchy of grids and cells. Higher-level structures like arrays and dictionaries are implemented in terms of various kinds of grids, and cells can be bound together to express relationships and formulas.

Kodu, a game-programming environment for the Xbox 360, does away entirely with a textual language, expressing conditionals, loops, and other actions as sequences of icons that can be created and moved around to create precedence and sequence. Kodu attempts to integrate ‘play mode’ with ‘programming mode.’ It’s an impressive project.

Circa, while not a particularly inventive language, was interesting in its support for dynamically reloading of code as it was changed by the programmer. Through a combination of code analysis and built-in mechanisms for saving and restoring state, it attempts to be a fluid environment for designing games.

Wheeler was certainly the strangest language presented at the conference. More easily demonstrated than explained, it is quite unlike most programming languages. In Wheeler, objects become related to each other basically through proximity — if they are mentioned together, they become automatically related into ‘categories.’ No hierarchy exists, nor is order important: interactions are (in theory) simultaneous. When categories interact, they cause transitions. That could be something like addition, or it could be sending a value to the console. Wheeler may not be the future of languages, but if you’re interested in the edge of computer languages, you might want to try to wrap your head around it.

Where to next?

I hope this series of articles has given you an entertaining and educational glimpse of the possible future of computer languages. Although it’s unlikely any of the languages featured at the camp will soon supplant mainstream programming languages, their concepts may indeed gradually be integrated. Perhaps one of these fledgling languages may be perfect for your next project. Whether your goal is security and reliability, expressiveness and poetry, or somewhere in between, there are many paths to choose.

Related:

August 04 2010

New languages get pragmatic

In my last post, I posited that emerging languages fell generally into two categories: the languages that solve problems of reliability, safety, and correctness, and the languages that enable beauty and expressiveness. I'll cover the practical side of things in this post. Beauty and expression will be addressed later this week.

As any programmer knows, all software has bugs. With design flaws, interface misunderstandings, inefficiencies, or typos, we put our software out in the world knowing that it will someday fail. Improving our engineering methodologies helps (for example, unit testing). However, often the core problem is not in how we architect or implement a system, but rather the quality of our tools. A language -- its syntax/grammar, compiler, and associated runtime -- that minimizes or avoids errors is seen as a significant benefit, and so research into safety and reliability is a major effort in emerging languages.

In emphasizing the "safety" of a language, common qualities are described: secure, strict, predictable, guaranteed, reliable, correct, performant. There is a sensibility of pragmatism and tradition, a working style midway between a mechanic and an academic. Jonathan Shapiro, in his Emerging Languages Camp talk on BitC, described the "human comprehension zone," beyond which languages and code become difficult to understand, and therefore more likely to contain errors.

Through occasional unification of earlier systems, gathered complexity is sloughed off, leading (in theory) to a simpler and therefore safer system. The Io, Ioke, and Trylon languages replace the usual built-in keywords, statements, and expressions with a very simple message-passing mechanism. Everything else is built above that. Interestingly, simplicity also comes up as a major value in expressive languages.

One area under great consideration in language circles is the general interaction of code and data. While encapsulation and similar concepts have helped structure the interaction of objects in a process, errors can still easily occur. The last wave of dynamic languages popularized open class systems, metaprogramming, and reflection. Ironically, these are now seen as potential problems by those concerned with safety and security.

The concepts of "type safety" (in Ioke among others) and "object capabilities" guarantee that one object cannot sabotage another. In order to limit an object to reach only what it's given access to, several languages have renounced global variables. Some even restrict access to a class hierarchy, preferring prototypes or factory methods on allowed objects.

Newspeak lacks both traditional references or pointers, instead using names to resolve related objects only when needed. Through "mirrors," Newspeak allows an object to specify what other objects can see from the outside. At the camp, Jonathan Edwards presented a fascinating glimpse at a possible future with his ideas on "declarative objects": objects not all piled together in a heap of memory, but carefully contained and accessible only within other related objects, or through model-view data flows. Ur/Web is a domain-specific language for web programming that isolates interacting modules, avoiding many common errors. Even within web scripting environments there is progress. The Caja language implements the object capability security architecture as a layer over JavaScript.

Another area of development is a reconsideration of concurrency. Rob Pike lauded Communicating Sequential Processes (CSP), a model of concurrency invented in 1978. CSP is somewhat like Unix pipes, but formalized into a language that avoids memory sharing, threads, and mutexes. Go implements the principles of CSP as co-routines that communicate by sending objects over channels. Stratified JavaScript implements a similar model by extending JavaScript, avoiding synchronization problems in web programming.

Functional languages have long been considered relatively "safe," and that field's concepts have been borrowed by several emerging languages. In Seph, everything is immutable. In D, an imperative OO-based language for systems programming, data can be declared as immutable, while functions declared as "pure" can only access immutable data, and have no side effects. One of the more interesting presentations was the persistent data structures of Clojure, in which values are not traditional variables but rather states over time of a versioned tree structure.

Safety means predictability and reliability. As one of the more extreme examples, the BitC language is for writing critical code in resource-constrained systems that are designed to work for decades: a pacemaker, for example. Traditional embedded languages like C are unsuitable for their lack of safety features, as are modern mechanisms like JIT (just-in-time) compiling that introduce unpredictability. In a different domain, AmbientTalk is designed for implementing applications on mobile ad hoc networks. Because mobile devices often lose connectivity, the language assumes failures are common, and avoids blocking or exceptions.

Even basic data structures are reconsidered. Both Ioke and Frink criticized the common floating-point types misused by many programmers, instead preferring either arbitrary-precision floating point provided by "big decimals," or rational numbers. Frink's designer, Alan Eliasen, additionally gave an overview of intervals, a number representing a range of values, and the arithmetic that can be done with them.

Finally, some presenters positioned their languages as a possible base for higher-level expressive languages. By building expressiveness on top of safety, the best of both worlds might be attained. Although Go is a language in its own standing, its designer expressed interest in having the language used as a safe and powerful runtime. The Parrot VM (now being redesigned as Lorito) is specifically targeted toward dynamic languages like Perl, Python, and Ruby.

In the next post, I'll cover the expressive side of the language spectrum.

Related:

August 02 2010

Parsing signals from the Emerging Languages Camp

The two-day "Emerging Languages Camp," held in a side room away from the main conference rooms of OSCON, was a surprisingly diplomatic and cooperative meeting of the minds. In all, more than 25 languages -- plus ancillary topics -- were presented by their respective designers. Although I was mentally saturated by the end of the camp (I seemed to have lost the ability to speak clearly or spell!), I was pleased to see so much progress in the field of computer languages, and I was motivated to experiment with some of the implementations that grabbed me.

Over the course of this week, I'll be examining the camp's larger themes and trends.

Steps to language evolution

The differences between computer languages are often seen from the view of syntax and form. Yet syntax is only the skin of a language. Today's programmers build their software on an evolutionary ladder of concepts whose steps were radical only a decade or two ago: garbage collection instead of manual memory management, object-oriented (OO) programming instead of procedural programming, and virtual machines instead of CPU-specific executable code.

The last wave of new languages popularized concepts that are still being integrated: interpreted code (vs. compiled), functional style (vs. imperative), dynamic typing (vs. static), Unicode support, closures (aka continuations, anonymous functions, lambdas), and list comprehension.

The important factor in this evolution is not the invention of a concept, nor its implementation as a library or freely available source code, but rather that the concept has been built into the language as a first-class citizen -- both runtime and syntax.

Emerging languages are looking farther into the future. Most languages presented during the camp integrated all of the above concepts. But new concepts appear regularly in the languages, and I reckon their repeated presence indicates their likelihood of being taken for granted in a decade or so.

Oft-noted concepts addressed at the camp included:

  • Map/reduce -- Taking a set of data, possibly transforming it (the map step), and finally computing a summarized result (the reduce step). Often applied to in-memory lists of data, but can be applied to objects residing in a database or even distributed among several computers.
  • Concurrency -- Fundamentally, doing more than one thing at once. Difficult to make work reliably in an ad-hoc manner, resulting in many solutions over the years (for example, Pthreads). New languages are going back to basics and implementing mathematically provable concurrency models.
  • Communications -- With nearly every application being network-aware, building communication methods into a language leads to easier programming, better reliability, and implementation of other emerging concepts like concurrency.
  • Reordering the object universe -- Although the object-oriented style has clearly proved popular, its potential complexity and fragility has caused some to reconsider its openness. Architectural models are being developed to control access and change of objects, even within a single process.
  • Code reloading -- A movement away from the current monolithic model where a change in a program requires a complete shutdown and reload of code, state, and data. Dynamic reloading would allow small changes to be loaded into running programs.
  • Program structure/execution visualization -- Moving beyond the traditional debugging model, into real-time inspection of stacks and data structures.
  • Language extension -- The ability to extend a language not just by adding classes/methods or functions, but through adding new keywords or operators. Domain-specific languages are a related concept.

Legacy of languages: influence over application

In the long view, a language may turn out to be important not for its particular application, but for its influence. Many of the camp presenters were quick to point out their influences and inspirations.

One might assume a single progenitor at the top of this tree, but it turns out to be a sort of holy trinity of computer languages: Lisp, ALGOL/Simula, and Smalltalk. The particular ancestor depended on the particular emerging language. Lisp-inspired languages in the functional style; Smalltalk in the OO style; and while Algol/Simula were actually not mentioned by name, I argue that Java (and Pascal and C++ before it) is the contemporary descendent of those 1960s-era languages.

Smalltalk was a direct influence on several languages that took its method-passing syntax quite literally, sometimes updating it with Erlang's messaging/concurrency model.

Interestingly, C and C++ rarely appeared as an influence in any of the emerging languages. The lack of C's influence was less surprising than C++. After all, it has been many years since C was a high-level language, and its elder years has found it as the language of choice for bare-metal applications like device drivers, kernels, and embedded systems. In these applications, C++ may fill in for a slightly higher-level systems programming language -- but its influence is clearing waning, with its place taken firmly by Java.

Java seems influential primarily for its context and conventions. Many programmers learned Java as the default language in school, and now work in environments where Java is the primary (and sometimes only) language. A language designer who is trying to better Java must realize that the way to the Java programmer's (and committee's) heart is not through radical syntax, incompatible libraries, or novel runtimes, but through comfort and familiarity.

Ruby was mentioned surprisingly often during the camp. It may end up a part of the language canon not because it is perfect or particularly innovative, but because it is both expressive and useful.

More to come

When viewed from a high enough level, the emerging languages presented during the camp fell generally into two categories: the languages that solve problems of reliability, safety, and correctness, and the languages that enable beauty and expressiveness. I'll discuss these themes in two upcoming posts later this week.

Related:

July 06 2010

The next wave of programming languages

This year's OSCON will showcase a host of new programming languages in the first Emerging Languages Camp. I got in touch with Alex Payne, Twitter's platform lead and the Camp's co-organizer, to find out why new languages emerge and which languages have captured his attention.

On the Emerging Languages Camp blog, you said new programing languages are often attempts at solving new problems. What are some of the biggest computing problems we currently face?

Alex PayneAlex Payne: The headliner that everyone's been talking about is concurrency. We have a handful of languages on the Camp roster that exist largely to address concurrency problems. Solutions could involve allowing people to spread computations over multiple physical machines in a pretty transparent way, or by providing different single-machine or single-virtual-machine concurrency paradigms. It's an interesting problem. There's a lot of conflicting takes on how relevant it is.

Some of the other problems involve expressability and maintainability of code. That's not a fundamentally new problem to the task of programming, but as there are more professional programmers entering the field at disparate levels of experience and education, having more languages that provide conventions toward readability of code has become a priority. There's no longer this monastic expert class writing Lisp in academic computer labs, nor people coming out of giant industrial organizations like IBM who go through a multi-week training process before they ever write code. A handful of the emerging languages are just explorations in maintainability.

Of the languages scheduled to be discussed at the Camp, which caught your eye?

AP: Gilad Bracha is presenting a language called Newspeak, which is a weird combination of ideas from Smalltalk and ideas from Bracha's experience with Java, and stuff from Lisp. In the programming language design community, small as it is, Newspeak is provocative. The discussions around it have been really interesting.

Rich Hickey is going to talk about Clojure. I've been to several conferences where he's spoken and he always has interesting metaphors from math, physics and literature. Clojure is a highly experimental language that's making inroads into industry, which is pretty rare. There's a lot of next-level ideas in Clojure, and people are actually picking it up.

OSCON - Save 20%Matt MacLaurin's Kodu is a visual programming language that was originally developed for the Xbox as part of a children's game. Visual programming languages have been around for a while, but this one is practical and applied. Kodu is also vastly different from anything else on the Camp's list.

Jonathan Edwards is at the MIT AI program, and he was working for a number of years on a language called Subtext that never saw the light of day. He's since reshaped that project into something called Coherence. I'm really interested to hear his talk, even though I think it's going to be very abstract. Most people get to the coding stage as soon as possible when they're working on a language because they're scratching an itch. Edwards is taking more of a hands-off, scholarly approach. He's been noodling on the ideas in this language for years.

Alan Eliasen works on a language called Frink. I hadn't heard of this language, but he found out about the event and wrote me a bold email that basically said: "My language is fantastic, and you should give me a slot because I'm going to be the hottest thing at your conference. I'll keep your people entertained." Frink itself is essentially a calculating language, but it has the concept of different units built in so you can easily convert calculations between units. It's all designed for scientific calculations, but it's got some neat syntactical stuff, more than you might imagine for a language that's built for calculations. On the Frink homepage, Eliasen has conversion examples for how much beer and how much jungle juice you would need for X individuals at a party. It's crazy.

Slava Pestov will talk about a language called Factor, which is a stack-based language like Forth. He and a couple of other people who work on Factor have done just an incredible amount of work in optimizing the compiler and the virtual machine for it. Once a month or so, they publish a blog post on what's going on in Factor, and essentially every one feels like a breakthrough in programming language implementation.

Where did the idea for an Emerging Languages Camp come from?

AP: I was at Foo Camp last year and did a session on what's coming in programming languages and what people would want out of an event that explored that. The Emerging Languages Camp is the result. I don't know how much of the feedback from the Foo Camp session ended up in the conference, but at the very least, there was a room full of people who thought that it would be an interesting way to spend a couple of days. So that was a big motivating factor.

What do you want the Camp to accomplish?

AP: I have a feeling that a number of the attendees who aren't language designers will be there because, like me, they're programmers who like working with new languages and are always looking for better tools. The real goal is to get the actual implementers connected so they can find commonalities. People have already started to find each other on the Camp's mailing list. I'm hoping those conversations continue afterward.



Related:




The first Emerging Languages Camp will be held at OSCON on Wednesday, July 21 and Thursday, July 22. Learn more about the Camp here, and receive a 20% discount on OSCON registration with the code OS10RAD.

June 22 2010

Does the world need another programming language?

Rob Pike has certainly been places and done things. In the early 1980s, he worked with Brian Kernighan and Ken Thompson at Bell Labs, where he co-wrote "The Unix Programming Environment" with Kernighan and co-developed the UTF-8 character encoding standard with Thompson. Pike is now a principal engineer at Google, where he's co-developed Go, a new programming language. Pike, who will discuss Go at next month's OSCON convention, talks about Go's development and the current state of programming languages in the following interview.

What were the motivations for creating Go?

Rob Pike

Rob Pike: A couple of years ago, several of us at Google became a little frustrated with the software development process, and particularly using C++ to write large server software. We found that the binaries tended to be much too big. They took too long to compile. And the language itself, which is pretty much the main system software language in the world right now, is a very old language. A lot of the ideas and changes in hardware that have come about in the last couple of decades haven't had a chance to influence C++. So we sat down with a clean sheet of paper and tried to design a language that would solve the problems that we have: we need to build software quickly, have it run well on modern multi-core hardware and in a network environment, and be a pleasure to use.

Although we targeted Go for a particular kind of problem, it turned out to be a much more general and adaptable programming language than we had thought. So we're using it for a lot of different things now. I think it might have an interesting future in any number of directions.

What's it like to program in Go?

RP: Go has the feel of a dynamic language like Python or Ruby or JavaScript, but it has the performance and safety of a language like Java or C or C++. So you get the lightweight feel of a modern scripting dynamic language but the robustness and performance of a more old-fashioned language.


Does Go have a robust development environment?

OSCON Conference 2010RP: We have an interesting set of tools now that play with the language. One of the standard libraries that comes with the distribution is a complete parser. So depending on how difficult the problem is, you can write your own tool and maybe a page of code with the existing libraries.

There's tools that let you link in existing libraries. With large packages like OpenGL or something like that, you're much better off just linking against existing ones. We can do that with our wrapper tool, and there's SWIG support so we can link against C++. But the fundamental libraries are all written in Go.

There's plug-ins for Eclipse and a couple of other environments. There needs to be more. We don't have an IDE yet, although we have some ideas about ways to do them.

Does the world need another programming language?

RP: It's an interesting time for languages because there are many new languages coming about. There was a burst of language development in the late '60s and early '70s and then things died down. That's not to say there weren't any new languages coming along, but language design didn't seem to be a very profitable enterprise. But then in the last five to ten years, there's been a renaissance. One of the reasons for that phenomenon, which is what I'm going to talk about at OSCON, is that the languages in common use today don't seem to be answering the questions that people want answered. There are niches for new languages in areas that are not well-served by Java, C, C++, JavaScript, or even Python.


How does Google compare to Bell Labs?

RP: A lot has changed in both worlds. When I worked at Bell Labs, we were doing much more research-driven, publication-oriented stuff. To a large extent, the company did not understand open source. When I came to Google, it was a very different orientation. We were definitely a company trying to make things happen. And at least a little later, open source became a fundamental part of the corporate culture. So they're very different in that regard.

As far as day-to-day work goes, I think they have a lot in common. They're both exciting places to work and they have a lot of smart people. But culturally, there's a difference between a telecommunications company and an Internet company. They're fundamentally different things.

This interview was edited and condensed.


Rob Pike will discuss Go's development at the OSCON conference (July 19-23 in Portland, Ore.) OSCON will also be the site of the first Emerging Languages Camp.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl