freyrs3

You have to appreciate the audacity of some of the portfolio companies in Fund I for getting away hilariously bad business models. They literally fleeced Chris Dixon into funding Pied Piper (dfinity.org) and crypto kittens and he actually bought it. There's definitely some massive sunk cost effect going on with this new fund on a scale we haven't seen before. Anderssen used to be the smart money in VC and now they're doing this fund.

Showing how Yang-Mills and SU(3)×SU(2)×U(1) fall out would be a natural starting point for a proposed unification theory. This model doesn't even try explain the existing particle hierarchy as a special case.

Ain’t that cool?

Oh it is! Now never use this.

If you want a description of the monad laws in Haskell terms you can Google and find like 80 expositions on the topic of various depths.

If you want a mathematical exposition. "Category Theory" by Awodey page 265 is a concise description.

Their usage in Haskell/OCaml etc is precisely faithful to their category theoretic definitions as can be in a general purpose language.

This debate about naming monads is pretty tiresome after so many years, if one called it "computation builder" it wouldn't change their structure or convey any notion of the laws any better than term monad. A monad at it's core is a set of algebraic relations.

The way this problem manifests in Haskell is in how incredibly clever it makes you feel to get something done in it. Haskell is different enough from most languages that everything feels like an achievement when writing it. “Look, I used a monad! And defined my own type class for custom folding of data! Isn’t that amazing?“. “What does it do?” “It’s a CRUD app”.

The fallacy here is that type classes, folds and monads are not esoteric structures within the context of Haskell, and using them to structure regular business is pretty mundane. If someone feels a sense of achievement from doing this, they're probably very new to the language. The author of the article has baked in a value judgement about the "normal" way to structure a CRUD application that precludes alternative approaches to structuring application logic.

You could just as well argue that laying out object class hierarchies and using inheritance is "[solving problems] that have nothing to do with what you’re actually trying to achieve."

It has two different parsings:

    avoid (success at all costs)
    (avoid success) at all costs

It's not a hot technology ( read as overhyped ), but if you're in the analytics space and not using Python/PyData tooling then definitely check that out. It's certainly as mature, if not more so than R.

The academic type theory mentioned in this post is not really terribly important to implementing type systems for general purpose languages. There's this growing divide between the engineering discipline of type systems in general languages and the pure theory people who seem only interested in theorem provers and constructive math.

Strictly speaking Hindley-Milner is the type system that itself admits tractable inference using the usual unification techniques via the Damas-Milner family of algorithms. Gradual typing itself uses type inference in the Damas-Milner family, although it diverges with it's notion of consistency.

Wadler's Law: https://www.haskell.org/haskellwiki/Wadler%27s_Law

    In any language design, the total time spent discussing
    a feature in this list is proportional to two raised to
    the power of its position.

           0. Semantics
           1. Syntax
           2. Lexical syntax
           3. Lexical syntax of comments

There were some interesting attempts trying to adapt LLVM's precise GC to Haskell's GC model and the difficulties with this approach: http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-w...

This is extremely well done, thanks for taking the time to make a screencast.

The elephant in the room in these discussions is that the cost of bringing a function compiler to fruition is so high that too much of the discussion gets muddled in the semantics of these hypothetical Haskell-successor languages while no one is actually working on said language. Academia simply isn't set up to incentivize large engineering projects, and industry would never invest in building such a thing either since there's no profit in language dev sadly.

The blunt truth is that at the end of the day Haskell works today, period, and until someone actually forks or starts writing a new language very little of these criticisms of Haskell actually matter if the answer to "what should I use for my project at work" is "well it doesn't exist yet, but it has modules and extensionality and a magical pony that shits money".

Might as well start worrying about an airborne mutation of HIV while we're at it. Wouldn't start heading for the bunker just yet.

I can't even begin to parse what you're trying to say or how it relates to my last comment.

Quite sure, in a dynamically typed language there is only a single static type inhabited by all values. If the compiler is reasoning about classes of values at runtime then it does indeed have nothing to do with static typing.

When is a language untyped

