3 ms·
I don't understand how the docs say: "Non-Nullable Types by Default: In Helix, all types are non-nullable by default, significantly reducing the risk of null-p
by munificent 1y ago
I don't understand how the docs say:
"Non-Nullable Types by Default: In Helix, all types are non-nullable by default, significantly reducing the risk of null-pointer errors. Helix uses a novel approach to nullable types - Questionable Types, which allows for more explicit handling of null or panicking values."
But then when you look at questionable types, it says:
"You can use a questionable type like a regular variable. If you use it in a context where a non-questionable type is required, Helix implicitly checks its validity: If the value is valid, it proceeds. If the value is null or an error, the program stops with a crash."
Is that not exactly the same behavior that Java has?
- 90s_dev 1y agoOh hey you're the guy who made the crafting interpreters book, that was really helpful when I went through my wanting to make a langauge phase, thanks for making a great book. Also yeah seems like they reinvented null pointer crashes but with extra steps.
- evertedsphere 1y agothe docs were clearly not written by a human, so proceeding from the expectation of global coherence, or that of adherence to principles that would be implied to a human being reading this in a certain context, is likely to end up being a waste of time
- 90s_dev 1y agoWait, was this language guided by AI???
- fwip 1y agoFrom my personal judgment: definitely using AI for the code & commits, probably for the documentation, no idea about the design. For instance, no human would write this commit message, with the preformatted-code-block: https://github.com/helixlang/helix-lang/commit/4d949efd42b8dce47bc02578c6ff5c54d4144241 https://github.com/helixlang/helix-lang/commit/4d949efd42b8d...
- ze7111 1y agoHey 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.
- lostdog 1y ago"Comprehensive Error Handling: Helix's error handling system is novel to helix, it allows for either complete error handling or a more pythonic approach to error handling, this allows for more control over how errors are handled in Helix." Wow, these really do seem to be LLM written, and I would guess ChatGPT. This long README has a bunch of generic, redundant statements over and over again.
- serial_dev 1y agoIt’s a NPE, but it passed through vibe coding.
- ze7111 1y agoHey, 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).
- setopt 1y agoNot obvious what is novel either. Languages like Haskell have had alternatives like the Maybe monad for a long time.
- grncdr 1y agoI believe it’s slightly different in that I can declare a value (or parameter) of type T and know that it can’t be null/invalid. Consider this Java method: void frobnicate(bar Bar) { // is bar null? Who knows? } To get the same behavior in Helix, one would have to declare the parameter type as “Bar?”. If the parameter type is plain “Bar”, callers can still pass you a “Bar?”, but presumably you’d get an NPE at the call site and not somewhere further down the stack. I’ve never heard of this language before today and don’t have an opinion on it, but I do find the Questionable Types interesting: sort of collapsing Option and Result into one very concise notation.
- munificent 1y agoAh, I guess that's a good point. You get safety for the non-questionable types. But it seems like if you're going to have questionable types, you're better off not letting users silently treat them as if they aren't questionable and then risk crashing at runtime.
- dudeinjapan 1y agoThis is a let-down, the user expectation here is compile-time checking (not runtime NPEs)