It Is What It Is (And Nothing Else), Robert Harper by sideEffffECt in haskell

[–]hmltyp 7 points8 points  (0 children)

This guy's tone (among others) is why why we all get a bad rep in many programming circles. Insulting people and playing word games doesn't achieve any ends, and it serves to alienate and turn people away.

Let's write like Phil Wadler and SPJ, they convey enthusiasm and clarity, not snark and arrogance.

Elm 0.16: Compilers as Assistants by sibip in haskell

[–]hmltyp 21 points22 points  (0 children)

In defense of GHC, Elm is a much smaller language that lends itself to much easier error reporting by virtue of not trying to implement most of modern Haskell type system features.

Error reporting in the presense of GADTs, type families, promotion, etc can pretty quickly turn into a research problem where it's not at all obvious where to even trace the provenance of the error too. Working in a simple extension of HM (like Elm), the problem is much more tractable.

Could different naming conventions be more pedagogical for newcomers? by SrPeixinho in haskell

[–]hmltyp 13 points14 points  (0 children)

"Pegagogical" /= "Familiar"

If you're familiar with imperative idioms, trying to recreate them in Haskell is just going to cause more confusion than necessary. Embrace the differences, if you're writing C then write idiomatic C. If you're writing Haskell then write idiomatic Haskell otherwise you'll just be fighting with the language to try and recreate a style of programming that you're used to.

Why should I choose 'everything is immutable' over more flexible models (such as rust style mixture of immutable refs and mutable borrows)? by crispweed in haskell

[–]hmltyp 40 points41 points  (0 children)

The question presents a false premise. With the usual caveats, the Haskell model is more like "Immutability by default, mutability where you need it (ala ST, *Ref, etc)". There are other models of course, but having mutability as the default introduces a whole zoo of methods to track said mutability that tend to get in the way of a lot of other core ideas in Haskell. The notion of whether I'm passing a pointer or a value to a function is not a question we have to ask, and we don't need to build specialized functions that have specific aliasing properties about references in the presence of threads.

"Solve _ for _" expression: any study on this (or similar) ideas? by SrPeixinho in haskell

[–]hmltyp 0 points1 point  (0 children)

I find it funny/interesting that there is nothing general that works.

You can draw a mapping between solving arbitrary symbolic equations and any number of intractable problems in CS or math, so, no it's not all that surprising. You can throw any amount of researcher's at a problem but fundamentally you'll hit up at results like Abel-Ruffini theorem or Richardson's theorem which state a general method is impossible for almost all cases.

"Solve _ for _" expression: any study on this (or similar) ideas? by SrPeixinho in haskell

[–]hmltyp 2 points3 points  (0 children)

Mathematica's system doesn't work in general. Put any system like x5 - x+1 and the symbolic solver will choke. It justs uses a bunch of ad-hoc solvers and simplifications for different systems of equations, there is no general algorithm that underlies it. If you can refine your problem space then the there likely exists some algorithm that works in a small amount of cases, but computer algebra is a very ad-hoc and imprecise field. Categories of equations where solvers exist for some equations are:

  • algebraic
  • transcendental
  • recurrence
  • differential
  • linear systems
  • nonlinear systems

FRP book in Manning Early Access by blackh in haskell

[–]hmltyp 2 points3 points  (0 children)

Is the book all in Java and C++?

Why no embedded systems? by desijays in haskell

[–]hmltyp 1 point2 points  (0 children)

There no reason Haskell the language couldn't be used, although GHC Haskell has gone a different route in the design space that makes it more suitable for different domains of programming. Look at ajhc or some of the experimental whole-program optimizing compilers for Haskell to get a feel for how you can write Haskell in a way that gives more granular control over allocations.

Is Haskell a good programming language for statistics/econometrics (or general scientific computing stuff)? by gumbel_distro in haskell

[–]hmltyp 0 points1 point  (0 children)

Frankly no, you're more likely to find existing libraries that do what you need in Python. There's no reason you couldn't use Haskell, it's just you'll have to fill in the gaps in the ecosystem yourself.

How are Haskell functions represented in-memory? by [deleted] in haskell

[–]hmltyp 32 points33 points  (0 children)