There's the formal definition of type and there's the colloquial definition of type. A type in the context of the article means a formal type, it is an syntactic classifier that is part of the static semantics of the language. The properties you describe ( string/number exceptions ) are part of the dynamics of the language, which is a separate concept. Dynamically typed languages quite often use boxed values with an attached runtime tags which are colloquially referred to as "types" even though they have nothing to do with static types.

If you read the article in the context of "type" meaning "static type" it will make more sense.

Because you've defined "safety" to encompass several orthogonal concepts and as such is meaningless. If you look at each axis on it's own ( type safety, memory safety, exceptional safety ) then Haskell will come out as safer than nearly any other available tool.

Safety as you're using is not the concept that Haskeller's refer to when they talk about the language. "Type safety" is a very precise term that refers to several proofs about the semantics of the language.

See: http://jspha.com/posts/all_you_wanted_to_know_about_types_bu...

The complaints in the article don't really generalize at all. It seems to just be a rant about why targeting the JVM from a functional language can yield non optimal code without certain program transformations. Haskell and OCaml don't have the problems mentioned here at all. I wish the title actually reflected the content rather than just being kind of antagonistic about functional programming.

There is an ambient culture of code reuse at a level I don't see elsewhere, that's one of Haskell's strength's in my opinion. Though it does make certain packaging problems more difficult.

Wouldn't say that the community is gravitating toward Nix, it's kind of a false split since Cabal and Nix can only be used together and Nix can't replace cabal. Though Nix can be used to manage a wider package environment than cabal-install can and then cabal is left to the role of a Haskell build system which it excels at.

Oh, we most certainly do have a choice, especially as developers. If enough of us don't support their infrastructure or buy their products then we most certainly can effect change and their bottom-line. Don't be upset and powerless, be proactive and don't support Apple in any way.

It is more difficult. By design Haskell shifts an enormous number of failure modes to compile-time and as such cabal gets an unnecessary amount of blame for library bugs. If you ``pip install`` a package that transitively dependencies on another library where the author has accidently introduced a backwards incompatibility in the API that occurs in 5% of use-cases, pip won't detect the change and will happily install the package and 95% of people will assume no problem exists until they hit a runtime failure. The job that pip has to do is trivial actually. In Haskell if there is an incompatibility that breaks the interface, and in the presence of "wild west" packages there will be, then it will manifest as a compile time build error instead of proceeding.

Like many people have pointed out, cabal and npm are not solving the same problem. npm appears to "work" more often because a whole class of problems in Javascript program are deferred to runtime while in Haskell all interfaces have to be compatible, link properly and compile. That's why "cabal hell" is such an imprecise term because on top of the version bound issues it's also used for any and every failure that happens when using cabal, even if it's the library in question that's to blame and not cabal. If you want to consider a similar problem, take 20 interdependent C++ libraries and try to link them into a single application using just version information and see how often that works out of the box.

If the core developers have committed to remaining C-ABI compatible with py3 until 2023 then there's basically no way anyone could fix the GIL. It would mean breaking ABI compatibility on the garbage collector and the interpreter. I find this aspect of the proposal kind of disturbing since it effectively prevents anyone from even trying to solve concurrency problems in mainline CPython for another decade.

You'd end up building a small functional runtime. That's a fun project to understand compilers better. But given that Haskell types are erased at runtime the very thing that makes monads monads wouldn't even be around anymore. All the values would be represented uniformly by some *StgClosure struct and the whole program would just be a mess of casts and projections into these values.

I try to put myself in the mind of someone who works in a language in which type notions like ( t : * -> * ) and ( a -> t b ) are completely inexpressible I can see how it can be hard to wrap your head around monads. I think a lot of the communication problem about monads is fundamentally a problem that higher types and parametric polymorphism are just not part of the general programmer knowledge and there's no reference point to understand the signatures.

C is probably the worst language to implement monads in because the type systems really lacks polymorphism, higher order functions and any sort of type-class overloading to clean up the syntax. I mean you could hypothetically pass around a record full of void function pointers to get around all this, but it would be so ugly and unintuitive that it would be silly to try and explain monads this way.