Oriel Jutty :hhHHHAAAH:

@yogthos

Crane decided to ask his AI agent why it went through with its dastardly database deletion deed. […] So, the agent ‘knew’ it was in the wrong.

No, you asked the confabulation machine to confabulate a reason/excuse after the fact, and it confabulated something that looks like a reason/excuse. At no point was there knowledge or introspection.

“AI” has also successfully found security vulnerabilities that don’t exist.

C++: [](){}

Yes, it’s sent to posthog.

That’s not what the Github ticket says.

Debuggers don’t go back; you have to restart and run through the whole thing

Yes, they do: https://rr-project.org/

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Reverse-Execution.html

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

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

Isn’t that how B worked?

Similarly, Perl lets you say

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

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

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.