Thought-provoking read on using Mirrors for language reflection, via @joshsusser

RT @jakedonham: today is a great day to try OCaml

Multi-language REPL running in-browser using EMScripten

A functional/logic programming language

Occam-PI - a CSP-inspired language

A critique from the maintainability standpoint.

An intro to PLT Scheme via graphics programming.

Tom is a software environment for defining transformations in Java.

Dylan is an advanced, object-oriented, dynamic language which supports rapid program development. When needed, programs can be optimized for more efficient execution by supplying more type information to the compiler. Nearly all entities in Dylan (including functions, classes, and basic data types such as integers) are first class objects. Additionally Dylan supports multiple inheritance, polymorphism, multiple dispatch, keyword arguments, object introspection, macros, and many other advanced features

XMF is an industry strength extensible programming language designed for Language Oriented Programming. All aspects of XMF can be easily extended or redefined at run-time allowing the dynamic construction of domain specific languages (DSLs) which can be used either standalone or weaved into existing DSLs.

This is the first episode in a tutorial series on building a compiler with the Parrot Compiler Tools.

Neko is a high-level dynamically typed programming language which can also be used as an embedded scripting language. It has been designed to provide a common runtime for several different languages. Neko is not only very easy to learn and use, but also has the flexibility of being able to extend the language with C libraries. You can even write generators from your own language to Neko and then use the Neko Runtime to compile, run, and access existing libraries.

Why programming language design repeats itself.

A High-Performance Open Source Smalltalk With An Optional Type System

My first job was working with Cold Fusion for a year. For the next two years I worked primarily with Javascript and a proprietary language. Next was a brief stretch with PHP and ASP, followed by about 3 years of .net. Finally, for the past 2 years I've been doing Ruby. I do not consider myself a Ruby developer. I prefer to just be a developer.I don't expect that Ruby will be the last language I ever work with. In fact, I expect I'll probably be doing something new in the near future. The question is what language should I work with next? Should I go for a classic like Lisp or Smalltalk? Should I give Scala or Erlang a shot and ride the concurrency wave?The problem is, I'm asking the wrong question. Rarely when discussing languages do the languages themselves dominate the conversation. I can't remember ever being in a conversation where someone won a language debate with things like closures, metaprogramming or static typing. Instead, the primary focus of language debates are usually around frameworks, performance, IDE support, developer availability, what OS does it run on, and any number of other factors that are only related to the language.The question extends even beyond factors related to the language.At Google I’ll work with C++ rather than (for example) Ruby but I do get to be part of changing the world. -- Jon TirsenJon gave up a job using his language of choice to work with another language he likes far less, but for a cause he's very interested in. I have another friend who recently starting working with an investment company because he was interested in the domain.Two years ago I started looking at Ruby because several of my colleagues were giving it a look. I preferred Rake to NAnt, and starting using it on my .net projects. Before long, someone asked me to be part of a Ruby project, because of my limited exposure to Rake.I got introduced to Ruby by coworkers who were interested. I got involved with Ruby because I prefer build files that do not require XML programming. I stuck with Ruby because we had a steady stream of Ruby projects that needed experienced developers, I got plenty of blog content, I liked the composition of the Ruby teams I got to work with, and I liked working with clients who are comfortable with early adoption.Notice, none of the reasons I use Ruby have anything to do with the Ruby language itself.I'm interested in doing something new because I feel like I've been doing the same thing for about a year now. I'm also interested in traveling to other ThoughtWorks offices and getting some fresh ideas for innovation.Again, none of my desires have anything to do with language.I'm not giving you the tired "no silver bullet" or the hand waving "the right tool for the right job". I'm asserting that people use those phrases to justify their language choice, but you'd be better off asking what the real motivations for choosing a language are. What other factors does the language introduce that make it their choice.It's also helpful to have this understanding when considering criticizing someone's language choice. My friends aren't using Java because they like Java, they are using it because they like IntelliJ, high performance on a few boxes, simple deployment, Hibernate, String Template, Spring, and a hundred other factors. Therefore, criticizing Java as a language doesn't really do anyone any good. Even if I convinced them that Lisp is a better language than Java, I still wouldn't have convinced them to use Lisp on their next project.© Jay Fields - www.jayfields.com