Uploading files with SWFUpload

SWFUpload News | SWFUpload

Tool which uses flash and javascript for file uploads. Much nicer then the normal file upload functionality provided by HTML.

Open Flash Chart

Open Flash Chart - Home

An open source flash charting module. Looks quite nice. Making a note here to come back and look into it a little more.

Common Lisp Quick Reference

Common Lisp Quick Reference

An incredibly useful reference for those of us that are still lisp newbies. I don't generally use this type of reference preferring to use online resources. But this stores a great deal of information in a compact format. A big thank you to Bert Bergemeister for putting this together.

Is Java Object Oriented?

Java is not Object Oriented | LispCast

You'll need to read the article to see the authors points. But one thing that was a new thought to me. We rarely reuse classes. We don't download a specific class from the internet and incorporate it into our current projects. But, we do reuse libraries of classes. In fact, the library is the primary method of reuse in almost all languages. Lisp seems to be an exception to this. There are libraries, but they don't seem to flourish quite as much as they do in other languages. The author makes the point that in Lisp, instead of pulling in a bunch of libraries to do the work, the programmer uses macros and functions to change the language itself to fit the problem space. I've always wondered why libraries in the lisp world seem much weaker then in other languages. Perhaps this is an explanation.

Python NetworkSpaces

Dr. Dobb's | Python NetWorkSpaces and Parallel Programs | July 2, 2007

I wanted to get this link saved. This article appeared in the July issue of Dr. Dobbs journal. It is a set of tools which allow a shared "network space" for python instances to connect to and work with. Networkspaces provides FIFO queus which multiple processes can read from in a safe fashion. Allowing you to setup a set of workers that read from some queues and write to others until no more data appears.

Really interesting approach and one I'd love to spend some time with at some point.

NetworkSpaces home

LispCast Article - Lisp, too, is mainstream

Lisp, too, is mainstream | LispCast

The article questions whether Greenspuns Tenth rule is still in effect. The article states that many of the features that made Lisp great are starting to find their way, or have already found their way into other languages. Of course not everything has been copied, macros come to mind as probably about the last feature that doesn't exist somewhere else. But, the author makes the point that there are features that other languages have that Lisp lacks. Namely things like huge standard libraries (java), large user bases, standards support, etc. These are not inconsequential when attempting to build a new product. The time saved by choosing Lisp, may be swallowed up in having to write code libraries for specific tasks. For example, if Lisp didn't have an SMTP library, would it make more sense to write a quick tool in python and use it's smtp library, rather then do it in lisp and have to build your own library? This is a dangerous line of reasoning for the lisper because you tend to then start thinking that language becomes less important. The quality and scope of the standard libraries becomes the bigger issue. Should we all be using PHP and Java?

In the comments, a discussion item was brought up about the fact that most other languages have a single canonical implementation that everyone uses. Whereas lisp has many implementations. So, not only must a developer decide on whether they want to use lisp or lisp like languages at all, but they must also decide on a dialect. Some push the expensive commercial lisps, others push for SBCL or PLT Scheme, open source implementations. Either way, when trying to incorporate a set of code into the lisp you've decided to use, you will probably have to do some porting of the package unless it is specifically written for the lisp you've decided to use.

As I have discussed before in previous postings, I believe this is one of the huge issues when trying to decide to use lisp for a particular project. The other for me right now is multi-processing. This is an area where no one has built a compelling, general purpose, set of functionality for lisp that takes advantage of multiple core processors and grids of computers. I hope someone does. Ironically, Google has shown that you can do grid processing even in a language like C++. So, perhaps this is not as big a deal as one thinks. Python too, appears that it will forever have a single threaded core. Yet, you can find grid computing tools for python, an arguably horrible language for parallel programming. Yet, it's ease of development and large set of libraries make it an attractive tool in some scenarios.

So, can Lisp overcome the problems of many different implementations and a standard library that seems to trail languages like Java, C# and Python? Can it effectively compete against languages that are exploring massively parallel programmaing like erlang, scala and haskel? Hopefully it can.

