Tag: philosophy

Literate Programming in Scheme

The release notes here for PLT Scheme 4.1.5 mention support for literate programming. Not being familiar with the term; I read more about it on Wikipedia here.
I have wanted in-code documentation generation tools to serve this purpose; but I have never succeeded with them. It had always felt like I was battling the intent of the tool. Even Eiffel’s notion of different views on code-as-documentation never quite fit for me. This approach is fascinating; it allows for you to tell a story about the code as you write the code. Having posted to the PLT list asking about it here; two folks replied with details on this style and Scheme.
PLT Scheme recently added literate programming support; documented here. One example of its application is in Chat Noir here; and the source code for it may be viewed here (Thanks Robby).
A tool for literate programming in Scheme called is schemeweb located here (Thanks Phil).

The contentment of content

A few weeks on a PBS television show hosted by Alan Alda the scientists being interviewed were talking about the “Contentment of Content”. They said the the research shows that most humans learn the bulk of their knowledge (in particular their approach for all sorts of problem solving) younger in life and never learn any new approaches later on because it would just show them how much they don’t know. In other words; it would require the act of learning and that takes work. They go on to explain that in fact, this approach not only happens at the macro level in life but also in the macro level for particular areas of expertise. For sake of discussion, I would focus on programming.
The idea is that once you learn how; you are very, very unlikely to learn “new ways of doing it”, and why would you? It makes you feel bad since it makes you look like you don’t know what you are doing. It is also very, very unpopular to admit that you don’t know everything (I wonder if it has always been this way?). This is unfortunate because most of us really never learned how to program well and in fact seems to be the complete antithesis of the behavior and approaches that are likely to have made you successful as a programmer in the first place.

Tony Hoare sorry for inventing the null pointer

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.

(via Reddit)

Lisp as a crucible

Scheme and Lisp force you *think* from the get-go. Most engineers and programmers hate to do that and it makes them uncomfortable. Starting a program in Java or C is easy. There’s a pile of boilerplate you can type without thinking about it, and it `feels’ like you’re programming. Then you have to haul out the bag of tools like the compiler and the linker and makefiles or ant. There’s a lot of busy work needed just to get going, and you feel like you’ve accomplished something.
In Scheme or Lisp, you start it up and there you are at the REPL. You have to decide what your program is going to do. You can’t waste time writing boilerplate (it’s unnecessary), designing data structures (just cons one and specialize it later), figuring out how to build complex inheritance hierarchies (do that once you know what you are doing), you have to dive into the problem right away. If you are willing to make mistakes and learn from them, then the REPL is a great place to play. If you prefer to plan ahead so you don’t make mistakes, a REPL is a very uncomfortable place to be.

— jrm
Having experienced the “discomfort” myself, I recognize now that this development approach acts as a mirror to your strengths and weaknesses. It reveals, very very quickly, whether or not you really have got a grasp both on the problem and how you plan to solve it. There is no where to hide! It is great.
(via R6RS)

The energy to become productive in a language

I’m not doing programming for it’s own sake, but because I’m trying to get my real work done and that involves writing code. I have neither the inclination nor the luxury of time to really delve down and spend three or six months learning a complex language in the hope that I’ll be more productive

— Janne
In the past I have said the same thing myself. This seems to be the status quo for the industry. I don’t feel that way anymore, though. It was the result of a feeling and not a rational thought process. Once you think about it, it doesn’t really make much sense.
If we don’t learn anything more than what we already know, then how will we ever get any more productive?
(via this comment)