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 »

Bench PSU made from an old PC power supply (by alaric)

My first PC compatible was an actual PC. As in, the original IBM PC - not even an XT. It died a death, but I salvaged the power supply from it, with the nice red switch, to be a bench PSU for my electronics experiments:

It supplies -12v, -5v, 0v, +5v, and +12v. Which served me well for some years, but these days, everything's 3.3v or 1.8v. And my termination setups - first wiring directly into the row of screw terminals on a breadboard, then later a bit of wood with metal strips nailed to it so I could attach croc-clips easily - all left something to be desired.

So I got busy and built this:

Complete with a power LED so I can see at a glance if it's live:

Inside it's quite simple. Most of the terminals are fed directly from the PSU via the black cable, but I added an extra wire for an earth connection to the chassis (which I checked was really earthed) for ESD wrist straps. I mounted 3.3v and 1.8v linear regulators on a bit of stripboard along with the LED and its series resistor, and hooked it into the 0v and +5v lines.

Job done. Now the last bit of major infrastructure I need set up is to get Ethernet into the lab so the PC I have in there for driving the dev boards can access the Internet and my version control system...

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 »