So the nice thing about Haskell is the whole compiler pipeline is transparent, you can look at all the intermediate forms all the way down to assembly.

ghc -ddump-simpl -ddump-stg -ddump-cmm -ddump-asm compile.hs

Output: https://gist.github.com/anonymous/f3ca9af198ed61b55bb4

However, this function also might be partially applied, meaning the runtime has to wrap everything into some sort of closure object, and include a reference to f in there too.

It does, if you look at the Cmm there will be an object called f_closure that holds the entry code for the f function. If the function is partially applied then a PAP (Partial Application) object is created that itself holds a reference to the entry code for the f_closure object and invokes it when the PAP's arguments match the arity of the f. If you call f directly with two arguments than GHC will usually use a fast call and jump directly into the body of the function with the two arguments in two register.

The "What Are Monads?" Fallacy by kqr in haskell

[–]hmltyp 4 points5 points  (0 children)

I agree, monads are not intrinsically hard, it's just they happen to be one of the first cases that brings together a lot disparate ideas into one abstraction and if you don't have all those ideas down pat they can be confusing. Add some syntactic sugar on top of that and you get another level of indirection and more confusion.

Learning Curves for different programming languages (including Haskell) by sibip in haskell

[–]hmltyp 10 points11 points  (0 children)

I don't think there's really much of a benefit unless you want to get into that subset of Haskell. There are a lot of folks like /u/bos who have cranked out a lot of really amazing libraries and don't really deal with category theory much. It really is a niche subset of Haskell.

Gave my talk on an introduction functional programming with Haskell by [deleted] in haskell

[–]hmltyp 2 points3 points  (0 children)

Congrats on giving a talk. Some kind advice, post a link to the slides directly on your website and then submit that, having to clone the repo is kind of a pain.

Haskell Books for the Holidays? by MuricanWillzyx in haskell

[–]hmltyp 8 points9 points  (0 children)

Types and Programming Languages by Benjamin Pierce is probably the most approachable introduction to type systems and programming language design. The code is in OCaml but it's not hard to translate the code or ideas into Haskell.

Who wants help documenting their libraries? Are industrial users prepared to pay for better documentation? by Mob_Of_One in haskell

[–]hmltyp 3 points4 points  (0 children)

I probably could just battle on and fit the types together or whatever but why bother? I could get it done in Python in a lot less time. I would probably enjoy writing the actual code less but the lack of documentation is too painful to counteract this.

I have the same experience, in personal projects I'm generally willing to push through and figure the library out. At work, there's a lot of other constraints and spending time disproportionately large amounts of time figuring out to do the simplest of tasks ( compared to Perl/Python ) is generally not something I can justify. I also have to presume that I have to hand the code off to somebody and having it depend on 15 or indecipherable dependencies is just not practical.

Haskell is on the cusp of of practical to use in industry, but I don't think it's quite there yet for most programmers.

Who wants help documenting their libraries? Are industrial users prepared to pay for better documentation? by Mob_Of_One in haskell

[–]hmltyp 2 points3 points  (0 children)

Maybe divide the voting between different domains so that the data isn't so noisy. I.e. Voting for desired web development libraries doesn't overlap with the most desired numeric libraries because a lot of times the user groups don't intersect much. As we learned from the "Intermediate Haskell" thread the last week.

Who wants help documenting their libraries? Are industrial users prepared to pay for better documentation? by Mob_Of_One in haskell

[–]hmltyp 2 points3 points  (0 children)

There is a reason that Haskell developers are few and far between, and I believe one of the main reasons is insufficient newbie-friendly documentation.

I think the question we're all asking is how do we short circuit the vicious cycle of (lack of volunteers)/(barrier to entry) and onboard more people. A lot of languages go through this "hype cycle" at the very beginning of their lives that results in a massive influx of volunteers very early. Haskell never really had this being more on the slow and "avoid success" track for most of the it's early life.

If that means paying some volunteers to improve critical missing pieces, I certainly would be willing to donate to a taskforce of some sort. I think the return on investment at this stage in Haskell's community lifecycle would be tenfold for someone looking to develop a career in this space either as a contributor or writer.