Noble Ape Simulation

Noble Ape Simulation: 26 May 2008

An interesting simulator. Attempts to do a cognitive simulation of a group of apes in the wild. Leo Laporte and Randal Schwartz interview the author, Tom Barbalet, during the latest FLOSS Weekly podcast.

From the website:

The Noble Ape Simulation has been in development for more than a decade.

It features a number of autonomous simulation components including a
landscape simulation, biological simulation, weather simulation,
sentient creature (Noble Ape) simulation and a simple intelligent-agent
scripting language (ApeScript).

Wow, running C and Python in the Browser

Running C and Python Code on The Web at Toolness

Here's the crux of the matter, click through to read the rest:

1. A special version of the GNU C Compiler—possibly llvm-gcc—compiles C code into instructions for the Low Level Virtual Machine.
2. The LLVM instructions are converted into opcodes for a custom Virtual Machine that runs in ActionScript, a variant of ECMAScript and sibling of JavaScript.
3. The ActionScript is automatically compiled into Tamarin bytecode by
   Adobe Flash, which may be further compiled into native machine language
   by Tamarin’s Just-in-Time (JIT) compiler.

Pretty amazing actually. Even though C is less interesting to me then some languages, this achievement shows very clearly that we are accelerating towards full blown applications that run in the browser, but have all the normal desktop functionality. Both from a developers perspective as well as a users perspective. In fact, one wonders if except for the odd special purpose app if almost everything won't be some hybrid application that partly lives on your machine and partly on the net. Or perhaps only on the net, but appears to be on your machine (downloads, is cached and runs locally natively compiled). Or perhaps not. Maybe people will rebel against the idea of letting other store all their information. Personally, I think not. With the advent of lighter and smaller internet access devices (think phones, tablets, tvs, etc), people will want access to all their tools in each place. And people have shown very dramatically that they are willing to give up nice gui interfaces and even let others have control over their personal information for something they can use anywhere with most any device. I think that this trend will continue to accelerate on the consumer side of the divide.

Businesses are a different story by far. They seem to be embracing web apps that they control themselves internally. And perhaps that's going to be the end game. The story for the business desktop seems to be one of increased lockdown and limiting of functionality. So, centrally managed applications are perfect. No need to have to maintain local installs of anything. Except when you can't find a web application that is as fully functional as a native application. There are a lot, including MS Office, Graphics packages, Financial Packages, and many, many more. But, I expect these will slowly be displaced by centrally managed applications within the business and to a lesser extent rented applications externally. The lure of central management and cost savings are just too extreme.

Erlang meets Lisp (again)

Random Bits and Pieces: Erlang meets Lisp (again)

Page lists the current and defunct projects attempting to reproduce erlang in lisp, or provide other means of tying them together. Nothing shockingly new in the rundown as nobody has really been able to reproduce the whole of erlang in lisp yet. The author points out that reproduction of erlang in lisp will probably fail because it will "lock out" other libraries which do not follow the concurrent "rules". His point, and I think a valid one, is that recreating the whole of erlang in lisp is a lot of work.

I think this is the achiles heel of lisp and multiprocessing. Most multi-processing ideas require very low level implementation in the language. All the attending libraries need to be built on top of these multi-processing primitives. Without that, all the existing libraries have to be rewritten, or you lose the ability to do parallel programming easily when using those libraries. Erlang espouses the share nothing approach and uses message passing instead. You can certainly model message passing in lisp, but since lisp never had the share nothing paradigm from the beginning, it seems as if a lot of library code is written assuming shared memory. Thus crippling easy conversion to multi-processing as well as multi-computer processing.

The other thing that I've been amazed at as there certainly isn't only one approach to multi-processing. Google's map reduce can be done in any language as long as the problem domain maps well to the approach, and not all problem domains do. But, perhaps instead of just trying to reproduce erlang, the lispers out there should be searching for something that plays to the strengths of lisp. Who knows maybe there is an even better approach to multi-processing.