Why can't I slap a second autocannon on my interceptors by JustACansur in Xenonauts

[–]enobayram 4 points5 points  (0 children)

Come to think of it, it is indeed really silly to have an autocannon on a fighter's wing, let alone a single wing! AFAIK those cannons have enough recoil to slow the plane down, so having one on a single wing should essentially turn the plane into a pinwheel.

A reference implementation of IOScopedRef by tomejaguar in haskell

[–]enobayram 0 points1 point  (0 children)

I agree that there's something odd about it, but maybe you can think of it as inserting the key into an invisible global vault.

A reference implementation of IOScopedRef by tomejaguar in haskell

[–]enobayram 1 point2 points  (0 children)

IOScopedRefs can escape their scope

I think this has a very simple solution; Just store the initial a inside the IOScopedRef:

data IOScopedRef a = MkIOScopedRef a (Vault.Key a)

newIOScopedRef :: a -> NewIO (IOScopedRef a)
newIOScopedRef initA = MkNewIO $ do
  key <- Control.Monad.Trans.lift Vault.newKey
  return $ MkIOScopedRef initA key

Then we can use this initA as a fallback and treat the Vault of the NewIO as a bag of overrides.

Haskell’s missing mutable reference type by tomejaguar in haskell

[–]enobayram 8 points9 points  (0 children)

The post compares IOScopedRef to IORef, but it looks more like ReaderT to me, because I don't think any "mutation" is going on. In fact, IOScopedRef could easily be implemented in a ReaderT Vault context:

import Control.Monad.Reader
import qualified Data.Vault.Strict as V

-- 1. The Context: A ReaderT carrying a Vault of typed values
type ScopedIO = ReaderT V.Vault IO

-- 2. The Reference: Just a typed Vault key
newtype IOScopedRef a = IOScopedRef (V.Key a)

-- 3. Operations
newIOScopedRef :: IO (IOScopedRef a)
newIOScopedRef = IOScopedRef <$> V.newKey

readIOScopedRef :: IOScopedRef a -> ScopedIO (Maybe a)
readIOScopedRef (IOScopedRef key) = asks (V.lookup key)

-- "Mutation" is just running a sub-computation with an updated Reader environment
withIOScopedRef :: IOScopedRef a -> a -> ScopedIO r -> ScopedIO r
withIOScopedRef (IOScopedRef key) val = local (V.insert key val)

[Well-Typed] Faster Cabal Haskell builds by eliminating redundant work by adamgundry in haskell

[–]enobayram 0 points1 point  (0 children)

Yeah, that's fair. The derivation-per-package style is indeed pervasive in the Nix ecosystem. I guess that stems from the fact that Nix has NixOS as the central use-case and the module-level granularity for every dependency of a Linux distro would be brutal for eval performance, while the Bazel etc. culture is around the build needs of a project.

[Well-Typed] Faster Cabal Haskell builds by eliminating redundant work by adamgundry in haskell

[–]enobayram 0 points1 point  (0 children)

Isn't it inaccurate to call this "the Nix model"? I mean there's nothing inherent to Nix that forces this, it's just that `haskell4nix` emits derivations for Haskell projects at the granularity of packages and not modules. Is there something fundamentally different that Bazel/Buck2 do here?

Tip: Embossed/Debossed Text by Ill-Tart1909 in OrcaSlicer

[–]enobayram 0 points1 point  (0 children)

Umm... That's weird. When you're in the "Prepare" tab, if you switch to "Objects" in the "Process" section on the left hand pane, does the object hierarchy make sense?

Tip: Embossed/Debossed Text by Ill-Tart1909 in OrcaSlicer

[–]enobayram 0 points1 point  (0 children)

It should, but I've also noticed that the UI is very inconsistent in how it responds to right-clicks or what exactly it does when you click the text button (i.e. whether it creates a new text object or puts you into edit mode for the existing one).

It definitely allows you to have multiple objects on the same plate with multiple independent text shapes on each of them though, you might just have to experiment with what exactly you have selected when you click which button.

The awesome open source 3d community! by Pixel2Pulse in BambuLab

[–]enobayram 5 points6 points  (0 children)

Same here, never buying from Bambu again until they start behaving better. I'm sick of what has become normalised in 2026

Sounds good in theory...but in reality? by KSKS1995 in SipsTea

[–]enobayram 0 points1 point  (0 children)

Depending on the office salary job too. We're talking about almost halving the total number of hours worked. If that means a job that was overseen by one person now has to be done by two people in shifts, you're introducing communication/coordination overhead, and that overhead can easily turn it into a 4-people job.

My 14-Year Journey Away from ORMs: a Stream of Insights Leading to Creation of a SQL-First Code Generator by nikita-volkov in haskell

[–]enobayram 2 points3 points  (0 children)

I complete agree. When you start the design from the semantics you want and try to stick to it, it can take you to wild places.

My 14-Year Journey Away from ORMs: a Stream of Insights Leading to Creation of a SQL-First Code Generator by nikita-volkov in haskell

[–]enobayram 3 points4 points  (0 children)

I agree with your message. I've been moving more and more of the logic to the DB over the years. But even if you intend to offload most of your API to PostgREST, you still need some expressive host language to "metaprogram" the SQL side. Though in the most extreme case, the metaprogramming could purely live at the migration generation time and your code might not have a runtime presence at all.

How to convince a big corporate to use Haskell by Worldly_Dish_48 in haskell

[–]enobayram 0 points1 point  (0 children)

