OWL (ow-lang), aka Owl's <insert-w-word> language (IPA: /wɜːldz/ /bɛst/ /ˈprəʊɡræmɪŋ/ /ˈlæŋɡwɪʤ/) is an opinionated language dedicated to making it easy to create high quality and polished user facing software. How will it do this? I don't have a clue as of yet, I have quite a few ideas, but I'm still in the design phase.

Suggestions and ideas are appreciated, but I can be quite opinionated in what I'll want to do.

A lot of these design principles will likely be quite different from what a language ends up focusing on, especially focusing on since the start, however I believe that following these principles is what will result in a good language for making user facing applications.

(The following list is not in any particular order).

The language should support custom static analysis as a first class feature. As the language and the standard library them self will make heavy use of static analysis, it should offer the same to the users of the language. This will also mean that the language/standard library can reuse the same system, in order to avoid bogging down the compiler with a lot of exceptions for special cases.

One of the primary reasons why I want to do this, is because I believe there are a lot of cases where the language and the standard library get a lot special privileges that are not then offered to the users, while still also having a lot of cases where a need of the user can only be met by forcing a lot of type safety. And this often leads to the point where it ends up looking and feeling unusual, forcing the user of the language/library to have to majorly change how they think in order to adapt to a library that was only designed in such a way, because it had to cope with the safety limitations of the language.

Whenever possible, the language, and its tooling, should not have to rely on external/system libraries/programs, and should instead make a best effort to ensure that they can be created and maintained "in-house" in order to: avoid heavy/bloated dependencies; reduce the complexity needed to use OWL and its tooling; and to reduce the installation complexity/requirements for the end user.

This does not mean that everything will be done in-house, however when possible the project should avoid turning into a dependency hell.

This language's primary aim is to make it easy to create UI applications. This will include focusing on GUIs, TUIs, CLIs, eventually mobile apps, and maybe (BIG maybe), web apps.

In the far, far, far, far, far, far, far, far, far away future this might, possibly, just maybe, potentially, have a chance of, also including support for embedded devices (no promises) where the focus is on user interaction.

The language should be designed to be maintainable, this will primarily mean that it should focus on readability and clarity, but also on how easy it is to refactor and modify existing code, since not everything can be achieved purely through refactoring tools.

It should also place a high priority on generating clear and actually helpful error messages and stack traces (and anything else that I deem useful) to aid with fixing bugs (which lets be real, will always happen in one way or another).

Since this language is meant for user facing applications, this means that responsiveness (commonly called perceived performance) is valued over true performance (for example: throughput).

This DOES NOT mean that performance will be neglected, or achieved by leveraging other languages. However, if a significant amount of responsiveness can be achieved by sacrificing some throughput, then that trade-off will likely be made.

When the developer wants to, they should be able to focus on the logic of their application, rather than on the semantics of the language, when the compiler is able to intelligently determine them.

For example, this means that if the developer doesn't care about integer / decimal type sizes, or text encoding, or async features in the code they are currently working on, then they won't have think about it.

The language should be designed in a way that encourages the developer to leave things up to the compiler, and allows the compiler to appropriately make those decisions when the developer isn't interested in them.

(Because in majority of the places, and in most applications, those things will really not matter).

When using UI/app frameworks, there are quite often a lot of commonly used patterns that end up being implemented in various ways through libraries. For example: MVVM, CQRS, and the mediator pattern. However, from what I've seen that also ends up being accompanied with quite a bit of boilerplate that then has to be worked around.

So I believe that a lot of these systems (I have not yet decided which ones) should be supported directly by the language and the compiler, instead of leaving it up to libraries which are forced to work with the constraints of a language that may not have the tools to appropriately fix these issues in a simple way.

Eventually I want OWL (and the supporting OwlDomain projects) to become a complete toolkit for making applications, as such a lot of the tooling will be considered straight from the start, instead of being left as an after thought, or being deferred to 3rd parties.

Not all the features that I have in mind will be listed here, as quite a few of them are experimental ideas that I have, but they will be documented properly when they're actually implemented. This also goes for the features that are already listed, but aren't quite fleshed out yet.

(The following list is not in any particular order).

Eventually the language should be a part of an official "kitchen-sink" ecosystem that will include everything needed to fill the needs of the majority of applications, instead of forcing the developer to scavenge for 3rd party libraries, or forcing them to make those dependencies by them self. Or having to merge two clashing libraries together when they need both of their functionalities.

OWL will include several frameworks in order to support different types of applications, the currently planned ones are GUIs, TUIs, and CLIs. These are the ones that I will 100% want to include and support.

OWL will have first class support for testing.

At the start, there should be a unit testing framework that can provide testing support for simple use cases, as long as collecting code coverage statistics.

The testing framework should also provide scaffolding for common testing scenarios, such as when testing equality, inequality, and comparison functions.

The language will be designed with specific features in mind to make testing them easier, such as encouraging injectable abstractions, and automatic mocking support.

Benchmarking and profiling can be a difficult thing to get right, there are a lot of pitfalls with it, and it's easy to get the wrong conclusions, or profile things in the wrong way.

To learn more about profiling things correctly, I recommend watching the "Performance Matters" talk by Emery Berger.

The plan is for OWL to eventually have a benchmarking framework, a typical flame-graph profiler, and a causal profiler.

I'm not quite sure what to call this feature actually hence the weird name for now, but the idea is that you'll be able to write a simple script that will be followed in order to create a screenshot or a video of your application, in order to help ensure that your guides and tutorials are up to date with the recent changes to your software.

This will also have the extra benefit of warning you if your app changes enough that the script no longer works without you modifying it, essentially telling you that your guide is likely out-of-date and needs updating.

From my experience, local apps have a big problem when it comes to persisting data. A lot of the time this is left up to the developers to figure out, and doing it properly is sadly not that simple, so a lot of developers end up taking shortcuts, which will typically either make things more annoying for the developers them self, or it'll introduce extra limitations for the users.

An example of this is when an app creates a local file store for its data, but then it doesn't implement error recovery, which can result in corrupted data. Or when it doesn't implement any locking mechanism, and then the developers decide to mitigate (and not solve) the issue by only allowing you to have one instance of the application running.

Right now, the current best solution for this ends up being to use a local database, most likely something like SQLite (as I'm not actually aware of any other widely used local database).

Sadly however, SQLite comes with it's own - pretty significant - drawbacks, in my opinion the primary one being that it is a table based database, rather than a document one, and requires the developer to have a lot of transformations between the way the persisted data is stored, and how it's actually used in the application code.

Typical logging sucks, it's bloated, collects the wrong type of information, and makes it difficult to actually help solve bugs and draw any meaningful conclusions.

To fix this, OWL will have a bespoke logging framework that's designed to actually turn logs into something actionable, rather than something you waste a lot of storage storing, and then forgetting about or ignoring.

I want the application frameworks in OWL to support a plugin architecture in which plugins can be easily unloaded and reloaded without having to restart the application. There are some typical problems with this approach, but I want to make the language itself support it.