ze7111's comments

Hey I'm on of the devs; No, the code is not by AI: the current compiler and , corelib's code, the thought process and language design is all human, AI would produce slop in that case, however, English isn't our first language, so things like README's, Docs and such, had the following process, we wrote an initial draft, with broken English not cohesive at all - but, the content is factual, then sent it to ChatGPT to improve it, did it use buzzwords and such - yes, but at the time, with our level of English it did seem really good, looking back now it does seem really bad, but Commit messages are done using GitLens Commit Message Generator - simply because I was too lazy to write each and every commit message, Moving forward, We have already started to rewrite the README and the Docs, by hand, we will first commit that, then do a revision with AI, while maintaining the tone and formality, only improving grammar and punctuation. AI is a really good tool when it comes to improving English and communication, however I do stand with the fact code should NOT be written by AI.

Hey I'm on of the devs; We aren't upset at all, this kind of publicity shows us what everyone else really thinks, being critical is a really good thing when it comes to programing, while I do admit, Our Docs is blank and most of the README + current outdated docs are written by AI (after an initial draft by us), and things are not fully polished, we are after all collage students, critical feedback helps us learn more, get better and find ways to improve. Always being complimentary, only boasts the ego and prevents us from really improving...

After reading though everything we've seen posted on here and reddit there's a couple things that keep coming up consistently: AMT - devs want to know more about it Vial - devs want to know more about it Helix the name - everyone thinks it overlaps with the Helix Editor Readme - Looks to generic, Afterall it was put through ChatGPT to make it have good English after a draft... Docs - Outdated and Missing Helix the logo - its too similar to the Helix Editor Our Feature set - devs think its too good to be true. Linux Support - devs think not testing Linux is a dealbreaker.

Addressing the issues: Linux - Issue is we need word and Microsoft apps for college, hence the use of Windows and MacOS, but starting now We will set up WSL to test for Linux as well. AMT - We will add a section in our docs explaining it much more in detail! Vial - Also add a section in the docs explaining it much more in detail! Helix the name - We've kept the name for over a year now, and yes Helix editor has been around longer; We will consider another name, but for the time being we will add a disclaimer. Helix the logo - We will redesign the logo to be truly unique, might take a few weeks but we will change it. Readme - We will rewrite the readme from scratch, would use AI after an initial draft but make the content not seem like trying to market the language instead show the raw technical aspects without buzz words and stuff like that. Docs - Started to rewrite the docs from scratch same thing as the Readme, will post a commit without any AI modifications first. Our Feature set - while it does seem far fetched, we have written down all of our features in MD files (internally) that outline the exact processes that we need to follow, along with the thesis and theory of them, Everything is planed out fully, we just have to implement, while saying this is easier said then done, our goal is to try to make all of the features happen, maybe a year or two down the line it should be complete (or at least a working alpha).

Thank you so much! for all the compliments and criticism, These comments do mean a, lot to us and our team we are all college students, trying really hard to get this working, our coding ability should allow us to make Helix a reality, we are trying to get better at the other aspects, such as marketing, communicating with other devs, listening to feedback, and continuously improving...

It depends on the context of the code, its after the optimization pass but before emission of LLVM IR, But in most cases it shouldn't be super expensive, the conversion itself happens at compile time, but the usage is at run-time, it can be turned off entirely, but we need testing to see the actual performance implications. Right now the AMT is written down in an internal MD document, we've figured out the whole theory bit, the implantation comes after we written the error-handler (for compiler side error messages), lexer, pre-processor, parser, symbol table, Optimizer passes, Borrow Checking IR (haven't decided a proper name on it yet for now its just BCIR), and then the AMT, followed by the Emitters. Then the rest of the features follow suite. but we will test each stage individually once their complete and have a proper dataset of numbers to see performance memory usage and other metrics, with proper real world cases (it very well may be slower or not, we don't know yet in theory, there's no immense performance implications at runtime other then a a couple ...ns extra).

Hey, I'm one of the dev's; We thought about this ALOT like 4 hour long arguments, we asked a lot of our friends and its was really mixed, some people hated the python style ternary, others loved it, we weren't sure what to choose but the numbers were 38.5% for `<expr> if <cond> else <expr>, 27.25% for `<cond> ? <expr> : <expr>`, and 34.25% for `if <cond> { <expr> } else { <expr }` we did also look at a few other styles like: `if <cond>: <expr> else: <expr>`, but we decided that the python style is the best for a simple reason, its easier for new dev's who want to come into systems programing or writing low level code. If a lot of people do really hate it, we can swap it out before an alpha it would be a really simple AST node parser change...

Hey, I'm one of the dev's; I do definitely agree with you, while bootstrapping isn't always the best idea and it does take forever, we are doing it for a really simple reason, the project was initially a passion project by me, and then A few friends wanted to jump-in as well and make it a fully fledged thing, so we thought it would be a good idea for me to get the bootstrap compiler completed before moving on to the main compiler, So my bootstrap compiler right now works, its not the best tho riddled with bugs and problems; but its enough to write a compiler with. As to the taper off, We all are working summer internships right now, so the development is definitely slowed down a little, but, we are working on it, albeit slowly for the time-being, but the bootstrap endeavor, isn't causing a stop but rather a slow down also paired with the summer internship, it will pick up back to speed once college starts in Fall...

Our timeline for a early working alpha with the bootstrap is Q1 2026 (or Q2) but no later.

P.S A reason why only I mainly wrote the initial compiler, and also we decided to make a new compiler is since this was a passion project, the code wasn't maintainable AT ALL, I didn't plan on anyone else working on it, the code is really bug prone C++, a lot of lines of code that make 0 sense, and no structure in the codebase. The new compiler however, we are properly structuring it, documenting it, following code guidelines, and working on it as a team as opposed to 1 man writing all the code and the rest of the team only stating ideas.

Hey, I'm one of the dev's; English isn't any of our first language, The Code is all human written (at least the bootstrap compiler is mostly by me), but the documentation README, and parts like commit messages and such are written by ChatGPT or GitLens's AI Commit Message Generator. But on another note the docs are quite outdated, We only posted on reddit to get an opinion, didn't except it to reach other places as well... But we are now working on rewriting the docs completely. Without AI initially but then with AI to make the English better, If anyone notices any weird things in there, please either do a PR or let us know to change it...

But also yes passing a null value into a non-questionable would lead to NPE however if the type has a questionable operator then that function would be used (like for strings, a questionable null string type is just a blank string, in which case using it with or without questionable doesn't make a difference).