Magic Pipes (by alaric)

One of the neat things in Unix is that you can make 'shell pipelines' of commands, from a suite of tools that come with most Unix systems, by feeding the output of one command into the input of another.

Read more »

FORTH (by alaric)

Recently there's been some excitement in some corners of the programming languages community over the fact that Forth Dimensions has been scanned in and OCRed and is now available.

Read more »

Assertions (by alaric)

Assertions are a useful tool in defensive programming. If you're writing a bit of code that assumes some condition to be true, since that condition being true is a design constraint of your system so it can only possibly be untrue if there is a bug elsewhere in your code, then it can help to put an explicit assert of that condition before your code.

Read more »

What’s neat about elegant languages (by alaric)

Most people who like to use "unusual" non-mainstream language have to have a motivation for doing so. After all, there are reasons not to - a smaller user community, although that can be a good thing, means less libraries, less support for more unusual platforms, and less likelihood of your programming in that language ever earning you money.

When asked, most will say that they find programming in their chosen language easier, but it can be hard to explain why.

However, in a discussion in IRC recently, I think I may have captured part of it:

• alaricsp: I do a lot of programming in various languages, and I tend to find that the amount of coolness I can do per line in Scheme is higher, and I get less bugs
• alaricsp: As in, I decide to do something complex, sit down and write a hundred lines of scheme, try to run it and get lots of syntax errors due to typos, fix those, then it's semantically bug free about 75% of the time; and in the remaining 25% there's usually just one simple bug (last one was due to me getting confused with some boolean algebra over lists, doing an any? instead of an every? or something like that)
• alaricsp: I start in implementation space and build up in thin layers to get to problem space
• alaricsp: Cheap easy-to-use abstraction means it's cost-effective to have lots of thin layers
• alaricsp: And thin layers are easier to think about, so less buggy

To which somebody else followed up:

• sjamaan: Aye
• sjamaan: I find the barrier to creating an abstraction in OO languages to be very high, for example
• sjamaan: I actually sigh everytime I have to create a new class file!
• sjamaan: Whereas I don't even think about creating a lambda
• sjamaan: I just do it

Memory management (by alaric)

A lot of the core infrastructure in a computer system - such as memory management - is somewhat overlooked for opportunities to improve things, because a vicious circle of conservatism sets in: we tune memory manages for systems that work like POSIX, and then stick with systems that work like POSIX since the memory management is so well-tuned...

So I set myself the task of designing, from scratch, an approach to memory management that's appropriate to an event-driven system based around a purely functional language with mutation expressed via unique typing.

It's far from complete, but here's a brain dump:

Read more »