Earlier quoted context omitted.
lol, what did they smoke to think that's reasonable?!
It’s their language, they can do as they wish.
That doesn't make it any more reasonable.
Gren – an Elm fork
31–40 of 129 posts
Re: Gren – an Elm fork
#32It is not a fork, it started as fork to save time, but targets/focus on node and will diverge from Elm.
I don't understand. How does that make it not a fork?
I think maybe the authors are using a strange definition of "fork": if you fork a project and then take it to a different direction, making incompatible changes from upstream then it's somehow not a fork anymore. I'm not too sure though if that's the thinking. (reading from https://gren-lang.org/book/faq.html)
Seems like a fork to me.
Or maybe the thinking is that they'll rewrite it from scratch at some point which would make it not a fork from code perspective.
Re: Gren – an Elm fork
#33Re: Gren – an Elm fork
#34Earlier quoted context omitted.
Yeah sad. I appreciate the philosophy with slow careful releases and I also believe that people should be allowed to make unorthodox design choices in order to stay focused (or at least I’m not sure qualified to critique their choices). But, it seems like there’s a culture of taboo/fear/fanboyism which is clearly not healthy.
I don’t get what’s unhealthy about anything on that page. Elm’s trade offs are in plain sight. If you don’t want them, then you have plenty of warning. Frankly Elm has more of a problem with negative fanboying: people who have decided it’s not for them yet have to constantly show up to neener neener every time Elm appears on HN instead of just moving on. It’s very weird to me as someone who uses Elm daily. We get it.…
It's totally fine to run the project (or don't run) as the owner see fits and use it however one wants.
But let's not pretend the project is actively maintained and there are no bugs. That's what klabb3 alludes to.
Elm has this "this is fine" phenomenon where people like to pretend its a one-of-a-kind software that has no bugs doesn't even need a patch with bug fixes.
Re: Gren – an Elm fork
#35Earlier quoted context omitted.
I don’t get what’s unhealthy about anything on that page. Elm’s trade offs are in plain sight. If you don’t want them, then you have plenty of warning. Frankly Elm has more of a problem with negative fanboying: people who have decided it’s not for them yet have to constantly show up to neener neener every time Elm appears on HN instead of just moving on. It’s very weird to me as someone who uses Elm daily. We get it.…
It's totally fine to run the project (or don't run) as the owner see fits and use it however one wants. But let's not pretend the project is actively maintained and there are no bugs. That's what klabb3 alludes to. Elm has this "this is fine" phenomenon where people like to pretend its a one-of-a-kind software that has no bugs doesn't even need a patch with bug fixes.
Do people pretend that? Or is it just an HN circlejerk that reports it be so?
I'm a regular user of the Elm ecosystem, like the Slack/Discord, and everyone talks casually about Elm's bugs. In the #beginner channel it's just "Yeah oops that's def a known issue, but you can work around that with X."
It's just that Elm is still a good tool despite its warts, and its bugs aren't catastrophic. Presumably that's the smoking gun for your "this is fine" phenomenon: that people still use it and dare to even enjoy it despite unfixed bugs.
Re: Gren – an Elm fork
#36Earlier quoted context omitted.
For one, it's been over 2 years without an Elm release. And there are many open bugs untracked in GitHub. https://github.com/elm/compiler/issues Unrelated to your question but for those curious, here's a comparison between Gren and Elm : https://gren-lang.org/book/faq.html#what-are-the-differences...
> No GLSL syntax. What does this mean? I know what GLSL is but I don't understand what Elm or Gren have to do with it.
Elm has a special syntax construct (similar to a Haskell quasiquote) to embed GLSL code into Elm files, and typechecking it as well.
I imagins this is useful when writing shaders for WebGL apps that are written in Elm. I don't know why Gren removed them, though.
Re: Gren – an Elm fork
#37Earlier quoted context omitted.
I mean the last commit for Elm core was in 2021. Changes require sign off that doesn’t seem likely from who is currently maintaining it. Why not fork it if you are interested in evolving ELM?
So elm is abandoned or there's more to this story?
You'll see people arguing that it's not, but I'll let you be the judge.
https://github.com/elm/compiler/pulse/monthly
https://github.com/elm/core/pulse/monthly
Re: Gren – an Elm fork
#38Obligatory https://iselmdead.info/
> Why is it a good thing that Elm doesn’t get frequent updates? First of all, it means your code will last a long time!
Stockholm Syndrome at work
Re: Gren – an Elm fork
#39Earlier quoted context omitted.
Yeah sad. I appreciate the philosophy with slow careful releases and I also believe that people should be allowed to make unorthodox design choices in order to stay focused (or at least I’m not sure qualified to critique their choices). But, it seems like there’s a culture of taboo/fear/fanboyism which is clearly not healthy.
I don’t get what’s unhealthy about anything on that page. Elm’s trade offs are in plain sight. If you don’t want them, then you have plenty of warning. Frankly Elm has more of a problem with negative fanboying: people who have decided it’s not for them yet have to constantly show up to neener neener every time Elm appears on HN instead of just moving on. It’s very weird to me as someone who uses Elm daily. We get it.…
> While the language doesn’t get frequent updates (and that’s a good thing!)
This is the part that bugs me. It confuses frequent changes with frequent updates.
A language that changes frequently is a PITA to use, and it's good for a language to find a place of stability to where there aren't breaking changes every year. However, if I'm going to use a language in production, I expect it to not go 4 years without a bugfix update. It's not like Elm doesn't have any bugs to fix [0].
I'm a PL hobbyist and don't have any problem with someone having a hobby language that they eventually abandon—I've abandoned plenty myself. I don't even have a problem with someone deciding that they're comfortable with the risk of using someone's abandoned hobby project. It's just weird to see people seriously trying to argue that a 4-year break between releases is totally normal and all according to some master plan.
[0] 290 issues and counting: https://github.com/elm/compiler/issues
Re: Gren – an Elm fork
#40Why is Elm getting forked?
For one, it's been over 2 years without an Elm release. And there are many open bugs untracked in GitHub. https://github.com/elm/compiler/issues Unrelated to your question but for those curious, here's a comparison between Gren and Elm : https://gren-lang.org/book/faq.html#what-are-the-differences...
One boring and banal problem I ran in to was that it will output text in yellow and some other colours which are hard to read on my white terminal background, and this is hard-coded and you can't disable colours (doesn't even disable with isatty). IIRC Evan didn't really want to fix it because "just use a dark background then".
This is basically why I never used elm: because the compiler is hard to use as I struggle reading its output.
(Before anyone comments "why don't you change yellow in your terminal": then this will break applications such as pamix which hard-code to a black background and use yellow text on that, or applications which have a black statusbar or the like with yellow text on it – it's not so easy to choose colours that work in all scenarios and all things considered sticking to the default set is the "least broken" since almost everything has an option to just disable colours).