You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This proposal represents the current understanding of the intent and implementation schedule for a new YAML library called Yaml that is YAML 1.2 spec-compliant, purely Haskell, and released under the BSD-3 clause license. In addition to the core library, we will implement a range of dependent libraries that will implement streaming, optic, and stream-transducer support in a modular way, with a minimal dependency footprint.
Introduction
YAML (YAML Ain't Markup Language)
Haskell has two existing YAML 1.2 implementations publicly available through the Hackage ecosystem: yaml, and HsYaml. Both of these packages represents years of work and value for Haskell developers and businesses alike, and have developed into small ecosystems unto themselves in terms of downstream dependencies. Both libraries, unfortunately, also have irreconciliable flaws that w
The prompt came from a tweet (later found out to be ranting into the void and not to be considered real advice) by a Stackage trustee:
Hey Haskell developers! STOP 👏 USING 👏 RESTRICTIVE 👏 UPPER 👏 BOUNDS! 👏 At least stop using them by default!
Part I
C: What do people consider the best practices on upper bounds in packages?
L: No build failures / No restrictive upper bounds. Pick one. (And stackage only works as a third alternative as long as you can afford to stay within it.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
From my experience fundraising in Haskell, companies who use it all seem to have suffered from the same two flavors of problem:
A rockstar comes in, dumps mindblowing code everywhere that dazzles the rest of the team and fools the product leads with pseudo-productivity until the rockstar leaves or finally wakes up. Cue the rest of the team death-marching for the next year or few years as the team attempts to juggle feature additions with excising or unraveling the impenetrable yarn-tangle of semantic misdirection.
An especially productive senior or team lead spends their time on refactoring and generally spinning their wheels with respect to product delivery, and then fails to deliver on time, or at all. Cue the rest of the team struggling to keep up with the refactors. The team's knowledge of the state of the product suffers, confusion about goals sets in, the senior/lead effectively becomes an anti-team player, throwing curveballs at the rest o
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters