Elm from a Business Perspective • Hacker News Board

Re: Elm from a Business Perspective

#71

Post by curried_haskell » Thu, Nov 10, 2016, 12:19 PM UTC

rtfeldman wrote: post #30

leshow wrote: post #23

Earlier quoted context omitted.

Your response to all the criticisms about boilerplate is basically sticking your fingers in your ears and going "nananana". Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. That's okay, but don't pretend like you didn't make the trade off.

> Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. I just straight-up disagree with this. If Elm added Haskell-style typeclasses today, and we refactored our whole code base at work to use them, I bet it would save us less than 1% LoC. This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the p…

The ridiculous comparison with parens only hurts your message.

I think a more apt comparison is comparing Elm to Go missing generics. Without do-notation I imagine that elm code is filled with a lot more awkward case branching.

Re: Elm from a Business Perspective

#72

Post by yakshaving_jgt » Thu, Nov 10, 2016, 12:20 PM UTC

_Codemonkeyism wrote: post #66

There is no business perspective to programming languages. Stop kidding yourself to explain your favorite tool of the week as good for business. Successful companies have used plain st* languages like PHP and Java, thousands of companies that use the tool of the week go bust. There is no correlation (perhaps you should not use Assembler or COBOL for web development) If there is any then companies that use the tool of…

As someone who worked at a large software company that suffered huge losses because of 1) client data loss caused by using unsophisticated tools and strategies and 2) accounting errors caused by a lack of type-safety: I disagree.

Re: Elm from a Business Perspective

#73

Post by kod » Thu, Nov 10, 2016, 12:53 PM UTC

skybrian wrote: post #12

petetnt wrote: post #10

> But than again, Elm is not too easy. This means that almost every developer I see that is already involved in Elm is a seasoned developer. Getting experienced developers on board means that they are immediately productive, which means we gain more per hour. Not really seeing this as a strong point. It feels like the same mindset that drove me away from Scala (and many others [0]!). Sure, it might be good for the co…

I don't think he's saying that Elm is actually hard to learn (like Scala or Haskell).

Yup, Elm isn't actually hard to learn. Nor is Scala (I had a team of people productive with it in under 2 weeks, with no significant prior FP experience).

Re: Elm from a Business Perspective

#74

Post by b123400 » Thu, Nov 10, 2016, 2:32 PM UTC

rtfeldman wrote: post #8

the_duke wrote: post #2

Well. Summary: "I have no idea about the technical criticism or type classes, but we use Elm and it works for us. It's easy, you are productive quickly (quicker than with React/Angular), it prevents bugs, devs like it, and so it saves us money." It's nice to hear that a company is able to utilize Elm effectively. It would be nice to know how big their 5 Elm projects "in various stages and different scale" are to judg…

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…

You definitely have access to something we don't, and that might changes how you view Elm. For example a normal Elm user can only send/receive values to/from JS via ports, and that is not scalable, e.g. you are not suppose to use ports in library. But at NoRedInk I guess you have some sort of native module wrapper (https://github.com/NoRedInk/take-home/wiki/Writing-your-firs...) that we cannot access?

Re: Elm from a Business Perspective

#75

Post by elbear » Thu, Nov 10, 2016, 3:17 PM UTC

b123400 wrote: post #74

rtfeldman wrote: post #8

Earlier quoted context omitted.

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…

You definitely have access to something we don't, and that might changes how you view Elm. For example a normal Elm user can only send/receive values to/from JS via ports, and that is not scalable, e.g. you are not suppose to use ports in library. But at NoRedInk I guess you have some sort of native module wrapper ( https://github.com/NoRedInk/take-home/wiki/Writing-your-firs... ) that we cannot access?

Anyone can write a native module. You can't publish it, but you can use it in your project.[1]

[1] http://faq.elm-community.org/#why-doesnt-the-elm-compiler-fi...

Re: Elm from a Business Perspective

#76

Post by [deleted] » Thu, Nov 10, 2016, 3:55 PM UTC

rtfeldman wrote: post #29

sotojuan wrote: post #20

Earlier quoted context omitted.

Not only does the creator of Elm work there but so do the people who know Elm more than anyone else in the world. Literally. While it's proof Elm can work it's not really a fair comparison for teams wanting to adopt it.

That's true for me, yes, but the author of this article works at a totally different company halfway around the world. :)

[deleted]

Re: Elm from a Business Perspective

#77

Post by lgas » Thu, Nov 10, 2016, 3:57 PM UTC

b123400 wrote: post #74

rtfeldman wrote: post #8

Earlier quoted context omitted.

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project…

You definitely have access to something we don't, and that might changes how you view Elm. For example a normal Elm user can only send/receive values to/from JS via ports, and that is not scalable, e.g. you are not suppose to use ports in library. But at NoRedInk I guess you have some sort of native module wrapper ( https://github.com/NoRedInk/take-home/wiki/Writing-your-firs... ) that we cannot access?

Native modules are accessible to anyone. Unfortunately the link you provided is a little out of date despite being the top hit on google. Here is an example of a native module that works with 0.17 though: https://github.com/evancz/elm-markdown/blob/master/src/Nativ...

Re: Elm from a Business Perspective

#78

Post by marcosdumay » Thu, Nov 10, 2016, 4:15 PM UTC

cassowary wrote: post #52

leshow wrote: post #47

Earlier quoted context omitted.

As an example, I see code all the time with many showX functions whose sole purpose is to turn come ADT into a string, this is the kind of boilerplate that would be reduced with some kind of abstraction mechanism. Same for map operations, fold, etc. Then there's other things that would benefit from further abstraction, like being able to compose apps or update functions without boilerplate. These are just a few examp…

Hi leshow, can you be more concrete? If I have a record `data Foo = Foo {fooA :: Text, fooB :: Text}` then I must write a method `show :: Foo -> Text` for it. It is immaterial if I write `instance Show Foo where` ` show foo = (... implementation ...)` or `shooFoo foo = (... implementation..)` I save no code with typeclasses (at this point at least). (I do save code with the magic "deriving", but that's not part of th…

!?

Of course you save no code on definitions. Some may even get more verbose.

You save code on usage, because you can use generic functions that will work for any instance of Show, instead of specifying them for every type.

Re: Elm from a Business Perspective

#79

Post by b123400 » Wed, Nov 16, 2016, 2:50 PM UTC

lgas wrote: post #77

b123400 wrote: post #74

Earlier quoted context omitted.

You definitely have access to something we don't, and that might changes how you view Elm. For example a normal Elm user can only send/receive values to/from JS via ports, and that is not scalable, e.g. you are not suppose to use ports in library. But at NoRedInk I guess you have some sort of native module wrapper ( https://github.com/NoRedInk/take-home/wiki/Writing-your-firs... ) that we cannot access?

Native modules are accessible to anyone. Unfortunately the link you provided is a little out of date despite being the top hit on google. Here is an example of a native module that works with 0.17 though: https://github.com/evancz/elm-markdown/blob/master/src/Nativ...

Yeah I figured the "rules" to write a native module for a while, but there is no tutorial, no support at all, which makes me rather uncomfortable, and I am never confident with that code.