Elm for the Front End, Right Now(bendyworks.com) |
Elm for the Front End, Right Now(bendyworks.com) |
Has anyone had some positive experiences with prototyping / rapid design iteration with Elm and can share some tips / encouragement?
I think two things are require for to solve this:
1. Some way to make it easy to drop in components into an existing view. Global state makes this hard, but it may be possible with some of Haskell's funky features, or even just type classes.
2. With the above we just need people to write some basic controls for Elm and give them more features. We need an ecosystem.
I totally understand that DOM access is a pain point for Elm developers right now. I often run into that issue myself. But declaring a port is a small price to pay for the all that the Elm compiler gives you. When I have to refactor a React/Redux app, I absolutely dread it. With Elm, I love it, even if the project is older or unfamiliar.
If we have to use JS via ports (and it has to be asynchronous! dang) to achieve complex things anyway, why not use typescript, which can do absolutely everything you need without the language context and async switch?
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 misunderstood. I love Elm and use it in all my side projects. I think it made wonders for introducing new people to the ML world.
Edit2: Sorry, didn't meant to make so much fuss about it. It is indeed a small thing.
Which is why for now I'm looking into Purescript and GHCJS which support features such as Rank N types, generics, typeclasses, functional dependencies/type families. Even though I don't use many of those features directly, I do benefit from libraries that depend on them.
https://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.
https://rawgit.com/krausest/js-framework-benchmark/master/we...
https://github.com/krausest/js-framework-benchmark/blob/mast...
http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Htm...
If I'm not mistaken this wasn't possible in Elm back then, and felt uncomfortable or even hard in ClojureScript. Has that changed?
To be fair if I started a new project like the one I'm working at now I'd much rather use server + template for most pages and add interactivity through JS once it boots up.
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.
In Elm I can see the same kind of framework simplicity that attracts me to Go.
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?
In time your brain realigns, depending on how much you appreciate the functional style or not.
BEGIN
FILE F (KIND=REMOTE);
EBCDIC ARRAY E [0:11];
REPLACE E BY "HELLO WORLD!";
WHILE TRUE DO
BEGIN
WRITE (F, *, E);
END;
END.
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 familiar.
Foe example types in Ocaml usually start with lower letter.
Also Elm has "Maybe", just like Haskell, instead of "option" of Ocaml.
Also in Elm, like in Haskell you would write "List Sometype", while in Ocaml it is "sometype list".
An example is a calendar control, in a grid control in a tab. You click right to go to the next month. That event needs to be bubbled through layers of boilerplate code to direct it back to the calendar's view.
Also another consequence is that the model is a mix of business data and UI state data. The selected month shouldn't affect the business logic, but it is bundled with THAT data which is annoying.
Not sure what the solutions are though.
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.
C has braces to introduce a new scope. The irony is that JS (until recently) didn't have block scope. It just has braces :-).
Now this is where it gets screwy. You are supposed to (but don't have to usually) add a semi-colon on the end of each statement in Javascript.
a = 52;
This has a semi colon because it is a statement. There is another construct called an expression. An expression is anything that can evaluate to a value. An statement can be an expression (the statement "a = 52;" is an example of that because it also evaluates to 52 and is thus an expression). But there are expressions that are not statements. Here is an example of an expression
(5 * 27)
It evaluates to a value, but doesn't do anything so it is not a statement. Usually in computer languages, if "statements" are actually expressions. So you can say
if (1>0) {"Yay"} else {"Boo"}
evaluates to a value ("Yay" in this case), but doesn't do anything in and of itself. The blocks in the braces may contain statements, but the if is an expression, not a statement. Note the lack of semi-colon. Again, presumably because it is an expression, not a statement.
You can try the above in Node and it will indeed return the value "Yay".
a = if(1>0) {"Yay"} else {"Nay"};
In this case the variable a should be assigned the value "Yay", because the if expression evaluates to a "Yay". For some strange reason (that I don't understand), Javascript (or at least Node, when I tried it) does not accept that. It gives you a syntax error. You can not use if "statements" as expressions in Javascript (which sucks quite a bit).
All of this to say that Javascript appears broken to me, no matter what geneology you assign to it :-D. I personally really like programming in JS (or actually CS), but it is a beast unto itself, I think.
I'd welcome comments illuminating this issue if I've made a mistake with the above! As I said, it's easy to do.
It does indeed, and it leads to some ugly code:
a = function() { if(1>0) { return "Yay" } else { return "Nay" } }()
a = 1 > 0 ? "Yay" : "Nay"
I'd say reducing weird syntax is a perfectly good reason. How is doing this while offering an easy migration solution in an early stage language a "huge red flag"?
There's a very good example in C++ of how this causes problems, where vector::clear and vector::empty are much too easy to confuse (which one of them deletes all elements, and which one of them checks if a vector is empty?). Replacing them with clear! and empty? (or is it clear? and empty!) would be a huge improvement. Whenever a language moves away from arbitrary legacy restrictions, that's a good thing.
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's syntax.
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 acknowledging reality. And an upside to that reality is that making these types of changes won't upset nearly as many people as it would if it were a more mature language.
> I disagree with you on this, for me it is very worrying.
You're not explaining why. Here (https://github.com/elm-lang/elm-plans/issues/4) are three good arguments for removing it:
1. It confuses newbies.
2. It's an easy character to miss.
3. It's easy to migrate away from it.
What are your arguments for keeping it besides the fact it's already there?
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.
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.
Some of the algorithms for reducing lambda expressions are symbolic, like, say, alpha reduction. But they are not done in lambda calculus itself, as far as I can see; they are done on lambda calculus (by the mathematician, or a machine for manipulating lambda calculus terms).
Analogy: just like ordinary algebra doesn't have symbols; but of course mathematicians work with symbols and so do computer algebra systems.
Since lambda calculus is Turing complete, it can of course represent lambda calculus manipulation (via Goedel numbering of lambda terms and then working with their arithmetic encoding as Church numerals, or whatever).
:D. Pun was not intended!
Edit: Plus, then you don't have to wonder if that particular function follows that naming convention; prime meaning strict isn't nearly as universally followed as ? or ! in Scheme, for instance.
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.
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.
The creators see it appropriate to enforce their strange preferences with dubious reasoning. The enforcement (in standard Elm format) of a 4-sized tab[1] is just another example.
Like you said I'd not have the language community enforce what is acceptable down my throat, and that conflict of preferences within a team is best solved by making style guidelines instead of having the language community spoon-feed an authoritarian preference.