Oriel Jutty :hhHHHAAAH:

If you were pair programming, your pair could always create a new failing test with the current implementation.

But I’m not pair programming. And you can’t always create a new failing test because int is a finite type. There are only about 4 billion cases to handle.

Which might take a while to type up manually, but that’s why we have meta-programming: Code that generates code. (In C++ you could even use templates, but you might run into compiler recursion limits.)

More to the point, the risk with TDD is that all development is driven by failing test cases, so a naive approach will end up “overfitting”, producing exactly the code required to make a particular set of tests pass and nothing more. “It can’t pass all test cases”? It doesn’t have to. For TDD, it only needs to pass the tests that have actually been written. You can’t test all combinations of all inputs.

(Also, if you changed this function to use modulus, it would handle more cases than before, which is a change in behavior. You’re not supposed to do that when refactoring; refactoring should preserve semantics.)

When you say “it can’t pass all test cases”, what do you imagine the tests look like?

Any ticket system that doesn’t even let you copy/paste text snippets in (like, say, a bit of JSON from a log file) without messing up the rendering¹ is terrible.

¹) In two different ways: The rich text editor mangles data one way, but when you submit your comment, Jira mangles it in a different way. You never know what you’re going to get.

@devilish666 C++ (non-stupid):

#include <stdio.h>
int main() {
puts(“Hello, world!”);
}

Prost! 🍻

C) It’s an obvious joke.

s/diplomated/graduate/
s/branche/industry (sector)/

Isn’t that how B worked?

Similarly, Perl lets you say

my $ret = do {    if (...) {        ...    } else {        ...    }};

To be fair, the C example could be detangled a lot by introducing a typedef:

typedef int Callback_t(int, int);Callback_t *(*fp)(Callback_t *, int);

Both of those declarations look weird to me. In Haskell it would be:

a :: Stringbob :: (String, Int, Double) -> [String]bob (a, b, c) = ...

… except that makes bob a function taking a tuple and it’s much more idiomatic to curry it instead:

bob :: String -> Int -> Double -> [String]bob a b c = ...-- syntactic sugar for:-- bob = \a -> \b -> \c -> ...

The [T] syntax also has a prefix form [] T, so [String] could also be written [] String.

OCaml makes the opposite choice. In OCaml, a list of strings would be written string list, and a set of lists of strings would be string list set, a list of lists of integers int list list, etc.

Because let x: y is syntactically unambiguous, but you need to know that y names a type in order to correctly parse y x. (Or at least that’s the case in C where a(b) may be a variable declaration or a function call depending on what typedefs are in scope.)

include Hebrew in their language, because I guess they were feeling kabbalistic

… or because the developers were Israeli: https://en.wikipedia.org/wiki/Zend/_(company)#History

I am 100% confident that your claim is factually wrong.

I agree with your core point, but no software is intuitive.

POV: You open vim for the first time.

b == 7 is a boolean value

Citation needed. I’m pretty sure it’s an int.

Do you know the difference between a script and a program?

A script is what you give the actors; a program is what you give the audience.

I don’t understand the complaint. What exactly is the issue?

I’ll update my mems when Microsoft decides to implement C99. (Hey, it’s only been a quarter of a century …)