ktilcu

A palindromic number is a number that remains the same when it is reversed; that is to sayit is the same forwards and backwards. For example 14,541 and 252 are both palindromeswhile 54 and 123 are not. The aforementioned cases are all in decimal but it's possible for numbers that are not palindromic in base 10 to be palindromic in other bases.

17 for example is not palindromic in decimal but is palindromic when represented in binary: 100012.Another example is 16 which is not palindromic in decimal but is palindromic in base 3: 121₃.

Write a Python program determines the smallest base (greater than or equal to 2) in which the first 1000 positive decimal integers are palindromes. Please include unit tests for any function you write.

Here's example CSV output for the first 20 non-negative integers:

"decimal", "smallest base in which the number is a palindrome"
0, 2

ktilcu

During a recent discussion Nathan made 2 excellent points about partials:

1. partials can be unneeded.
2. partials can be opaque.

I would like to support those and add a bit of advice:

3. Avoid partials!

Un-needed _.partial

ktilcu

const readline = () => (Math.random()*10).toString(2); // setup

for(r=readline,x='',t=r(y=r(i=0));i<7;x+=t[i]|t[y],i++);print(x)

ktilcu

Build an identity Matrix for n columns and rows

Array(n).fill().map(_=>Array(n).fill(0)).map((v,i)=> {v[i%n]=1;return v.join``}).join`\n`

ktilcu

I was reading this article about why A/A is better than Promises and saw a few code examples stood out to me as being unfair. I am not saying A/A is not better, I just think we need to be a lot more explicit about why it's better. Read below and I will go through each section in the article.

Overall, I think the main benefit of A/A is readability for people who are not familiar with Promises. The problem is that in order to understand A/A at a useful depth, you have to understand promises. In my mind, we are just covering one problem with another and making YAA (yet another abstraction) that people have to understand in order to figure out async programming.

I think a post talking about how to do promises well would be much more useful than one that shows that new language features are better than bad code.

ktilcu

const makeRequest = () => {
  getJSON()
    .then(JSON.parse)
    .catch(console.log)
    .then(console.log)
}

ktilcu

const contextLogger = fn => ([...args]) => 
  fn
    .apply(null, args)
    .catch(err => {
      console.log({args, err});
      return Promise.reject(err);
    });

const makeRequest = () => {
  contextLogger(getJSON)() // weird i know but I'm doing this without curry.

ktilcu

const makeRequest = () => {
  getJSON()
    .catch(console.log)
    .then(JSON.parse)
    .catch(console.log)
    .then(console.log)
}

ktilcu

const makeRequest = () => getJSON()
    .then(data => data.needsAnotherRequest ? makeAnotherRequest(data) : data)

ktilcu

// Imperative A/A
const makeRequest = async () => {
  const data = await getJSON()
  if (data.needsAnotherRequest) {
    const moreData = await makeAnotherRequest(data);
    console.log(moreData)
    return data.concat(moreData); // added this

  } else {
    console.log(data)