advent2020
ihp
advent2020 | ihp | |
---|---|---|
1 | 124 | |
1 | 4,233 | |
- | 0.5% | |
3.9 | 9.5 | |
over 3 years ago | 4 days ago | |
Haskell | Haskell | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
advent2020
-
Haskell is a Bad Programming Language (2020)
Haskell has a lot of problems, but this article is not good, and does not describe them well. It reads like someone who has tried Haskell, and has sort of written some code in it, but has mostly been put off by bad and confusing tutorials, and has never really grokked the language. Indeed, look at the author's GitHub - of their 50 projects, only 1 is Haskell, and that is a handful of commits before giving up.
My main complaint with Haskell is that it's actually a great language, wrapped up in (1) hilariously beginner-unfriendly syntax and tooling, and (2) a library ecosystem that does not quite understand the value of friendly documentation (although this is actually improving a lot). There are also some weird warts around the language itself, but those are mostly tolerable and not so much worse than the weird warts in all other languages.
My specific complaints about beginner-unfriendliness in syntax and tooling:
- The compiler will infer the types of names as generally as possible, and will run this inference both forwards ("this variable started as a string, so must be a string now") and backwards ("this variable is used as a string, and therefore must have been a string earlier") depending on what information is available for inference. This means that type errors are hit-or-miss -- about 60% of the time, the type error will point you to your actual mistake, and the rest of the time
- The syntax is VERY minimal, and prefers minimalism over readability. In particular, Haskell has no explicit parentheses for function calls, and has implicit currying! This means that it is very easy to accidentally get the arity wrong in a function call (for example, `foo (bar baz)` and `foo bar baz` mean very different things!), and create an extraordinarily confusing type error.
- This minimal syntax also means that you can sometimes type something that is _almost_ correct, but is actually valid syntax that means something totally different! In some of these cases, you may even type something that is not syntactically valid vanilla Haskell, but _is_ valid Haskell-with-some-extension, and the compiler will unhelpfully suggest that you turn the extension on even though it may not be what you want (and also provides no explanation of the extension).
- The compiler tells you what expression has a type error, but never actually tells you the exact term that has a type error. You have to sort of guess at this by understanding the rough high-level of how the type inference works. It's something you have to really pick up, and is hilariously unfriendly compared to e.g. `rustc --explain`.
- Print-debugging works differently than what you'd expect. Nobody ever teaches you that `trace` is a thing (seriously, this should be thing #2 that is taught), and nobody ever teaches you that "you might get trace messages in a different order than you expect because Haskell is evaluating using graph reduction, not evaluating in the order of the lines of code you wrote").
Really this boils down to: even though Haskell will do a very good job at preventing you from holding it wrong, you really do have to _have a decent grasp on what you're doing_ to write a program. As a complete beginner, you can't just put something you think will mostly work and then rely on good compiler errors to tell you where to spot fix. (Fortunately, this gets much better over time - you learn how to interpret compiler errors better as you get a grasp on the language, and you learn tricks for building incrementally correct programs up using `undefined` and friends).
My specific complaints about documentation:
- Contrary to this article, types actually ARE decent documentation in Haskell. The constraints you can do with types in a pure language are much, much stronger than in other languages you've used before. Trust me - this is a Blub paradox thing.
- Unfortunately, although types do a great job at preventing me from plugging the pipes together wrong, they still don't tell me anything about the _semantics_ of a function. Lots of older libraries do a very bad job at documenting semantics, but this is getting a lot better.
- Arguments in Haskell functions are not named (or at least, their names are not exposed in documentation). This makes for some confusion sometimes - what arguments should your `foo :: String -> String -> String` take?
- Lastly, a lot of libraries document very academically. Here's an example: https://hackage.haskell.org/package/logict-0.7.0.3/docs/Cont.... The documentation here is written assuming you understand how Logic computation works, provides no examples, and you're supposed to read the module documentation and actually _go and read the paper_ (in fairness, it's pretty short) that they've linked. This is a far cry for NPM world, where everybody has a quick start.
Overall though, it's a really good language. Once you get monads (and a HUGE part of this is not the idea of monads, but the really unfriendly syntax and error messages of Haskell), a lot of things make a lot more sense. It's my regular side project driver.
Lastly, a word of advice to anyone looking to actually make a good-faith evaluation of Haskell: try it, make something substantive, and stick with it until you actually grok it. Seriously, don't just pick it up, get stumped by error messages, and give up. The tooling is very beginner-unfriendly, but fortunately the humans over at the Functional Programming Slack (https://fpchat-invite.herokuapp.com/) are VERY friendly. As a first project, I'd recommend doing the Advent of Code, or building a small web application (IMO with Scotty, which feels like Express, rather than Yesod, which feels like Rails. Yesod is almost certainly better in production, but has a different and IMO less instructive learning curve). If anyone needs help, follow along with my AoC 2020 (https://github.com/liftM/advent2020), although be aware that some things I do there are a bit fancier than necessary.
I find that articles like this that complain about things like type obsession or the academic focus really are not representative of the actual pain points with Haskell, and are FUD more than useful. Yes, the tooling is beginner-unfriendly. Yes, you will probably need to ask some questions on the FP Slack on your path to learning, things that a friendlier language would have documented. But this mystical aura of "ooh, there are types and they are very abstract!" is not reflective of reality, is not a criticism grounded in the reality of writing Haskell, and IMO is misleading for people genuinely trying to assess the language.
ihp
- IHP – The Haskell Framework for Non-Haskellers
-
Ask HN: Why are all of the best back end web frameworks dynamically typed?
I found IHP straightforward:
https://ihp.digitallyinduced.com/
despite not remembering much haskell!
This assumes you can get past nix for the install.
I find IHP well-designed. I just wish the licensing scheme were more transparent.
- IHP v1.1.0 has been released 🎉
- IHP Haskell Framework v1.1.0 has been released
-
Servant or framework
You can find the docs at https://ihp.digitallyinduced.com/ and some getting started videos at https://www.youtube.com/watch?v=PLl9Sjq6Nzc&list=PLenFm8BWuKlS0IaE31DmKB_PbkMLmwWmG
-
Haskell Optimization Handbook
In case this got you interested in Haskell, and you want a good way to start your Haskell journey (and have something to apply the optimization handbook to), check out IHP. It's the Rails/Laravel of the Haskell world. You can start here https://ihp.digitallyinduced.com/Guide/index.html or check it out on GitHub here https://github.com/digitallyinduced/ihp
-
Show HN: Algora.io – Open-source development bounties
At IHP we've been using Algora for a while now and it works really great. Here's e.g. one PR that was merged last week with a bounty attached https://github.com/digitallyinduced/ihp/issues/1621 Everything was set up in less than 15 minutes and ioannis and zafer have been super helpful with any questions we had.
In general I think this is a good direction and an interesting take on the open question around sustainable open source. Congrats on the launch and keep up the great work! :)
- Por que Elm é uma linguagem tão deliciosa?
-
Any open source projects to contribute to for beginners
You could contribute to IHP! We have some great docs to get started here https://github.com/digitallyinduced/ihp/blob/master/CONTRIBUTING.md And we have some low hanging fruits in GitHub issues for you to get started with, e.g. https://github.com/digitallyinduced/ihp/issues/1601 (also there's always lots of activity in the IHP Slack, in case you have any questions/need help)
- IHP Haskell Framework v1.0.1 has been released
What are some alternatives?
haskell-ux - Let's make Haskells error messages helpful :)
miso - :ramen: A tasty Haskell front-end framework
Ruby on Rails - Ruby on Rails
Phoenix - Peace of mind from prototype to production
ghc-proposals - Proposed compiler and language changes for GHC and GHC/Haskell
purescript-flame - Fast & simple framework for building web applications
Hobo - The web app builder for Rails (moved from tablatom/hobo)
penrose - Haskell to JavaScript compiler, based on GHC
purescript - A strongly-typed language that compiles to JavaScript
gitpod - The developer platform for on-demand cloud development environments to create software faster and more securely.
nixfmt - The official (but not yet stable) formatter for Nix code