Oriel Jutty :hhHHHAAAH:

I disagree with pretty much everything you write here, but especially this:

First of all, you have exact same amount of parens as you would in a mainstream language like Java, C, or Js.

My Perl example uses “mainstream language” syntax. Apparently that doesn’t count because it’s Perl (scary! mental overhead! write only!), so here’s exactly the same thing in JavaScript:

function hypot(x, y) {    return Math.sqrt(x ** 2 + y ** 2);}

… or

const hypot = function (x, y) {    return Math.sqrt(x ** 2 + y ** 2);};

… or

const hypot = (x, y) => Math.sqrt(x ** 2 + y ** 2);

Note how none of these involve four layers of nested parentheses.

OK, my code snippets are Common Lisp. But note that none of them involve list/vector/set literals. I was thinking of [] for array indexing and {} for code blocks.

As for infix macros, sure, that’s not hard to do, but it’s not built into the language and there being “plenty of libraries” is part of the problem: They’re all subtly different, none are standard, and I suspect most people don’t use them anyway. (Plus there’s fun little design issues like whether a*x + b should parse the same as a * x + b, and if it does, then how do you refer to a variable called a*x from an infix environment?)

It doesn’t solve the main issue anyway. Take this snippet from the “infix” readme:

(def hypot  (fn [x y]    (infix sqrt(x ** 2 + y ** 2))))

It ends with a cluster of )))) (reinforcing the “lots of parentheses” impression) and all of those parentheses mean something different: From the outside in, we have the end of a symbol definition (def ...), the end of a function (fn ...), the end of a macro invocation (infix ...), and the end of a function call sqrt(...). It definitely isn’t just “the same number [of parentheses] as any other language that uses parentheses to make function calls”.

Compare e.g. these versions written in Haskell:

hypot = \x y -> sqrt (x ** 2 + y ** 2)

… or Perl:

sub hypot($x, $y) {    sqrt($x ** 2 + $y ** 2)}

… or if you want to separate the function and symbol definition parts:

*hypot = sub ($x, $y) { sqrt($x ** 2 + $y ** 2) };

This is false. Lisp uses parentheses where other languages use (), [], {} or nothing at all. For example, in C I can write int i = 0, but the equivalent Lisp code involves three pairs of parentheses. Or take something like a[i] = f(i + 1) / 2 + p. The equivalent Lisp code is something like (setf (aref a i) (+ (/ (f (+ i 1)) 2) p)), and you can’t tell me that’s not a lot of parentheses.

I, too, love living in a society that never makes errors, ever, as I myself am quite infallible. https://www.web3isgoinggreat.com/

Transfers are predictable and rapid.

And don’t forget how easy it is to reverse them in case of error.

That’s just syntax.

>>> 10 .yearsTraceback (most recent call last):  File "<stdin>", line 1, in <module>AttributeError: 'int' object has no attribute 'years'

Does Ruby require the use of [] and {} there? Because those %w/%i/etc things look like custom quoting operators and at least in Perl you can use any delimiter you want: qw(a b c) is a list of strings, but so are qw+a b c+ and qw;a b c;.

I like the original.

$ python3 -c 'f = (lambda x: x + 0.5 - 0.5); print(f(2**52))'  4503599627370495.5

#python

If you had let me write the C++ code, I could have literally destroyed your dataset in a couple of seconds.

I believe now it is my turn to say you’re spewing nonsense. Have you ever used a language with a type system? Because this whole idea of “testing external data to see if it is the right type” doesn’t really make sense.

At the lowest layer, generally, external data is an array of bytes. It has no other type you could “test”. However, you can decode or parse it into a form that makes sense for your program. And why couldn’t I cleanly recover from parse errors? (And how do you think Python does it?)

Again, “strong types” doesn’t mean anything.

But from a type theory perspective, having “dynamic types” absolutely means you don’t have a type system. All Python has is runtime exceptions. The fact that one of them is named TypeError doesn’t make it a type error in the formal sense.

The point of a type system is not that variables have types, but that types are assigned to expressions (i.e. pieces of code in your source file), not to values (i.e. pieces of data). This is important because it guarantees that certain errors cannot occur in a program that passes the type checker (assuming you have a sensible/useful type system). And you get this assurance without running a single line of code.

To get a similar guarantee from Python, you need to write exhaustive tests, just as with any other runtime error.

“Strongly typed” is meaningless. (Or nearly so; in practice it means “I like this language” and “weakly typed” means “I dislike this language”.) The point is that Python has no type system.

Python is un(i)typed.

Haskell.

Only since 2014, so barely over a decade.

BTW, you can configure uBlock Origin to block all 3rd party javascript by default, but allow 1st party scripts, so you don’t even need NoScript to get most of these benefits.

There’s a lot of distorted facts here, but the weirdest one to me is “instead of regrouping their efforts (which, I might add, they did, and they got their day in parliament)”. The first half just contradicts itself (“instead of doing X, which they did, …”???) and the second half (“they got their day in parliament”) is verifiably, obviously false: The EU petition is still ongoing and collecting signatures. The deadline is July 31.

@tetris11 @Aedis More like:

isEven() {    case "$1" in        *[02468]) return 0;;        *) return 1;;    esac;}

(If all the line breaks are gone from this code snippet, blame Lemmy. It looks fine here.)

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.)