Over the holidays there was a big debate on compilation time in the C++ community. It started with a blog post by Aras Pranckevičius: "Modern" C++ Lamentations. The post picks on the Standard Ranges by Eric Niebler, that shows how you would implement Pythagorean Triples with Ranges, a new addition to C++20 standard.

At the heart of Aras' argument was the following two facts:

• the range-based Pythagorean Triples is much longer and more complex than a simple C-style implementation
• compilation time increases from 0.071s to 3.02s (when going from C-style to range-based implementation -- that is 42 times slower

The "modern" C++ tends to be more complex and less usable.

As Sparrow has for some time ranges as a core usability feature, and compilation time is not necessarily a strong point of Sparrow, I feel obliged to stat

First, the slow part:

• personal problems for the last two months -- life is hard
• changing the type system is slightly harder than I originally thought
• adding unit tests & refactoring along the way

There is little you can do for the first bullet point. Therefore, I'll focus on the other two bullet points.

Before starting the type system work, Sparrow had zero unit-tests. With this effort, I was convinced that we need unit-tests to make considerable progress in Sparrow. That took a lot of work, but it's starting to show signs that it pays off. I have now, some rough numbers that I can use to see if it pays off.

Previously, when I developed a more complex features, I encountered one or more road-blocks. I used to spend, let's say, 20 hours to avoid a road-block. Because of the complexity of the software, I didn't fully understand what the compiler is supposed to do, so I had a lot of wrong assumptions, and also there were a lot of bugs

For some time now I've started to change the type system of Sparrow. I wanted to add immutability as a first-choice instead of the current "everything is mutable". For more details see: http://lucteo.ro/2018/07/08/designing-Sparrow-type-system/

The problem is that I'm moving too slow. It takes me a long time to make changes that can be seen as minor. I make one change here which seems good, and immediately I find errors in some other part. I fix that error, and a new error appear. It feels like going in circles. Actually, it I step back a bit, I realize that:

• I don't understand that code that I've written some time ago
• the number of cases that I need to consider exceeds by a large margin the number of things that I can hold in my head at a given time
• the code related to typing rules is too fragile
• it seems that the code contains a lot of "this will fix my immediate case" logic

That is the essential complexity that Brooks ta

Dear all,

I am a strong believer in the value generated by unit-tests. We programmers are not as great as we would like to be. We introduce subtle bugs everywhere (if not obvious ones), we make a lot of copy-paste errors, we make a lot of bad-replace errors, and we claim to understand the code much more than we actually do. Not to mention the fact that our memory is not as good as we think it is; when we don't make mistakes, we simply don't fully understand the code, even our code. Our mind is not that powerful to keep the ever-more complex code structures in our head.

You can see this even from the development of Sparrow. While trying to speed things up, I constantly ignored the testing aspect of development. And, I've often found that I've spent more time investigating subtle bugs than actually developing Sparrow features. That means, I've spent more time because of the lack of testing than I would have spent on writing unit-tests.

Another challenge that delayed my adoption

I finally finalized the blog post with the proposed design of the new Sparrow type system. It is still high-level, but I wanted to make sure we have enough understanding of the main features that the design proposes.

Here it is: http://lucteo.ro/2018/07/08/designing-Sparrow-type-system/

Any feedback is welcomed!

I'm currently focusing on redesigning the Sparrow type system. It's currently too simple. Based on the low-level analysis I've made for C++ (http://lucteo.ro/2018/06/17/beyond-the-type-system/), I'm trying to analyze the desired features of the Sparrow type system, and how we can achieve that in the simples way.

Currently, the list of goals are:

1. have proper support for immutability; if possible immutability by default
2. allow safe const reference passing for input parameters, preferably, without the user needing to type too much
3. simpler and safer rules for lifetime of objects passed as parameters
4. support move semantics
5. support forwarding pass semantics

Expected first draft: a week or two.

Any feedback is greatly appreciated.

I just merged to master the feature branch that implements the dot operator. This feature was planned a while ago, and it got pushed around for some time. It is intended to simplify the handling of some type wrappers.

The problem Imagine a simple pointer class:

package A
    
    datatype Ptr(type: Type)
        using ValueType = type

        _ptr: @ValueType

    
        fun get(this: Ptr) = _ptr

    _ptr: @ValueType

[protected]
    fun get(this: Ptr) = _ptr

[/code]

Each time the user would want to use this, the code would look something similar to:

datatype MyObj
    x: Int
fun print(this: @MyObj)
    cout << 'MyObj.print: ' << x << endl

fun test
    var o: MyObj = 0
    var p: Ptr(MyObj) = o

    p.get().x = 30
    p.get().print
    p.get print    

fun test var o: MyObj = 0 var p: Ptr(MyObj) = o

p.get().x = 30
p.get().print
p.get print    

[/code]

You can see that the extra get() is annoying.

Previously, we've implemented a hack with the -> operator. This would be implemented like a macro in Sparrow. The usage code would look like: