Elm changed my mind about unpopular languages • Hacker News Board

Re: Elm changed my mind about unpopular languages

#261

Post by rkangel » Tue, Feb 20, 2018, 10:00 AM UTC

blunte wrote: post #74

mooreds wrote: post #7

Earlier quoted context omitted.

> This is always a risk with new tools and techs. Absolutely. Whenever I see a new project, I look at business risk and technology risk. Either one is OK, but both are not. (I picked that up from someone, don't remember who). I think that there's real value to being a Tom Bombadill (and really learning a language/framework/problem space deeply) as opposed to being a Gandalf. However, one fundamental issue is it's eas…

I have pondered about this depth vs breadth approach for some time. My path has made me a generalist who learns and does whatever I think is necessary in a given situation. This is great because I can do anything. But I envy the domain experts who do one (or a related few) things VERY well. Perhaps it depends much on the mind of the person; I don't think I could just focus on one thing forever. But while the new shin…

I work for a consultancy (both general consultancy and engineer), and the phrase they like to use is "a T-Shaped consultant". Meaning that you have a broad base of skills and one specialism. For us, most people fitting that model works pretty well.

Re: Elm changed my mind about unpopular languages

#262

Post by rkangel » Tue, Feb 20, 2018, 10:31 AM UTC

TremendousJudge wrote: post #50

I don't get it. The author didn't address his original concerns, he just said "Elm is awesome", which may be true, but isn't a rebuttal of his previous points, which are condensed here: >You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.

The point I took from it was "These issues are valid, but in some cases there are benefits that outweigh them".

Re: Elm changed my mind about unpopular languages

#263

Post by brokenbyclouds » Tue, Feb 20, 2018, 10:42 AM UTC

rtfeldman wrote: post #217

brokenbyclouds wrote: post #197

Earlier quoted context omitted.

Worth noting is that you haven't been able to find a single criticism of elm in years. You hired the language designer so it's understandable that you'd have an easier time with the language. However, you've consistently kicked dust in everyone's eyes every time anyone has anything remotely critical to say about elm. It's frustrating because you are so smart and so insightful and it just looks like you're deliberatel…

Elm doesn't support code splitting or `insertRule` styling, both of which are important for performance. `elm-package` is currently piggybacking GitHub's infrastructure instead of having its own hosting. I think Elm should have more patch releases. I don't think `comparable`, `number`, or especially `appendable` should be in the language, and hope they get removed someday. I don't think `==` should be `a -> a -> Bool…

You're right, my comment was needlessly harsh and I apologize for that. You didn't deserve that and it was rude of me.

The subject of Elm often gets me riled up because there's so much good about it mixed with what to me is a greater portion of frustration. I strongly disagree with how the language is managed, with the closed nature of its development, but mostly with what looks like the constant dismissal of any concerns about any of these issues any time they're brought up. By far, the most common response feels something like "everything is fine and your opinions are baseless."

There are people I know who, like me, have tried to convince employers to even consider Elm and have been shot down because, in management's words, "there doesn't seem to be any idea where the language is going", or its "too unsafe, its all dependent on one guy" or "looks like its dead now anyway, no releases in over a year and apparently it sucks at basic things like dealing with json". And yeah, some of those things, like the json nonsense, shouldn't be showstoppers. But not having an idea of what the roadmap or timeline looks like is a big deal. No releases in a year is a big deal. So then you bring that up on the elm forums or the slack, and you end up getting blasted there too because now you're seen as criticizing this thing that everyone loves.

Obviously I'm just a jackass on the internet with more mouth than brains and I wouldn't hold your breath waiting for me to ever make anything as interesting or yes, successful, as Elm is right now. I appreciate the work you've put into making Elm as good as it is.

Re: Elm changed my mind about unpopular languages

#264

Post by ldrndll » Tue, Feb 20, 2018, 11:01 AM UTC

LeonidasXIV wrote: post #54

pbiggar wrote: post #43

Earlier quoted context omitted.

I saw the same at CircleCI with clojure. People want to use functional langs in real systems - we had a lot of Haskell lovers apply because "close enough". Way easier than hiring rails devs. One of the reasons I'm using OCaml/Elm in my new startup :)

> One of the reasons I'm using OCaml/Elm in my new startup Where do I apply? ;-) (To prove the point: yes, I'm one of those passion people, moving to Denmark to work in OCaml full-time, before working in Clojure full-time. Now someone give me an Idris job, heh!)

Out of interest, where were you doing OCaml work in DK? Issuu?

Re: Elm changed my mind about unpopular languages

#265

Post by scns » Tue, Feb 20, 2018, 11:24 AM UTC

masklinn wrote: post #40

seveibar wrote: post #20

Earlier quoted context omitted.

> > First, Elm has the natural predictability of a pure functional language; when you write Elm, the compiler forces you to consider every case. > I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language? Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely…

> Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). Neither is even remotely as robust — let alone friendly — as Elm's type system.

Check out ReasonML, great Typesystem and robustness. Tooling is still a little rough though.

Re: Elm changed my mind about unpopular languages

#266

Post by wz1000 » Tue, Feb 20, 2018, 11:25 AM UTC

dbpatterson wrote: post #66

danharaj wrote: post #45

Earlier quoted context omitted.

GHC will coverage check any case equivalent to one you can write in Elm. You can just write more powerful types where GHC can't tell that your case is exhaustive so it warns about missing branches that won't ever actually be taken. I seem to remember that perfect exhaustive checking for some combination of Haskell extensions is undecidable.

Pattern matching on GADTs will get you there, I believe.

Its been improved a lot- https://lirias.kuleuven.be/bitstream/123456789/512439/1/icfp...

Re: Elm changed my mind about unpopular languages

#267

Post by nivertech » Tue, Feb 20, 2018, 11:33 AM UTC

Can rewrite the example from the post:

  uniqueAuthors =
              books
                  |> List.map .authors
                  |> List.concat
                  |> Set.fromList
                  |> Set.size

as

  uniqueAuthors =
              books
                  |> List.concatMap .authors
                  |> Set.fromList
                  |> Set.size

Re: Elm changed my mind about unpopular languages

#268

Post by marcosdumay » Tue, Feb 20, 2018, 12:02 PM UTC

username223 wrote: post #221

marcosdumay wrote: post #110

Earlier quoted context omitted.

You don't get that choice. You can't select for people that care about your product, but you can select for people that care about some technology. And, if it is a good tech that fits your business, why wouldn't you?

> You can't select for people that care about your product, but you can select for people that care about some technology. If that's true, it's kind of awful. "'Once the rockets are up, who cares where they come down? / That's not my department', says Wernher von Braun."

Well, ok. Some people can select for caring about their product. But a random company is almost certainly not in this set.

Re: Elm changed my mind about unpopular languages

#269

Post by rthomas6 » Tue, Feb 20, 2018, 12:06 PM UTC

brightsize wrote: post #198

rthomas6 wrote: post #105

Earlier quoted context omitted.

Wow, this looks very cool! Why is this not more popular? Coconut seems like something many people, including me, would want to use for every Python project of sufficient complexity. What's the catch?

Fanboy here. I've used Coconut extensively and it's a joy. I wouldn't start a (personal) Python-targeted project without it. Pattern-matching, a non-horrid lambda syntax, lazy evaluation, TCO, a built-in partial function syntax, and finally the pipeline operator (|>) are all things I'd hate to be without now. A more detailed list of features (incl. MyPy integration) is here: http://coconut.readthedocs.io/en/latest/ .…

I thought about it, and I think the unpopularity of Coconut might be due to the existence of the Toolz library. That gives most things that Coconut does minus better lamda and TCO.

Re: Elm changed my mind about unpopular languages

#270

Post by michaelcampbell » Tue, Feb 20, 2018, 12:14 PM UTC

dozzie wrote: post #160

onebot wrote: post #62

Earlier quoted context omitted.

Don't you want people that care about your product instead of the technology behind it? I do. Because there may come a time when another technology is a better fit for your product and ultimately your customer's experiences. Then what? Now your not using elm and your team leaves or is disgruntled. I hire on passion for what we are trying to accomplish, not the technology stack.

> Don't you want people that care about your product instead of the technology behind it? I do. I would rather have people who care about their craftsmanship and are indifferent about the product than people who care about the product and are indifferent about the craftsmanship. The former ones do a good job regardless of what the product is about.

Indifferent to either is a red flag for me; I'll take neither, thanks. You don't have to have one at the expense of the other.