# The Quest for a New Favorite Language

###### Aug 4, 2023

So last time I made a post, I discussed ways that working with Elm made me want to change how Python worked with little tricks to enforce types strictly.

This was great, but a few things really emerged from that:

- I could just use mypy and try to have that strictly enforce types.
- By creating functionality to enforce types in the code, I'm now creating chances for errors that I have to catch during runtime.
- I was attempting to turn Python into a language that was very much _not_ like Python.

So what do I do next? I can keep creating little bits to keep enforcing types in Python, but that's not the point of Python by design. I'm very familiar with Python's syntax, libraries and quirks, but would picking up a different, stricter language be a good option?

But, Elm _has definitely_ changed how I prefer languages to behave.

Having confidence in types, even to where the compiler **just knows** the types you're taking into a function and returning from a function, recognizing where something may go astray, and alerting you of nearly everything creates this peace of mind. The compiler substantially cuts down on runtime errors which means less cases where weird bugs and things come up (granted, there will always be edge-cases, especially when user inputs and external APIs/JSON are involved). Monadic types are weird, but I fully welcome them now.

So where do I go from here? I wanted more reliability for projects of **ALL** scopes, and not just with some "magic" that just gets built in. As much as I do enjoy Elm, the entire view/update/Msg system and init system works on some magic built into the compiler.

I debated what language I wanted to take on. I'm still going to use Python for various things, but I made the choice that I wanted to move my main language to something else.

I'm considering Java. It's good with types, very wordy with it's syntax, but there's still a lot of error handling to be had. Also: Braces (ew.)

I'm considering Kotlin. It's almost like a weird hybrid between Java and Python. Everything else is almost like Java.

I'm considering Typescript and Purescript. One of the immediate dissuasions was the trans-pilation to Javascript, which puts Purescript specifically in a similar boat to just using Elm. However, it seems backends for Purescript exist to transpile to C++ or Go and compile a binary from there. At that point, it almost feels like I should just go for Haskell.

I'm considering Haskell. I like the functional style of Elm, and apparently it's common for Elm-people to attempt to learn Haskell. However Haskell is a bit of an enigma to me. Lots of symbols for infix-functions (sometimes even ones specific to libraries). Also a cacophony of unqualified imports leading to functions and types that come from who-knows-where (unless you clone and heavily inspect it). Pragmas to just _change how the compiler works_. And for some reason my IDE's seem constantly confused by supposedly-valid syntax. It's not impossible to learn it, but it's definitely a bit daunting. Maybe I'm just looking at the wrong examples.

I'm considering Roc ([https://www.roc-lang.org/](https://www.roc-lang.org/)), which is currently in the works but seems pretty neat. Also in that functional-style like Elm, but seems like **much** less of the mystery that is Haskell.

I even briefly considered diving into Rust. I then decided I don't hate myself _THAT_ much. But then I also remembered I'm also considering Haskell, so who honestly knows at this point.

Lastly, I'm considering..... A currently non-existent language. Yes, I'm even considering creating _my own language_ to try and get what I'm looking for exactly. A language which is oddly, a mix of mostly everything above. Some inspiration from Python. Some from Elm. Some from Java, and Kotlin, etc.

The result in my head looks like if basic YAML syntax became a _very_ type strict scripting language, that could be checked and ran without compilation, or checked and compiled to a binary. Monadic types. Explicit names. Less symbols. Easy to understand. Something that looks like this:

```
ref ExampleFile:
# Other options above can be
# "main :"
# or "ext :"
# The former is for the main execution point in projects.
# The latter is for creating exportable public libraries.
# "ref" is just a generic local file
# to be imported into something else.
    import from file:
        # All of these will be accessible by file.
        read
        write
        touch
    import from term as t:
        # All of these will be accessible by t.
        std_in
        std_out
        std_err
    export:
        # These will be accessible if ExampleFile is imported into another file.
        test_func
        life

# Things can be written inline...
var this:  = "A String!"

# ...or on separate lines with indentation.
const life:
     = 42

# Create a var without a value
var that:
    

# And assign later. But MUST be the type declared.
that = 0f24.82

# Maybe an odd choice, but I'm giving decimal types
# the default on typical xx.yy numeric notation.
# Classic floats can still be used
# with (maybe) a new 0fxx.yy notation?
# Should prevent dumb -but completely logical- accidents like
# 0.1 + 0.2 != 0.3
# 0.1 + 0.2 == 0.30000000000000004

const logic:
     = True xor False
    # Yay xor

func test_func:
    args:
        # arguments to be passed in
        arg_a: 
        arg_b: 
        # arg_b can be a string or an integer
    returns:
        
        # For you Monadic people: Maybe Int

    doc:
        "I'm a markdown-able docstring!"

    def:
        t.std_out(arg_a)
        match type(arg_b):
            Str:
                return Null
            Int:
                return (NotNull arg_b)

# Unsure if I want to change syntax/semantics
# and whatever in the future.
# Also, there's more that isn't displayed here,
# like classes, enums, data models, piping,
# public/private methods, scaffolding, etc.
```

But now all that means is I have to learn tools to lex/parse/compile/evaluate a language that doesn't exist yet **and** make it handle bugs and errors (and actual code, hopefully) reliably **and** maintain it and improve it when it's all done.

To which, all of this feels like the beginning of a weird journey to becoming a goat farmer. For those who may not know, here's a lovely meme from the music production world (no idea where the origin is from):

> I thought using loops was cheating, so I programmed my own using samples.
>
> I then thought using samples was cheating, so I recorded real drums.
>
> I then thought that programming it was cheating, so I learned to play drums for real.
>
> I then thought using bought drums was cheating, so I learned to make my own.
>
> I then thought using premade skins was cheating, so I killed a goat and skinned it.
>
> I then thought that that was cheating too, so I grew my own goat from a baby goat.
>
> I also think that is cheating, but I’m not sure where to go from here.
>
> I haven’t made any music lately, what with the goat farming and all.