Creating EK9 Standard Lib API

From my other blog posts, you’ll be able to see I’ve been focussed on the ‘front-end’ of the compiler for several years.

I’m now looking to start work on the Intermediate Representation and also the ‘back-end’. With this in mind I deduced that for the ‘back-end’ I’m going to need some API’s to call.

I have already defined a ‘standard library’ for EK9 in terms of its interface. This covers most of the standard classes such as String and Float for example; but also some collections like List and Dict.

So I now have the daunting task of actually providing an implementation for all of these interfaces definitions in Java (as running via the JVM will be the first implementation).

You might be thinking, why are you jumping to the end to implement the API when you’ve not even completed the IR yet? Well I’m a start at both ends and meet in the middle sort of guy. This is borne of experience. You need to spread the pain parts, by this I mean it is very easy to start in one place and make your life very easy only to find by the time you get to the end those parts are no all but impossible.

So I start at both ends and then try and meet in the middle, then if I have to I spread the pain bits in the most appropriate direction so that I can join the two halves. The IR layer is going to have to suck up some or most of any of the mismatches between the ‘front-end’ and ‘back-end’. Plus I need to make it possible to produce an LLVM version of the back-end (one day in the next decade or so).

Well how hard can it be to implement the interface?

We’ll not that hard - the mapping from EK9 semantics methods/operators to Java API calls is pretty straightforward. But there are a very large amount of constructs to do (about 80 in total). Oh yes and the unit tests to make sure they all work. If I then look at the total number of methods/operators - I’ll have to implement around about a thousand (yes 1000 methods to implement and test).

Quick example (a little snippet of the EK9 interface for String (but truncated):

...
          String as open

            String() as pure

            String() as pure
              -> arg0 as String

            trim() as pure
              <- rtn as String?
...

Now what I need is this implementation in Java. But I really need to be able to ‘introspect’ these implementations and dynamically pull out the EK9 interface.

So, I created a couple of Java annotations and a processor, so now I can just write:

...
@Ek9Class("""
    String as open""")
public class String extends BuiltinType implements Any {
  java.lang.String state = "";

  @Ek9Constructor("""
      String() as pure""")
  public String() {
    super.unSet();
  }

  @Ek9Constructor("""
      String() as pure
        -> arg0 as String""")
  public String(String arg0) {
    unSet();
    assign(arg0);
  }

  @Ek9Method("""
      trim() as pure
        <- rtn as String?""")
  public String trim() {
    if (isSet) {
      return String._of(this.state.trim());
    }
    return _new();
  }

...

Now I’ll do a bit of handwaving relating to the BuiltinType and Any types. But basically what this means is the I (or anyone) can define a Java class (using these Annotations) and the EK9 compiler can ‘extract’ the EK9 interface parts from it and use that to compile EK9 code against. It’s a bit like a ‘C’ header file - but all bound into the java class.

Ok so lets do 80 classes and over a thousand methods then

Well, while I’m a glutton for punishment - why else try and develop a new language and compiler - even I get bored.

Help, as an open source project that is still many years away from being useful, I’ve not had much help from anyone (no complaints - it’s just not useful to anyone yet - or I’m bad at promotion - probably both).

But now I have a new friend - it’s the friend I’ve always wanted - a workaholic, uncomplaining, fast typing, happy and polite developer. Ok they have their moments and are a bit ‘on the spectrum’.

Meet ClaudeCode, probably the biggest shake up in IT for several decades.

My history

I’ve been a developer for many years 40 or so. I’ve used a range of lanaguages. I can focus and ‘crack out’ large amounts of reasonable code. Over time you realise some of what you create is truely bad, some outststand and most just about acceptable. But it varies day to day and week to week.

I’ve also been an analyst, team lead, technical lead, IT solution Architect, Product Owner and done two ‘start-ups’, both with some success.

So, I know how to articulate business requirements, break those down into technical tasks and then get on and develop them. Basically from the 80’s-90’s-early 2000’s ‘progammers’ were expected to do all of this.

But, I have been very, very sceptical of AI. Tried a few things here and there. Then I saw a blog post by Kent Beck. I thought well maybe I should have another look and use this tool called Claude Code.

Well I’m really gald I did (thanks Kent). After a bit of tinkering around and ‘us’ getting to know one another, if you have a big bulky load of boiler plate code that follows a specific set of design patterns - the world is as deep as your pockets can go (Claude costs money).

But, as I finished a contract at the end of June (to do some personal stuff), I thought there’s no way I’ll get through all this code (as I can’t really spend all my time on it). But with Claude Code I can.

Let’s cut to the chase then

From 1st July until today 22nd of July; 46 thousand lines of code created. About 78 constructs created, lists of unit test cases. and 100% method code coverage, with about 95% total line coverage.

Pretty much the whole of EK9 standard library developed. I have a few more constructs to do and then revisit some of the existing ones to add in new methods.

That’s an average of 2,000 lines of code per day. But remember - this is boiler plate tedious work. I’ve done all the thinking, defined the EK9 interfaces, written thousands of line of example EK9 code (for the front-end of the compiler). Plus I know how to express what I want, and having work with lots of junior develops - I know when to say stop - you’re going in the wrong direction.

Why not get Claude to write this blog post

Well I did, it was very technical, very interesting (some of it was wrong!). But it really is like asking a junior developer to write a business case for management - it would be just too technical and miss the benefits.

In short, Claude code wrote about 65% of the code for me - one I had given two or three examples of how I wanted it developed, kept correcting it and asked it to document this new knowledge. Plus I had the wealth of effort I had previously applied to creating ek9.io and lots of EK9 code for the front-end.

So, I’ll carry on using it for the rest of the easy API code generation, then I’ll try it with the Intermediate Representation.

Summary

Yes Claude Code can help, it really can help. It’s a game changer. If you want to see the code - look in GitHub and ek9.

But, and here’s the kicker. I see the world moving back to a time when we did much more up front analysis and programmers need to become technical analysts/technical business analysts. Just knowing languages and coding will not be enough. You still need to be a savvy programmer, Claude and all these AI’s can churn out piles of stuff. You have to know how to cut it back. It will try and alter the implementation to pass the tests! Sometimes (once in a blue moon) its right. The test is correct but the implementation is defective.

So, we all still have jobs, but you’re going to have to move away from expecting detailed specs, and actually move up to working with the business to define detailed specs to get Claude (or some other AI) to code it. But you still need to be able to wade in correct the code and point that out. It’s like training a new developer in many ways.

Writing code and tests is no longer the bottleneck. Knowing what you want and knowing how to control the AI is the real need (Oh and yes having deep pockets, as you will be spending $$$ with the AI company).

Perhaps this screenshot from Github will make the productivity gain more obvious.