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

Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

dailydrip.com

Post reply on HN
Print view View original

61–70 of 76 posts

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#61

Post by inopinatus »

griffinmichl wrote: post #60
ModernMech wrote: post #18

How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…

The JS community has been pretty good about taking ideas from Elm. Redux is an insanely popular JS library that is basically a replica of the Elm architecture (though, having used both extensively, redux doesn't come close to the beautiful simplicity of Elm). As far as why people don't just use Elm, I think it's the same reason functional language are less popular in general: fewer familiar engineers and steep learni…

Yeah, I had mentally tagged Elm as "interesting language that future browser languages/frameworks might claim as an inspiration".

But, I thought the same about Coffeescript. And then Rails gave it massive traction. I wonder if the same might happen to Elm, should Phoenix adopt it as their browser language of choice. That might also offset concerns about Elm's fledgling status and key man risk.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#62

Post by qaq »

rdtsc wrote: post #50
geonnave wrote: post #49

Earlier quoted context omitted.

Actually, variables in Elixir can be re-binded : > x = [1, 2, 3] > x = 2 # the structure [1, 2, 3] still exists in memory, but now the variable x is bound to the value 2 All data is still immutable, the BEAM itself requires so. Dave Thomas explains this in its "Programming Elixir" book.

> the structure [1, 2, 3] still exists in memory, but now the variable x is bound to the value 2 I wasn't talking about data, I was talking about variables. Yeah you just called it "re-binded". I called it "changed" or "mutated". You have a function, and you see x=1 first and print its value. You'd see "1". Then you can have x=2 maybe a few lines or pages below, print it, you get "2". Variable x has changed its value…

It's not mutated or changed it points to a totally different memory location. It's called immutable data not immutable identifiers. Immutable data is what eliminates a large number of potential bugs. Having a ton of intermediate variable names could actually be a source of bugs plus you have to care if someone reuses the name above the point in code you used it. By allowing rebinding you only care about the code below the place your introduced a variable.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#63

Post by rdtsc »

qaq wrote: post #62
rdtsc wrote: post #50

Earlier quoted context omitted.

> the structure [1, 2, 3] still exists in memory, but now the variable x is bound to the value 2 I wasn't talking about data, I was talking about variables. Yeah you just called it "re-binded". I called it "changed" or "mutated". You have a function, and you see x=1 first and print its value. You'd see "1". Then you can have x=2 maybe a few lines or pages below, print it, you get "2". Variable x has changed its value…

It's not mutated or changed it points to a totally different memory location. It's called immutable data not immutable identifiers. Immutable data is what eliminates a large number of potential bugs. Having a ton of intermediate variable names could actually be a source of bugs plus you have to care if someone reuses the name above the point in code you used it. By allowing rebinding you only care about the code belo…

> It's called immutable data not immutable identifiers.

immutable/mutable data and immutable/mutable identifiers are two different things. One is not called the other, they are separate things really.

> It's not mutated or changed it points to a totally different memory location

So you said it yourself. It points to a different memory location. So how is x not mutated then? "Mutated" is a synonym for "change", or so I thought apparently.

I don't see how one can look at a variable being reassigned and say "nope, variable didn't change", where it clearly has a new value in the line below.

> Immutable data is what eliminates a large number of potential bugs.

Agreed. Was using Erlang for many years and tried Haskell before. Immutable data is pretty nice most of the time.

> care if someone reuses the name above the point in code you used it.

Wait, is it the opposite of what you were trying to say? Wouldn't you want to care if you are now randomly re-using or changing variables someone else assigned. I thought immutability was a good thing.

> By allowing rebinding you only care about the code below the place your introduced a variable.

Unfortunately in my code base, the code above the place where variables are introduced is just as mission critical as the code after the place. Maybe I am using a strange coding style or paradigm ;-)

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#64

Post by efficax »

bbcbasic wrote: post #52
shados wrote: post #47

Earlier quoted context omitted.

PureScript is a good example. The problem isn't that it doesn't work. It's that what you do with ports only work in the context of your application. The JavaScript part has to be defined somewhere else, the Elm code assumes the JavaScript part will be there. You can't redistribute that easily. How to make it better? that's easy. IT ALREADY EXISTS and is part of Elm. It's just a private API. But it totally does work.…

> How to make it better? that's easy. IT ALREADY EXISTS and is part of Elm. It's just a private API. But it totally does work. It's how the native wrappers are written. You mean like this: https://github.com/mcapodici/capodicis-notes/blob/master/elm... That is an example where I connected chrome extension storage functionality using native wrappers. This is the Elm wrapping for it: https://github.com/mcapodici/capodi…

