I used to think that the benefits of functional programming was overrated. 
And then I got tired of fixing null pointers, "undefined is not a 
function", "why aren't these things equal" and "why has this changed" 
errors in production. Thing is, functional programming is easier, safer and 
faster than non-functional programming once you get used to it.

You're also correct. Everything you can do in Elm can also be done in 
Javascript. But consider for a moment what that means.

Type safety => flow or typescript
Immutability => immutable.js (and disipline to make sure the abstraction 
doesn't leak)
Declaretive UI => React
One way control flow => Redux
Managing side effects => disipline, disipine, disipline

Or, you could just use Elm which has all this out of the box, with easier 
syntax.

But you're right. You can't use Elm everywhere, yet.

onsdag 5. oktober 2016 19.50.52 UTC+2 skrev Sarkis Arutiunian følgende:
>
> Recently I read article about Functional programming, all 5 parts 
> <https://medium.com/@cscalfani/so-you-want-to-be-a-functional-programmer-part-1-1f15e387e536#.5il2s42gl>.
>  
> Yes it's pretty interesting article, written in interesting way. And I 
> really like pattern of 'functional programming', immutability and etc.
>
>
> But there is a question. Where the line between propriety and paranoia?
>
>
> I prefer use native javaScript for everything where I can do it without 
> any libraries. Yes exactly you should use some UI libraries like React and 
> some module bundler like webpack. But I think propriety of using this tools 
> is obvious. It's better to use JSX then use native js to create DOM or it's 
> better to use webpack at least to uglify and optimize your code because 
> some things just impossible to achieve without webpack.
>
> And we have absolutely opposite situation with Elm. Yes they have some 
> features to make function a little bit shorter than you'll do it in vanilla 
> javaScript and only in some case. It's not that difference like create 
> nodes with JSX or js.
>
>
> And all this stuff about immutability, can be easily achieved in plain 
> javaScript. Eventually is Elm code will be converted to plain javaScript 
> and not vice versa, so that's mean you can do all that stuff in javaScript 
> but for sure there are some features in javaScript which you can't do in 
> Elm. And using Elm you are limited with one pattern. And what if it's not 
> enough or it's not best solution in some case, what than? For example right 
> now I'm working on new CMS for one of my projects, on React/GraphQL/Nodejs 
> and hybrid storage MongoDb with mySQL. I would like to use this pattern in 
> some cases but I just can't use it everywhere, so that's mean I shouldn't 
> use Elm?
>
>
> Don't think that I'm against to Elm. I just want to see opinion of others. 
> And I want to see that line, between propriety and paranoia.
>
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to