TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

2022 State of Haskell Survey

48 点作者 luispauloml超过 2 年前

8 条评论

gamegoblin超过 2 年前
This is maybe a big ask, but could anyone who has been a long time Haskell user give some bullet points on major language developments since ~2015 or so?<p>I was deep into Haskell and used it as my primary language from 2012-2015, but switched over to Rust around that point. I&#x27;ve been thinking about trying a mid-size hobby project in Haskell to get updated on the new state of the art.<p>Some things I have heard tangentially (and may be misremembering):<p>- Field accessors (i.e. `myObject.field` instead of `field myObject`)<p>- Monad hierarchy refactoring (monad of no return)<p>- LiquidHaskell making some inroads<p>How is package management these days? Is cabal hell still a thing? How&#x27;s the IDE situation?
评论 #33455463 未加载
评论 #33455909 未加载
doe88超过 2 年前
I&#x27;m a relatively newcomer so maybe discard this comment. What hurts me most at this point is the lack of documentation, or at least the lack of simple examples. This is the only language I know where more often than not the main documentation of a module is a link to a journal paper. Alternatively, I&#x27;m just not always able to infer what a function does just by looking at its signature. Just give examples.
评论 #33480090 未加载
tomas789超过 2 年前
I have tried to push for a Haskell in my previous job. We had a task that was especially well suited for that. It was a large collection of mostly declarative computations for the mixed-integer optimization. I also wanted to take an advantage of Liquid Haskell since that would allow us to move a few checks from runtime to compile time. That would be a game changer. Things like divide by zero were very common. It is easy to detect division by zero but not so easy to cover all the edge cases that could cause it.<p>At the end of the day we did not go forward with that. The reasons mostly were:<p>1. Even though I used a lot of my &quot;social credit&quot; on this everybody was scared of it. Mostly because of the vibe that comes with Haskell.<p>2. Purely functional languages come with lots of concepts that are unfamiliar to most programmers (everybody in my team was well equipped with CS degree and theoretical knowledge but still those concepts were new-ish).<p>3. The higher in company hierarchy the more people were scared (this was a critical project for the whole company of ~22k people).<p>4. We couldn&#x27;t figure out debugging. Our codebase was ~40k generated lines of code (type definitions, basic accessor functions and so on) plus ~10k LoC we would write on top of that. The only VSCode-based debugging I was able to figure out was basically loading it in GHCi and then doing the debugging which was fine. The problem was the load itself. It took ages because it recompiled majority of the codebase on load. No precompiled parts were used. Result was that every debugging session took minutes to start up.<p>On the other hand Liquid Haskell has a great potential and I hope that there is a future in which we have similar tools in more common languages. As the complexity of the codebase grows it become more important to have a tool to provide additional guarantees. We did not have much of the code on its own but it was packed with complexity and dependencies. Liquid Haskell seemed to provide a tool that does not get into your way when you don&#x27;t need it but it available when you want it.
weatherlight超过 2 年前
I hope tooling becomes the #1 priority. - after using languages like Rust and Elixir, It&#x27;s hard going back to other langs where the tooling is not at that standard,
评论 #33454500 未加载
luispauloml超过 2 年前
I really wish I could use Haskell all the time instead of Python and the most dreaded programming language, a.k.a. MATLAB.¹ I guess all that&#x27;s left for me is to do whatever toy projects come to my mind in my free time.<p>¹ <a href="https:&#x2F;&#x2F;survey.stackoverflow.co&#x2F;2022&#x2F;#most-loved-dreaded-and-wanted-language-love-dread" rel="nofollow">https:&#x2F;&#x2F;survey.stackoverflow.co&#x2F;2022&#x2F;#most-loved-dreaded-and...</a>
cfiggers超过 2 年前
Haskell is a beautiful, elegant language. And the tooling is a trainwreck that keeps me from using it.
评论 #33454467 未加载
评论 #33454111 未加载
nawgz超过 2 年前
As a non-Haskeller, the only tool I can think of interacting with that has any Haskell is Hasura&#x27;s graphql-engine[0], which GitHub stats say is 28% Haskell (and then like 55% web languages, so I assume the backend is all Haskell and the web languages are for the UI it presents etc)<p>Are there other popular Haskell tools? Or is it more of an academic language? I was surprised to see it on the GitHub repo.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;hasura&#x2F;graphql-engine" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hasura&#x2F;graphql-engine</a>
评论 #33455579 未加载
评论 #33455546 未加载
carterschonwald超过 2 年前
There’s a bunch of issues with how these surveys have been designed in the past, imo, and generally solicitating easily interpretable qualitative responses on technical systems is just hard.