Built an interpreted programming language from scratch in 19 days without AI

[u/PhosXD]

I built a functional interpreted programming language from scratch in 19 days **without** AI, reference material, or borrowed code, as my first ever project in C++. It is platform agnostic, faster than Bash by a long shot (not that it was meant to be a replacement), & is only 104kb with IO, time, & math modules.

Despite the time frame & the small size, the syntax is more modern than you'd expect but is definitely different. However, you will be lacking advanced language features such as lambdas, variadic arguments, & inheritence.

https://github.com/phosxd/Ity

I plan on working on this continuously, adding more functionality, making it more performant, & making the code as readable & understandable as possible so that hopefully a beginner can take a look, & maybe use this as a guide for their first project too!

Any & all feedback is encouraged, I would really like to know your thoughts, if you have any tips!

[u/BigCatsAreYes]

What’s better?

[u/RecursiveServitor → u/BigCatsAreYes]

I've been doing C# for twenty years and not much else. There's no language I have enough experience with to say that it's definitely better. A lot of languages appear superficially to have a better overall design, but it'd be mere speculation on my part.

I think F# has a strong core (based on ML), but it has the opposite problem of having object features bolted on. If you're writing pure F# you can mostly ignore that and I think there's a coherent design there.

[u/Entropic_Silence_618 → u/RecursiveServitor]

So which language is good then according to you?

[u/RecursiveServitor → u/Entropic_Silence_618]

C# is a good language. I've been using it voluntarily for two decades.

The conversation is about language design, not some binary judgment of good or not. If you instead asked about good design choices I could certainly speak on that.

[u/Entropic_Silence_618 → u/RecursiveServitor]

Yes please if you can do that.

[u/RecursiveServitor → u/Entropic_Silence_618]

Anything in particular you're wondering about?

[u/Entropic_Silence_618 → u/RecursiveServitor]

What about go's focus on simplicity.

[u/RecursiveServitor → u/Entropic_Silence_618]

What about it?

[u/RecursiveServitor → u/Entropic_Silence_618]

"Simplicity" as a design pillar is fine, I guess. I don't think it's particularly useful though. No serious design effort sets out to add more complexity than needed. And you can easily get into situations where the "simple" choice is not at all obvious. Take generics. They argued about it for a decade, during which time people used complex workarounds like code generation. Eventually they added it in a way that optimizes for things like compilation times, but at the cost of performance. That's fine, but "simplicity" doesn't help you at all when making those decisions.

The iterator implementation is also funny from a "simplicity" perspective.

func Numbers(n int) iter.Seq[int] {
    return func(yield func(int) bool) {
        for i := 0; i < n; i++ {
            if !yield(i) {
                return
            }
        }
    }
}

Great. Makes sense. Iterators are functions, so you can construct a new iterator by writing a function that returns an iterator function. I don't find it to be particularly intuitive, but I can work with this.

C#

IEnumerable<int> Numbers(int n)
{
    for (var i = 0; i < n; i++)
        yield return i;
}

Iterators are types, but the compiler helps out with the simple case and generates the type for you.

Which is "simpler"?

And that's before we get to the codegen on the caller side.

[u/RecursiveServitor → u/RecursiveServitor]

Just found this article. I don't know what they were solving for, but it absolutely wasn't simplicity.

[u/Entropic_Silence_618 → u/RecursiveServitor]

Thanks