@screwtape Hey, I thought that today would be only a sound check, not the real interview... I am not prepared for the real interview! 😬😬😬

Can we postpone it? I will be super busy until may 20 - but I'll be have lots of time afterwards...

@eduardoochs @screwtape
Since it's now getting to be last-minute, to save screwtape's theme for today, it could just be about different things people mean by "types", laying the groundwork for whatever you have in mind later.

For instance, we could all roundly criticize "stringly typed"[1] 😉

[1] one of a zillion search results: https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed

@vnikolov

@dougmerritt @eduardoochs @screwtape

dougmerritt> we could all roundly criticize "stringly typed"

Yes, the latter is a far, far cry from (say) typed lambda calculus (among others).

By the way, note that lisp's eval does not take a string as its argument (unlike some other languages).

#Lisp
#StringlyTyped

@eduardoochs
oh, sorry for the confusion! We can have a soundcheck before the show and /no/ interview.

@vnikolov @dougmerritt
types sound good. One thing I find confusing in Sandewall's work is that his typing was "you /must/ set an entity's type in its plist and are encouraged to use it []" (and 'new types' are entities of type thingtype)

@vnikolov @dougmerritt
I guess you two remember I keep mentioning Goodwin 1981's Why Programming Environments Need Dynamic Types, in which Goodwin is basically suggesting lisp programmers to actively use DEFTYPE and TYPECASE (though at the time of writing, these were still congealing). Of course DEFCLASS and DEFSTRUCT implicitly DEFTYPE.

Goodwin, James W. "Why programming environments need dynamic data types." IEEE Transactions on Software Engineering 5 (1981): 451-457.

@eduardoochs

@vnikolov @dougmerritt
in languages that handle PARSE-INTEGERable strings /such as #javascript (#Kitten)/ is the equivalence (sometimes) of "1" and 1 an example of defeasible inheritance?
In that
c = a - b
if c is 2 and a is 3, b might be a positive integer 1, or it might be a string "1" in js. #programming #types #defeasibleInheritance

@eduardoochs

@screwtape @vnikolov @dougmerritt @eduardoochs I'm the classic "strong typing is for weak minds" guy, having done too much web dev, BASIC, REXX, shell scripts, etc. These let you trivially use strings as numbers, because user input is more important than "correctness" whatever that is.

If your focus is all careful math with units, then you want typing of some kind, but most of us code junky dialogues with users or real-world text files, so loose string handling is good.
#types #programming

But then Little Bobby Tables comes along…

Who has implemented “janky” as a type?

@mdhughes @screwtape @vnikolov @dougmerritt @eduardoochs

@clew @screwtape @vnikolov @dougmerritt @eduardoochs The REXX data type is anything: string, integer, floating point with potentially bignum precision, or stem (associative array, key/value can be anything, by convention(!) .0 is length of an indexed array).

It's incredibly liberating if you just want to solve problems. It's scary to type-safety people.
#programming #types

@screwtape @mdhughes @clew @dougmerritt @eduardoochs

screwtape> How often do numbers 281474976710656 or higher actually happen ;p

Depends on the domain.
The first example that comes to mind:
often enough if you calculate products of, say, 512-bit primes.

@screwtape @sektor @mdhughes @clew @eduardoochs @dougmerritt

> there is a countable infinity of them

Pedantically, if you ignore that memory isn't unlimited.

> tiny changes of 1+ ... the program's behaviour radically changes (bignum + not fixnum +).

I see now.
That is a different point and yes, we ought to be aware of such things.
I can't improvise a proper discussion right now, but also compare to reading memory addresses past the end of a CPU cache line.

@mdhughes
I finally got to the end of @smlckz ' article which I think captured some of our discussion here:

Static type checking shows that a program either is correct or else might be correct

and dynamic typing = testing shows that a bug either is present or else might be present.

@vnikolov @sektor @clew @eduardoochs @dougmerritt

@screwtape @smlckz @vnikolov @sektor @clew @eduardoochs @dougmerritt
Static checking can only show that the program passes types down consistently, it says nothing about the logic or correctness of the program itself.
function addints(int x, int y) : int { return 3; }
is "consistent" and "type-safe", it returns an integer. But it's not "correct" for anything except addints(1,2).

Unit tests will quickly expose that addints is incorrect, even if you remove all the types.
#programming #types

@mdhughes @screwtape @smlckz @sektor @clew @eduardoochs @dougmerritt

The point is not that static type checking is omnipotent: it isn't, of course.
The point is that it catches _very many_ mistakes that programmers are _prone_ to make.
I say again: mistakes that are _often_ made, not all that can be made _in principle_.

> function addints(int x, int y) : int { return 3; }

This is too trivial.
Warning: variable declared but never used.

#StaticChecks
#StaticTypeChecks
#StaticTyping

@vnikolov @screwtape @smlckz @sektor @clew @eduardoochs @dougmerritt
Anecdotal, but I almost never make the kinds of errors that type checking can find. I did make one a few weeks ago! I was very surprised, I'd passed an entirely wrong kind of object to a function. Once a year error. YMMV.

And yes, intentionally trivial example is trivial. Add
log("addints", x, y)
and now the type checker is a blind idiot again. You cannot make types enforce logic!