A culture of problems

It seems like my culture has expended a great amount of effort in teaching the individual how to identify and report on the sad state of affairs which he is in, but has not taken the next logical step by teaching him how to move beyond that state. He is a man who knows how to identify problems , with no chance of solving them. This is a cruel punishment that has created a culture full of problems seemingly without solutions.

About the PLT Scheme Source Search

John asked about the status of the PLT Scheme PLaneT source search system here; to which Jens replied here and referenced this post. This post has information about why you might want to use the search engine (find out where set! is abused!) and also links to all of his posts about the development of the engine itself.
Jens mentions that he is not able to focus on maintenance at the moment; but if anyone is interested he would be happy to pass them the code.

Normal order and applicative order in Programming Languages

James had mentioned applicative and normal order in a post, on which Matthias commented and then elaborated here.

Normal order and applicative order are failed attempts to explain the nature of call-by-name programming languages and call-by-value programming languages as models of the lambda calculus. Each describes a so-called _reduction strategy_, which is an algorithm that picks the position of next redex BETA that should be reduced. By 1972, it was clear that instead you want different kind of calculi for different calling conventions and evaluation strategies (to the first outermost lambda, not inside). That is, you always reduce at the leftmost-outermost point in a program but you use either BETA-NAME or BETA-VALUE. Non-PL people were confused (and still are) because BETA-NAME looks like BETA but nearly 40 years later, everyone should figure this out. SICP was written when the majority of people were still confused. — Matthias

Player/Stage Robotics Software

The Player Project creates Free Software that enables research in robot and sensor systems. The Player robot server is probably the most widely used robot control interface in the world. Its simulation backends, Stage and Gazebo, are also very widely used.

Stage simulates a population of mobile robots, sensors and objects in a two-dimensional bitmapped environment. Stage is designed to support research into multi-agent autonomous systems, so it provides fairly simple, computationally cheap models of lots of devices rather than attempting to emulate any device with great fidelity. We have found this to be a useful approach.

Gazebo is a multi-robot simulator for outdoor environments. Like Stage, it is capable of simulating a population of robots, sensors and objects, but does so in a three-dimensional world. It generates both realistic sensor feedback and physically plausible interactions between objects (it includes an accurate simulation of rigid-body physics).

This looks like a great way to get started with robotics without worrying too much about purchasing hardware.
(via PLT)

New PLT Scheme DEV Mailing List

PLT Scheme has a new development related mailing list. The focus of this list is on the development of the PLT Scheme system itself rather than the utilization of PLT Scheme.
Here is a link to the post.
Here is a link to the signup page for the list.
Here is further clarification on who might be interested in this list, as plucked from the “Welcome” email from the list:

Welcome to the [email protected] mailing list! This list is for discussions on the implementation and development of PLT Scheme. It is aimed at people who are interested in contributing to PLT Scheme, or who are interested in the implementation of PLT Scheme. However, it is not for general discussion of Scheme, PLT Scheme, or programming — please use the plt-scheme list for those.

MOSS: A System for Detecting Software Plagiarism

Moss (for a Measure Of Software Similarity) is an automatic system for determining the similarity of C, C++, Java, Pascal, Ada, ML, Lisp, or Scheme programs. To date, the main application of Moss has been in detecting plagiarism in programming classes. Since its development in 1994, Moss has been very effective in this role. The algorithm behind moss is a significant improvement over other cheating detection algorithms (at least, over those known to us).
Moss can currently analyze code written in the following languages:
C, C++, Java, C#, Python, Visual Basic, Javascript, FORTRAN, ML, Haskell, Lisp, Scheme, Pascal, Modula2, Ada, Perl, TCL, Matlab, VHDL, Verilog, Spice, MIPS assembly, a8086 assembly, a8086 assembly, MIPS assembly, HCL2.

Moss was created by Alex Aiken.
(via PLT)