xoofx / xoofx.github.io

Repository of my blog
https://xoofx.github.io/
7 stars 1 forks source link

Stark - Language And Frontend Compiler - Prototype 2019 #9

Open xoofx opened 4 years ago

xoofx commented 4 years ago

Comments for Stark - Language And Frontend Compiler - Prototype 2019

Noemata commented 4 years ago

Very interesting approach to bootsrapping a new language. What is the end game? A new language for Unity?

xoofx commented 4 years ago

Very interesting approach to bootsrapping a new language. What is the end game? A new language for Unity?

I can't tell from today what is going to be the end-game of all of this. But a big milestone will be to run a client Stark App + Melody OS on a Raspberry Pi connected to a deployed server Stark App + Melody OS on a Azure/Cloud. Developing a Game OS could definitely be a longer term milestone, though the development of GPU drivers would be the challenging part. Otherwise, this project is not affiliated to Unity.

hasan-hasanov commented 4 years ago

Very interesting article and project, I've really enjoyed it. I could not wait to see the outcome of all of this.

JasonBock commented 4 years ago

This is a great article and there's a lot in Stark that I find appealing. I have to admit, though, that reading this:

And for checked exceptions, the syntax is following the Java syntax.

That made me cry a bit. I've never been a fan of that.

xoofx commented 4 years ago

That made me cry a bit. I've never been a fan of that.

Hehe... annoyed by the syntax or the whole checked exception concept? Checked exceptions are developer recoverable errors (so in the end, end-user), so if they are not part of the contract, then user code will not take into account that something different could happen.

In my opinion, that was an unfortunate design decision in .NET. It certainly makes things easier (oh, no, I have this exception to manage, I don't have time to handle it, I need to ship) but it makes the code - and so the entire application, very fragile. You can certainly do a try { } catch { } with the same kind of harm, but at least in a code review you would see the trick of the lazy developer. And I don't trust myself enough as much as I can be lazy sometime! 😉

JasonBock commented 4 years ago

The checked exception concept. I never liked it when I saw it in Java, and I was very happy to not see it in .NET.

mikernet commented 4 years ago

@JasonBock Did you read the Midori Error Model link in the article that he said he based his checked exceptions off of? Midori improved hugely on the checked exception model of Java so it's not really the same thing if he is following that model.

Midori nailed a lot of things oh so right.

JasonBock commented 4 years ago

@mikernet yes, I've read about that error model, and it's a great read. Maybe I don't quite understand what Stark is doing with exceptions.

xoofx commented 4 years ago

@mikernet yes, I've read about that error model, and it's a great read. Maybe I don't quite understand what Stark is doing with exceptions.

So Stark should be very similar to what Midori did in that area (e.g they had checked exceptions)

Ultrahead commented 3 years ago

Will the compiling process optimize code like the one you posted as an example?

for(int i = 0; i < array.size; i++)