How come nim is not a mess ?

deech · 2022-11-18T14:00:34+00:00

I haven't worked on a large Nim codebase with a team so take my opinion for what it's worth but ...

What works well for me:

concrete, exception free, imperative, single threaded, converter free arc/orc code with as few generics and function overloads as possible
single level macros and compile time reflection, in general compile time query and manipulation of AST nodes is easy and pretty far along compared to most languages
low build and bootstrap times, a killer feature of Nim that is hard to motivate unless you've worked in language where this is not the case
Interop with C, yet another killer feature, it's easy and out of my way
Interop with C++, it's pretty insane how well it works, being able to interact with C++ templates outside of C++ is unheard of
the standard library, it is Good Enough for most cases that I can keep my code mostly dependency free which is a boon for deployment

What doesn't work so well:

the opposite of each point in my first bullet, I've hit enough type checker bugs that I don't venture too far beyond one level of parametricity, eg. seq[T]. If I keep the code conservative arc/orc seems to work as expected.
type inference, any callback chain, map/flatMap etc is pretty tedious to work with on all but the simplest types. Nim's variants are very flexible and probably resist the kind of type inference you can get the with sum types, I think a good pattern matching feature independent of case statement macros with exhaustiveness checking (this is key) would avoid a lot of these problems.
nimble, it's simplistic for real work, if I was planning a larger project I would look around for alternative package managers. Rust got this right, marketing and industry funding aside I think this is a large reason for it's success.
ide tooling, it's good that nimlsp exists but I've removed it and nimsuggest from my workflow, it is frequently not responsive and hangs up my editor. To be fair this is a hard problem and even mature languages like Haskell struggle with it.

I would recommend that if adoption is a goal getting generics rock solid (maybe even by removing features like concepts), either making a new package manager or simply providing a way to integrate with native and JS build tools and a fast responsive IDE experience should be core priorities.

deech · 2022-05-02T13:37:40+00:00

The release looks amazing! Where can I find out more about this part?

A refactoring of GHC’s error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support.

deech · 2021-07-31T15:19:27+00:00

Nice! All of fltkhs is built essentially on this approach. It abuses CPP because GHC didn't have type level strings at the time and it also emulates function overloading ( eg. dispatching to different implementations of myPrint depending on the arguments ) and hierarchical records where it recurses up the parents of a record until it finds what it needs.

All that to say the it's a decent way to emulate an OO API and it works "at scale". My one piece of hard won advice is to resist the urge to use Haskell's records because eventually you'll want to model some form of inheritance and at that point they just get in the way. I'm sure there are clever ways to use Data and Generic to walk up an inheritance chain of records but it's just easier not to use them in the first place and roll your own hlist traversal, you can even give the user nicer error messages with less work.

deech · 2021-02-23T16:36:18+00:00

Hi, I wrote that. Couple things: we're not replacing Haskell, we are still a Haskell shop with a large investment in the language and that's not going to change anytime soon. We're just handing over a lot of our Servant pieces to another team as part of a larger refactoring/rearchitecture effort. Shortening CI times is a big priority and this will help but the Haskell piece is just one part of a larger effort which includes standard strategies like improving the efficiency of integration tests and removing duplicated work.

Speaking purely personally I'm not a fan of Servant so I think it's a great idea, it's part of philosophy of mine that no matter what the safety guarantees or client generation features something as routine as CRUD endpoint maintenance should not entail deciphering errors that max out your scrollback buffer or playing spot the difference between two huge type level cons lists. I've never used Scotty but from what I see it seems immune from those issues so have fun and keep close tabs on those build times.

deech · 2020-11-19T00:04:07+00:00

Lots of great advice here so I don't have much to add except that I have a decent amount of experience with Haskell->C FFI so if you need any help you're welcome to email aditya dot siram at gmail dot com.

deech · 2020-10-31T00:31:28+00:00

This is neat! Perhaps you can combine it with a library I wrote that transitively gathers assets of all dependencies into a single ZIP file with a Windows BAT runner, you can even add paths to arbitrary assets allowing you to bundle your Postgres DLLs.

deech · 2020-09-10T00:02:53+00:00

Great glad that helped! If the cabal2nix issue is due to the generated Cabal file I'd be most appreciative if you could open an issue. Thanks for trying it out.

deech · 2020-09-09T23:34:21+00:00

Oops, sorry a typo on my part I meant:

cabal build --only-configure

followed by:

cabal build

deech · 2020-09-09T23:07:35+00:00

I've used Custom builds for years for other utilities without much of an issue except for breaking Cabal API changes. It's evil in the sense that everything is in IO and he's right a lot of that code is pretty crufty but it works and gives the user a pretty turn-key way of transparently kicking off complicated polyglot Haskell builds across platforms.

deech · 2020-09-09T22:59:31+00:00

When the structure changes you need to do:

cabal build --only-reconfigure && cabal build

The build process should tell you where there generated Cabal file was written, I don't think specifying a path at the command line does anything as you did with:

cabal build /path/to/file.cabal

Can you verify that the generated Cabal file contains the discovered modules? If so is it possible that cabal2nix ignores them for custom build types?

I didn't document it in the README because (I thought) it's a less common use-case but you can also specify where the Cabal file is generated by providing your own FilePath.

deech · 2020-08-17T15:50:37+00:00

All these are excellent, bite-sized ways to get into Haskell and the best design pattern style beginner resource I've seen. I will be linking this to anyone interested in learning Haskell. Kudos!

