Earlier quoted context omitted.
It's not at 1.0, there's no promise about preserving backwards compatibility at this point.
See my reply to the other thread. 1. If it is not ready for prime time, maybe we should stop promoting it? 2. React was 0.14 up to a year or so ago. The number doesn't mean anything.
Elm for the Front End, Right Now
21–30 of 81 posts
Re: Elm for the Front End, Right Now
#22Earlier quoted context omitted.
> early stage language I keep hearing this excuse, and to be honest I don't like it. On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. > I'd say reducing weird syntax is a perfectly good reason I disagree with you on this, prohibiting the users from using the prime character has nothing to do with the language…
> On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. If I didn't know what changes we're referring to, it would sound like there was some critical change to the core functionality of the language. Instead, they're removing one weird bit of syntax. It's not an excuse that it's an early stage language - it's ackn…
No, I acknowledged early on, and many times, that it is a very minor thing. My only concern is that it is worrying for the future. (Using the word huge in the "huge red flag" was an exaggeration. I shouldn't have done so).
> 1. It confuses newbies.
Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me.
Is a language that allows Unicode characters for variable names confusing for newbies?
> 2. It's an easy character to miss.
Again, it is in my code.
> 3. It's easy to migrate away from it.
That's not an argument for removing something.
Again, my point is that is has to do with personal taste, yet Evan decided to force it to anybody who uses the language.
He could have very easily enforce it to core packages, and nobody would complain. But forcing it on my code, is worrying.
Re: Elm for the Front End, Right Now
#23From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.
In time your brain realigns, depending on how much you appreciate the functional style or not.
Re: Elm for the Front End, Right Now
#24currently a pretty nice reactive mobx-state-tree is on the frontpage of hn.
Re: Elm for the Front End, Right Now
#25Earlier quoted context omitted.
Because I really like syntax like Haskell (the type signature is much clearer especially in generic code compared to Java or Scala etc. for example), I'm curious, what is so uncomfortable about the syntax?
The lack of parentheses around function calls makes it hard for people not familiar with ML-style languages to tell where the function calls are and what the arguments are to each function call. There is a wide variety of syntax among mainstream languages, but basic function calls are pretty much all the same. Take a look at Reason [1] for an example of how a functional language (OCaml in this case) can be made more…
Re: Elm for the Front End, Right Now
#26From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.
Yeah, it seems like a step back in readability... It's not at all intuitive and once I figure out what its doing, I can't find a reason for it.. Lisps are hard to read, but there are at least a few reasons for the syntax (not that i like them) ... This just seems... weird and unusual for no reason...
Re: Elm for the Front End, Right Now
#27https://www.youtube.com/watch?v=XJ9ckqCMiKk
The first half is about Phoenix, the second about Elm. I don't know much about front-end stuff but I did like the Elm bit as an intro, especially the debugging and nice error messages part.
Re: Elm for the Front End, Right Now
#28why not flowtype/typescript+js es6+react+redux/mobx? currently a pretty nice reactive mobx-state-tree is on the frontpage of hn.
- Flow vs Typescript
- ES5 vs Babel
- React vs Angular vs Vue vs jQuery
- Webpack vs Rollup
- Redux vs Flux vs Mobx vs React states
etc...
Plus, probably lots of dev prefer Elm's syntax and design.
Re: Elm for the Front End, Right Now
#29Earlier quoted context omitted.
> On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. If I didn't know what changes we're referring to, it would sound like there was some critical change to the core functionality of the language. Instead, they're removing one weird bit of syntax. It's not an excuse that it's an early stage language - it's ackn…
> it would sound like there was some critical change to the core functionality of the language No, I acknowledged early on, and many times, that it is a very minor thing. My only concern is that it is worrying for the future. (Using the word huge in the "huge red flag" was an exaggeration. I shouldn't have done so). > 1. It confuses newbies. Remove it from core language then. Having the prime character in my code, do…
Until you take your personal style to Github, or coworkers...
Evan is doing a pretty good job at managing Elm – in fact I don't know any other language except maybe Swift where the rollout is planned to such a depth.
Re: Elm for the Front End, Right Now
#30Earlier quoted context omitted.
It's not at 1.0, there's no promise about preserving backwards compatibility at this point.
See my reply to the other thread. 1. If it is not ready for prime time, maybe we should stop promoting it? 2. React was 0.14 up to a year or so ago. The number doesn't mean anything.
Apparently, prime time came and went :)
> If it is not ready for prime time, maybe we should stop promoting it?
It's about as ready as the impression it makes: yes, you can use it for project. But you may need half an hour every few months to update.