91–95 of 95 posts
Earlier quoted context omitted.
This is becoming funny. I recommend this book for you, you should read it. I have: https://www.cambridge.org/core/books/term-rewriting-and-all-...
Funny indeed, that’s the first reference on the wiki article. shrugs
I wouldn't think so, because you don't seem to know the first thing about equational reasoning, namely that it is ALWAYS ABOUT EQUATIONS.
Oh, I’m huge on doing the opposite of this. When I write JS (not TS), I prefer as much as possible to use destructuring in every function definition. Named keyword arguments. Try to change the name of something as little as possible even as it gets passed around. It’s more powerful than a type system in some ways. Not always doable, but just try it sometime; it’s fun. I call it nominative programming.
function greet(greeting, name) {
return `${greeting} ${name}`
}
const greetWithGreetingHello = greet('hello')
greetWithGreetingHello('sally')
function greet({greeting, name}) {
...
}
const greetWithGreetingHello = greet({greeting: 'hello'})
greetWithGreetingHello({name: 'sally'})
greetWithGreetingHelloAndWith({name: 'sally'}).
"and with name sally"
Oh, I’m huge on doing the opposite of this. When I write JS (not TS), I prefer as much as possible to use destructuring in every function definition. Named keyword arguments. Try to change the name of something as little as possible even as it gets passed around. It’s more powerful than a type system in some ways. Not always doable, but just try it sometime; it’s fun. I call it nominative programming.
I feel like JS needs auto-currying. function greet(greeting, name) { return `${greeting} ${name}` } const greetWithGreetingHello = greet('hello') greetWithGreetingHello('sally') And this should work with named arguments too. function greet({greeting, name}) { ... } const greetWithGreetingHello = greet({greeting: 'hello'}) greetWithGreetingHello({name: 'sally'}) With named params, curried functions can be read more na…
A javascript object is like an S-expression if you squint. The subtree nesting is messier.
Tinkering with APL (Dyalog) gave me one of my most mind-bending programming moments. dismal ← 10⊥(⌈/10⊥⍣¯1⊢) This is the complete solution to addition in the framework of Dismal Arithmetic [1]. The pivotal idea there was the inverse of a function, and "trains". Until that moment of insight, I was fiddling about with dfns, which looks janky in comparison. dismal ← {10(⊤⍣¯1)⍵}∘{⌈/⍵}∘{10(⊥⍣¯1)⍵}⊢ ⍣¯1 is APL for "inverse…
>The pivotal idea there was the inverse of a function I was curious about this piece of unexplained cryptic code, so I did a little investigation to see what's going on. Unfortunately there aren't any revolutionary concepts here, just esoteric notation. I'll explain: To do that "dismal addition" thing, you need to split a number into digits and build a new number using the largest digit at each position. dismal(123,…
Oh, I’m huge on doing the opposite of this. When I write JS (not TS), I prefer as much as possible to use destructuring in every function definition. Named keyword arguments. Try to change the name of something as little as possible even as it gets passed around. It’s more powerful than a type system in some ways. Not always doable, but just try it sometime; it’s fun. I call it nominative programming.
I feel like JS needs auto-currying. function greet(greeting, name) { return `${greeting} ${name}` } const greetWithGreetingHello = greet('hello') greetWithGreetingHello('sally') And this should work with named arguments too. function greet({greeting, name}) { ... } const greetWithGreetingHello = greet({greeting: 'hello'}) greetWithGreetingHello({name: 'sally'}) With named params, curried functions can be read more na…