joel_ms

Crypto really is the grotesque despressive clown staring our desperate civilization in the face, while futily screaming about our all consuming absurdity.

Crypto works fine in a world that is not addicted to burning fossil fuels.

Unfortunatly, we live in a world that is not only desperately addicted to them, but literally subsidizes the consumption of fossil fuels.

joel_ms

6 lat temudiscuss

>I'm personally of the opinion that less is more.

I used to have this position as well, writing everything in either assembly or pure lambda calculus, to avoid all these pesky higher level language features.

joel_ms

6 lat temudiscuss

So scala is neither taken over or destroyed and the author of this post stresses multiple times that he does not suggest that this approach by adopted by the rust community, even concluding with:

>But Rust is not Haskell. The ergonomics of GATs, in my opinion, will never compete with higher kinded types on Haskell's home turf. And I'm not at all convinced that it should. Rust is a wonderful language as is. I'm happy to write Rust style in a Rust codebase, and save my Haskell coding for my Haskell codebases.

How is any of this fanatical?

joel_ms

6 lat temudiscuss

>In many cases there are actually several layers of popups obscuring the content, and some are delayed so they only pop up after you start reading the content.

I swear I've had ones that popup as I move the mouse to close the tab.

joel_ms

6 lat temudiscuss

Interestingly, he does not consider the Holomodor to be a genocide against ukrainians.

https://www.theguardian.com/commentisfree/2008/apr/03/swallo...

joel_ms

6 lat temudiscuss

Thank you!

I was more wondering how time leaks and laziness relates to denotational vs operational semantics? I couldn't find anything about either in the links (they seem to be general descriptions of haskell and laziness..?).

joel_ms

7 lat temudiscuss

Last year, the US bought more than all of Europe. Asia is still the big buyer tho

https://www.washingtonpost.com/world/2019/09/16/who-buys-sau...

joel_ms

7 lat temudiscuss

>this is a curse that's almost unique to Haskell—the language is also prevented from utilizing future improvements to sorting algorithms!

Back in reality of course, Haskell has fast, generic, linear-time sorting: https://hackage.haskell.org/package/discrimination

joel_ms

7 lat temudiscuss

Given the speaker, I'm guessing the suggestion is that the incident sowed the seed for him to develop Hoare Logic[0]

[0] https://en.wikipedia.org/wiki/Hoare_logic

joel_ms

7 lat temudiscuss

That's the attitude that's running our civilization to the ground...

joel_ms

7 lat temudiscuss

>To be honest, I find the idea of passing a parameter to Log() (whether it's the value or the function) that your don't actually want logged, so that you can shoehorn two statements into an expression, abhorrent.

You've basically reimplemented Haskell's Debug.Trace[0] :)

The difference is of course that Haskell doesn't really have statements in the same way that C# does, so in Haskell it's nescessary to turn the log/trace-function into an identity function after you've applied the message-string.

I agree that it is ugly, and in any serious project I would use a proper logging setup, but I almost feel like the ugliness is a feature not a bug. It's like an extra cost when doing debug-by-print, which at least seem to keep me more mindful about cleaning up after myself.

[0] http://hackage.haskell.org/package/base-4.12.0.0/docs/Debug-...

joel_ms

8 lat temudiscuss

I got used to this in Haskell, but I have to say that Elm's solution is pretty elegant:

  Elm:               Haskell:

  f <| g <| x   ==   f $ g  $  x    -- application

  f << g        ==   f . g          -- composition

  x |> g |> f   ==   x & g  &  f    -- reverse application

       g >> f   ==       g >>> f    -- reverse composition

It's nice to be able to change between composition and application by changing between | and < in the operator. I've actually done this quite a lot when refactoring code in Elm lately, there's something visual and intutive about it that I like. It makes it easier to mix left-to-right and right-to-left in the same code, while keeping it obvious what's going on.

I've found that certain parts, that scan/read better as imperative steps (think chains of List.map, Maybe.map, <MonadlikeModule>.andThen etc.) often benefit from a reverse application and/or composition. Sort of to simulate the look of do notation since Elm doesn't have that. Smaller functional parts are better with regular application/composition. With the directional operators, this becomes quite ergonomical.

Probaly helps that I use (and enjoy, ymmv) a font with ligatures for these symbols.

joel_ms

8 lat temudiscuss

>His point about `Either a b` was perhaps further from the mark. It is not a data type that represent logical disjunction. That's what the logical connective, disjunction, is for. Haskell doesn't have union types to my knowledge. Either is not a connective. It's a BiFunctor. His point that it's not "associative" or "communtative" or what-have-you simply doesn't make sense. In fact he calls Either "malarky" or, charitably, a "misnomer."

I don't agree with Hickey, but isn't there a connection between Either as a basic sum type and logical disjunction via the curry-howard correspondence?

