Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm Compiler Written in Elm

github.com

Post reply on HN
Print view View original

81–84 of 84 posts

Re: Elm Compiler Written in Elm

#81

Post by piaste »

weavie wrote: post #35
onethought wrote: post #21

Earlier quoted context omitted.

It’s quite parallel to typescript (strict) refactoring, isn’t it?

I suspect not. With Typescript even with strict typing, mutating state is still possible (I believe, correct me if I'm wrong..). This adds an extra layer of complexity to the refactoring process. With Elm, mutation is impossible - everything goes through the update loop. There are no escape hatches. This does mean you have to jump through a number of hoops to use FFI. It can be a pain at times, but does make for much…

> This does mean you have to jump through a number of hoops to use FFI.

TBH, I thought the pain of FFI in ports (the only mechanism available in Elm 0.19) was kinda overblown. Function input goes into a command, function output comes back as a message. That's just a few extra lines of standard code.

I think they become annoying if you do lots of small, synchronous, safe calls, like using a JS math library. In that case I suspect I would prefer writing a larger JS function instead of having an Elm function full of JS calls, even if I could use a more permissive unsafe FFI, because every JS invocation is still a chance at runtime errors due to type conversions (even with ports).

Re: Elm Compiler Written in Elm

#82

Post by johnkelly »

andrewzah wrote: post #78
savanaly wrote: post #68

Earlier quoted context omitted.

One's attitude towards Elm directly correlates with the degree to which one likes to dig into and tinker with the internals of their tools and frameworks and rearrange things. Unfortunately that means it's a hard sell around HN-- in a way it's antithetical to "hackers". But I don't think it's antithetical to John Carmack's proverbial "engineer"-- someone who wants to do what they can do with what they've actually got…

I don't buy this argument. I am also someone who just wants to get shit done. I've never had an issue with php, c#, ruby, crystal, go, rust, haskell, erlang etc's compilers/interpreters in terms of letting me get what I want done. Yeah, I haven't actually forked or patched those compilers but neither have they been hostile to their users. The reason I would use literally any of those except Elm is that the maintainer…

> How can I "get things done" if I'm being told "oh no, you're not allowed to do , we've decided that only us on the Elm team can do that".

I think this is common in almost any language. For example, in JavaScript there isn’t a way to turn off the garbage collector. Why are browser authors limiting us? I’m sure they have good reasons - reasons that I may not fully understand but that’s fine! Maybe this isn’t the best example but I’m sure you or someone else could think of one for me.

Anecdotally, even when lower level/advanced features are exposed, I personally haven’t had the need to reach. For example, say python allowed for custom memory management features - I’ve never had the need for them! And I’m just fine working on a large django application with thousands of concurrent users. This isn’t to say I will never need some advanced lower level feature of python, however, I haven’t needed for >5 years.

The point is, if elms feature set works well for most of its applications - what’s the problem? The creators have a vision for the constraints of the language! Which is directly related to the intended goals and benefits of the language

Re: Elm Compiler Written in Elm

#83

Post by terezasokol »

lisardman wrote: post #26
vanderZwan wrote: post #6

Earlier quoted context omitted.

I don't see how the emojis have anything to do with that section, since they're all over the readme anyway. Aside from that: what they're stating is that they "don't want to and aren't planning to divide the community into multiple Elm derivatives, and will actively try to prevent that". Not dividing the community is not the same thing as threatening the main Elm team. And for a smallish language like Elm it makes se…

To give a bit context, Elm main team has been defensive against forks. They are preventing development of features they don’t think worth to them. It’s not possible to publish packages with low-level access without Elm main team approval. The compiler even has built-in DRM about that. My point is more compilers is exactly what Elm needs to flourish. C has several compilers. Python has even”jython”. That doesn’t make…

> Elm main team has been defensive against forks

You're more than welcome to create a fork, as long as you name it something else. This is so people are not confused as to what they are getting into! :)

Post reply on HN