John

@eveninghere @ruffsl that claim’s correct. But so far it doesn’t have great performance on a single core.

@errer @pro_grammer

I believe that the trick is not to show the developers the bill.

Let the developers all tell each other “it’s cheap because you don’t have to buy the servers; you only pay for what you use!”

Only managers see the real price.

@armchair_progamer

Awful naming. Forgetting the fortune 500 company you’re already thinking of, there’s already a Meta Lang, abbreviated to ML.

Besides that, does it have any ‘meta’ features? E.g. Homoiconicity?

@okamiueru @balder1993

It’s an overloaded term:

“Dependency inversion” is a language-agnostic technique for producing testable, loosely-coupled software.

“Dependency injection” just means dependencies should be passed in through the constructor, instead of being magically new()'d whereever.

“DI frameworks” are Satan’s farts. Classpath-scanning nonsense that turns compile-time errors into runtime errors. Not only is your Ctr still coupled to your Svc, but both are now coupled to Spring.

@onlinepersona

An enum is a sum type because the number of inhabitants of the enum is the sum of the inhabitants of its parts.

A product type’s number of inhabitants is the product of its parts’ inhabitants. So a struct would fit that definition, or a pair, or a tuple.

Looking at the pic on your Cartesian product link:
if A is an enum {x,y,z} and B is an enum {1,2,3}, then a struct AxB has 9 possible inhabitants.

@onlinepersona @armchair_progamer

A type has a number of ‘inhabitants’. ‘Sum’ indeed corresponds to adding the possible inhabitants together.

A Boolean has two inhabitants - true and false. A byte has 256 inhabitants. A BoolOrByte type has 258 inhabitants.

If you have BoolByte pair, that’s a product type - 512 possible inhabitants.

It may make no fucking sense depending on your exposure to Java, where Void (literally ‘empty’) has an inhabitant, and Boolean has 5.

@Windex007
> You as the writer, you don’t know either?
Not until the compiler tells me.

> Or is the argument that nobody but the compiler and god need know? That having an awareness of the types has no value?
No, I want to know, because knowing the types has value. If the compiler has inference, it can tell me, if not, it can’t.

@Windex007

lexer :: Parser LexState (Vector Int, Vector Token)
lexer = do
(positions, tokens) <- _ nextPositionedToken
…

What goes where the underscore is in the above snippet?

@Windex007 @snowe

Yes. Type-inference typically *knows better than me* what the types should be.

I frequently ask the compiler what code I need to write next by leaving a gap in my implementation and letting the compiler spit out the type of the missing section.

@demesisx @lysdexic No safety issues mentioned around ReaderT. The speaker was talking about how stacking monad transformers mtl-style can generate unnecessary closures that GHC can’t optimise away.

@tatterdemalion @armchair_progamer
No.
Elaborate?

@armchair_progamer no mention of (mutual) recursion? It’s been a while since I worked on my type checker, but I thought that you needed to separate inference into unification variable generation and constraint solving so that you don’t fall into an infinite loop (each function asking the other functions type - forever).