About this blog (whetting your appetite)

This is a blog about designing a new programming language, Fencore. I tried hard yesterday to concisely write up the most important reasons why in my opinion, you want to be programming in Fencore, and it became a long list. ;-) That made it sounds like Ada, though ("take everything cool and put it into a single language"), which doesn't do the language justice: One of the two basic principles of Fencore is to be a conceptually very simple and pure system (like in the lambda calculus, say), and everything else follows from there.

The other basic principle is extensibility. Not only will the language be extensible at every level, but it will have support for extensible data structures. If you know the Semantic Web, you'll have some idea of what I'm talking about.

Fencore isn't here yet, but it's more than a thought experiment. I hope to have a version one by the end of this month. I have a tendency to understimate the time it takes to design something, though, so let's see. It will be free software when it's published. If you're not interested in hearing about vaporware, we would like to apologize for the inconvenience; please try again later.

Perhaps the main reason for Fencore is that part of it is a logic that allows you to prove things (and have the computer check those proofs) about the programs you're writing, but that it's designed as a comfortable language for hackers, not a framework for writing specification legalese. Why you would want to do such a thing? Here's one of the things I wrote yesterday:

When writing code, you want to make it as powerful as you can, but you also want it to be easy to understand and efficient enough. Fencore will let you write code without caring about efficiency at all. After you have done that, it will let you tell it how the parts that need to be efficient should actually be implemented, and prove that your efficient code actually does the same thing as the easy-to-understand code.

I've often felt in my own work that the simultaneous pressures of making my code powerful, easy to read and efficient have made it less powerful, less efficient, and more complicated than acceptable, really. Thus Fencore.

The weird thing about formal logic is that usually neither logicians nor computer geeks realize that formal logic on computers is both useful and fun. Formal logic allows you to write down why you think that your tree balancing algorithm should work, and have the computer tell you "yes, indeed" or "no, something is wrong with that explanation," making you realize the bug that would have eaten the user's data one in a thousand times. Unfortunately, both logicians and hackers generally believe that you have to write the proofs on a blackboard and check them yourself, leading to proofs that are more likely to be buggy than the programs they are supposed to prove correct.

That's sort of like using an assembler program to tell somebody how to multiply matrices and expect them to flawlessly work out all the register values, and if they make a mistake, conclude that programming languages are useless.

I also think that hackers' opinion of formal logic isn't helped by tools that feel more like Cobol than Python on first impressions.

Well, that's it for now. Fencore is a nice design, but this blog post is too short to contain it. I'll explain it in more detail over the next couple of days; stay tuned.

Fencore is influenced by ideas from mathematical logic, functional and logic programming. Don't be scared by that; I'll try to explain everything along the way that's necessary for understanding what I want to say. As noted above, Fencore is also influenced by and based on the Semantic Web. I hope you won't be scared by that either, but I'll assume some familiarity with RDF.

If you decide to keep reading anyway, welcome.