“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?
@Kecessa no you missed my point. You change the behaviour of the producer, not the consumer.
@eveninghere @ruffsl that claim’s correct. But so far it doesn’t have great performance on a single core.
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.
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?
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.
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.
lexer :: Parser LexState (Vector Int, Vector Token)
lexer = do
(positions, tokens) <- _ nextPositionedToken
…
What goes where the underscore is in the above snippet?
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.
@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).
@DmMacniel @vzq
> Given the nature of JS running only on a single thread.
No no, I think you found the language flaw.