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.
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 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....
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.
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.
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.
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.
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...
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.
The emphasis is on the 4 major problem areas that crop up in an attempt to convert Scheme to C:
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.
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.
The MOZ 2004 "Second International Conference on
Active forum topics
New forum topics