2022 is over

2022 - The Seeds Are Sown

Well, 2022 is almost over, and while Flower did not meet its goals during 2022 it certainly has gone quite a bit forward. Like stated previously, my original goal was to be able to handle Advent of Code with the language, but I was pretty sure already in October it wouldn't happen.

Anyways, this is a bit of a overview of current state and my current ideas for the future.

So what happened December?

Nothing concrete. I changed 0 lines of code, made 0 changes to the specification, and basically took a break from the entire thing.

I looked at first day of advent of code, and quite quickly realised that I would basically need to write the programs in C and then use Flower's FFI to wrap around it.

It would've been C but worse. I saw little reason to carry on with this year's AoC with Flower.

So Is Flower dead before it began, like the precedessors of its namesake?

No. Far from it. I actually have plenty of motivation to carry on, but it'll have to wait for a bit. Real life got in the way a bit, but that's not all bad -- even for the language itself.

Refined direction for the language

I've had the questionable honour of having to deal with FORTRAN code as of late. Having taken a closer look at Julia, Python and FORTRAN I can see a niche that Flower could well fit in.

Even with the current design Flower has features that fit well with domains where currently either Julia, Python or FORTRAN are the usual choices. This is not entirely surprising, as Flower always had some ideas about how math-heavy code should be handled. But now that I've dealt with that domain again in the usual languages. I can see that there actually could be a spot for Flower there not out of "it can do the job" but from actually "it fits the job better than alternatives".

I actually think that technically C++ would be better fit than either Julia, Python or FORTRAN for scientific / simulation domain. Its problem is that learning to write decent C++ code takes way too long.

Even less surprisingly, this has somewhat upped my motivation to continue working with Flower and given me some insight on where most attention needs to be paid. In other good news, this doesn't even change the design. Just the initial focus points.

What I imagine would make Flower better than alternatives?

How I see it, the language needs to be relatively simple, after all, it's probably not all software engineers, but also scientists using it. Python probably is going to stay simpler to start than Flower, but I hope I can beat Julia. Definitely can beat FORTRAN or C++.

The language needs to encourage structure. I find Julia, Python and FORTRAN all quite lacking in this department. C++ has the necessary features, but it doesn't really encourage their use - and there are way too many tutorials and courses both online and off that outright skip reasonable structuring in favour of proven-to-be-bad practices. Flower, like Python, has metaclasses, but it also handles usual POD structures more elegantly.

The language needs to be performant. Python completely drops the ball here, as optimising python code is usually just rewriting the Python parts with more efficient languages. But Julia, FORTRAN and C++ all can be used with LLVM. That makes them all quite performant, and existing FORTRAN and C++ code has been optimised to the death. It's unlikely Flower can match that in a while, but hopefully we can get close. What I think Flower has here, is its ABI typing which, as noted before, can work as a reasonable way to handle heterogenous programming, which I see could open quite significant possibilities in performance department though. C++ seems to aim to do heterogenous programming at some point as well, so we'll keep an eye on it.

I have no idea if any of these will actually materialise, but there certainly seems to be a reason to think Flower could be useful in the domain.

New directions

So, where does this leave Flower development? Not too much actually has changed. I still need to finish base features, but the need to get working with the standard library became painfully obvious when I looked at the Advent of Code.

Unfortunately, I'll probably still be unable to work with Flower in January due to time constraints. But I guess I could set the next goal to be able to start working on the standard library in June.

Let's see if that goal will fail as well. It is quite tight (mostly since Flower has no module system currently, and I can see design & implementation of that taking easily more than a month), and I suck with setting reasonable timeframes for milestones, but there's one.

Happy New Year 2023. Hope it will be more boring than the previous years.