And wouldn't "forall a b. Either a b" be the bifunctor, since it has a product type/product category as it's domain, while the result "Either X Y" (where X and Y are concrete types, not type variables) has the semantics of logical disjunction ie. it represents a type that is of type X or type Y?

joel_ms

8 lat temudiscuss

Yeah, you're right, I got confused when interpreting the parent comment. Thanks for pointing it out!

I guess I overlooked it because the other way is so logically trivial, since it basically boils down to A -> B => (A || Nothing) -> B, which is just an or-introduction. So if you wanna implement Maybe generically the "work" lies on the other side.

But since Hickey's argument sort of is that we shouldn't implement Maybe generically, I guess my argument here becomes circular. (Begging the question maybe?)

joel_ms

8 lat temudiscuss

> Why is it illogical to say that a Maybe a -> b should be callable as if it were a -> b?

Fundamentally because it would require you to conjure up a value of type b from nowhere when the Maybe a is Nothing. If we view the function type as implication this would not be valid logically without some way of introducing that value of type b.

You could imagine some function from Nothing -> b that could rescue us. But since it only handles one case of the Maybe type, it is partial (meaning it could give undefined as an answer). There is basically two total functions that we could change it to:

   * Maybe a -> b in which case we are back where we started.
   *  Unit -> b which essentially is just b, which can be summed up as meaning we need some kind of default value to be available at all times.

So to be able to call Maybe a -> b as a -> b you would need some default value available at all the call sites for a -> b

Now this is only "illogical" because we don't postulate a value of type b to be used as this default.

> It's like saying (+) works on integers, but not on 3

No, it's like saying (+) must work on all integers AND a special value nil that is not like any other integers, but somehow included in them and all other data types. We can't do anything with this nil value since it doesn't carry any data, so in the case of (+) we would essentially have to treat it as an identity element.

This is good though, since (+) has 0 as an identity element, so we can just treat nil as a 0 when we encounter (+). However, when we want to define multiplication we still need to treat nil as an identity element (since it still doesnt carry any data), except the identity element for multiplication is 1. This would be repeated for every new function that deals with integers.

So by mashing together Maybe and Integer we have managed to get a frankenstein data type with an extra element nil which sometimes means 0 and sometimes means 1.

Why not just decompose them into Maybe and Integer and supply the default argument with a simple convertion function like fromMaybe?

(FWIW, I actually agree with Hickey that using Maybe in api design is problematic and I've encountered what he's talking about. But while that might be an argument for where he wants to take Clojure, it's not an argument for dismissing type theory the way he does.)

joel_ms

8 lat temudiscuss

Then they decided to stop improving IE6 (outside security updates) because they (correctly) realized that the web was a threat to the company. IE7 was released 5 years later, literally due to the pressure of other browsers on web standards support.

That's when IE 6 sucked, and we all had to live with that suckiness for years on end because of microsofts insane backwards compatibility policies keeping deprecated software alive on life support.

Even Microsoft has a IE6 countdown timer now https://developer.microsoft.com/en-us/microsoft-edge/ie6coun...

IE6 was an unfathomably damaging disaster for the web.

joel_ms

8 lat temudiscuss

The damage done to human culture by our current copyright enforcement regime is heartbreaking.

We have to means to make human cultural output accessible to unprecedented numbers of people around the world, but we don't, largely because it would interrupt the flow of money to incumbent rent-seekers.

joel_ms

8 lat temudiscuss

Makes me think that we've already made the same mistake with fossil fuels and climate change :/ (Tangible benefit: material wealth and prosperity. Theoretically valuable: a balanced ecosystem)

(not to start an off-topic discussion about that, but just an observed parallell)

joel_ms

8 lat temudiscuss

How so? I've always felt that intuitionism/constructivism were closer to theoretical computer science due to constructivism requiring you to produce (or compute) the what you're trying to prove.

joel_ms

8 lat temudiscuss

> A (data) type is a set, and a value is an element in that set.

Nope, a type is not a set. Type theories are separate formal systems designed to be (among other things) computationally aware alternatives to set theory, and they are defined by "terms", "types" and "rewrite rules". The whole point of a dependent type theory is to be able to encode things like sets and propositions in the same formal system.

The rest of your comment is wildly off based on this misunderstanding.

What the GP was probably referring to is the persepctive of dependent types from the lambda cube, where you have three different extensions to simply typed lambda calculus's regular functions from value to value:

    1. Parametric polymorphism, which are functions from type to value
    2. Type operators, which are functions from type to type
    3. Dependent types which are fubnction from *value to type*

Since dependent types allows functions from value to type, it kinda erases the artificial barrier between type-level and value-level. In reality it doesn't really erase it, somuch as replace it with an infinte hierarchy of levels to avoid Girrard's paradox.

Submissions

HBO Nordic is having server issues

comments