General

How birds learn songs

Research on Teaching Birds to Sing. Since we periodically delve into general language issues, I thought this work might be of interest since it is related to language learning.

Learning how baby sparrows learn to sing their songs could provide clues to how humans learn to speak languages. University of Utah biologist Gary J. Rose and his colleagues have taught baby sparrows to sing a complete song, even though the birds were exposed only to overlapping segments of the tune rather than the full melody.

(Though, we still appear years away from providing a general purpose PL for the winged community. And even then, we'll have to engage a full combinatory community).

Tim Bray: Sun & Dynamic Java

Tim Bray,

So on Tuesday we held a summit here at Sun, with a few of our internal Java leaders, and on the dynamic-languages side, Larry Wall and Dan Sugalski (Perl and Parrot), Guido van Rossum, Samuele Pedroni and Sean McGrath (Python), and James Strachan (Groovy). It was an educational day for us; herewith some take-aways and pictures.

Everyone and his sister is linking to this blog post, so you might have seen it already.

For a touch of flavor, here’s just part of the list that of things to discuss that Larry had prepared: anonymous code/closures, lvalue methods/functions, variadic call/return, constant/rw/copy/ref/lazy parameters, wrappers/AOP, eval, exception handling/undef/nil/unthrown exceptions, exception handlers with lexical access, temporization/hypotheticality, efficient regex with complete semantics, access to dynamic context/want/caller, redispatch of methods (fallback upon "fail"), efficient switch statement?, versioned modules/classes, virtual classnames, continuations.

Feel free to express your opinion regarding this list, and other relevant factors.

Casting SPELs in Lisp

A short and sweet Lisp tutorial that has the courage to introduce macros to absolute beginners.

The reader is shown how to build a simple text adventure game using Lisp. The code is available for download.

The IDE Divide

(via Keith)

Oliver Steele:

The developer world is divided into two camps. Language mavens wax rhapsodic about the power of higher-level programming — first-class functions, staged programming, AOP, MOPs, and reflection. Tool mavens are skilled at the use of integrated build and debug tools, integrated documentation, code completion, refactoring, and code comprehension....

You can be the only one on a team to use Eclipse. If you’re the only one on your team using Haskell, something is probably wrong.

It has been awhile sine we had a good IDE war er.. discussion...

The distinction between language mavens and tool mavens rings true. It shouldn't be too hard to guess to which camp I belong... I rarely spend time thinking about IDE issues if I can only help it.

Extending Ruby with C

I've generally found that the APIs for bridging the gap between Perl and C are either cryptic (XS) or fragile (Inline::C). While Python is better in some ways, I still find its C API rather difficult to read. Tools such as SWIG can help alleviate this problem, but you still need to write a bunch of glue code to bridge the gap between the high-level agile languages and the low-level C code.

When I first looked at doing the same kind of thing for Ruby, a whole new world opened up. The APIs are simple, to the point where I was up and running in minutes rather than hours.

A nice tutorial article on extending Ruby by providing access to a C library (GenX).

It has been awhile since we discussed language extension mechanisms and multi-language programming, yet these techniques are quite important when building real life systems.

Haskell Communities and Activities Report, Seventh Edition, November 2004

The November 2004 edition of the biannual Haskell Communities and Activities Report has been published. Lots of new stuff in the last six months, and some old stuff updated as well. The HC&AR has been steadily growing over the last three years, showing that FP is gaining users both professional and private.

Several of the HC&AR items are interesting enough to have their own LtU stories, which may appear shortly.

OOPSLA essays track

The program chair for OOPSLA 2005, Richard P. Gabriel, wants to shake things up. As part of that he's going to institute an Essays track, and I will be program chair for that track. I'm hunting for people to serve on the committee. -- Brian Marick

Might want to send in your suggestions.

Me, I am going to think of an essay topic...

End Users to Shape Effective Software

This might be an interestng project to keep an eye on.

The papers seem to cover a wide range of topics relevant to end user programming in a variety of settings.

The 90 Minute Scheme to C compiler

90 minute video presentation from Marc Feeley, along with accompanying PowerPoint slides and source code, for a Scheme to C compiler. Good discussion of continuations and closures, as well as some dipping into the area of compiler construction.

How to write a simple Scheme to C compiler, in Scheme. In only 90 minutes! And although not supporting the whole Scheme standard, the compiler supports fully optimized proper tail calls, continuations, and (of course) full closures. The compiler is implemented using two important compilation techniques for functional languages: closure conversion and CPS-conversion.

The emphasis is on the 4 major problem areas that crop up in an attempt to convert Scheme to C:

  • tail-calls a.k.a. tail-recursion opt.
  • first-class continuations
  • closures of indefinite extent
  • automatic memory management i.e. GC

The solution presented gives a series of source-to-source transformations. Stage 1 of the compiler expands the 'let' forms in the Scheme code. Stage 2 converts continuations to CPS. Stage 3 converts the code to closures using encapsulated closure objects. Stage 4 is not presented but touches on how the results would lend itself to a GC implementation.

Programming for non-programmers

A thread over on the PLT mailing list that LtU-ers may find interesting.

The thread isn't very technical, and the title may be a bit misleading: It's more about programming skills than about programming by non-programmers.

I wonder how many people outside the PL community would agree with the statement that Programming is just another name for the lost art of thinking. Perhaps a better formulation would be Programming, done right, is just another name for the art of thinking.

And by done right I mean using the right languages, of course.

XML feed