Support audio?

[liamzee]

Are there any plans to support audio in Brick? Some users seem to be building GUI games, so having audio might be useful.

[jtdaugherty]

Hi @liamzee - I'm not sure why Brick would need to "support" audio, since Brick has nothing to do with audio specifically. It is only for dealing with keyboard and mouse input and terminal output. Audio devices are totally separate. Right now there should be nothing in the way of adding audio functionality to Brick programs since the event-handling monad EventM is based on IO and presumably any audio libraries would just need access to IO to do their work.

Is this question speculative? Or are you wanting assistance on actually integrating audio into a Brick application of your own?

[liamzee]

It's more speculative; I am going through a framework mania phase and the notion of Brick coming in with audio support built in, instead of having to go through other libraries was interesting. Once again, thanks for your time.

[jtdaugherty]

I see, thanks! Yeah, there is a lot that a UI framework for games could take on that Brick doesn't touch, like animations, sound, window management, even memory management, file asset loading, etc. Brick isn't aimed at game development specifically, though, so it's a level of abstraction or two beneath what a game engine would help with. But at the same time, Brick shouldn't present obstacles to dealing with those other things, should the need arise.

[liamzee]

My thinking right now is that from a production point of view, Haskell needs more frameworks, because while teaching / learning Haskell is a nuisance, teaching / learning a framework is not, and might result in faster onboarding times.

My experience with Servant and monomer is suggests that you can even drop monads, or at least postpone them, because if you look at monomer, it amounts to Elm on desktop through Haskell. It also helps because it avoids the question of MTL vs free monads vs ReaderT IO vs algebraic effects systems; i.e, it takes time to learn all of these, and by handling (most) of the effect-throwing code with frameworks, we're able to skip a lot.

I think it's IHP that's making a shot at it, but they're locked to nix. I also noticed Graninas' EulerHS framework, but that's also nix-based.

[jtdaugherty]

teaching / learning a framework is not

I find this viewpoint interesting, since I hold the opposite view: particularly if one's goal is to become effective with the language, frameworks are often too heavyweight and prescriptive and can be confusing for a beginner. In addition, the Haskell frameworks I've looked at (e.g. Yesod) typically have the drawback that they ask you to buy too much into their conventions in order to use the framework at all, which I believe is a mistake. That's usually inherent to frameworks, but I believe a framework should be lean and give you the scaffolding to do what you need without getting in your way or forcing you to write all of your code just so. Yes, a framework inherently has some conventions that you'll need to participate in to get its benefits, but some go much too far for my taste.

If your goal is to put Haskell into production, then I think that the evidence shows that lack of frameworks is not the problem at the top of the list.

And if learning and teaching Haskell is a nuisance, perhaps that suggests Haskell isn't the right language for you, or maybe there just need to be better learning resources, or maybe Haskell is just hard to learn (but worth it, I think). Regardless, though, I don't think frameworks will help solve that problem, because to use those frameworks one typically has to have command of some of the language's more difficult-to-understand features!

[liamzee]

IHP seems to have some success by selling their framework as Haskell for non-Haskellers, although hearing about the inclusion of (|>) annoys me.

As far as learning Haskell goes, consider Haskell Phrasebook, or Gloss-based tutorials, or Write Yourself a Scheme in 48 hours. All very simplified, and not really Haskell, but I think it shows that we can rush it.

From what I've read, 2-3 weeks from zero to production contribution is possible, but getting to 1 week with a competent imperative programmer would be desirable. A framework that wants pure functions and values, IMO, would be simplest.

---

I guess I'm implicitly with graninas as to Haskell being in crisis, Hasura is rewriting in Rust, and I think a lot of businesses that use Haskell are moving to Rust (Tsuru Capital is notable, Facebook is very pro-Rust). Looking for new ways to keep the language in production is valuable, although for some reason we don't see a lot of IHPers in Haskell social media.

[jtdaugherty]

As far as learning Haskell goes, consider Haskell Phrasebook, or Gloss-based tutorials, or Write Yourself a Scheme in 48 hours. All very simplified, and not really Haskell, but I think it shows that we can rush it.

Why is rushing important? Is this important to you, or are you saying you think this is important to others, speculatively? I don't think the standard of "it needs to be learnable in a week" is a healthy standard for a programming language, particularly Haskell. And if something is so simplified as to "not be Haskell," then that's not really a success story in Haskell adoption anyway.

getting to 1 week with a competent imperative programmer would be desirable

Desirable to whom? Companies that are actually using Haskell in production would presumably understand that their labor market is limited, that learning the language takes time, and that even 2-3 weeks is ludicrously, unrealistically short for learning Haskell unless by "learning Haskell" we mean "able to do basic stuff."

