zeendo

Is your Haskell solution open source?

Obviously they could have. Obviously it's much easier now.

I would love to hear more about how you accomplish this.

If you have the time, I'm specifically interested in:

Are you really all only using a single agent/context window? Or do you still use a coding agent individually but have other domain, planning, etc conversations with the shared context?

What tooling and model(s) are you using to do this?

How big of a team are you doing it with?

How long did it take you to transition to this process before it felt good?

I am surprised by this take, honestly.

We're a Haskell shop (and have been for over 10 years now) and are finding agentic development with Haskell to work pretty damn well.

Cold compile times in Haskell are painful indeed. Our development practices don't really cause us to do that much - even with agents.

It's unclear to me if the development practices at Scarf that cause them to hit this pain often are worth it if it means giving up Haskell because the compile times are too bad. Maybe they are, but I don't think so.

Oh thanks! I thought they meant this was going on in the real emacs man.

I didn't invent this mitigation FWIW - I saw it mentioned in one or another thread about this by someone else - possibly on the big reddit thread on this topic, not sure.

I can't find that branch here - https://cgit.git.savannah.gnu.org/cgit/emacs.git

Am I looking in the wrong place?

I have perf issues with emacs-pgtk on a 4k screen on Wayland with Niri in both Emacs as a client and not. The issues appear with typing or scolling, the delay and lag become noticeable.

For me the issue is only unbearable when running fractional scaling, for some reason.

I'm going to try the branch mentioned in the sibling comment, though.

As someone else mentioned, that's what GHC2021 and GHC2024 are for.

If you're suggesting that _every_ GHC extension is enabled then I think you don't really understand the implications of that. Many aren't compatible with each other in varying degrees, for one. They also exist on a wide range of stability and production readiness.

On the other hand, I agree that the extensions indeed hurt Haskell. Standardizing on them is absolutely necessary to survival for a team of even a modest size. GHC2021 and GHC2024 help to do this for the community at large.

The real "deep" change that I think would be best for Haskell is probably impossible - that would be for GHC to split into two compilers - one for production use and one for research. I don't even know HOW we'd do that but I think that's ultimately what us production users want in some form or another.

Pretty dishonest take. The most gracious read on this is that you encountered this situation ages ago and assume it's still the case today.

I've been writing Haskell in production for almost 10 years now and manual dependency resolution has never been a thing.

Because Anthropic, at least, gives you the option to opt out of training? I think Google and OpenAI do, too.

I'm asking this with probably half curiosity and half rhetorical intent but....why even give a warning?

Her blog has lots of quality content that's been featured on HN several times - well before AI writing became a thing. Not that you should necessarily know that but just strong evidence that your intuitions here are way off on so many levels.

Your entire take is super strange and presumptive.

Are you being willfully obtuse or do you actually believe that's true of everyone? There are so many reasons why someone might have a laptop in such a situation but not be able to use a hotspot on their phone - it's not even worth listing them.

This comes down to intentions versus results. Viewed through the lens of results the comment you're replying to is still correct: The result is incompetence. I'd argue that's the only lens that matters when you're on the receiving end of such work.

Yeah. I mean, I still hold out hope that enough of the driver support will get mainlined or just rolled into some distro I want to use that I can use it for _something_ but right now it just sits unplugged on my desk. :(

Last I checked BredOS was close to having a reasonable experience with it but I haven't had the time to poke at it again. Personally I'd prefer an Arch derivative like BredOS or FreeBSD. I don't really want to buy a GPU to put in it but it seems like that's my only option at the moment?

Embarrassingly, I don't really understand Hyper. I have a Moonlander and AFAICT the firmware (or at least the Oryx configurator tool they provide) says Hyper is just a combination of the basic 4 - Alt+Shift+Ctrl+Meta. I'm pretty sure that's at least not historically true... but I don't have a whole lot of use for it so I haven't tried to wrap my head around what's going on there.

I imagine there's a "real" hyper modifier but I haven't attempted to use it. For my sake, since I use GUI Emacs I find that I have enough mappings without it (I'm also a dirty evil user). A friend makes extensive use of it because he primarily uses Emacs via a terminal and Hyper avoids all other terminal keybind conflicts he might otherwise run into. But, he uses X11, too so no PGTK Emacs even if/when he does run GUI Emacs.

I'll try to dig into this some though and see if I can (a) determine a way to map a "true" hyper to my keyboard and (b) use it in PGTK Emacs and follow up with you.

Glad to see a good write-up of Wayland issues. My day-to-day doesn't run into the vast majority of these problems so when I see people melt down over a single trivial seeming Wayland choice about window coordinates then I have a really hard time relating.

This post is a lot more relatable.

As an aside, regarding remote Emacs - I can attest that Waypipe does indeed work fantastically for this. Better than X11 ever worked over the network for me.

I, too, suffer from the pgtk is slow issue (only a 4k monitor though it's mitigable and manageable for me)

The Orion? God mine is so annoying. What a waste of money.

Not who you're replying to, but no - this isn't the same. You can't share that album with others. Or have others collaborate on it.

You can do this with a few scripts and the Immich API - but that's not something the average user will do.

Agreed. The weird shilling of this nonsense is exhausting.

Can you not have an Optional<Optional<String>> in Java? That would allow you to represent explicit null with Optional, wouldn't it?

This style of engagement is so off-putting.

As a full time Haskell developer, I have a similar aversion to Haskell-based distro packages which aren't statically linked.

There ARE statically linked Haskell packages in the AUR so it's at least feasible. I haven't even dug into the conversations around why packagers are insisting on dynamic linking of distro packages - I just avoid them for the same reasons you mention.

I can't really speak confidently to why it is exactly - I can only guess. Clearly dynamic linking makes sense in a lot of cases for internal application distribution - which is where Haskell is often used - so maybe people are incorrectly projecting that onto distro packages?

You mean X users, right?

These seem nice but honestly feel like overkill for the most basic (and probably most typical?) use of tmux and similar.

I generally have a single session I care about per machine (rather than per project) and wezterm's built-in multiplexing handles this out of the box.

If you can't install screen then I'm surprised you can install tmux - BUT if you can install wezterm then it solves this need nicely by adding sessions + multiplexing to the terminal emulator itself.

https://wezterm.org/multiplexing.html

Yeah - it seems like this is a pretty undersold feature of WezTerm. It has completely eliminated tmux and Zellij for me outside of pairing with others.

Run WezTerm on the server, too. https://wezterm.org/multiplexing.html

I used XSLT and Active Server Pages to build my school district's website back around 2000 - each school had their own page and each teacher had their own, too - teachers could modify their pages directly in the browser.

I forget the _exact_ mechanics but it was definitely all done in Internet Explorer with XML as the actual content per-page and transformation was done using XSLT.

Interesting but I definitely hate XSLT as a result. Considering this was my first real programming job, it's surprising I continued.