"Traditionally, testing was often relegated to the final stages of development, just before the release"
I was going to dismiss this as another strawman - the same strawman that we've been whipping since Winston Royce, 1970.
But then I see:
"At the outset of a project, during the planning phase, testers should collaborate with developers and stakeholders to understand the requirements and define clear, testable acceptance criteria."
"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.
@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.
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.
@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).
@vitonsky this link is political. Do not click it! (You know, for security reasons)
@atzanteol @kogasa bullshit
@paf0 @neme Nope. People will put up with anything.
@DmMacniel @vzq
> Given the nature of JS running only on a single thread.
No no, I think you found the language flaw.
@planet @clojure
"Traditionally, testing was often relegated to the final stages of development, just before the release"
I was going to dismiss this as another strawman - the same strawman that we've been whipping since Winston Royce, 1970.
But then I see:
"At the outset of a project, during the planning phase, testers should collaborate with developers and stakeholders to understand the requirements and define clear, testable acceptance criteria."
How did we get back to waterfall?
@DanTDM
"you will begin to associate “easy to learn with cool features” as the worst mistake that the language made."
No JS Dev has ever behaved that way.
@Kecessa no you missed my point. You change the behaviour of the producer, not the consumer.
@Kecessa @grue knowing that the source will be published discourages bad actors from putting crap into the program in the first place.
And if they do it anyway, other people can come along and repackage it without the bad bits, like vscodium.
@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).