The Native interop changed with core >= 4.0, so that relatively straightforward way of accessing native js no longer works, and the new Native is (deliberately, I believe) undocumented.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#65

Post by qaq »

rdtsc wrote: post #63
qaq wrote: post #62

Earlier quoted context omitted.

It's not mutated or changed it points to a totally different memory location. It's called immutable data not immutable identifiers. Immutable data is what eliminates a large number of potential bugs. Having a ton of intermediate variable names could actually be a source of bugs plus you have to care if someone reuses the name above the point in code you used it. By allowing rebinding you only care about the code belo…

> It's called immutable data not immutable identifiers. immutable/mutable data and immutable/mutable identifiers are two different things. One is not called the other, they are separate things really. > It's not mutated or changed it points to a totally different memory location So you said it yourself. It points to a different memory location. So how is x not mutated then? "Mutated" is a synonym for "change", or so…

I obviously phrased it poorly as not to copy too much text the post by Jose Valim on the topic: http://blog.plataformatec.com.br/2016/01/comparing-elixir-an...

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#66

Post by ccapndave »

ModernMech wrote: post #18

How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…

You take that back! I've been using it professionally for about 6 months.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#67

Post by qohen »

inopinatus wrote: post #61
griffinmichl wrote: post #60

Earlier quoted context omitted.

The JS community has been pretty good about taking ideas from Elm. Redux is an insanely popular JS library that is basically a replica of the Elm architecture (though, having used both extensively, redux doesn't come close to the beautiful simplicity of Elm). As far as why people don't just use Elm, I think it's the same reason functional language are less popular in general: fewer familiar engineers and steep learni…

Yeah, I had mentally tagged Elm as "interesting language that future browser languages/frameworks might claim as an inspiration". But, I thought the same about Coffeescript. And then Rails gave it massive traction. I wonder if the same might happen to Elm, should Phoenix adopt it as their browser language of choice. That might also offset concerns about Elm's fledgling status and key man risk.

I wonder if the same might happen to Elm, should Phoenix adopt it as their browser language of choice.

There's definitely a connection there -- for what it's worth, the keynote at 2016's Erlang Factory conference was a shared talk between Chris McCord (creator of Phoenix) and Evan Czaplicki (creator of Elm), "Making the Web Functional" [0]

[0] https://www.youtube.com/watch?v=XJ9ckqCMiKk

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#68

Post by bbcbasic »

efficax wrote: post #64
bbcbasic wrote: post #52

Earlier quoted context omitted.

> How to make it better? that's easy. IT ALREADY EXISTS and is part of Elm. It's just a private API. But it totally does work. It's how the native wrappers are written. You mean like this: https://github.com/mcapodici/capodicis-notes/blob/master/elm... That is an example where I connected chrome extension storage functionality using native wrappers. This is the Elm wrapping for it: https://github.com/mcapodici/capodi…

The Native interop changed with core >= 4.0, so that relatively straightforward way of accessing native js no longer works, and the new Native is (deliberately, I believe) undocumented.

That's Elm's weakness then. The goalposts keep moving.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#69

Post by rspeer »

kika wrote: post #37
ModernMech wrote: post #18

How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…

I walked away from Elm still being very enthusiastic about it and watching its progress. I started coming to Elm hackathons in 2014, did a few helloworlds of increasing complexity, eventually tried to write a portion of my app in Elm; there were ups and downs and then one of my (very few) customers asked me to create an API call to something that was happening in the browser. This code was written in Coffeescript, an…

Elm keeps sounding like a great language, but the fact that it locks my code into a web browser, with no headless way to run it, is a deal-breaker indeed.

Re: Integrating Elm and Phoenix Channels via Elm-Phoenix-socket

#70

Post by hoodunit »

akst wrote: post #29
ModernMech wrote: post #18

How come no one (seemingly) uses Elm, despite all the love? I've noticed a lot of quick, drive-by posts in Elm related threads about how great the language is. This thread ("This is a great little webstack!") and today's other front-page elm thread[1] both do this. With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses: 1) There are no unhappy users because un…

Coming from Haskell, I kind of dismissed it on the basis of missing a construct like interfaces/protocols/traits/type-classes, and started checking out purescript instead which is closer to Haskell. Eventually stopped using purescript due to some unbearable compile times (in purescript's defence it was early on in it's development, and it's still pre 1.0). All that said, I'd probably check out elm now only because I'…

PureScript compile times have been quite good for me in the last two versions or so, so there has been some improvement there.
Post reply on HN