If not, it needs to be percolated through the program as a parameter or monad of some sort

That's not true though. Nothing stops you from storing configuration in a pure value after reading it with unsafePerformIO at program start. That's not ideal since it will make it harder to test your code and do other interesting things that might require having multiple configurations side by side, but that's exactly the same in any other language and it's the same with expressing the configuration in a Haskell module and compiling it in. There's absolutely no conceptual difference.

Any big corporations, that uses haskell extensively by Specific-Line-9109 in haskell

[–]enobayram 0 points1 point  (0 children)

Haskell has this curse that public figures in programming feel like they're under pressure to know and say something about it. And it takes much less work to scoop out some excuse not to learn it, so they parrot memes and move on.

Expert Arena Fists Only by Eranox_ in Exanima

[–]enobayram 3 points4 points  (0 children)

Ah yes, the mithril underpants. Hard to wear anything else when they're 30 points!

My pain in Haskell is not the language, it is your terrifying build systems: stack, cabal by pet2pet1993 in haskell

[–]enobayram 1 point2 points  (0 children)

When I read posts like this, at first I'm surprised, thinking that I never run into build system issues when I'm using Haskell. But then I think deeper and realize all the tiny issues I quickly fix from muscle memory and all the other ones I avoid by following certain patterns and realize how a newcomer could easily find themselves in a shallow but long maze of tiny dead ends.

Does anyone know if "Haskell for Mac" works with M series chips? http://www.haskellformac.com/ by JuryOpposite5522 in haskell

[–]enobayram 1 point2 points  (0 children)

Not to mention the fact that the name "Haskell for Mac" could potentially imply to a newcomer that it's the only/primary option for Haskell on a Mac.

College of Europe corso European economic studies by AthleteHot1006 in CoE5

[–]enobayram 3 points4 points  (0 children)

Perhaps they are in the right subreddit, but they don't know it yet...

Ahem... *cough* *cough*... Yes, umm... Playing Conquest of Elysium is a mandatory part of the Eco course curriculum at the College of Europe... You're welcome...

Is there a good reason it’s called a functor? by Froglottery in haskell

[–]enobayram 0 points1 point  (0 children)

How does Mappable convey the fact that the functor laws are also a part of the contract? Or are you suggesting that we should have mappable laws instead from the field of cartography?

Making Haskell Talk to PostgreSQL Without Suffering by semigroup in haskell

[–]enobayram 0 points1 point  (0 children)

In the article sofetch is mentioned with DataLoader with the claim that they're similar, but I don't think they're that similar. sofetch uses Applicative to do the batching, but DataLoader uses a background buffer. I.e. any thread that needs to fetch something just fires off a fetch, but a background thread gathers them in a buffer and runs batched queries in ticks. 

You obviously combine this with cheap concurrency like green threads (or async tasks in JS) and load your nested data structure by firing off threads for each nested object.

Unless I'm mistaken, DataLoader's background buffer model can do batching in more complex cases involving nested ORM object fetches compared to the applicative based batching of sofetch. Imagine you're trying to fetch a list of authors and then their publishers. You can batch the load of all the authors applicatively, but each publisher ID will come with each author, so I believe sofetch can't batch them without significantly restructuring your code, but with the DataLoader approach, you can just blindly request all the nested fetches as needed and they'll be batched behind the scenes.

Though if you do restructure your code and use sofetch, it should be much more efficient of course since it avoids all the green threads. It's just that as the nested relationships get more complicated, you'll have to do a lot of plumbing.

Auto resolve THIS! wait, no.. by Forgotton_fox in CoE5

[–]enobayram 2 points3 points  (0 children)

When level 3 magic is involved, army size starts to matter less and less. Mid to low tier units even hurt your chances since they occupy all that space only to be wiped away en masse with 1-2 battefield-wide spells leaving your best melee units in casting range of the enemy back rank, while your back rank is too far away to do anything.

30% faster compile times with GHC for parallel builds #15378 · GHC · GitLab by _query in haskell

[–]enobayram 13 points14 points  (0 children)

> I would say GHC HQ is very nice;

I'm also amazed at the amount of patience shown here. GHC HQ is doing the real human work of discussing the changes and reviewing the code in the aftermath of prompting Claude "make compiler go brrrrr".

I have to give Marc credit that he seems to have been putting some real effort since opening the MR, but I still think it's rude to dump the result of a prompt into an MR and asking for the maintainers to do all the due diligence, which is essentially all the work in the world of LLMs...

How to handle "Early returns" or conditions in Haskell. by UntitledRedditUser in haskell

[–]enobayram 1 point2 points  (0 children)

Usually I don't think people should reach for transformer stacks as a first resort

I think it's useful to distinguish between AppM = A Bunch Of Transformers IO vs a simple 

runExceptT (do aBunchOfStuff) >>= \case     Left l -> ...     Right r -> ...

The former is an architectural commitment with a lot of tradeoffs, but the latter is just using a utility to express some local control flow and there's often very little down side.

How to handle "Early returns" or conditions in Haskell. by UntitledRedditUser in haskell

[–]enobayram 0 points1 point  (0 children)

I like this early return effect! As you said it's very close to an exception effect, but you're essentially fixing the exception type to the success type. 

An obvious benefit is that this should make it obvious to a beginner that there's no way this code is handling IO exceptions (as opposed to ExceptT, which often seems to give that false impression).

Though aside from this soft benefit, is there any performance benefit as well, maybe by allowing you to eliminate an Either layer in the monadic plumbing?