Probably Dance

I can program and like games

Ideas for a Programming Language Part 1: Source Code in Database

My main motivation for wanting to write a programming language is that I believe I can make programmers much more productive. Somewhere in the archives of unfinished blog posts for this website here I have a very long post about what language features and coding practices I think contribute to programmer productivity, (and what harms productivity) but I believe that in the long term the one most important contributor is the quality the tools that we use to program.

And “tools” is a very vague word. It includes everything from source control to text editors to test frameworks to debuggers to refactoring helpers to code completion to compiler warning messages to static analysis to profilers, diff, make and many more categories. All of this surrounding infrastructure that we use around coding actually has a much bigger impact on productivity than which language we pick. Which makes sense because those tools are usually written by someone not directly involved in the language. And if they took the time to write the tool, you bet it will have a big impact on their productivity. So I want to make a language that will have the best tools ever. I think that’s actually not too difficult. It seems that nobody has had that ambition before.

And for that my language will store its source code in a database instead of text files.

Read the rest of this entry »

plalloc: A simple stateful allocator for node based containers

Allocators in C++ are awkward classes. Allocators are usually zero size to make the containers small, and they have no state because that used to be difficult to do in C++. But nowadays we don’t really care about the size of our containers (we care about the size of the content of the containers) and since C++11 we have support for stateful allocators.

The problem I’m trying to solve is that node based containers have bad cache behavior because they allocate all over the place. So I wrote a small allocator which gives out memory from a contiguous block. It speeds up std::map and std::unordered_map. It’s called plalloc because I think this is a pool allocator.

Code is below:

Read the rest of this entry »

Ideas for a Programming Language

I’ve been simmering ideas for a programming language for a while. I’ll probably get around to actually writing one in a year or so. But Jonathan Blow is writing a new language right now and there is some overlap between his ideas and my ideas, so I kinda feel compelled to write about mine.

Since he just had a talk about compile time function evaluation, that will be my first post. But that’s not actually the order in which I want to write about things, so I’ll do a Star Wars move and post part 3 before posting part 1 and 2.

But still this post is a summary of what I will write:

Read the rest of this entry »

Comma Operator RAII Abuse

Here’s a neat little trick that one of my co-workers, Clint Levijoki, discovered. In C++ you often use an RAII wrapper that you place on the stack if you want to be sure that code gets run at a later point. One good example would be std::lock_guard which you use if you want to be sure that a lock gets released in the future, or scoped profiling which you use to stop a timer in the future. For example for this:

std::string foo();
void bar()
{
    std::string baz = foo();
    // do something with baz
}

If you want to profile foo() you’d write it like this:

std::string foo();
void bar()
{
    std::string baz;
    {
        ScopedProfiler profile_foo("foo()");
        baz = foo();
    }
    // do something with baz
}

Which is less pretty and slightly slower. Alternatively you can use the comma operator and do it like this:

std::string foo();
void bar()
{
    std::string baz = (ScopedProfiler("foo()"), foo());
    // do something with baz
}

And this will start a timer before calling foo(), and stop the timer after calling foo(). You could wrap it in a macro to make it more readable. And the benefit is obviously that you don’t have to destroy your function flow when you want to insert RAII objects.

Read the rest of this entry »

Another Opinion on “Almost Always Auto”

Herb Sutter has been promoting his almost always auto style again, and I think it is harmful. I would agree with “almost always auto” in Scala. I disagree with it in C++. And that’s because there is a slight difference in syntax for type inference between the two languages.

Here’s type deduction in Scala:

val inferred = 0
val typed : Int = 1

And here it is in C++

auto inferred = 0;
int typed = 1;

Seems similar, right? But the difference in syntax leads to different long term programmer behavior.

Read the rest of this entry »

The Curious Failure of Functional Programming for Parallel Applications

Long title, but it is interesting how functional programming has mostly failed to gain traction in parallel and concurrent applications. People think that functional programming should become more popular as we do more and more parallel programming, but that doesn’t happen. As an example this blog post made the rounds recently which has this quote in it:

However, the key to multicore programming is controlling mutation. This is why functional languages have been steadily gaining ground in concurrency and parallelism.

Which I would disagree with. Not the controlling mutation part, but the steadily gaining ground part. Let’s look at a few examples:

Read the rest of this entry »

format_it: Iterator based string formatting

format_it is my attempt at writing string formatting that is good enough that it could make it into the C++ standard. It’s not quite there yet but I haven’t gotten to work on it in a few months, so I will publish what I have so far. It is fast (much faster than using snprintf to write to the stack), type safe, memory safe, doesn’t truncate, extensible, backwards compatible for std::ostream and somewhat composable.

The syntax is a mix of printf, ostream and varargs. I’ll just show an example:

// format "100 and 0.5" into 1024 bytes of stack memory
fmt::stack_format<1024> format("%0 and %1", 100, 0.5f);

// print "Hello World" into 1024 bytes of stack memory
fmt::stack_print<1024> print("Hello", "World");

// prints "100 and 0.5\nHello World\n"
auto format_to_cout = fmt::make_format_it(std::ostreambuf_iterator<char>(std::cout));
*format_to_cout++ = format;
*format_to_cout++ = '\n';
*format_to_cout++ = print;
*format_to_cout++ = '\n';

Where the first and second struct mimic snprintf, and the third example introcues the formatting iterator that they use behind the scenes.

Read the rest of this entry »

Databases are Fucking Stupid

I’ve been trying to do some database programming and goddamnit do databases make my life difficult. I’m using PostgreSQL but it doesn’t really matter what you use. Let me get the most minor complaint out of the way: Why do I have to talk to databases using text?

Every time that I want to store a value in a database I have to convert it to a string and the database has to convert it back from a string. This is slow, lossy, leads to bugs (SQL injection) and is completely unnecessary. But I can accept that bit of stupidity.

My bigger issue is that databases don’t know how to do their job.

Read the rest of this entry »

I Wrote a Faster Hash Table

This is a follow up post to “I Wrote a Fast Hash Table.

And I’ll start off with a download link.

I’ve spent some time optimizing my sherwood_map implementation and now it is faster than boost::unordered_map and boost::multi_index. Which is what I would have expected from my first implementation, but it turns out that those containers are pretty damn fast.

If you don’t know what Robin Hood Linear Probing is I would encourage you to read the previous post and the post that I linked to from that one. With that said let’s talk about details.

Read the rest of this entry »

I Wrote a Fast Hash Table

As others have pointed out, Robin Hood Hashing should be your default hash table implementation. Unfortunately I couldn’t find a hashtable on the internet that uses robin hood hashing while offering a STL-style interface. I know that some people don’t like the STL but I’ve found that those people tend to write poorer interfaces. So I learn from that by not trying to invent my own interface. You can use this hash table as a replacement for std::unordered_map and you will get a speedup in most cases.

In order to reduce name conflicts I call it sherwood_map, because Robin Hood Hashing.

Read the rest of this entry »

Follow

Get every new post delivered to your Inbox.