From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.
Yikes, you should branch out more.
Elm for the Front End, Right Now
31–40 of 81 posts
Re: Elm for the Front End, Right Now
#32why not flowtype/typescript+js es6+react+redux/mobx? currently a pretty nice reactive mobx-state-tree is on the frontpage of hn.
Typescript has types, but it's the same terrible language underneath.
Re: Elm for the Front End, Right Now
#33why not flowtype/typescript+js es6+react+redux/mobx? currently a pretty nice reactive mobx-state-tree is on the frontpage of hn.
I'm quite sure it's exactly for that reason, not having to choose between - 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.
Parent is absolutely correct.
I can either work on Elm and deal with breaking changes like variable declarations (as noted above), or work on my React/Redux app, where I'm halfway refactoring from ReactRouter v3 -> v4 and Redux Form v4 -> v6, both of which are painful upgrades. Which would you rather deal with?
Re: Elm for the Front End, Right Now
#34Earlier quoted context omitted.
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…
Or maybe people could just become familiar with ML-style languages? The basic syntax shouldn't take more than an hour or two to pick up.
Well sure, but you could say the same thing about Lisp.
Re: Elm for the Front End, Right Now
#35why not flowtype/typescript+js es6+react+redux/mobx? currently a pretty nice reactive mobx-state-tree is on the frontpage of hn.
I'm quite sure it's exactly for that reason, not having to choose between - 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.
This is exactly the reason I'm interested in Elm. My team has gone from React to React + Flux to React + Redux to React + Redux + Immutable to React + Redux + Flow in the last 2 years. That's a _lot_ of change, and we're not even talking about the build tool side of things with Browserify, Babel, Webpack etc.
In Elm I can see the same kind of framework simplicity that attracts me to Go.
Re: Elm for the Front End, Right Now
#36Earlier quoted context omitted.
I agree... I wish we still had the prime character. But since Elm isn't at 1.x status yet, that earns me an "irritated smirk" rather than a table-flip. :)
Yes, I am not saying it is a big thing. It's a small thing in itself, but breaking backwards compatibility for no good reason is huge red flag for the future.
Before you reach a 1.0, you should be able to break backward compatibility for any and no reason.
Most likely the reason is that you want to make something that you yourself are proud of or at least satisfied with.
Unless you're being paid for the project, satisfying your psychological goals should be the prime point of pre-version 1.0 software.
Re: Elm for the Front End, Right Now
#37From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.
Completely logical. Java, C, PHP are said to be algol descendants. In two words: curly braces. JS wasn't supposed to but ended up curly because social trends are that strong. Now imagine JS function being the only thing you use, then that language users and designers evolving a syntax for typed js-like functions, rince repeat, you get ML, Haskell, Elm. In time your brain realigns, depending on how much you appreciate…
Not quite. ALGOL doesn't have curly braces, just BEGIN and END blocks.
BEGIN
FILE F (KIND=REMOTE);
EBCDIC ARRAY E [0:11];
REPLACE E BY "HELLO WORLD!";
WHILE TRUE DO
BEGIN
WRITE (F, *, E);
END;
END.
Re: Elm for the Front End, Right Now
#38I wish they would stop making changes just for the shake of change. E.g. Up until 0.17 most code examples where using the prime ' character. With 0.18, Evan decided that using prime is bad taste, so he decided to break any code that uses it. Sure, it is not a big change, but it means they are not respecting user's time and it is a sign of things to come. Sorry for the rant. Edit: I hope my reply doesn't get misunders…
I actually think that's a terrible idea. `0.x`v versions are precisely the time to try and get this stuff in, before you end up locked into it forever.
Re: Elm for the Front End, Right Now
#39Earlier 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…
Yes, I agree, that took me also some time to get used to when I dabbled with Haskell and I looked at more complex programs.
Re: Elm for the Front End, Right Now
#40Earlier quoted context omitted.
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...
Have you spent much time with it? Like all things, you need to learn before you understand, and then it becomes clear.
I've written a fair amount of Elm, and I still find it awkward. One issue is that I feel like I end up having to go back and add in brackets more than I would with the C-style syntax. I'm not sure if that's just the way I think thanks to being used to that, or an inherent problem.
The main issue really is that I think it's harder to read, as it's less clear what is being used where. The explicitness of the C-style makes it easier to see what goes where.