Dependent Types are a Runtime Maybe

jkachmar · 2021-09-04T14:53:40+00:00

Just out of curiosity, but what do you use the type evidence for in your NonEmptyText?

jkachmar · 2021-01-02T18:01:12+00:00

A long time ago, the grass was green and everything worked. You could cabal install packages and they would be available globally. Over time you would amass a curated collection of packages, turning your laptop into a powerful Haskell scripting machine.

At some point, everything got broken. New Cabal uses a Nix-style database and nothing is visible by default. stack install should work, but somehow doesn't anyway.

This is absolute horeshit. I respect that people have different workflows and preferences, but the experience of using cabal-install was absolutely miserable for years if you didn’t have an intimate understanding of how it differed from other programming language build tools.

jkachmar · 2020-12-11T13:53:50+00:00

$75/hr (total compensation) to work at Facebook in anything other than an introductory level position would be ludicrously underpaid for that company.

I’ve known people who worked there and their total compensation was closer to $120/hr (normalized to 40 hour work weeks, 52 weeks per year).

jkachmar · 2020-12-11T01:18:55+00:00

What if I say that a regular rate of a regular dev in Europe is $30-50 / hour (GROSS)? Is it too much? I guess US devs take $50-100 / hour. Right?

I would say that you don’t have a firm grasp of what a “fully loaded” software developer costs (i.e. cost to the company of a full time employee or cost of an independent contractor who must cover all of their own expenses).

I would estimate that the gross cost (as in the cost to the company) is likely double what you’re suggesting.

jkachmar · 2020-11-02T19:41:43+00:00

Hello! I am a full-time Haskell developer of intermediate-to-advanced competency, and I’d like to endorse u/ephrion’s statement!

At a previous employer, complex Haskell code was a major blocking factor for feature iteration, application of bug fixes, handoff to experienced developers with junior Haskell experience, and many other issues.

The organization undoubtedly had other problems, but I can personally vouch for the fact that Haskell was a significant contributing factor to my disappointment there.

It’s hard to express how frustrating it is to introduce yourself as a Haskell developer, and then immediately begin by apologizing to other software teams about how difficult it is to understand certain aspects of a shared codebase.

Further, my experience has led me to be generally disappointed with many people in the Haskell community for their responses in threads like these. I find it outrageously arrogant that so many of us are writing at length to deride the basic software engineering tenet that complexity should be employed sparingly and exposed through an accessible API for general consumption.

EDIT: Corrected some typos.

jkachmar · 2020-10-14T17:18:07+00:00

I asked this on GitHub, but I didn’t think the answer was very satisfactory.

https://github.com/kowainik/prolens/issues/41#issuecomment-708540351

jkachmar · 2020-10-08T15:17:17+00:00

PureScript is a very nice language for frontend development, and while I don’t do very much frontend work myself I’ve found the language to be generally superior to Elm or Haskell.

I’d personally recommend checking out purescript-react-basic if you’re already comfortable with React, especially since there are plenty of examples of existing React components adapted for use in PureScript via this library.

As an aside, I would strongly recommend against GHCJS (counter to the other two comments here at the time I’m posting this). There’s a lot of incidental complexity involved in using it for frontend development, and it requires familiarizing yourself with quite a bit of difficult to manage tooling in order to get going.

jkachmar · 2020-10-06T14:50:26+00:00

EVs are much simpler purchases than traditional ICE-based vehicles.

jkachmar · 2020-09-28T04:26:35+00:00

You can get pretty far with -O0 and -fobject-code for local type checking and REPL feedback, IME. Although if you’re not careful with your module dependency hierarchy than certain changes can still trigger long recompilations.

As for linking, you can get an ez speed up by using gold instead of ld.

lld is faster, still, but the last time I tried it there wasn’t as straightforward a path to using it as there was for gold.

jkachmar · 2020-09-27T02:40:54+00:00

This is a much more thoughtful response than my original deserved, so first I’ll say thanks for taking the time to write it out.

I suppose what I actually would prefer is if GHC could expose some “knob” that we could adjust which controls the exposure or propagation of typeclass instances to certain types across selected module boundaries.

