September 7, 2007
August 23, 2007
The primary benefit of static type checking is that a compiler can catch a wide variety of bugs at compile-time. With dynamic languages, on the other hand, some bugs aren’t revealed until they actually blow up in your code. Between run-time and compile-time, however, there exists “binding-time”. This is when you actually load all the libraries you are using into a runtime to begin execution. It might be useful to delay type checking until this point to allow runtime manipulation of modules and environments. I can generate code and interfaces at binding-time, then run the type checker and report errors. This gives you most of the flexibility of dynamic code, but preserves most of the safety of statically typed code. You won’t discover the error until you load everything into a runtime. I know of some early static checking tools for C that did this, but I don’t know of any statically typed languages that move checking to this phase of development.
August 21, 2007
I’d like to implement a new programming language for my personal use. Here are some qualities I’m interested in:
- small: It should be as small as possible, like lambda calculus.
- extensible: All syntactic sugar added here. Also, must support compiler extensions.
- concurrent: need abstract notion of concurrency built in.
- typed: static is better than dynamic typing, but it should support both.
- lazy: the implementation can still be strict, but lazy gives more freedom to programmers
- modules: need a simple, yet reflective, module system.
- FFI: should be able to easily access foreign code, preferably C-like.
It seems like I could build my language on top of Clean. I’ll try writing some programs in Clean first.
August 10, 2007
I wrote a Yahoo! widget that displays the energy cost of running a computer. Based on Google’s paper on data center energy consumption, it uses CPU load as a good approximation of energy usage. You can calculate your computer’s peak power requirement by adding up all the components in your system. Since your power supply loses some energy to heat, you should divide by it’s efficiency rating (mine’s 85%, but most computers are ~60%). This total number will be significantly higher than the true peak power load because manufacturers list very conservative (i.e. high) numbers. Google found their server ran at 60% of the “nameplate” value. I’d say take 80% of your total to get closer to a real peak power number.
At 0% CPU, a computer still consumes 50% of peak power. It’s linear from 0% to 100% CPU, so it’s easy to compute how much power is consumed: (50+(CPU load/2))% of peak power(W/hr). Multiply this by your cost per kW/hr to get the energy cost. You can also compute how much pollution was generated to provide you with that energy using this table: http://www.eia.doe.gov/oiaf/1605/e-factor.html. The point of all this is to illustrate that the energy required to run your computer is a significant cost per year. If my computer sits idle all year, it costs about
$70 $200 to power it. [edit: I misread my power bill]
July 26, 2007
I’ve been thinking more about programming languages for children. It appears these languages attempt to make normal programming control constructs appear slightly less nerdy, but it really has the same behavior. For example, you must specify all the branches for an IF statement at development time, which requires kids to consider all possibilities up front. That might be difficult for a 5 year old. One idea I’ve been thinking about (for a while, actually) is an incremental IF that can be dynamically extended at runtime. For example, you can type in the statement “if (x < 10) then doX()” and run the program in incremental development mode. The program runs normally unless it hits this line with x >= 10. Then the program will ask the user what it should do in this case. You can type in a new behavior “doY()”, or you can enter a new IF-THEN clause. The program adds this to the program and continues execution. People do this anyway with edit-compile-debug cycles or rapid prototyping in an interpreter. But that’s too tedious and difficult for children and other non-programmers. Now how can I make loops incremental, too?
July 23, 2007
At the Cooper Union Design Museum, there was a poster for a programming language called Processing. Isn’t it absurd that a PL would be in a museum? It appears to be a minor syntactic improvement over Java, plus a radically simplified graphics library. It refers to another language called Design By Numbers, which also aims to make programming simpler for artists. Finally, I ran across (again) an environment called Scratch designed for children. It is a media production environment built on top of Squeak. All three aim to make programming easier for non-programmers. However, in most cases these language merely offer syntactic sugar over traditional PL control constructs. People can learn that “for (i=1;i<=10;i++)” is the same as “repeat i 1 10” (dbn). It just feels like Cobol all over again: make the syntax “friendly” and programming is a snap. I think much more needs to be done to make programming much simpler (and less powerful) for non-programmers in special domains.
July 19, 2007
Here’s an idea for a new community based web site. Develop an online expert system where individual contributors can extend its knowledge base with new rules. Expert systems have been around for a long time. The technology is fairly easy at this point, but it’s always been hard to find experts to fill up the knowledge base. If such a system were available to the public, then individuals can extend the knowledge base for a particular domain in small pieces. Domains might include auto repair, health information, investments, computer problems, etc. I’m not sure what the rule language would look like, but it would need to be something where the machine can gather them into a decision tree, rather than individuals extending the tree manually. Of course, this depends on a diligent group of contributors to keep the rules honest, much like Wikipedia. I’ve not seen such a site yet, but I’ll poke around some more.