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

Elm for the Front End, Right Now

bendyworks.com

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Elm for the Front End, Right Now

#51

Post by kazinator »

skybrian wrote: post #20
redtuesday wrote: post #14

Earlier 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…

Of course, if we adjust "mainstream" so that it refers to that set of languages which have pass-by-value, strictly evaluated arguments, with no implicit currying, then your point is nearly self-evident. :)

Re: Elm for the Front End, Right Now

#52

Post by conistonwater »

thatswrong0 wrote: post #9
kinkdr wrote: post #5

Earlier quoted context omitted.

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.

> breaking backwards compatibility for no good reason 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"?

A prime as an identifier constituent is not "weird syntax". The ancient C tradition of only allowing [_[:alnum:]] characters in identifiers is pretty pointless anyway. I really wish more languages would allow question marks and exclamation marks (and everything else), the way Lisp and Scheme do (e.g., https://docs.racket-lang.org/guide/syntax-overview.html#%28p...)

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.

Re: Elm for the Front End, Right Now

#53

Post by fnovd »

mikekchar wrote: post #43
agumonkey wrote: post #41

Earlier quoted context omitted.

Wow, couldn't be more wrong. It's indeed C family (BCPL, B). Thanks a lot for the note.

Well, I wouldn't be so hard on yourself. IIRC (and I hope someone corrects me if I'm wrong), algol introduced block scoping. Whether you use BEGIN/END or {/} I think is a pretty minor point. 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 t…

>You can not use if "statements" as expressions in Javascript (which sucks quite a bit).

It does indeed, and it leads to some ugly code:

a = function() { if(1>0) { return "Yay" } else { return "Nay" } }()

Re: Elm for the Front End, Right Now

#54

Post by bbcbasic »

kcarnold wrote: post #42

I really want to like Elm. When I'm writing JS/React code, I sometimes think "this would be so much nicer in Elm!" - especially for architectural issues. But the few times I’ve actually tried doing something in it, I find that the parts of what I want to do that fit cleanly within Elm’s walls are really nice, but the parts that don’t quite fit get hard quickly. Suppose I want to do something with the DOM that doesn’t…

Similar experience. Once you get to grids and calendar controls it is a hassle with no clear path.

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.

Re: Elm for the Front End, Right Now

#55

Post by ziad-saab »

fnovd wrote: post #53
mikekchar wrote: post #43

Earlier quoted context omitted.

Well, I wouldn't be so hard on yourself. IIRC (and I hope someone corrects me if I'm wrong), algol introduced block scoping. Whether you use BEGIN/END or {/} I think is a pretty minor point. 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 t…

>You can not use if "statements" as expressions in Javascript (which sucks quite a bit). It does indeed, and it leads to some ugly code: a = function() { if(1>0) { return "Yay" } else { return "Nay" } }()

You can also write:

a = 1 > 0 ? "Yay" : "Nay"

Re: Elm for the Front End, Right Now

#56

Post by fbreduc »

kazinator wrote: post #50
eastWestMath wrote: post #46

Earlier quoted context omitted.

Well they're both the lambda calculus, Lisp just had parentheses.

Does lambda calculus have character strings, structures, exceptions, symbols, mutable variables, quoting code as data, macros and three different kinds of object equality?

it does have symbols

Re: Elm for the Front End, Right Now

#57

Post by jmcdiesel »

cnp wrote: post #26
jmcdiesel wrote: post #11

Earlier 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.

Thats kinda the point... with the vast array of languages out there, that are performant and powerful and very well established, why should anyone suffer through the learning curve? what value does the language offer to make that worth the effort?

Re: Elm for the Front End, Right Now

#58

Post by eastWestMath »

jmcdiesel wrote: post #57
cnp wrote: post #26

Earlier quoted context omitted.

Have you spent much time with it? Like all things, you need to learn before you understand, and then it becomes clear.

Thats kinda the point... with the vast array of languages out there, that are performant and powerful and very well established, why should anyone suffer through the learning curve? what value does the language offer to make that worth the effort?

Well, evaluation in these languages is more transparent. The syntax is basically the lambda calculus, so once you've actually learned the language it makes a huge difference. I'd try reading up on "referential transparency".

Re: Elm for the Front End, Right Now

#59

Post by kinkdr »

matt4077 wrote: post #30
kinkdr wrote: post #17

Earlier quoted context omitted.

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.

> prime time 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.

> Apparently, prime time came and went :)

:D. Pun was not intended!

Re: Elm for the Front End, Right Now

#60

Post by nmdanny »

I think that Elm is a fundamentally good language, being catered towards JS developers will hopefully attract more of them to FP development. However, I feel that the language is too restricted compare to other FP languages (Haskell, Purescript, even Scala), as a result you often need to write too much boilerplate and the Elm architecture doesn't seem to fit nicely for all kinds of components.

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.

Post reply on HN