I’m confused by the discussion of bringing new programmers on a team up to speed with these lesser-used languages; this blog is quite explicitly from a one-man dev shop.
He seems to do contract work with teams. The bio might be old.
Our Use of Haskell and Elm
21–30 of 68 posts
Re: Our Use of Haskell and Elm
#22Learning ELM really helped me learn Haskell which is something I'm continuing to do, but Elm helped a lot. So I can see why a Haskell shop would want to use Elm for their frontend work. This makes total sense. That said, my initial enthusiasm for using Elm, aside from a gateway-drug to Haskell, has waned. I just do not have enough confidence in adopting Elm for our internal project nor to recommend it to other compan…
You can follow along on the #elm-dev slack channel to know everything that's happening with the development with Elm. What 0.19 is going to include has been documented and made available to anyone that wants to know.
A long release cycle has meant I don't have to update any of my existing Elm code. That's a WIN to me! :)
Re: Our Use of Haskell and Elm
#23They mention plentiful motivated job applications, how is the market from the perspective of a developer looking to focus on Haskell?
> They mention plentiful motivated job applications I'd take anything from an advocacy article with a grain of salt. > how is the market from the perspective of a developer looking to focus on Haskell? Considering the only response you got points you to a subreddit, I'm guessing it isn't so great. At best, it is a niche market ( though that could be lucrative ). I wouldn't put all my eggs in one basket. I'd make sure…
There are two sides to the coin. It is a LOT easier to hire for a Haskell developer, because the pool of jobs is so small compared to the amount of people that would like to work with Haskell in their daily life.
That of course also means that the opposite is true for someone looking for a job—it's a lot harder to find something, so most trudge on, writing code in some language and then use Haskell in their spare time.
The last part usually also mean that the developers you find, as a company looking for someone, usually have a higher lower bar, by the very nature of having invested time into learning a niche language. Of course, that goes for most such cases as above, not that Haskellers are magically better programmers.
Re: Our Use of Haskell and Elm
#24I’m confused by the discussion of bringing new programmers on a team up to speed with these lesser-used languages; this blog is quite explicitly from a one-man dev shop.
the use of "our" threw me off a bunch, unless they're referring to clients
Re: Our Use of Haskell and Elm
#25I’m confused by the discussion of bringing new programmers on a team up to speed with these lesser-used languages; this blog is quite explicitly from a one-man dev shop.
I'm guessing he's working with other people; a "team" perhaps. Consultants are, sometimes, hired to work for or with companies; even for long periods!
Re: Our Use of Haskell and Elm
#26Learning ELM really helped me learn Haskell which is something I'm continuing to do, but Elm helped a lot. So I can see why a Haskell shop would want to use Elm for their frontend work. This makes total sense. That said, my initial enthusiasm for using Elm, aside from a gateway-drug to Haskell, has waned. I just do not have enough confidence in adopting Elm for our internal project nor to recommend it to other compan…
Why is the pace of releases an important metric for using a programming language? Focus on code quality, and maintenance simplicity. If anything, being able to use the same version for x years and having it be consistently better than any JS library/framework I used, means that the work done is of high quality. Maybe you should watch Evan's talks from various Elm conferences ( search on youtube, for example https://w…
If releases are the primary means by which bug fixes are distributed then a slow release pace means a slow pace at which bugs are fixed.
Otherwise, I too enjoy the stability of using working tools that don't necessitate a lot of fast-paced changes.
Re: Our Use of Haskell and Elm
#27I’m confused by the discussion of bringing new programmers on a team up to speed with these lesser-used languages; this blog is quite explicitly from a one-man dev shop.
I’m assuming that the author is describing his experience working as a consultant for a software company with a larger team. The article explicitly refers to multiple programmers working on the code base.
Re: Our Use of Haskell and Elm
#28Learning ELM really helped me learn Haskell which is something I'm continuing to do, but Elm helped a lot. So I can see why a Haskell shop would want to use Elm for their frontend work. This makes total sense. That said, my initial enthusiasm for using Elm, aside from a gateway-drug to Haskell, has waned. I just do not have enough confidence in adopting Elm for our internal project nor to recommend it to other compan…
> any advantages Elm might have had initially, is coming to parity with other solutions. Absolutely. Elm filled a particular void in front-end development for a while, but much more mature, well-maintained, growing communities are now sprouting up that offer powerful statically-typed functional programming that transpiles to Javascript, all valid alternatives to Elm with far fewer risks. ReasonML probably being at th…
TypeScript is at the top of the list if you include unsound approaches.
Re: Our Use of Haskell and Elm
#29Earlier quoted context omitted.
Why is the pace of releases an important metric for using a programming language? Focus on code quality, and maintenance simplicity. If anything, being able to use the same version for x years and having it be consistently better than any JS library/framework I used, means that the work done is of high quality. Maybe you should watch Evan's talks from various Elm conferences ( search on youtube, for example https://w…
If releases are the primary means by which bug fixes are distributed then a slow release pace means a slow pace at which bugs are fixed. Otherwise, I too enjoy the stability of using working tools that don't necessitate a lot of fast-paced changes.
Agreed.
But the main thing to check first is : are there many bugs? Struggling to find any. On the other hand in js...
I suppose it's more of a perception thing. We are used in js-based projects to have a lot of bugs as a given, so plenty of updates is a good thing.
Re: Our Use of Haskell and Elm
#30Learning ELM really helped me learn Haskell which is something I'm continuing to do, but Elm helped a lot. So I can see why a Haskell shop would want to use Elm for their frontend work. This makes total sense. That said, my initial enthusiasm for using Elm, aside from a gateway-drug to Haskell, has waned. I just do not have enough confidence in adopting Elm for our internal project nor to recommend it to other compan…
Why does it matter when the next release is coming, as long as the project is actively maintained?
It matters for planning. If I knew when the new release is coming, and which features it brings, then I can decide whether I use the current stable version, and upgrade later if required, or just use the beta version during the development knowing it will go live in time for my go live.
Knowing just that there will be some changes, but having no information about he final scope or timeframe makes the decision much harder to take, and can just lead to leaving to the competing product / language / library / framework with more predictable timelines.