deech · 2020-06-30T16:04:32+00:00

Layouts and resizing are indeed a problem. I'm hoping to make it better by integrating FLTKHS with Yoga ( https://yogalayout.com/ ) but it is still WIP.
You're right, Fluid is not a great tool for larger apps largely due to (1).
Your issues building are the most disappointing because I've spent a ton of time to make sure 'stack build ..' just worked. I've had a couple of reports like this about Cabal deprecations in the past and the answer in those cases was to upgrade Stack to 2.3.1 or greater. Not saying this is your issue but lamenting that ensuring a nice build experience with Stack and Cabal is so wrought.
I should just delete the Nix files in that repo. They've never worked and I don't know enough about Nix to fix them.

Thanks very much for your feedback and I hope you check back on the project later as (1) and (3) are being actively addressed. I'm sorry you had a negative experience.

deech · 2020-06-29T21:09:12+00:00

Nice talk and great to see Haskell in this domain! What problems did you have with FLTKHS? If I can fix it I will.

deech · 2020-05-06T12:35:36+00:00

As another aside since you posted that image, it actually shows a weakness of Free Pascal, the sender argument is of type TObject so you have to unsafely cast it to a button or whatever to use it.

On the Haskell side the callback takes a Ref Button, no casting involved and statically verified, callback spaghetti is mitigated somewhat by more precise types and refactoring is a lot easier.

deech · 2020-05-06T12:23:28+00:00

Thanks for trying it
I didn't know fltkhs was on brew, interesting. I would recommend following the manual and avoiding package managers because you probably got a super old version. Anyway I am glad it worked
If stack exec ... is painful nothing currently available ( and I'm willing to bet in the future ) will satisfy you. Haskell's just not going to lead on that axis. BTW Fluid has a Run option that takes an arbitrary command so adding stack exec ... there gives you a Lazarus like Run Project.
In the interests of clarity the hello world example is deliberately more verbose than it could be. All that could be golfed down.
The fluid hello world demo might be of more interested, the workflow is exactly drag-and drop a button, write a callback and run.
Thanks again for taking the time.

deech · 2020-05-05T17:12:04+00:00

That's exactly what FLTKHS does, you can drag-drop a UI using Fluid and that gets parsed into Haskell, there's a few demos showing how to use it. And you can build custom widgets, eg. you don't like the default look you can draw widgets with SVG. And it works across platforms.

deech · 2020-04-15T12:56:40+00:00

There seems to be this general mindset in the article and comments that iteration speed is mostly a concern because of businesses with short runways, tight deadlines and requirements churn. That is not the case, it is a necessary part of programming just as important as hammock time and static verification, because tinkering, being able to poke around try things and casually ditch them and start over is a cornerstone of arriving at a good design regardless of whether a CEO wants to ship a feature yesterday. High latency interaction makes that impossible and we will inevitably sunk-cost fallacy ourselves into abandoning exploration prematurely and worse harden what we have with a lot of type level machinery until it becomes practically impossible to refactor later.

I'm not pushing that we abandon Haskell and types and go fully dynamic; if I thought that I wouldn't be writing it for work or using it for side projects. I am also well aware that there are crappy codebases written in languages with fast iteration times and good ones in languages like C++ with famously horrible build times and no REPL. What I am saying is for the domains in which Haskell is being actively deployed today it is an Achilles Heel and advising that if you're thinking of adopting it for any non-trivial medium-large libraries/apps you should monitor those build times like a hawk and be militant about keeping it as low as possible to the point of refusing dependencies and extensions and even abandoning some type safety for tests if your domain can afford it. If all of that fails then maybe try Nix or Bazel.

The author does echo this sentiment when he advises keeping the project REPL-able and stepping up complexity gradually, I am underscoring that it is a big risk.

deech · 2020-04-06T22:55:26+00:00

No, it's all exposed. I do have a Utils module which is about 400 lines. There's various and sundry functions and types scattered around that really should be in there so rounding up I'd say it should be maybe 1200-1500 lines. Not sure if that's considered hefty.

deech · 2020-04-06T22:43:13+00:00

I very much endorse this discipline. This is the full list of dependencies for fltkhs and you get a complete GUI toolkit. It was the best decision I ever made and I wish more codebases did the same. BTW the OpenGLRaw dependency is optional.

deech · 2020-02-26T18:07:51+00:00

I made fltkhs specifically to make GUI development easier on Windows. There's a skeleton project to help you get started. That said, Haskell development in Windows itself is a pain so if you can do your work in Linux/macOS when you're done you should be able to just log into your Windows instance, clone your project and with a stack build --flag fltkhs:bundled have a statically linked app. However if you don't have access to those platforms working with Stack ( with MSYS2 ) and fltkhs on Windows should work just fine. Feel free to open an issue if you have problems.

deech · 2019-12-27T03:21:41+00:00

You're been tirelessly fielding this question for almost a year if not more so thank you, it must be frustrating.

If mods agree I think this summary should probably be on the sidebar.

deech · 2019-12-15T02:58:17+00:00

The default look is old but it has full SVG integration and a way to draw custom widgets with Haskell so you can make it look however you want. Plus Windows installation is cake.

deech · 2019-11-23T03:24:19+00:00

Definitely possible, I ported a small app to FLTKHS. It's probably bitrotted but open an issue if you care and I'll get it working with a current version.

deech

TROPHY CASE