I guess I'm implicitly with graninas as to Haskell being in crisis

I don't know what "graninas" is, but the claim that Haskell is somehow in crisis is laugh-out-loud ridiculous to me. At the very least, companies moving to Rust is not, in my view, evidence of any crisis, nor is that even mutually exclusive with them also using Haskell; the tech industry is big, and people change technologies all the time. Being "in production" can mean a lot of things, from "used by Facebook" to "used by companies with 100 employees." Haskell has a long tail of production use by organizations much smaller than Facebook, and I think that for Haskell, that's enough. If Haskell isn't a good fit for a Facebook-sized organization that needs to churn through programmers who need to come up to speed in a week, then that's not a problem with Haskell itself if Haskell is getting plenty of attention and flourishing in all sorts of other places. Haskell doesn't need Facebook-level adoption to thrive.

[liamzee]

graninas is Alexander Granin, author of Functional Design and Architecture and someone who swapped Smalltalk and Ruby in some Robert Martin talk for Haskell and Rust.

---

But sorry for bringing it up; there's a chicken little faction that's scared by the Rust defections (I'm not sure if Snoyman is joining the Rust camp, but it's amusing to see that the Rust community doesn't seem to care about his book "Begin Rust"), I guess I'm with them, and you're not. I'm interested in seeing whether experiments with Haskell frameworks can make Haskell more accessible (and broaden the community to a size I'd consider sustainable), but of course your objections are valid; I'm told IHP extensively uses XImplicitParameters? Yuck.

Thank you for all your great work on Brick, especially the work toward expanding it toward Windows!

[jtdaugherty]

But sorry for bringing it up

Sorry if I come across as combative, too. I guess this is a somewhat touchy issue for me. :)

there's a chicken little faction that's scared by the Rust defections (I'm not sure if Snoyman is joining the Rust camp, but it's amusing to see that the Rust community doesn't seem to care about his book "Begin Rust")

Well, Snoyman has not exactly been the best actor in the Haskell community and has had a history of self-promotion. That doesn't tend to go over well with people.

and broaden the community to a size I'd consider sustainable

I don't know what "sustainable" means to you, but having been involved in Haskell for 15-16 years at this point, I don't really see any issues. But then again, the joke about Haskell from the beginning -- by its creators -- has been to "avoid success at all costs." I'm still okay with that. :)

Thank you for all your great work on Brick, especially the work toward expanding it toward Windows!

I'm glad people find it useful, and I'm glad there has recently been a lot of activity on the Vty front, adding support for Windows!

[liamzee]

Well, it boils down to this, although it's 3 years old and I'm unsure to what extent it's current:

ghc-proposals/ghc-proposals#378 (comment)

Camp 1, for a long time, was interested in Boring / Simple Haskell (there's apparently a production Haskeller in Zurich who banned either :: (a -> c) -> (b -> c) -> Either a b -> c ), but I personally suspect at this rate that the framework-driven approach meets their needs better than Boring / Simple Haskell. More importantly, I think the fundamental definition of a Haskeller involves gravitating to Camp 2 idioms, and initiatives to limit the language in use require suppressing the instinct.

A framework-based approach, at least hypothetically, should give you the benefits of Boring / Simple Haskell (faster onboarding) while not proscribing -XTypeFamilies etc; i.e, the weird Keto diet of production constrained Haskell.

[jtdaugherty]

Well, it boils down to this, although it's 3 years old and I'm unsure to what extent it's current:

Interesting, thanks for sharing that! Incidentally, I have worked for Galois for over a decade. (That doesn't mean I share exactly the same views as everyone else at Galois, but it does mean I have some common ground. Although I tend to avoid overtly dependently-typed approaches due to the various problems those approaches pose to maintainable code.)

[liamzee]

Finally, re Snoyman, imo, he tried and failed (in the main, I find his contributions generally helpful in parts). Stack is not supporting backpack and I suspect a lot of people are moving to Nix, graninas (he at least was consulting for Juspay) is selling a cool EulerHS framework for CRUD apps (on mobile, would otherwise link it on GitHub) that's restricted to Nix and thus not on Hackage.

The point about increased adoption for me, at least, is, well, when are we getting true / ergonomic dependent types (as opposed to type-level hackery)? There's someone working on it at Serokell, but it's just one person. Warp, at least in theory, could be substantially faster (benchmarks worse than Go right now). A larger userbase, albeit one still small enough to avoid Camp 1 running off Camp 2 and the research camps (that would kill the point of Haskell, and implicitly that post admits that Haskell is not an excellent production language, it competes via it's research features), would result in a faster pace of progress, especially when all the cool features of Haskell are being steadily copied off by other languages, and I think the pace of innovation needs to pick up.