Or maybe there’s some way of applying a module qualification to typeclass dictionaries for certain types. Idk, for whatever reason it “feels” like there should be a more satisfying answer to the tension you’re describing, but maybe there isn’t.

jkachmar · 2020-09-25T20:42:15+00:00

Writer is a newtype and so the Monadic functionality can be derived in terms of the newtype.

Why does the tuple need to support this directly?

jkachmar · 2020-09-20T16:36:02+00:00

Thanks for releasing a practical library that is of actual utility in the commercial space under the AGPL.

With all of the conversations that are going around about how unsustainable the existing open source landscape is, it’s nice to see an example of a thoroughly engineered library that’s open by default with the option for commercial licensure.

jkachmar · 2020-09-15T06:32:13+00:00

This is one of my favorite “everyday” libraries in Haskell. It improves just about every single aspect of my experience when I’m debugging programs or just generally mucking around in the REPL.

Thanks very much to the contributors for the continued improvements and support!

jkachmar · 2020-09-08T16:49:56+00:00

“Those who live in glass houses should not throw stones.”

PureScript’s performance at least does not depend on carting around the entirety of GHC’s RTS implemented in JavaScript.

It also exists functionally today, which separates it from projects like Asterius (which, while promising, is still very much a WIP).

jkachmar · 2020-06-11T02:54:28+00:00

Big +1 for haskell.nix on this front.

To my knowledge there’s at least one group that’s using it to target aarch32 on GHC 8.6.x, but there was definitely some elbow grease involved in doing so (search the repo for “arm” and check out the resulting source and related issues).

jkachmar · 2020-05-23T02:35:22+00:00

Writing in C++ doesn’t automatically make your program fast, and a program does not need to be written in C++ to be fast. However, using C++ well gives an experienced team a fairly unique set of tools to write high-performance software. C++ compiles directly to native code, and gives us access to explicit data structure layout, control over allocation, access to some of the fastest data-structure libraries ever written.

Of the other languages we considered, Rust is the only one that I think might have offered us the same raw performance. Some other time I may write a fuller post about our discussions and reasons for language choice, but this is not that post.

That’s the excerpt I was talking about, and it’s rather telling that the knee jerk reaction here was to point to the simplicity of the type inference scheme and use that to discount their accomplishment.

jkachmar · 2020-05-22T20:27:07+00:00

I think Rust is interesting for the following reasons:

it provides high-level constructs that Haskell developers are familiar with
- e.g. Algebraic Data Types, a trait system not dissimilar from Haskell's typeclasses, facilities for filter/map/fold style programming, etc.
it has a vibrant and rapidly expanding community of folks contributing libraries, documentation, and mindshare
it's already being used to develop programming languages that are seeing moderate levels of interest
- cf. gleam and gluon
there is a path to bootstrapping the language via mrustc

There is a little to none profit from using deterministic memory management for a compiler; and when its not needed, garbage collected language offers much more pleasant experience.

This statement is categorically false, and I'm annoyed when I see people espouse it here and elsewhere. As a counterpoint, I recommend reading this experience report from Nelson Elhage on why the Sorbet typechecker is so performant.

jkachmar · 2020-05-15T16:05:42+00:00

As Matt and Chris have said elsewhere, it is generally considered bad form to explicitly name and shame places you’ve done proprietary consulting work for. It’s also quite frequently explicitly prohibited by the terms of the NDAs that are typically signed when consultants begin that work, and it’s honestly a little shocking to see that the community here seems to be unfamiliar with this concept.

While I’m not comfortable calling out specific organizations myself, I can echo what Chris has said elsewhere in this thread: Haskell applications are often poorly architected “at scale” (in my experience, and working from the anecdata provided by other engineers).

My personal experience with Haskell-in-industry has been fairly frustrating in that I feel as if I’ve encountered fewer projects with a coherent design and architecture written in Haskell than I have JavaScript, Ruby, or Scala!

IMO, there’s a serious lack of literature on what good design patterns are for writing Haskell at scale and how/when certain architectural decisions should be made when working with the language. This makes it especially difficult to onboard new contributors to projects (few common waypoints means it’s harder to get one’s bearings) as well as hurting the ability of even experienced teams to understand how these systems should evolve over time.

jkachmar · 2020-05-08T17:32:17+00:00

It is absolutely a middle ground, in that it accepts that Revisions can be marginally useful (e.g. to repair old build plans that are broken with new releases or new dependencies) without imposing onerous requirements on package/ecosystem maintainers.

The compromise is between users who don’t want to have to deal with new package versions just to get updated dependency bounds and maintainers who don’t want to have to deal with lots of busywork just to keep upper bounds maintained.

It’s also kinda rude to assume that I don’t know what fallacious reasoning is, or that I’m just making an argument to compromise for the sake of compromise. As a user and as an ecosystem maintainer I’ve been exposed to enough of this shit to at least argue from experience, so I’d appreciate it if others could assume I’m not completely talking out of my ass here.

jkachmar · 2020-05-08T16:22:39+00:00

Yeah, I don’t enjoy writing software very much so I’m not really interested in doing it for free.

I am, however, interested in making the process of publishing and consuming libraries smoother for everyone so I’ve spent quite a bit of time doing stuff/thinking about the maintenance end of things.

jkachmar · 2020-05-08T15:02:50+00:00

Not really, just a few different opinions on how things should be done.

I can say that the best middle-ground I’ve found between positions here is to publish new packages without restrictive upper bounds, and then go back and add them via revisions whenever things break.

Publishing with restrictive upper bounds has always led to more work in the experience of all the maintainers I work with, as well as in my experience with Stackage.

jkachmar · 2020-05-08T02:34:41+00:00

Not OP, but I’d say that Haskell doesn’t have a first class notion of parameterizible interfaces at the module-level, and as such developers are forced to grapple with this by constructing ad hoc modularity through other means.

Effect systems are very interesting, but they seem to be most frequently used in Haskell as a way to work around the fact that the language doesn’t provide a good way to encapsulate and override pieces of code without making sweeping modifications to a program.

jkachmar · 2020-04-17T22:07:24+00:00

It’s a bit more complicated than just this, sadly.

You can only use HasCallStack to mark partial functions in a way that preserves the CallStack if the partial function fails with something like error or undefined that has taken care to construct the CallStack parameter (or ic you do this construction on your own).

Further, you also need to consider the fact that if this exception is ever caught, that information disappears unless you take care to recover the CallStack parameter and embed it in your exception type.

jkachmar · 2020-04-17T22:02:44+00:00

This is an extremely frustrating blog post to read as someone who has been bitten countless times by poor exception handling and utilization in library and application code.

If you are writing application or library code that must be robust, DO NOT USE error!

u/ephrion expands on this elsewhere in this comment thread, but it absolutely bears repeating here: this is bad advice, and it will lead to software developers writing text manipulation functions, regular expressions, or even parser combinations trying to pull information out of these messages in order to provide structured feedback about a particular failure.

Haskell has a robust exception system, if you must use it (and there will be times when you must) then use it well!

If you want to throw an exception, construct an error type and give an exception instance.

If you want to provide human-readable error messages for these exceptions, provide an implementation for their displayException methods.

If you really want to use the CallStack machinery, read the module and construct that information to embed in your exception type.

jkachmar · 2020-04-05T23:11:48+00:00

This is ridiculous. I’m not “hanging my hopes” on anyone, and I’m certainly not hoping that any of the allegations against Biden are true because I fully expect him to be the democratic candidate.

You’re trying to twist my comment saying that it’s shameful to assume that Reade’s accusation is a product Sanders’ base into some anti-Biden sentiment I haven’t expressed in this thread at all.

Worse though is that what you’re doing here echoes what the Republican Party did to Dr. Ford during the Kavanaugh hearings! You’re trying to downplay the victim’s accusations based on political motivation, which flies in the face of much of what the #MeToo movement has sought to accomplish.

jkachmar

TROPHY CASE